Hello to all. This is my first post on this channel.
My health system (Northwell Health) is in the process of converting our HIE data into FHIR. Our HIE maintains a hub-and-spoke architecture of our hospitals and ambulatory practices. The “hub” is our patient index and the “spokes” are individual hospitals/practices.
Current capabilities:
This model allows us to view the FULL aggregated patient record or PARTIAL by selecting specific hospital records to look at.
Demographics could conflict/change over time and we need to maintain clarity on each hospital’s demographics data for a patient.
As we transition to FHIR we want to maintain the above two capabilities. How would we design our FHIR resource architecture for patients?
Options:
Use a Person resource as the “golden record” version of the aggregated demographics and use Person.link to ALL relevant Patient resources with clinical data hanging off each of those?
Manage 1 “golden record” Patient resource ALONG WITH Patient.link (“replaces”) records with individual hospital demographics.
Clinical data will ALL be under the “formal” patient record with tags pointing to the source Patient record for filtering purposes.
Something else?
Would love to have a longer discussion (perhaps another medium) to get this group’s understanding of the pros, cons, and general challenges with this type of architecture.
I think the base question is “What sort of information do you have in your master-patient index?” If you don’t have Patient.contact, Patient.multiple[x] or Patient.generalPractitioner in your index, then Person will work. If not, you’ll need Patient. If you use Patient, I’d recommend “see-also” rather than “replaces”, as your index Patient definitely isn’t replacing the patients in the spoke systems.
If you do go with Patient, I’d still have the source data hanging off the source Patient resources. I don’t think you can count on systems paying any attention to tags.
“If you do go with Patient, I’d still have the source data hanging off the source Patient resources. I don’t think you can count on systems paying any attention to tags.”
Can you expand a bit on the implication of implementing this structure on the consumers of a patient’s data? Assuming most applications will be interested in the complete/composite record rather than an individual source, what would querying for Vital Signs look like?
If you query, either the central Person with sub-patient structure or the central Patient with sub-patient, you’ll get Observations, Conditions, etc. against the sub-Patient instances in both cases.
You could transform the data to all use a ‘central’ Patient instance, but that then loses the information about the context in which each set of clinical data exists. (You’d also break signatures, if those were present.)
The default behavior is that “see also” isn’t going to change search behavior. If you want that to happen, you’d have to embed a transformation layer in your interface. There’s no “automatic” behavior here - just differing system architectures that behave in different ways.
From FHIR’s perspective, we don’t care how your data is stored under the covers (or even if it’s represented as FHIR at all). If you want to surface all data as belonging to the MPI patient, you can do that. If you want to automatically include linked patient data, you can do that too - though some clients may find it unexpected and get confused.
