Should EVENT_CONTEXT.setting be made optional and/or it's associated terminology updated?

Specifications RM
1

A finding from the Swedish openEHR work is that the general usefulness of the attribute “setting” of EVENT_CONTEXT (see diagram below) and the choices available in associated terminology (see XML below) feel a bit too country/organisation specific (and old) to be mandatory in the RM in current form.

Questions:

  1. Could/should setting be made optional in a future RM release?
  2. What do people from other countries think of the current alternatives in the terminology?
  3. In what kind of applications/use-cases is the “setting” variable used and useful today? How well would they work if “setting” was made optional and some of the data in an EHR no longer had it set at all?

Problem examples:

  • In general we often want multiprofessional EHR notes (COMPOSITIONs) that are updated by different professions, so the split medical/nursing/allied in both primary care and secondary care creates more problems than it solves.
  • There is a mix in the terminology between responisble healthcare level and physical place. When it comes to “home”, there are professionals from at least three organisational levels working with home based healthcare in Sweden (primary, secondary, municipal)
  • The division between primary and secondary care is slowly dissolving in some collaborative settings that actualy want to document the care together.

image
image936×878 64 KB

Image from EHR Information Model chapter 5.

Terminology explained in Support Terminology specification and actual content available in terminology/openehr_terminology.xml - excerpt below:

	<group name="setting">
		<concept id="225" rubric="home"/>
		<concept id="227" rubric="emergency care"/>
		<concept id="228" rubric="primary medical care"/>
		<concept id="229" rubric="primary nursing care"/>
		<concept id="230" rubric="primary allied health care"/>
		<concept id="231" rubric="midwifery care"/>
		<concept id="232" rubric="secondary medical care"/>
		<concept id="233" rubric="secondary nursing care"/>
		<concept id="234" rubric="secondary allied health care"/>
		<concept id="235" rubric="complementary health care"/>
		<concept id="236" rubric="dental care"/>
		<concept id="237" rubric="nursing home care"/>
		<concept id="238" rubric="other care"/>
	</group>
1 Like
2

Completely agree. I make little use of this - the boundaries are increasingly blurred. Generally set it to ‘other care’. I would make it optional and also open for other terminologies e.g SNOMED or national coding systems

2 Likes
3

I also agree (and very recently asked @ian.mcnicoll about it). I think its a nearly unique case in the specifications where we are forced to use a kind of classification with no obvious origin.

A related topic would be, as it has been discussed at some point, to clearly define if that terminology codes are mandatory, or extensible, as it’s done in FHIR

2 Likes
4

Just looking at the value set I have to say I would have thought just the simple split of (say)

  • primary care
  • hospital in-patient
  • hospital out-patient
  • specialist clinic
  • ambulance
  • community (including aged care)

or even just primary / hospital / other would be more useful. Then you can find out simple things like what procedures were delivered by hospitals that could have been delivered in general practice or somewhere else.

I know that it’s not always 100% clear when you have a GP clinic and when you have a hospital - it’s the one place in some rural places.

5

THat’s not wrong but there will often be other ‘not wrong’ splits applied locally and this is not terribly interoperable, as it is heavily dependent on the healthcare economy.

It also conflicts/collides a bit with XDS type metadata. So I would both make optional and make the termset an example.

3 Likes
6

If that is the main known use case I believe we’d get better granularity and flexibility for such questions by deriving statistics from the attributes health_care_facility (and sometimes possibly location) combined with organisational levels from an organisation registry/catalog for that specific state/country.

Are there any other known use cases? (Question #3 in the original post)

I agree with @ian.mcnicoll that opening it up to other (possibly local/national) terminologies would likely make the attribute more useful than the currently available code list.

3 Likes
7
  1. I’d be in favour.
  2. They are problematic, many settings are country/organisation specific, we miss mental healthcare (cr) and we recognise very much that settings are increasingly blurry.
  3. I’m not aware we actually use this data other than recording it.

This is a theme I’m spending a lot of time and thought on. Especially since Nedap customers are mostly multidisciplinary teams. And I’m not sure I agree with the current statement. Could please elaborate on it so I can learn what you mean?
For me it makes me think about the discussion around problems. Where we wanted at first to record different names per discipline for the same problem/diagnosis where @ian.mcnicoll convinced us to record them separately and link them together. Audience specific problem name
Off course there are many perspectives and scenarios so I’m mainly curious and looking to share knowledge and align modelling patterns.

2 Likes
8

Hi!

Do we have any PR/CR for…

  1. …making the EVENT_CONTEXT.setting optional…
  2. …and open to any codes …

…as discussed above?

I only found the PR [SPECPR-382] - openEHR JIRA and the related CR [SPECTERM-20] - openEHR JIRA that requested an addition of “mental healthcare” to the list, but I may have missed something.

9

Hi Erik,

I did raise this at a SEC meeting - I think there are a whole host of places in the RM e.g. setting or Normal_status in Quantity, where we either need ot be more pro-active in updating the ‘official codes’ or IMO better still makes these ‘examples’ in FHIR binding terms.

I did actually go through and document some suggestions somewhere - I’ll chase that up.

The Specs are actually a little vague on whether these existing codesets are mandatory andf eg, Better allow other normal_status codes where Ehrbase is stricter.

2 Likes
10

#1 is the most important.

I wonder if both #1 and #2 non-breaking changes that can go in to a minor release of the specifications?

In the sense that data coded as today in existing EHRs will still be fully valid, I believe both are non-breaking.

(However in practice if an old (non-updated) system receives data with missing/null setting or a setting code from some other vocabulary than the current one, then that data won’t get through validation in the old system. I guess a recommended default way data import functions in old systems could handle this could be to convert missing/unknown codes to “other care” and put any incoming new unknown code into FEEDER_AUDIT or something. But just updating the system to accept the relaxed rule might be just as easy.)

@ian.mcnicoll if you find a PR/CR with this during your “chase” please inform us, otherwise someone will have to make a PR/CR.

1 Like
11

@ian.mcnicoll did you find any CR/PR or other things regarding this? Or should we try to create a PR at Specification PR tracker - Issues - openEHR JIRA?

12

I coudn’t find a CR/PR for this , Erik.

Here is my review of the current openEHR codes

Proposed optional openEHR Terminology

External preferred terms

external_id=“openehr_compression_algorithms”

external_id=“openehr_integrity_check_algorithms”

External example terms (or extend to current FHIR Valueset)

external_id=“openehr_normal_statuses”

https://www.hl7.org/fhir/valueset-observation-interpretation.html

Internal required

name=“attestation reason”

name=“audit change type”

name=“composition category”

name=“property” ???

name=“version lifecycle state”

name=“instruction states”

name=“event math function”

name=“extract content type”

name=“extract action type”

name="extract update trigger event type

Internal optional (exemplar/extensible)

name=“null flavours” ?? https://www.hl7.org/fhir/valueset-data-absent-reason.html

name=“participation function”

name=“participation mode”

name=“subject relationship”

name=“term mapping purpose”

name=“setting”

13

We are currently looking into using EVENT_CONTEXT, and the setting being optional would make sense to us and also make our life easier.

It seems like everyone in this topic agrees to make it optional, so we also think we should create a PR for this.

1 Like