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.

[Haritha_Tadikon]

Was your issue resolved? We are encountering a similar issue.

[Marek_Aksamit]

@Joe Bunch was your issue resolved?

[Joe_Bunch]

No, still have an open ticket. They have logs, but no confirmation of issue or resolution ideas yet. 

[Mark_J_Baker]

@Joe Bunch - Curious, do you have an SIU feed into OnBase for Appointments? The FHIR call will not trigger an ADT event itself, but if a document was created in Epic (DCS record exists?) you might get this ADT feed from the T08 message if you have the bi-directional scan maintenance configured in your Epic environment.