Composition commit and change types

Technical (archive)
1

Hi all, I’m testing some cases in the EHRServer and I want to confirn some grey areas.

If the EHR receives a commit of a persistent composition and the change type is creation, should the EHR create a new composition?

i.e. I don’t see an EHR having two different medication lists, is that possible?

I guess persistent compos can only be created one time per archetype (one medication list, one problem list, one vaccination list, etc. per patient), and after the creation, all commits should be modification. Does this make any sense?

If this is OK, to avoid errors from client applications, I would return an error when a creation is committed for a persistent compo archetype that already has a conpo instance.

And about the first commit. Should, lets say, the medication list be created when the first medication is recorded or can it be created empty? What do other implementations out there do?

Thanks a lot!

2

Regardless of whether it makes sense conceptually, you will,
at any rate, encounter clinicians of differing specialities
working against the same OpenEHR intance wanting to have
"their own" medication list each.

Whether the backend actually does "their own" is another matter.

Karsten

3

I guess you need to version it, if you want it to be according the specs.
That means, when you use it for a medication-list, you will get many versions of the same compositions for a patient.

But if you do not version it, that means that the concept of replaying the Past in case of legal investigation will not be possible.

Bert

4

Hi Pablo,

When I am advising implementers on this, I use the following categories ...

## Composition Commit Styles

Depending on the clinical requirement, 3 styles of commit strategy are
suggested.

1. **’Event’**

e.g Nursing observations, clinical encounters, reports.

Each time the composition is committed, create a new instance via a POST.

Generally only do a PUT if an error needs to be corrected

2. **’Episodic’**

Create a new composition via POST for each Period of Care i.e an
admission. If it needs to updated, use a PUT to modify i.e Each
patient has a single instance per Period of Care.

3. **’Longitudinal’**

Create a new composition via POST for each patient. If it needs to
updated use a PUT to modify i.e. each patient has only a single
instance over their lifetime. This will be unusual in a hospital
record where there is generally limited ability to curate the patient
record in this way.

So your persistence uses cases are either 2/3. Currently to manage
Episodic persistence, you need ot set the composition category to
event, as the RM currently forces a 'persistent' composition to be
contextless i.e. the context attribute is 0...0. This will change in
an upcoming RM revision.

The decision about when/where to maintain persistent/curated lists is
one which will vary between implementations. I would generally expect
Medication lists, Allergies and some documents such as Resuscitation
preferences to be maintained as single, persistent instances. Although
Problems and Procedures should also probably be maintained that way,
there are valid situations where departmental problem lists e.g Renal
medicine have validity.

There are strong arguments, at least in UK practice, for maintaining a
single cross-organisation outpatient/community medication record but
each inpatient medication list should be separately maintianed for
each instiution/episode of care.

Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

5

I think that has more to do with the user interface than how compositions are committed, since I can filter meds by who prescribe them with ease.

6

All is already versioned, my question is about how to commit compos and if it makes sense to have two different versioned compositions for the same persistent compo archetype.

7

Hi Pablo,

I disagree for safety reasons. Knowing all of the medications that the
patient is taking/should be taking is a critical part of prescribing.
Of course it is legitimate to apply filters but I would be very
unhappy with an institution that wanted to maintain multiple
medication lists.

Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

8

"All is already versioned, my question is about how to commit compos
and if it makes sense to have two different versioned compositions for
the same persistent compo archetype"

For a persistent composition you should generally only maintain a
single instance that is continually updated i.,e same instance, same
compositionId, new version.

As I said before things are a bit more hazy for compositions whose
persistence only lasts as long as a care episode, where a new instance
might be created for each care episode but then that same instance
updated through the episode.

Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

9

Good info and the criteria makes sense.

I would use episodic for things like hospitalization and treatments that are not a knee time thing (event), maybe with help of folders. Also I would focus on intra hospital longitudinal lists since it is very difficult to reach agreement in the enterprise. And when that time comes, I would just implement a new set of rules for the enterprise :slight_smile:

Thanks!

10

Hi Ian and Pablo,
Although I don’t like commenting on how others implement their systems I would hate for this discussion to become the defacto standard on how the API works in the context of persistent compositions.
Although I understand Ian’s position on best clinical practice of a single medication list represented as a persistent composition in a person’s EHR, there is nothing stated about this in the specifications.
I would be interested in other vendors implementations in this area, but as a service implementation I do not like makinging these application oriented decisions unless they are in the specification. There are way too many use cases where our service is used and many will break this scenario like merges, distributed EHRs and cross organisational shared records.
I think it is the application that needs to apply these business rules.
I think this needs to be addressed by the API SEC before recommendations that appear normative are made on the lists.
Personally we have had big problems with persistent compositions due to lack of context, although we are working on fixing these, I still feel that perhaps we are not ready to have the category attribute constrained in the archetypes that we currently state are persistent for these same reasons. I have seen cases where there is a desire for different problem lists from different clinical perspectives, in particular a consumers view vs a GP vs a specialist.

Regards

Heath

That looks correct to me :slight_smile:

Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

11

Hi Heath,

There are way too many use cases where our service is used and many will break this scenario like merges, distributed EHRs and cross organisational shared records.

It would be helpful if you share which scenarios break the rule I stated on the previous email to improve it.

IMHO I don’t think anybody will take this little convo as a de facto standard, also I’m not trying to set that, never stated that. I just want to make the life of my users simpler by establishing an initial set of rules they can use until they find requirements that might need a more complex rule set, to have many cases that should be supported. I prefer that to start, instead of leaving the definition of the rules 100% to the clients of my API, considering that most of them won’t have any experience with openEHR and how an openEHR backend should work. Of course this might work for my tools and my target customers, and I know this won’t fit everybody, but this rule might help others to adapt it to their specific needs. And I agree if this has to be defined for an API behavior, the API SEC should be the place to define it.

12

Hi Pablo,
I did include my scenarios re problem list at the bottom of the email. Having said that there had been some movement around what compositions are persistent due to no context issues so problem list may no longer be a persistent composition.
There are similar scenarios for other persistent compositions also, it all comes down to context of use.

As I said, I don’t like advising how others implement their systems so if you think your users will benefit from this rule then go ahead, I was more concerned about Ian’s response sounding definitive than your query. This has risen a interesting topic for the API SEC to address.

Regards

Heath

Hi Heath,

There are way too many use cases where our service is used and many will break this scenario like merges, distributed EHRs and cross organisational shared records.

It would be helpful if you share which scenarios break the rule I stated on the previous email to improve it.

IMHO I don’t think anybody will take this little convo as a de facto standard, also I’m not trying to set that, never stated that. I just want to make the life of my users simpler by establishing an initial set of rules they can use until they find requirements that might need a more complex rule set, to have many cases that should be supported. I prefer that to start, instead of leaving the definition of the rules 100% to the clients of my API, considering that most of them won’t have any experience with openEHR and how an openEHR backend should work. Of course this might work for my tools and my target customers, and I know this won’t fit everybody, but this rule might help others to adapt it to their specific needs. And I agree if this has to be defined for an API behavior, the API SEC should be the place to define it.

13

I thought you had more specific cases :slight_smile:

Having specific lists per clinician was commented by Karsten on a previous message and I commented on that. I’m not sure at which extent that is a backend issue, an API issue or an UI issue. I would say if this is just a display requirement, is more UI related and we need to find ways in the backend to provide the data to address this requirement, independently of if we have or not singleton versioned_compositions per persistent compo archetype.

OT but related:

Now this got me thinking about commits. Until now, I was thinking of full composition commits, so if you want to add a medication to a medication list, you need to commit the data in the current version, plus the new entry for the new medication. But what about delta commits? If I didn’t changed anything on the current medications, can’t I just commit the new medication? Is this possible or somebody implemented something like this?

I would think of that as a commit “mode” that applies for amendment and modification change_type, and would allow to log individually added entries, and keep track of whole “singleton” persistent lists.

Does this makes any sense?

Thanks!

14

I think it is not just a display requirement, at least in some countries. There are separate care plans for example in the UK for some patients for relatively unrelated conditions. Whether separate medication lists really exist at the clinical level is a question (a bad idea for obvious reasons, same for allergies), but I suspect it could exist at a practical level in some places, if a GP or other Meds list is imported into a hospital environment that has its own medications list; in this case, the two taken together would be seen as the total logical list, but each part being owned by a different provider. We need more concrete evidence on this, but I don’t see anything to prevent this sort of thing happening. openEHR doesn’t say how to store the Versions, only that the logical view needs to be that each Version appears to have the full content. If you want to engineer a delta-based storage mechanism, you can, the specs don’t prevent that. Note that implementing differential representations for object structures is non-trivial, but doable (AOM2 does it for example); if you are storing some serial format, then you can potentially use text-based diffing, although you have to be careful of ordering within Hashes and Lists, which tends to break purely logical versioning e.g. on XML. Well, all it really means is that a function might be added to the EHR API that enables you to ‘add’ just a medication to a medication list, and the API will actually figure out how to create the whole composition, do any diffing, and store the proper Composition within a Contribution. Personally I think a better way that I have advocated for some years is a business level service + API called ‘medication list’ that provides functions like:

15

Hi Thomas,

What about having the ‘delta’ mode just at the API level? Storage might not store delta objects, just full objects, but the API allows to send only what was added, modified or deleted instead of the full compo?

16

then you have a transactional concept, i.e. ‘add’, ‘remove’, ‘modify’ etc… so for me the better way to think about it isn’t in terms of data structures but in terms of logical changes to the existing state of some Composition. But the logical thing is just a function of the form so then it’s just a case of what level of domain semantics you want. For example, you could have a function: so it’s not far to get to: Now - we don’t need a path, since the API knows we are dealing with a MedicationList Composition (that should follow an archetype of that name) and new medication orders (Instructions) only go in a certain place. So you can take your pick - the great thing about APIs is you can have as many as you like - as long as they all obey the same rules of data structuring and validity. If it makes sense in your environment to create an API of the flavour of the first one above I say go for it. - thomas

17

I think that can work for some implementations.

What I was thinking is not adding parts to an existing compo, but to commit a full COMPO, just with the changes. That means, the newObject would be a COMPOSITION or even a VERSION. If this is for the Problem List, to add a new one, the COMPO will have just one EVALUATION with the new problem. If commit mode is “delta”, the backend will do what it needs to reflect that addition to the current Problem List. If the commit mode is “full”, that means one problem was added and the rest removed.

IMO this can use the same commit(VERSION versions, AUDIT_DETAILS audit) adding a String mode param or adding another operation commit_delta(VERSION versions, AUDIT_DETAILS audit).

For my implementation all commits are for completed COMPOS, the API you described might allow partial updates to already committed COMPOS, and I don’t think delta commit should imply partial updates. Delta is just to commit a completed COMPO but without the need of replicating all the information that hasn’t changed. The backend can create the full compo internally, that would not be an issue.

Also, that is related with the initial issue: detecting individual changes to persistent COMPOS. Sending just the changes, allows to identify those with the user responsible for the changes, so it is easier to create lists of problems, medications, etc. per user or organization, even if internally that is stored in one singleton VERSIONED_COMPO. per persistent archetype.

Consider this is only for my implementation, I’m not looking for defining this for the official openEHR API, but can help as input. I want to double check my criteria with other implementers before implementing anything :slight_smile:

18

Hi Pablo,

I think there are lots of interesting approaches (though potentially
challenging in complex environments) but I would definitely want to
handle the question of 'diffs or not' behind the service layer. As a
consumer I just want to be sure that the current composition
accurately reflects changes made. Full revision is a bit dumb but it
is safe!

Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

19

I agree with that, rephrasing, this “delta mode” would be just an API feature. Also both modes full and delta can be supported by the same API, with the same results when querying data back. This might not be part of a generic API spec, but more a concrete ITS.

I think especially for persistent compos, the delta mode is smarted than the full revision, and with a little thought/design, might be as safer as the full revision.

I’ll put this idea in my icebox, since my user base is growing, in the near future I can send a survey to them to see if this might make their life easier. I won’t write a line of code for this until I have a change request, and I’m sure this doesn’t complicate other features.

Either way, it would be useful to have input from commercial implementers about if they support something like this, and also about the original issue