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?
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.
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.
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.
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.
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?
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.
There are a couple of uses for this kind of ācompound documentā
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
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.