Custom terminology for 'mode' in participation class

Specifications Terminology
1

Regarding the attribute ‘mode’ in the participation class.

Is it mandatory to use codes of the openEHR the terminology? For instance (197 videophone; 204 telephone ;and so on ).

Custom coding can be used?
For our use case we need values that are not included in OpenEHR terminology. Example: Non-face-to-face visit.

And one last question: A ‘Home visit’, is it equivalent to ‘physically remote’?

A mixture of openEHR and custom does not look like a good idea.

3 Likes
2

Sorry for bringing this up in this thread, but @SevKohler and I had a similar discussion on the codes allowed for the setting attribute. Some aligned with more broadly used value sets would be nice so that we have an easier time integrating with other systems.

Of course we should aim to keep this standardized between openEHR installations, but I think the current terminology is not optimal.

2 Likes
3

I had the same problem several times: in some areas the openEHR terminology is not sufficient, and implementations need to extend codes in some of the terminology groups.

In HL7 v2.x there is the notion of HL7 table vs. User table, which allow to define codes for specific fields. When HL7 is sure that it covers all use cases, then the code is set by an HL7 table, but when they know its a code that could be set or extended for a specific context, then they leave that to the implementers as a User Table.

I do believe some of the terminology groups mentioned here might need to be set by users and not by openEHR. The matter about not being compatible with other implementations IMHO is minimal, since for almost every integration there should be some kind of beforehand coordination anyway, and these terminology groups can be part of that coordination when integrating with different vendors.

1 Like
4

There is already a PR open on this issue and a proposal to add binding strengths to the various openEHR cdesets.

https://openehr.atlassian.net/browse/SPECPR-439

Draft proposal:

Correctly, the binding strengths should be applied to the attributes and not to the codesets but this is a little easier to document

Required binding

  • 3.1.1. Countries
  • 3.1.2. Character Sets
  • 3.1.3. Languages
  • 3.2.1. Attestation Reason
  • 3.2.2. Audit Change Type
  • 3.2.3. Composition Category
  • 3.2.4. Property
  • 3.2.5. Version Lifecycle State
  • 3.2.9. Instruction States
  • 3.2.10. Instruction Transitions
  • 3.2.13. Event Math Function
  • 3.2.15. Extract Content Type
  • 3.2.16. Extract Action Type
  • 3.2.17. Extract Update Trigger Event Type

Preferred binding

  • 3.1.4. Media Types
  • 3.1.5. Compression Algorithms
  • 3.1.6. Integrity Check Algorithms
  • 3.2.6. Participation Function
  • 3.2.7. Null Flavours (consider updating/referencing the latest HL7 equivalent)
  • 3.2.8. Participation Mode

Example binding

  • 3.1.7. Normal Statuses (consider updating/referencing the latest HL7 equivalent)
  • 3.2.11. Subject Relationship
  • 3.2.12. Term Mapping Purpose
  • 3.2.14. Setting (clinical setting)
1 Like
5

The idea of preferred and example bindings instead of required is the way to go IMHO, like the user defined tables in HL7 v2.x.

We need to be sure that the required bindings can be 100% defined by openEHR, like composition.category.

Though there are some externally controlled codes in the required list and that could lead to sync problems, for instance Character Sets, we can use the IANA ones instead of having them “required”, could just be “preferred”, noting that our list could be incomplete (IANA might add codes and we can get out of sync with them).

1 Like