Hi! Apologies for the naive question but was wondering for those who have implemented openEHR as a data model for your database how did you go about storing demographic data? Was it done in a separate database, the same one?
Thanks
Dan
The most common answer to this is that demographic data are already represented in an existing MPI (master patient index) or similar registry system, either in the local environment or at some state or national level, and the openEHR EHRs just reference it.
A more advanced system would convert snapshots of that MPI data to openEHR format, and store it in a dedicated demographic cache DB, still separate from the EHR DB, for privacy reasons. The EHR data in this architecture would now reference the openEHR demographic data. This approach allows you to a) archetype the demographic data in the cache and b) version the changing data from the MPI (which is almost never versioned properly).
openEHR can also be used as the primary representation of the demographic data of course, but I don’t know if this has been done in practice.
1 Like
There are just a few openEHR implementations using the openEHR RM-Demographic package. At Code24 we do this also. For all our customers, for more than 6 years now, we actively use demographic instances (data) based on archetypes on PERSON, GROUP, ORGANISATION, AGENT and their relationships. We do this with success for a lot of process and purpose, like Patient administration, Care team and caseload, planning and scheduling, Patient’s social contacts (network), Referrals, FHIR API, etc.
Technically, our demographic data resides in a separate database (not inside the EHR), yet it still versioned and archetyped like the other EHR content. We use same backend workflow and principles, same tooling as for the other openEHR RM data. One of the difference is that data there is not ‘bounded’ anymore to a single EHR, but relates to the whole system (collections of EHRs). Like Thomas mentioned above, we use something similar to a MPI to ‘connect’ those demographic instances to EHRs.
But if I’m not mistaken, the most common pattern among real life openEHR CDRs is (as mentioned above) to store some of patient-context data in the EHR (gender, age, etc.), as perhaps ADMIN_ENTRY, and via a MPI and EHR_STATUS.subject connect it to an external Demographic system, most likely a non-openEHR system, due to requirement to connect to a local or national registry system.
3 Likes