How does openEHR handle linking of multiple EHR ids which are generated for the same patient?
Ideally, we would like to have 1 EHR id per patient, but sometimes a temporary EHR ID may have to be generated for things like emergency care. Administrative errors are also another reason why this might happen.
How does one handle merging/linking EHR ids in an openEHR data repository (like EHRBase / EHRServer)?
Maybe the different original ids could be put in the EHR_STATUS information, and if you need just let the platform assign a new uuid for your patients
These are understood as admin functions - merge and de-merge, that would be included in a service like this (not there yet).
To support that, you have to use a service such as EHR Index (also draft) or e.g. an IHE service to maintain the EHR id x subject id (i.e. patient id) relationships. This can be a NxN relationship, due to various factors, including the error same patient being giving 2 EHRs (an annoying error), 2 patients having data put in the same EHR (a dangerous error).
All of this presumes that you will not put subject ids (i.e. patient ids) into the EHRs directly, which is a common option in openEHR.
I am not sure what a ātemporary EHR IDā is - an EHR id in openEHR is just a GUID. You might have temporary patient ids, but the above arrangement will take care of that.
Are multiple subject IDs allowed in the EHR_STATUS? Itād be great if I can query the patient by multiple hospital IDs and still get the same EHR.
{
"_type": "EHR_STATUS",
"archetype_node_id": "openEHR-EHR-EHR_STATUS.generic.v1",
"name": {
"value": "EHR Status"
},
"subject": {
"external_ref": {
"id": {
"_type": "GENERIC_ID",
"value": "ins01",
"scheme": "id_scheme"
},
"namespace": "examples",
"type": "PERSON"
}
},
"is_modifiable": true,
"is_queryable": true
}
I am using the subject Id (hospital number) in the EHR. In case of emergency care, the patient identification will take some time, so we usually assign a temporary hospital ID (subject ID). Iām trying to see how to go about doing it using openEHR. Itās common to have multiple patient records associated with the same patient. So which EHR should the new data be added to?
And until the Admin Service becomes more mature and gets implemented by EHRBase, should compositions just be recommitted to the same EHR ID manually?
It has an other_details attribute where you could put that
I think subject ID would be the correct way, but at the moment it is limited to one instance. I think there is no good reason for this limitation and we should create a CR to fix this.
In EHRbase, separating and merging EHRs is not supported yet as a backend service. This is on the roadmap though and should become available later next year.
This is best managed in the demographics of the patient. You could allow multiple IDs for the patient all linked to the same personUuid and use that to create the ehrId.
That way you can assign temporary id to start with and later assign actual hospital id and still ensure that the ehr points to the same
Regards
I do not think merging of ehrs are described as part of openEHR specs and in fact it may never be.
It will probably ramain implementation specific. In fact it may beat be handled as a db function of finding and replacing one ehrid with another one.
It is good to hear that ehrbase has it in their roadmap.
Regards
Iāve always seen that as the āsource of truthā (i.e. The real subject as identifier on the system). Other ids (e.g. national ones) would be stored in the other details. Maybe the same could be used for legacy identifiers
That is exactly the purpose of the EHR Index service, or equivalently IHE PIX service - but to be able to do this, you canāt use the simple option of putting the / a subject-id inside the EHR. It has to be a separate location. Logically, it can be a very simple table, with columns such as:
You would normally want to index on at least the first two columns.
It is not a complex thing to agree on at least a simple version of the above and document that in openEHR, such that it can be implemented e.g. in EhrBase etc. I think adding multiple subject ids directly to EHRs will only cause problems.
This would not be the case with an openEHR system. Separate EHRs causes all kinds of problems - where does the master problem list go? Medications list? Allergies? Patient preferences?
This is what we have tried to do in EHR.Network. All the external IDs including the hospital IDs are mapped to the subject_id in the demographic service. This subject_id is in turn linked to the ehr_id. This ensures that we are able to maintain one unique ehr_id for a person.
However the merging of ehr_ids when multiple ones have been created accidentally is a more complex problem. For the sake of clinical accuracy and audit, this will need a workflow and decisions outside the EHR system to validate and document this change before actually doing it within the system. The actual process of merge is implementation specific as it may involve changes to multiple services such as EHR index, EHR and possibly other services that support the clinical application.
Where I used the term subject_id, I just mean any of those external ids. I think you are using subject_id as the reliable id of a single master instance of a patientās entry in the demographics system. In that case, your EHR index service DB table needs to be:
Yes, true - but my knowledge of real hospital systems and contexts tells me that itās hard (maybe impossible) to escape 100% from this. There always has to be this merge / demerge function in the system.
Our (company Better) EHR Server has an administration function to merge EHRs. It physically moves all compositions from one EHR to another, but keeps a note of that in case the operation needs to be undone due to an error (āunmergeā). I find this to be quite an elegant and definitely a totally transparent solution, but I donāt think it needs to be standardised.