Hi, Sebastian,
You are absolutely right. But as I mention, we have another service of a master patient index not included in the design where subjectID and EHRID are registered, so there is no need to provide the EHRID in the TDD. The master patient index service auto routes the TDD to create the composition in the right EHR basing on the SubjectID in the TDD.
If a subject has more that two EHR IDs, well there is a process of merging/harmonising the two but I have not yet encountered this.
Thanks Michael, that does help explain your approach.
I thinkj the problem may be that PARTY_REF is unsupported by FLAT_JSON (and PARTY_SELF does not have an external_ref). However PARTY_IDENTIFIED does work.
<subject xsi:type="PARTY_IDENTIFIED">
<external_ref>
<id xsi:type="GENERIC_ID">
<value>179</value>
<scheme>scheme</scheme>
</id>
<namespace>namespace</namespace>
<type>ANY</type>
</external_ref>
<name>Ian King</name>
</subject>
"annual_review/blood_pressure/subject|id": "179",
"annual_review/blood_pressure/subject|id_scheme": "scheme",
"annual_review/blood_pressure/subject|id_namespace": "namespace",
"annual_review/blood_pressure/subject|name": "Ian King",
Having said all that, I’d be strongly suggesting that you do not mix up different EHR subjects in the same composition - that is definitely ‘off-label’ behaviour for openEHR and might come back to bite you!!
1 Like
Hi Ian,
I am glad I made the clarifications.
About having same EHR subjects in the same composition, no, that is something I have not yet encountered. At least steps have been taken to ensure every composition is created in the right EHR of the composition owner.
Unfortunately I have retried the above you used but still nothing about the subject on FLAT_JSON.
And I cannot have Subject details i.e name or actual HIS ID in the openEHR CDR. These are details rather on the mpi service. I am not sure but guessing that this could be one of the reasons the “PARTY_IDENTIFIED” is not working for me.
<subject type="PARTY_IDENTIFIED">
<external_ref>
<id>
<value>dWjspnQmmRU6nguc9n2EFp</value>
<scheme>PATIENT</scheme>
<_type>GENERIC_ID</_type>
</id>
<namespace>1.2.2.3.4.5.6.7.8.9.200</namespace>
<type>ANY</type>
</external_ref>
</subject>
Hi Michael,
I’m even more confused now!! Where are you expecting the subject details to appear in the FLAT JSON ? - For each Lab test entry or one for the whole composition?
and if all of the tests in the composition refer to the same patient, why do you need to recored them there at all, since the subject of the composition can always be inferred?
I would just add a dummy name e.g. ‘-’ and you can make the external_ref anything you wish - it does not have to be a HIS ID.
Hi Ian,
I am sorry this is going on.
So here is what is happening. compositions are created correctly in the repository; to the right Subject, EHR etc.
This data now needs to be mapped to FHIR for inter-exchange, and I am utilising a 3rd party application which requires FLAT_JSON format. But on my side a FLAT_JSON openEHR request produces content with no Patient information (ID). So, I cannot really proceed to map an openEHR composition to a FHIR profile especially if there is not subject identifier in it . Adding dummy or not cannot solve the issue as in the end by policy “here” patient demographics are not to be stored in the repository except an ID.
Ah- got it now!! If the third-party app expects FLAT_JSON, it must be openEHR-aware there must surely be away of passing through the ehrID (to be resolved externally to a FHIR subjectId?
1 Like
Yes, that is starting to make sense. How the resolving to get the Subject ID will work I have no idea yet, but this makes sense now. Enabling the metadata (true) exposed the EHRID. which is step towards solving my many issues with process. Thanks a lot Ian for the help 