Exploring the Use of openEHR for Integrating Patient Health Records Across Multiple Systems

[erik.sundvall]

Hi!

After the openEHR SEC REST working group meeting yesterday I’d like to revive this thread. We discussed at least two use cases likely similar to the one @badsmith describes:

1. In the RCC organisatiation’s INCA system in Sweden they have an openEHR CDR where they want to aggregate openEHR Compositions replicated from several different openEHR source systems. Even for the same patient the compositions can come from different sytems with different system-IDs since cancer care in Sweden is distributed and many cancer patients get some specialized treatments at another provider than in their home region. In this use case there are links between openEHR ACTIVITY instances in INSTRUCTIONs (e.g. parts of chemotherapy medication orders) and ACTIONS (e.g. chemotherapy administrations) in the future there may be other kinds of links too. Thus it would be deisrable to keep the identities of COMPOSITIONs and other VERSIONED_OBJECTs form the source system when importing data to the national INCA CDR. This means there will be a mix of system_id in the composition identifiers. (@robahs at RCC might add more info later)
2. @sebastian.iancu described another use case in the Netherlands where they want to aggregate data (selected COMPOSITIONS?) from several different CDRs to a central CDR, Sebastian can describe further in a separate post.

As @pablo reminds in two related threads, this is exactly what openEHR’s IMPORTED_VERSION described in e.g. chapter 6 of Common Information Model was intended for as designed by @thomas.beale and others a long time ago:

@pablo

Then another question would be: do you want to maintain the reference to the originating system or do you want to start from scratch? openEHR has this IMPORTED_VERSION class that allows to have a reference the data in the original system, though if it wont really be used you can just create all the data as new ORIGINAL_VERSION.

REST API for creating compositions with id

I think this is a case for the IMPORTED_VERSION class (Common Information Model) which I don’t think is well supported by the current API, at least there are no clear use cases for it. Though I don’t have strong opinions, I think this use cases shouldn’t be part of the normal clinical flows API, but of an administrative API, because the use case is importing documents from another CDR, which is an administrative task, not directly related with the health care process.

As @pablo says above, we don’t know how well supported IMPORTED_VERSION is in systems, it would be very helpful if somebody from each openEHR supplier could mention current status, previous experiences and maybe future plans about support for this, for example:

• @Seref mentioned that @chunlan.ma from Ocean Health systems might have some experiences from a system that used IMPORTED_VERSION
• @thomas.beale what are Graphite’s thoughts regarding this?
• @Bostjan_Lah or others from Better do you support or plan to support this?
• @vidi42 or @birger.haarbrandt or others from EHRbase/Vitasystems do you support or plan to support this?
• @bna are there experiences about this at DIPS?
• Are there others that have implemented this (or plan to)?

When we know a bit more about this it would be interesting to discuss what the alternatives are regarding modifying/extending openEHR’s REST interfaces etc to accomodate for generating IMPORTED_VERSIONs when recieving COMPOSITIONs and other VERSIONED_OBJECTs from external systems that have different system-ids.

Readers not familiar with IMPORTED _VERSION etc will find things like the figures below in Common Information Model