Composition mapping to FHIR

This is meant to be high level and a ‘fag packet’.
(I am looking at understanding COMPOSITION and making notes as I go along and based on the diagram from here EHR Information Model)

Any major issues?

Hi Kevin, thanks for sharing. Could you elaborate a bit more please, in what you’re trying to achieve.

It’s sometimes a bit hard to judge what’s coming from where. E.g. the “patient details” composition, where is that name defined and by whom?

My background is HL7 and trying to understand openEHR.

So I’m really try to map my current understanding to openEHR.

This might be a technical (and incorrect reply :slight_smile: ). I think openEHR has it’s own copy of patient_details, I’d assume this is sync’d with a PAS system via HL7 v2 (or openEHR can also act as a PAS)


There is an openEHR Demographics model which can be used to store PAS-type information and/or staff details but ? most openEHR implementers do not use this but just use an existing PAS/ Demo service, often via a FHIR wrapper.

For your purposes, I’d suggest largely keeping formal patient demographics out of scope - it is certainly not handled in an openEHR CDR - Care team info is, however, in scope

Thanks for making the effort to understand openehr. In my experience mappings like this are useful as a discussion starter. But since the perspective of the specs (‘exchange vs persistence’) and the scope of the models (e.g. openEHR COMPOSITION vs resource) is very different. It quickly will become confusing to understand openEHR from a FHIR mapping perspective. A suggestion would be to view it from a data instance (actual fake patient data) instead of abstractly comparing the models. At least for me that would make it easier to help. Does that make sense?

(Agree with Ian regarding demographics btw)

I’ve actually gone for a two phase map.

Phase 1 - Template → FHIR Questionnaire and then Composition → FHIR QuestionnaireResponse.

Phase 2 - Use FHIR SDC and in particular this Form Data Extraction - Structured Data Capture v3.0.0 as an approach mapping to other resources. Initial tests appear to this would work.

Have managed a round trip from openEHR to FHIR to FHIR SDC and back to openEHR

And using the PARTY_PROXY.external_ref field that is inherited into PARTY_SELF, PARTY_IDENTIFIED etc.

1 Like

Spoke with @ian.mcnicoll yesterday.

In my FHIR conversion, I’m trying to get two conversions which:

  • Is used to build a UI for capturing the data (it resembles how templates are displayed in CKM)
  • Can be used to render Composition in a UI
  • Has mapping metadata for conversion between HL7 standards and also mini LOINC/SNOMED maps (we can add in more complex conversions using FHIR StructureMap - FHIR v4.0.1) - I think some of this might be useful to add to openEHR Template model.
  • Can be used to pre-populate openEHR Composition (from external sources)
  • Can be used to extract openEHR Composition into FHIR resources (Sharing option A - Decomposed))
  • QuestionnaireResponse can be used to share openEHR Composition with non openEHR users (Sharing option B - Not decomposed). As this is a more basic format and aimed at rendering, it might be easier to convert to PDF (Sharing option C)

The rough pattern is based on IHE SDC

and so is also following

This might also serve as a bridge between openEHR and LOINC Panels Panels and Forms – LOINC
which I’m presuming are often implemented at HL7 v2 ORU.

LOINC exposes these panels via a FHIR Server LOINC Terminology Service using HL7® FHIR® – LOINC

I think it’s possible for CKM to do similar and expose openEHR definitions and terminology as
FHIR CodeSystem, ValueSet and Questionnaire

Main reason for doing this is to allow developers (well me at least) to compare apples with apples.

This probably has overlaps with Introducing FHIR Connect
I was using Betters One London UCP as a use case, but wasn’t aware of fhir connect.

Main difference is I’m seeing a FHIR conversion which is more like Composition (FHIR QuestionnaireResponse). FHIR QuestionnaireResponse can be mapped to other FHIR resources if the end system desires so. (Converting to a FHIR Bundle with many resources may be unnecessary, especially if the recipient doesn’t have a FHIR Server)

You might find this useful … Using the openEHR Template Designer to create Clinical Document Definitions - #4 by linforest

I shuddered when I read CDA :slight_smile:

Don’t quote me but is some talk of CDA and FHIR Documents being a dead end.

My view is if QuestionnaireResponse or even PDF gets the data shared… why bring in other formats?
This is really a question rather than a statement.

If you are interested in the template → questionnaire way take a look at this