Linking multiple compositions with a "compound composition"

[HHeiser (Hendrik Heiser)]

Hello Community,

My company is thinking about how to best connect multiple compositions that are used within the same context (e.g. a single visit or a status report). Using a single large template for all datapoints is not possible for us for this use case.

As mentioned in this thread, we tried out folders, but are not convinced that this is the optimal solution. Specifically, we found no way to get the folders that a composition is part of (and even if we did, it would be a list of IDs that would somehow have to be indexed to find the folder corresponding to the correct context), and we found no way to attach metadata to contained compositions.

Another option may be openEHR tags, although they may suffer from similar problems as folders (as these tags have no direct connection to the referenced compositions). Also, the implementation status is a bit unclear, since they are part of the specs, but not included in a RM release yet (according to the Amendment Record)

Then, we encountered the “compound document” that Better is using (and automatically generating) when submitting multiple compositions within the same contribution, e.g. via their Form Builder. This compound document is a nearly empty “wrapper” composition that only contains the EHR_URIs to the compositions that are part of that contribution.

We would adapt this idea and create a “compound composition” template, whose compositions can be queried and fetched like any other composition, and linked compositions can be resolved in a second request. In addition, metadata for the linked compositions (name, author, creation date…) can be persisted in the compound composition for a high-level overview.

We would be interested in what the community thinks about this approach, and if people have encountered this use case and solved it in a similar or different fashion. Did we make any mistake in our assessments, or missed something?

Thanks for your input!

[pablo (Pablo Pazos)]

Hi, in this case I think LINK applies if you want to associate compositions without creating a new object.

Though there is a use case for automatically generated composition content, for instance if a committed compo has a medication prescription, you might want to add that to the persistent “medication list” automatically (without a person doing also that commit). Though that’s a (nice) technical solution not part if the specs.

Both things are valid and sometimes really needed.

[SevKohler (Severin Kohler)]

Not sure about compound compositions.

We do two things,

1. label the data of a study with tag (study=coolStudy).

2. We use Cluster Archetype: Case identification [openEHR Clinical Knowledge Manager] in the other_context of each composition here we enter the case id (which also the case has itself) + we plan to use LINKS to the case (german: Fall ) composition in the future.
   This way we link via ID + links.

[sebastian.iancu]

We encountered similar problems when we tried to implement the Episode concept, or Careplan “holding” several compositions of various type. Tried folders and get them working decently, although it comes to is complex logic and coding.
With RM 1.1 this is simpler because EHR may have ad-hoc FOLDERs and FOLDERs have other_details attribute which can carry metadata (archetyped). But that might be still seen as complex. Lack of (standard) support in AQL folder is also not helping there.

Probably the best you can do with solutions nowadays is to use those compound compositions. The main disadvantage might be that what operation you described with contribution and compound-composition is a vendor-feature, and might not be available outside of that openEHR implementation.

[joostholslag]

To me it depends on whether there’s ‘serious’ data about real world events in the ‘compound composition’.
If not folders are the way to group compositions, and allow for some archetypeing.
Feature wise there’s big overlap imho.
Your reason for not using folders seems like a shortcoming of the implementation you use. Off course this could be a pragmatic reason not to use them, but that’s a little less interesting to the debate from my perspective.

I don’t like clusters with identification numbers, nor tags. I think it should be properly structured. (Again for pragmatic reasons off course, go ahead). Probably just a personal preference.

In a recent project I did around care planning I did something very similar as your compound compositions. I created a ‘master care plan’ ‘index composition’ that linked and structured all the individual problem oriented care plan compositions using archetyped dv_ehr_uri s. Which would link to individual care plan compositions. One key thing is the links are structured and have meaning: e.g. classification, ordering, grouping annotation etc. to me this curation warrants a composition to record those.

Now each individual care plan would have progress notes report compositions associated with it. Often called an ‘episode’ (carefull, overloaded term). I think folders is a nice way to model those. Because there’s little individual meaning in the links to the report compositions and the care plan composition. And there’s little data to be recorded about the grouping itself.

[linforest (Forest)]

Here (cn), a typical health checkup report would usually include many reports from different departments such.as lab, radiology, ultrasound, ecg, internal medicine, surgery and so on.

[joostholslag]

Are those reports separate compositions or entries in one composition? If they are separate compositions how are they linked together? Which openehr structure do you use for that?

[linforest (Forest)]

They are just actual report pratice here. But I don’t have much product experience on this although I did some exercises on such reports and treated them as sections in a single report composition.

[ian.mcnicoll]

There are a couple of uses for this kind of ‘compound document’

1. Where a single UI e.g. a single form interacts with several compositions as part of an encounter. These would be submitted via a Contribution *standard openEHR) but there may be a need to have a ‘primary/parent composition’. I know that Better use this approach to facilitate multiple compositions per-form. Nevertheless the enclosed compositions are still what we would regard a s normal compositions

2. As I understand it, CISTEC are experimenting with an approach that allows the creation of much more dynamic compositions. e,g allowing end-users to define their own datasets but based on pre-constrained components and with out the burden of having to maintain multiple templates.

So the idea is to break down e.g a typical discharge summary report into chunks roughly Section or Entry size, but for each of these to be managed as a whole composition, rather than as a section. So rather than a discharge report document being a simple composiotn, it is constructed from multiple compositions, where the end-users can define their own UI against those stands composition templates without any need to do their own templating.

The issue then is how to re-capture the notion of an overall composer/ start_time etc with a ‘master composition’.

I know that there have been several efforts in the past to allow some sort of dynamically constructed templates but it is hard to see how that can work without creating, essentially a template per composition variant at run-time.

It is an approach that might be very useful e.g. in Cancer care where there is some basic commonality for care planning across all cancer types but also wide variability in the depths.

To me it depends on whether there’s ‘serious’ data about real world events in the ‘compound composition’.

Absolutely yes, this is information that would ‘normally’ be part of a single data collection experience and we might normally think of it as being a single composition/ template but where it might b helpful to split the data into multiple templates/compositions to allow much more flexibility.

[bna (Bjørn Næss)]

This is a highly appreciated topic..

The problems which @ian.mcnicoll describe are met on a daily basis for most modelling domains. We are working with hospitals where there will be different workflows collecting data which should be summarized as one. The admission note for a acute ward or the more generic outpatient clinics might be a potential explosion in modelled datasets.

We’ve not found an optimal solution.

I would like to see an adoption of smaller and well defined components (templates, forms and stored AQL) which can be connected into a whole.

Such approaches will impact how clinical modelling is done. Currently I see a pattern with large composition templates. I would like to see more reusable templates with the potential of adding them dynamically Into a composition.

Another hard problem is how to combine persistent and event based data in data capture. It’s often hard for users in advanced care setting to tell who is responsible for the persistent data. There is a need for some rules and workflow to cope with this.

Health informatics is a hard domain…

[Seref (Seref Arikan)]

@HHeiser

Then, we encountered the “compound document” that Better is using (and automatically generating) when submitting multiple compositions within the same contribution, e.g. via their Form Builder. This compound document is a nearly empty “wrapper” composition that only contains the EHR_URIs to the compositions that are part of that contribution.

That’s a bit confusing to me @HHeiser I can understand the idea of a meta-composition (or an index-composition) but the semantics of a contribution is not at the same level of abstraction: that’s a logical change set, closer to data semantics than clinical semantics.

There may be a special case in time when a contribution has a one to one mapping to a clinically meaningful set of compositions but that special case won’t hold all the time. There’s probably more depth to what you’re describing than I can see, but I’d suggest leaving the contribution out of the effort to define a logically associated set of compositions.

Happy to be educated about the above.

[joostholslag]

I’ve always seen the contribution as a logical clinical change set, less so a physical technical one. I still read it that way from the CIM spec:
“ …committed to a repository as a Contribution. For example during a patient encounter, the following might occur:

• addition: a new Composition is created recording the Observations (e.g. physical examination), etc that are made during the Encounter;
• modification: the Composition containing the current medications list is updated, due to a prescription being given during the encounter.

These two changes together constitute a logical change-set, and would typically be included in the one Contribution. In general, there might be any combination of the logical change types in a single commit by an application, corresponding to a single real-world business event, such as a GP Encounter”

I would like to be able to use the contribution as a way to find all changes from a single clinical session. Especially to understand why some changes was made, e.g. an addition to the problem list composition can be understood because the contribution also contains an encounter composition detailing observations and evaluations that sustain the diagnosis.

[ian.mcnicoll]

I think agree here @Joost. I agree with @Seref that Contribution acts as logical changeset and not every Contribution will reflect a clinically-driven changeset i.e we used Contributions when committing imported data in London, however, I did then struggle to think of a situation where a clinical activity that required the committal of multiple compositions, would not require a Contribution.

So I guess one of the questions is whether at least some of these clinical ‘linked commits’ merit some kind of ‘meta composition’ to capture the overarching clinical context , composer etc, or tot act as a link point into the UI, which I suspect was the requirement for Better.

The other thing that does emerge is that we do not have an easy way to define the event/persistence behaviour that should apply to the commit of each composition.

The underlying issue that led to @HHeiser question also deserves a separate thread - Is it possible to have a more dynamic way of validating compositions, where the exact content required is largely unknown?. e.g a GP encounter, discharge summary, where potentially a very large number of archetypes need to be considered, and right now included in a single template. This if Compound composition is seen as one possibility to solve this problem.

I’ll raise this separately, as I know there have been repeated attempts to solve this problem.

[joostholslag]

@bna

I would like to see an adoption of smaller and well defined components (templates, forms and stored AQL) which can be connected into a whole.

Such approaches will impact how clinical modelling is done. Currently I see a pattern with large composition templates. I would like to see more reusable templates with the potential of adding them dynamically Into a composition.

Another hard problem is how to combine persistent and event based data in data capture. It’s often hard for users in advanced care setting to tell who is responsible for the persistent data.

Yes, in my opinion the basic design is those components are already small. (Archetype, templates, queries). OpenEHR isn’t itself concerned about forms. But a form could be an artefact that brings those smaller components together, connecting it to the UI. And an action on the form probably should be reflected in a (single) contribution. So a form that displays 1. a template for a cardiology encounter 2. An AQL for the recently recorded eval.PROBLEMs and 3. the template for editing the ‘episodic’ problem list. A save on the form should commit all/both those changes as a singular change set to the CDR.
So a form relates 1:1 to a contribution regarding it’s changes. Now, I think (for now) it’s fine not to define ‘form’ in openEHR.

But there are some issues:

1. it might be useful to be able to archetype CONTRIBUTION. Because currently the contribution is only a list of VERSIONs, so changes to (usually) one or more compositions. But how exactly the changes in one composition relate to another is undefined. It would be helpful in some cases to define that relationship. E.g. recording an eval.problem in an encounter event compositions CAUSES an addition of a new eval.problem to the problem list episodic composition in a single contribution.

2. as Ian describes it might make sense to record details about a health care event at the contribution level, instead of or in addition to the composition level. I actually think it might make sense to move the event_context of a composition to the contribution, since event_ context doesn’t make much sense for, or at least have inconsistent semantics with non-event compositions (currently persistent and episodic, with the possible future addition of report.).

3. in complex curation cases like care plan compositions it makes sense to reference other care plan compositions in stead of containing them. I’ve written and spoken about this many times. This mostly already works from a specification perspective but there’s one feature lacking wich is constraining DV_EHR_URI to link to only care plan compositions with concept ‘care_plan’ (not to e.g. encounter or medication list)

4. Templates are currently implemented in a fixed way. So if you potentially need some archetype in a template you need to add it a design time. Which leads to huge templates. Which is unhelpful from a UI form/template renderer perspective. It should be possible to add archetypes to a composition at run time. I’m not convinced this requires a spec change. I think the spec, with its constraint model, is compatible with the idea of dynamic templates. One technical strategy would be to generate an OPT that includes the new archetype the user requires in this specific case. This would require the users system to have access to both template (‘oet’) and the archetypes at run time. And for the spec to specify an (oet) template is an ‘in-exhaustive’ set of constraints on an archetype, in other words anything it doesn’t constrain is still ok. So e.g. if an encounter template includes an observation,blood_pressure with no other constraints it means it’s ok to add an eval.problem at run time. I know this is currently not how constraints are understood but I think it’s a stricter and more useful way to interpret ’constraint modelling’. One issue @MattijsK pointed out is how to keep paths consistent, especially avoiding node_id conflicts. This is way I think it would be necessary to generate an opt at run time that specifies the path to the new archetype including the node id. It would mean accepting that one (oet) template may contain conflicting paths in downstream opts. I guess that’s ok? It may require clearer separation of identification of oets and opts, and ‘versions’ of an opt.

5. In modelling a ‘dataset’ it’s often useful to model mixed ehr and non ehr ‘archetypes’ and probably non-openEHR data (billing codes or appointments) and persistent and event compositions. I think it would be useful to be able to do that within openEHR. Because most of the complexity has been solved within openEHR. And the tooling and infrastructure are a good fit. (Like this example: GitHub - openehr-nl/ACP: ACP). It might be an archetype on contribution as described under 1. And 2. Or a new concept of a dataset.

And yes let’s please separate this into different discours topics. And ideally bring it together again in a confluence post.

[ian.mcnicoll]

I have re-opened a dynamic compositions topic Dynamic archetype in slot based on preconditions - #8 by ian.mcnicoll

to allow further discussion of that problem, as the original question here was essentially trying tosolve similar problem.

The compound composition solution has other potential uses, and both would have value.