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

**Category:** [RM](https://discourse.openehr.org/c/rm/42)
**Created:** 2022-02-22 16:58 UTC
**Views:** 1358
**Replies:** 12
**URL:** https://discourse.openehr.org/t/should-event-context-setting-be-made-optional-and-or-its-associated-terminology-updated/2390

---

## Post #1 by @erik.sundvall

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|533x500](upload://43Ocuz5TAyy9AtiG9BEv2sGWYHb.png)

Image from https://specifications.openehr.org/releases/RM/Release-1.1.0/ehr.html#_composition_package chapter 5.

Terminology explained in [Support Terminology specification](https://specifications.openehr.org/releases/TERM/latest/SupportTerminology.html#_vocabularies) and actual content available in [terminology/openehr_terminology.xml](https://github.com/openEHR/terminology/blob/master/openEHR_RM/en/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>
```

---

## Post #2 by @ian.mcnicoll

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

---

## Post #3 by @damoca

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
https://discourse.openehr.org/t/addition-of-required-extensible-preferred-example-terminology-constraint-to-aom-and-adl/933

---

## Post #4 by @thomas.beale

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.

---

## Post #5 by @ian.mcnicoll

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.

---

## Post #6 by @erik.sundvall

[quote="thomas.beale, post:4, topic:2390"]
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.
[/quote]

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.

---

## Post #7 by @joostholslag

[quote="erik.sundvall, post:1, topic:2390"]
* Could/should setting be made optional in a future RM release?
* What do people from other countries think of the current alternatives in the terminology?
* 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?
[/quote]

1. I’d be in favour. 
2. They are problematic, many settings are country/organisation specific, we miss mental healthcare ([cr](https://openehr.atlassian.net/browse/SPECPR-382)) and we recognise very much that settings are increasingly blurry. 
3. I’m not aware we actually use this data other than recording it. 


[quote="erik.sundvall, post:1, topic:2390"]
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.
[/quote]

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. https://discourse.openehr.org/t/audience-specific-problem-name/1924
Off course there are many perspectives and scenarios so I’m mainly curious and looking to share knowledge and align modelling patterns.

---

## Post #8 by @erik.sundvall

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 https://openehr.atlassian.net/browse/SPECPR-382 and the related CR https://openehr.atlassian.net/browse/SPECTERM-20  that requested an addition of "mental healthcare" to the list, but I may have missed something.

---

## Post #9 by @ian.mcnicoll

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.

---

## Post #10 by @erik.sundvall

[quote="erik.sundvall, post:8, topic:2390"]
1.  …making the EVENT_CONTEXT.setting optional…
2.  …and open to any codes …
[/quote]

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

---

## Post #11 by @erik.sundvall

@ian.mcnicoll did you find any CR/PR or other things regarding this? Or should we try to create a PR at https://openehr.atlassian.net/jira/software/c/projects/SPECPR/issues?

---

## Post #12 by @ian.mcnicoll

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](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"

---

## Post #13 by @MattijsK

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.

---


**Canonical:** https://discourse.openehr.org/t/should-event-context-setting-be-made-optional-and-or-its-associated-terminology-updated/2390
**Original content:** https://discourse.openehr.org/t/should-event-context-setting-be-made-optional-and-or-its-associated-terminology-updated/2390