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

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 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

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

1 Like

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

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.

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

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
  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