How to use a FHIR Patient instance as an external reference for the subject?
The namespace and id/value are taken from an example FHIR Patient . When using the EHRBase server, and if the MDM is a HAPI FHIR server with the BaseURL " http://hapi.fhir.org/baseR4", then how to properly represent the external reference and configure the MDM server’s settings such as its BaseURL. And any examples on the Internet such as GiuHub? Many thanks.
Are you sure you need/want a pointer from the EHR.subject to a FHIR Patient instance rather than the other way around? We instead add the openEHR EHR.ehr_id as an identifier inside the FHIR Patient resource.
(We also identify the EHR system the ehr_id belongs to, in case we would need to point to different ehr_ids of the Patient in different CDRs for different purposes, e.g. any separate research EHR pseudonymised with different ehr_id for the patient.)
How have others done linking in the combo of openEHR EHRs and FHIR Patient resources?
I am aware of 2 approaches used in the UK, both of which put the patient ‘external id’ in subject.
Store the FHIR Patient id in the ehrStatus.subject, and keep the ‘national identifier’ (NHS Number) in the FHIR Patient.identifier. This requires a 2 stage process to hook up the NHS Number to the ehrId - reterive the Patient.id via Patient.identifier (NHS Number) , then retrieve the ehrId via the ehr_status.subject. external_ref.value (which will be the Patient.id
The advantage is that the NHS number does not appear in the EHR at all
Store the NHS Number directly in the ehr_status.subject. Obviously simpler with a a stage look up, if the NHS number is known. It seems be working well in production.
One more opinion on that: In our commercial product (HIP CDR) we also store the openEHR EHR uuid as identifier in the FHIR Patient resource and we don’t populate the external subject ID in EHRbase.
Not having identifiers in the CDR was preferred here as being a better way to pseudnoymise the EHR content (e.g. in research use cases). For many applications this will of course require a lookup call to the Patient resource first, but that is often needed anyway by applications to get patient name, age etc and then you can get the ehr_id in the same call.
Thanks, @birger.haarbrandt and @erik.sundvall.
In addition, IMO, such good/best practices and patterns above shared by experienced experts should be extracted and incorporated into the relevant sections of the relevant specs to maximize the benefits.