Stream: implementers
Topic: Writing data to a FHIR server
Theoharis Nalmpantidis (May 22 2019 at 20:48):
(deleted)
Mohannad Hammadeh (May 22 2019 at 22:04):
What is the expected workflow for an application that wants to write data to a FHIR server, specifically when it comes to figuring out what the patient reference should be in the resource being submitted?
For example, if we have an EHR application that wants to submit patient observations to an HIE's FHIR endpoint as they get added into the EHR. The EHR application has its own representation of the patient (local patient identifier) and the HIE could have its own representation of the patient as well as that of its participants.
When the EHR application wants to submit an observation resource to the HIE, that resource needs to be associated with a patient and the patient reference must be included in the appropriate field. How does the EHR determine what to include in the reference field? Is the EHR expected to query the HIE first to check for the patient and get the patient reference before submitting the observations? Or is there a way where if the EHR assumes that the patient is already in the HIE, the EHR can send the observation sans the patient reference but including their representation of the patient (somehow) so the HIE can match the patient and incorporate the observations?
Michele Mottini (May 22 2019 at 23:02):
In our system (that is used by HIEs) the EHR would POST a transaction with a Patient resource + the resources to be associated with it
The Patient resource should contain all the demographic data available in the EHR - that then will be used to do patient matching
Michele Mottini (May 22 2019 at 23:04):
Having the EHR query first is probably not a good idea - FHIR searches are not a good substitute for patient matching
John Moehrke (May 23 2019 at 12:37):
I would expect the app to use patient searches to first determine the Patient. Expecting this to happen when you submit the data is leaving it up to fail late, and possibly attach the wrong Patient identity. To support this, I would expect the HIE to have patient lookup services that address matching. Getting exactly one match is important, and confirming the results you get are agreeable to you is also important. Leaving it up to the server side alone can miss a false-positive.
Mohannad Hammadeh (May 23 2019 at 21:40):
Thanks @John Moehrke , is this assuming that there is a person driving each interaction between the EHR and the HIE? Would you expect it to work the same way if the data that is being submitted to the HIE is done in the background?
Mohannad Hammadeh (May 23 2019 at 21:42):
Thanks @Michele Mottini , I had a similar thought but I wasnt sure if there was a pattern already in place that other implementers have adopted. How do you handle the issues that @John Moehrke highlighted?
John Moehrke (May 23 2019 at 22:01):
If it is automated then the lookup response that is not a single entry can't be used. Thus if more than one entry is returned then the automated process can/t proceed without some intervention. Regardless of method done for patient identity matching... right?
Michele Mottini (May 24 2019 at 02:38):
The submitted Patient is compared with the existing ones and merged with the one(s) that match. If none match a new record is created
Michele Mottini (May 24 2019 at 02:40):
Note that there _can_ be multiple matches - resulting in the merging of multiple existing patients
Last updated: Apr 12 2022 at 19:14 UTC
