FHIR Scan Call Methodology Question

[Joe_Bunch]

So from the looks of the FHIR logs, when scanning an Appointment document, it calls things in a chained methodology...

aka APPT FHIR called, returns CSN, calls Encounter FHIR, which returns Patient, which in turn calls Patient FHIR...

But if it breaks in that chain (with a FATAL error : [FATAL] The FHIR ID provided was not found)... it still stores the document, at least in our system it does.

So we have a document with only APPT information on it (CSN).

Then ADT needs to hit to fill in the rest of the keywords, esp in this scenario as the CSN didnt exist in OnBase yet (which I believe would autofill immediately if it was).

Is it normal for the document to be stored in Epic/OnBase when a secondary FHIR call gets a FATAL error vs the primary?

I have a support ticket in for this scenario... just curious if I can get it answered quicker via the forums.

[Joe_Bunch]

we do not have an SIU feed, but have the bi-directional. But what I am really trying to determine is why if what I am guessing is the method of getting info from epic fails at any point, the storage is still allowed, unless designed to be that way. We get blank keyworded documents and from what I can tell it is because subsequent calls fail, not the primary call.

[CurtisFox]

Hi @Joe - The process is that we attempt to store the document in OnBase before attempting to link the document in Epic via the FHIR APIs. The document will be in OnBase at that point, which is expected behavior. We do not go back and automatically delete the document from OnBase if the FHIR API calls to link the document in Epic fail for some reason. I know that doesn't address the root cause of whatever is causing the link to fail in the first place, but hopefully that answers your question about the expected behavior in that scenario.

EDIT: Corrected a confusing typo in my first sentence.

[Ryan_Wakefield]

Hey Curtis,

If the attachment to Epic fails, is there a way to know this in OnBase so that a normal HL7 message can be sent to Epic to attempt the attachment the old fashioned way?!

Thanks!

[CurtisFox]

Hello @Ryan - there is not a way to accomplish that at this time. OnBase doesn't track whether or not documents are linked in Epic, therefore we would have no way to denote whether a link failed/succeeded at this time. That could be a future enhancement. However, that should not be happening, and the root cause should be addressed in order to ensure documents are linking correctly.

[Ryan_Wakefield]

I don't disagree with you Curtis. However, there is always the possibility of this happening especially due to the bugs that I discovered and are currently fixed. Unfortunately, we are still dealing with one outlying bug that we just can't seem to pinpoint the issue.