openEHR Support Terminology - Binding-strengths

A number of openEHR implementers have reported that some of the openEHR Support terminology bindings to RM attributes are too restrictive.

Where the terminology lacks some items required locally e.g. https://openehr.atlassian.net/browse/SPECPR-437
Where an external terminology is not aligned with the current international version. e.g. https://openehr.atlassian.net/browse/SPECPR-97 Although this issue is closed, it is very likely that the list of mime-types is again incomplete.
Where an alternative terminology is required locally, or by integration. https://openehr.atlassian.net/browse/SPECPR-435

The key issue, is that the RM Specifications always assume that the bound Support terminologies are always required unchanged and cannot be replaced or extended.

This requirement is expressed as part of the Invariant section of the RM Class e.g. For PARTY_RELATED

Invariants	Relationship_valid: `terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_subject_relationship, relationship.defining_code)`

Invariants	Relationship_valid: `terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_subject_relationship, relationship.defining_code)`

Binding-strength

Some of these issues might be resolved by better response to Change requests and alignment to changes in external reference codesystems, but in other cases, it has to be questioned if the ‘required’ status enforced by Invariant constraints should be relaxed.

Traditionally openEHR has not had the idea of terminology ‘binding-strength’ i.e. the degree to which the use of a specific codesystem or valueset at a particular datapoint is mandatory, or whether it can be extended or replaced.

Note This is separate from mandation of the data point itself e.g. An Allergy ‘reaction’ node can be optional but the associated valueset is required to be a specific SNOMED valueset

HL7 FHIR uses the idea of binding-strength on data nodes, and this has recently been added to the ADL2 specification for archetype-based codesystems/valuesets.

HL7 FHIR Binding-strengths

Code	System	Display	Definition

Code	System	Display	Definition
required	http://hl7.org/fhir/binding-strength	Required	To be conformant, the concept in this element SHALL be from the specified value set.
extensible	http://hl7.org/fhir/binding-strength	Extensible	To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
preferred	http://hl7.org/fhir/binding-strength	Preferred	Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
example	http://hl7.org/fhir/binding-strength	Example	Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.

The suggestion at https://openehr.atlassian.net/browse/SPECPR-439 is to apply binding-strengths to RM attributes which are bound to openEHR Support terminology, and in some cases to relax the ‘required’ constraint expressed in the RM specification documents.

Actions

Categorise the binding-strength of RM attributes which are bound to openEHR terminology
Document RM attribute binding-strength in Specifications
Consider documenting RM attribute binding-strength in BMM

1: Proposed RM attribute binding-strength

Rationale

Required: Where strict adherence is required for correct RM functionality e.g Version Lifecycle_state or Instruction states

or where a high degree of alignment with external terminologies can reasonably be expected and adhered to, and there is unlkely to be local variation

Extensible: Where a terminology has a degree of standardisation and adoption but may not be complete enough to handle local requirements e.g. Media types. Normal Status
Note: Normal status is currently based on a very old HL7v2 codeset. Recommendation is that we update this to include appropriate codes from the current FHIR codesystem, but allow it to be extensible to capture unusual local lab codes.

Preferred: I could not find a use for preferred.

Example: Where an openEHR internal codeset is unlikely to gain traction as a standard, over other local or reference terminologies e.g. Setting and Subject Relationship.

In some cases the links to an external reference is no longer valid and we should take the opportunity to tidy this up.

Codeset	Used in RM attribute	Binding-strength	External Ref	Check Ref

Codeset	Used in RM attribute	Binding-strength	External Ref	Check Ref
3.1.1. Countries	COMPOSITION.territory	Required	ISO Countries list
3.1.2. Character Sets	ENTRY.encoding DV_ENCAPSULATED.charset	Required	IANA Character Sets
3.1.3. Languages	ENTRY.language COMPOSITION.language DV_ENCAPSULATED.language	Required	ISO Language codes
3.1.4. Media Types	DV_MULTIMEDIA.media_type	Extensible	IANA Media Types
3.1.5. Compression Algorithms	DV_MULTIMEDIA.compression_algorithm	Required	HL7 Compression algorithms	Yes
3.1.6. Integrity Check Algorithms	DV_MULTIMEDIA.integrity_check_algorithm	Required	HL7 IntegrityCheckAlgorithm domain	Yes
3.1.7. Normal Statuses	DV_ORDERED.normal_status	Extensible	HL7 Observation-Interpretation vocabulary	Yes

Vocabulary	Used in RM attribute	Binding-strength	External Ref	Check Ref

Vocabulary	Used in RM attribute	Binding-strength	External Ref	Check Ref
3.2.1. Attestation Reason	ATTESTATION.reason	Extensible	HL7 ParticipationSignature domain	Yes
3.2.2. Audit Change Type	AUDIT_DETAILS.change_type	Required
3.2.3. Composition Category	COMPOSITION.category	Required
3.2.4. Property	DV_QUANTITY	Required	Regenstrief Institute - Unified Codes for Units of Measure
3.2.5. Version Lifecycle State	ORIGINAL_VERSION.lifecycle_state IMPORTED_VERSION.lifecycle_state VERSIONED_OBJECT.lifecycle_state	Required
3.2.6. Participation Function	PARTICIPATION.function	Extensible
3.2.9. Instruction States	ISM_TRANSITION.current_state	Required
3.2.10. Instruction Transitions	ISM_TRANSITION.transition	Required
3.2.11. Subject Relationship	PARTY_RELATED.relationship	Example
3.2.12. Term Mapping Purpose	TERM_MAPPING.purpose	Extensible
3.2.13. Event Math Function	INTERVAL_EVENT.math_function	Required
3.2.14. Setting	EVENT_CONTEXT.setting	Example
3.2.15. Extract Content Type	EXTRACT_SPEC.extract_type	Required
3.2.16. Extract Action Type	EXTRACT_ACTION_REQUEST.action	Required
3.2.17. Extract Update Trigger Event Type	EXTRACT_UPDATE_SPEC.trigger_events	Required

2: Updating the openEHR Specification (RM/Terminology)

Add the binding-strength terms to the Support Terminology.
Add a tag to the RM attribute to specify the binding-strength, and add a link back tothe codeset.
Where the binding-strength is not ‘required’ remove any current Invariant constraint

Example of updated EVENT_CONTEXT Specification

Invariant for setting removed sincse it is not required.
Link to openEHR setting codeset.
Binding-strength in brackets (as per FHIR) with a link to the binding-strength terminology in openEHR Terminology support.

3: Adding binding-strength to BMM (BMM specification change)

Should we add support into BMM to capture binding-strength for RM attributes?

see https://specifications.openehr.org/releases/LANG/latest/bmm.html#_value_set_types