How to model and store reports that belong to multiple clients?

Clinical Clinically Relevant RM Discussions
1

Hello openEHR community,

We are currently working on several use cases where we need to record information that is relevant to multiple subjects, EHRs, or groups of people. While openEHR provides clear mechanisms for recording information within a single EHR, we are struggling to find a clean and interoperable approach for information that naturally spans multiple records.

We would be interested to hear how others have solved these problems in practice, and whether there are ongoing discussions or plans within openEHR to better support such scenarios.

Use cases

Family care

A care professional has a group conversation involving:

  • Two children, both of whom are receiving care and therefore each have their own EHR.

  • Two parents, who may or may not have their own EHR.

Examples:

  • A report about the family conversation that should be available in both children’s records.

  • A report concerning the father that should be visible in both children’s records.

Residential groups

A care professional wants to record:

  • A general report about events, observations, or activities affecting the entire residential group.

  • Separate client-specific reports for individual residents.

Day activities / day care

A care professional wants to record:

  • A general report about what happened during a day of activities.

  • Separate client-specific reports for individual participants.

Potential approaches we have considered

1. Using PARTICIPATION for people without their own EHR

For individuals who do not have an EHR, it seems possible to represent their involvement using PARTICIPATION entries within the EVENT_CONTEXT.

This appears relatively straightforward.

2. Carbon copies across multiple EHRs

Store the same report separately in each relevant EHR, with a shared identifier indicating that they originated from the same source report.

Advantages:

  • Fits within the current openEHR model.

Challenges:

  • Deduplication in reporting and querying.

  • Updates become difficult: if the report is corrected or amended, the changes need to be propagated to all copies.

  • Potential risk of divergence between copies.

3. One report linked to multiple EHRs

Store the report only once but associate it with multiple EHRs simultaneously.

Advantages:

  • Single source of truth.

  • Easier maintenance and versioning.

Challenges:

  • Complex access control and authorization requirements.

  • We do not see a way to model this within the current openEHR EHR structure.

4. Group EHR / Group record

Create a separate EHR for a family, residential group, or activity group and store shared reports there.

Advantages:

  • Clear separation between shared and individual information.

Challenges:

  • Unclear legal ownership and governance.

  • Unclear whether this aligns with current openEHR concepts and best practices.

  • Difficult to manage changing group compositions. For example:

    • Child 1 + Child 2 + Father + Mother

    • Child 1 + Child 2 + Father

    • Child 2 + Father + Mother

  • It is unclear whether a new group EHR would need to be created for every variation in membership, or how shared information should be handled when group membership changes.

Questions

  1. Have others encountered similar requirements?

  2. How have you implemented these scenarios in production systems?

  3. Are there recommended openEHR modelling patterns for information that belongs to multiple subjects or EHRs?

  4. Do you think there is a gap in the current specifications that would justify future extensions or changes to better support these use cases?

Any experiences, references, or examples would be greatly appreciated.

Thank you!

2

1 makes sense for some simpler use cases but 2 3 and 4 are not really feasible with the current rm.

We faced a different use case which was a public health incident which may not always or ever be associated with a single individual . However the rest of the openehr documents tree worked very well. We considered i producing the idea of DOSSIER object. Basically identical to an EHR but explicitly not having a subject. It has been discussed at SEC. We had another use recently for molecular tumour board meetings who look at a set of genomic lab results for multiple patients. That is being implemented as a DOSSIER by using a explicitly labelled EHR object. I woukd prefer that this a true artefact and indeed managed in a separate cdr or cdr domain .

@joostholslag @David-Jobling