...
...
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
Introduction
This page provides information on which a technical solution to bidirectional openEHR / ISO 13606 conversion can be based. Since ISO 13606 uses the ISO 21090 pre-standard for data types, this mapping necessarily involves an openEHR datatype <-> ISO 21090 mapping as well. Key points to note:
...
Common IM structures
openEHR | attribute | type | 13606 | attribute | type | description | exceptions / ambiguities |
---|---|---|---|---|---|---|---|
PATHABLE |
|
| RECORD_COMPONENT |
|
|
|
|
| parent (not persisted) | PATHABLE |
| orig_parent_ref | II [0..1] | rule: generate openEHR URI | see mismatches below |
LOCATABLE |
|
| RECORD_COMPONENT |
|
|
|
|
| uid | UID_BASED_ID [0..1] |
| rc_id | II [1] | rule: generate openEHR URI | see mismatches below |
| archetype_node_id | String [1] |
| archetype_id | String [0..1] | rule: String id->II |
|
| name | DV_TEXT [1] |
| name | TEXT [1] | rule: DV_TEXT -> TEXT | what are possible name values? |
| archetype_details | ARCHETYPED [0..1] |
|
|
|
|
|
| feeder_audit | FEEDER_AUDIT [0..1] |
| feeder_audit | AUDIT_INFO [0..1] | rule: follow link & map |
|
| links | Set<LINK> [0..1] |
| links | Set<LINK> [0..1] | rule: 1:1 iteration |
|
| - |
|
| sensitivity | Integer [0..1] |
| MISSING IN OPENEHR - could either be on LOCATABLE or on COMPOSITION |
|
|
|
| policy_ids | SET<II> |
| In openEHR, these settings are in the ACCESS_CONTROL object |
|
|
|
|
|
|
|
|
AUDIT_DETAILS |
|
| AUDIT_INFO |
|
|
|
|
| system_id | String [1] |
| ehr_system | II [1] | rule: String id->II | which system id is being used here? |
| committer | PARTY_PROXY [1] |
| committer | II [1] |
| which user id is being used here? |
| time_committed | DV_DATE_TIME [1] |
| time_committed | TS [1] | rule: |
|
| change_type | DV_CODED_TEXT [1] |
| reason_for_revision | CV [0..1] | rule: DV_CODED_TEXT->CV |
|
| description | DV_TEXT [0..1] |
| - |
|
| LOST INFORMATION |
+VERSION | lifecycle_state | DV_CODED_TEXT [1] |
| version_status | CS [0..1] | rule: DV_CODED_TEXT->CS |
|
+VERSION | preceding_version_id | OBJECT_VERSION_ID[1] |
| previous_version | II [0..1] | rule: |
|
+VERSION | owner_id | HIER_OBJECT_ID [1] |
| version_set_id | II [0..1] | rule: |
|
PARTY_PROXY |
|
| RELATED_PARTY |
|
|
|
|
| external_ref | PARTY_REF [0..1] |
| party | II [0..1] | rule: | LOST INFORMATION: namespace, type? |
PARTY_IDENTIFIED |
|
|
|
|
|
|
|
| name | String [0..1] | Demographics_package | name | ENTITY_NAME[*] | rule: String -> ENTITY_NAME synthesis |
|
| identifiers | List<DV_IDENTIFIER> [0..1] | Demographics_package | role | HEALTHCARE_ | rule: for each identifier: DV_IDENTIFIER -> HEALTHCARE_ |
|
PARTY_RELATED |
|
| RELATED_PARTY |
|
|
|
|
| relationship | DV_CODED_TEXT [1] |
| relationship | TEXT | rule: DV_CODED_TEXT->TEXT |
|
PARTY_SELF |
|
| RELATED_PARTY |
|
| convert to RELATED_PARTY with relationship = self? |
|
PARTICIPATION |
|
| FUNCTIONAL_ROLE |
|
|
|
|
| function | DV_TEXT [1] |
| function | CV [0..1] | rule: DV_CODED_TEXT->CV | LOST INFORMATION |
| performer | PARTY_PROXY [1] |
| performer | II [1] | use rule for: PARTY_PROXY.external_ref | LOST INFORMATION |
| time | DV_INTERVAL [0..1] |
| - |
| (no mapping available) | LOST INFORMATION |
| mode | DV_CODED_TEXT [1] |
| mode | CS [0..1] | rule: DV_CODED_TEXT->CS |
|
( EVENT_CONTEXT) | health_care_facility | PARTY_IDENTIFIED [0..1] |
| healthcare_facility | II [0..1] | use rule for: PARTY_PROXY.external_ref | healthcare facility is in openEHR.EVENT_CONTEXT (since there cannot be 2 HCFs in one ENTRY) |
( EVENT_CONTEXT) | setting | DV_CODED_TEXT [1] |
| service_setting | CV [0..1] | rule: DV_CODED_TEXT->CV | service setting is in openEHR.EVENT_CONTEXT (since there cannot be 2 types of service setting in one ENTRY) |
Section & Entry structures
openEHR | attribute | type | 13606 | attribute | type | description | exceptions / ambiguities |
---|---|---|---|---|---|---|---|
SECTION |
|
| SECTION |
|
|
|
|
|
|
|
|
|
|
|
|
ENTRY |
|
| ENTRY |
|
|
|
|
| language | CODE_PHRASE [1] |
| (items) | ELEMENT | generic mapping rule: | Can ELEMENT.name be used in this way? |
| encoding | CODE_PHRASE [1] |
| (items) | ELEMENT | generic mapping rule: | Can ELEMENT.name be used in this way? |
| subject | PARTY_PROXY [1] |
| subject_of_information | RELATED_PARTY | rule: PARTY_PROXY->RELATED_PARTY |
|
|
|
|
| subject_of_information_category | CS [0..1] | proposed rule: |
|
| provider | PARTY_PROXY [0..1] |
| info_provider | FUNCTIONAL_ROLE | map EVENT_CONTEXT. | MISSING IN OPENEHR - ENTRY.mode |
| - |
|
| uncertainty_expressed | Boolean [1] | rule: | Hard to see how this attribute could be a) on all Entries, and b) be a Boolean |
CARE_ENTRY |
|
| ENTRY |
|
|
|
|
| protocol | ITEM_STRUCTURE |
| (items) | CLUSTER/ELEMENT | use algorithm 1 below. |
|
| guideline_id | OBJECT_REF |
| - |
|
| INFORMATION LOST (not likely to be present in source in most cases) |
ADMIN_ENTRY |
|
| ENTRY |
|
|
|
|
| data | ITEM_STRUCTURE |
| (items) | CLUSTER/ELEMENT | use algorithm 1 below. |
|
OBSERVATION |
|
| ENTRY |
|
|
|
|
| data |
|
| (items) | CLUSTER/ELEMENT | use algorithm 1 below. |
|
| state |
|
| (items) | CLUSTER/ELEMENT | use algorithm 1 below. |
|
EVALUATION |
|
| ENTRY |
|
|
|
|
| data | ITEM_STRUCTURE |
| (items) | CLUSTER/ELEMENT | use algorithm 1 below. |
|
INSTRUCTION |
|
| ENTRY |
|
|
|
|
| narrative | DV_TEXT |
| (items) | ELEMENT | use algorithm 1 below. |
|
| expiry_time | DV_DATE_TIME |
| (items) | ELEMENT | use algorithm 1 below. |
|
| wf_definition | DV_PARSABLE |
| (items) | ELEMENT | use algorithm 1 below. |
|
| activities | List<ACTIVITY> |
| (items) | CLUSTER/ELEMENT | use algorithm 1 below. |
|
ACTIVITY |
|
| CLUSTER |
|
|
|
|
| description | ITEM_STRUCTURE |
| (items) |
| use algorithm 1 below. |
|
| timing | DV_PARSABLE |
| (items) | ELEMENT | use algorithm 1 below. |
|
ACTION |
|
| ENTRY |
|
|
|
|
| time | DV_DATE_TIME |
| (items) | ELEMENT | use algorithm 1 below. |
|
| description | ITEM_STRUCTURE |
| (items) | CLUSTER/ELEMENT | use algorithm 1 below. |
|
| ism_transition | ISM_TRANSITION |
| (items) | CLUSTER | use algorithm 1 below. |
|
| instruction_details | INSTRUCTION_DETAILS |
| (items) | CLUSTER | use algorithm 1 below. |
|
ISM_TRANSITION |
|
| CLUSTER |
|
|
|
|
| current_state | DV_CODED_TEXT |
| (items) | ELEMENT | use algorithm 1 below. |
|
| transition | DV_CODED_TEXT |
| (items) | ELEMENT | use algorithm 1 below. |
|
| careflow_step | DV_CODED_TEXT |
| (items) | ELEMENT | use algorithm 1 below. |
|
INSTRUCTION_DETAILS |
|
| CLUSTER |
|
|
|
|
| instruction_id | LOCATABLE_REF |
| (items) | ELEMENT | use algorithm 1 below. |
|
| activity_id | String |
| (items) | ELEMENT | use algorithm 1 below. |
|
| wf_details | ITEM_STRUCTURE |
| (items) | CLUSTER/ELEMENT | use algorithm 1 below. |
|
|
|
|
|
|
|
|
|
Sub-ENTRY structures
openEHR | attribute | type | 13606 | attribute | type | description | exceptions / ambiguities |
---|---|---|---|---|---|---|---|
HISTORY |
|
| CLUSTER |
|
|
|
|
events | (parts) | ||||||
EVENT |
|
| CLUSTER |
|
|
|
|
data | (parts) | ||||||
| state |
|
| (parts) |
|
|
|
POINT_EVENT |
|
| CLUSTER |
|
|
|
|
|
|
|
|
|
|
|
|
INTERVAL_EVENT |
|
| CLUSTER |
|
|
|
|
|
|
|
|
|
|
|
|
ITEM_STRUCTURE |
|
| CLUSTER |
|
|
|
|
|
|
|
|
|
|
|
|
ITEM_TREE |
|
| CLUSTER |
|
|
|
|
| items |
|
| (parts) |
|
|
|
ITEM_TABLE |
|
| CLUSTER |
|
|
|
|
| row |
|
| (parts) |
|
|
|
ITEM_LIST |
|
| CLUSTER |
|
|
|
|
| items |
|
| (parts) |
|
|
|
ITEM_SINGLE |
|
| CLUSTER |
|
|
|
|
| item |
|
| (parts) |
|
|
|
CLUSTER | items | List<ITEM | CLUSTER |
|
|
|
|
|
|
|
|
|
|
|
|
ELEMENT | value | DATA_VALUE [0..1] | ELEMENT |
|
|
|
|
| null_flavour | DV_CODED_TEXT [0..1] |
|
|
|
|
|
ENTRY Conversion Algorithm (algorithm #1)
...
Without this attribute, the best that can be done to avoid losing structure and information is to make special use of the ISO13606 RecordComponent 'name' attribute. This is illustrated in the following suggested structuring of openEHR data in ISO13606 form.
openEHR | ISO13606 | ||||
|
|
...
The following table is a list of notes relating to some of the attributes from abstract classes including ANY that need to be dealt with somehow in 13606/openEHR - the QTY data type has been used as the example here. These come either from the standard or from Grahame Grieve, its principal author. These could be used to develop a 13606 profile.
21090 class | attribute | comments |
---|---|---|
HXIT |
| 21090 spec: Because of the way that the types are defined, a number of attributes of the data types have values with a type derived from HXIT. In these cases the HXIT attributes are constrained to null. The only case where the HXIT attributes are allowed within a data type is on items in a collection (DSET, LIST, BAG, HIST). |
| validTimeLow, | GG: Intended for when a receiver system assembles a structure, but one of the pieces of data comes from somewhere else and is subject to separate life-cycle management - a piece of foreign data. So your own version management/life cycle stuff doesn't apply, but it's state is of sufficient interest to know this. (it's somewhat unusual, therefore, because most data is either handled in system, or its state is not tracked at all) So yes, the normal cycle is not respected (in the local context), but the data is of sufficient interest to track that state from where is is respected (elsewhere) a little. |
| controlActRoot, | The idea is that GUIDs would be generated for specific events - like measuring a person's BP. Or the BP being a certain value at a certain time - by some systems, and then used to refer to those events later on. This is a referent-tracking idea See Ceusters et al. |
ANY |
|
|
| nullFlavor | Mostly maps to ELEMENT.nullflavour. Exceptions:
|
| updateMode | RECOMMENDATION: eleminate from 13606 profile |
| flavorId | RECOMMENDATION: should not be in model; eleminate from 13606 profile |
QTY |
|
|
| expression | Was designed for representing a prescription dose dependent on external factors (e.g. patient peak flow rate, for an asthma drug). Should not really be on QTY. |
| uncertainty, uncertaintyType | Appears also to relate only to specific uses of certain kinds of QTY. Could be mappable to openEHR precision and accuracy in some cases. In openEHR, 'uncertainty' is a concept associated with assessments, diagnoses etc. |
| originalText | TB: this is a contextual idea that assumes a data entry application situation. The problem is that all kinds of ways of entering data are possible: it could be chosen from a dropdown or tree widget, or be a dial widget, calendar picker, or any one of a myriad of modern GUI entry mechanisms. So I don't see how this field can be meaningfully populated in many source systems anyway; I also don't see what to do with the value of the field if it doesn't match teh stringified version of the data item, e.g. what if this field value is '11/10/2009' and the actual value string is '2009-10-11' - then it is purely duplicate information and of no use; what if the value string is '2009-11-10'? We assume then a US-style interface, but otherwise it is still a duplicate. |
The following table is a map of data types.
openEHR Class | attribute | type | 21090 Class | attribute | type | description | exceptions |
---|---|---|---|---|---|---|---|
DV_BOOLEAN | value | Boolean [1] | BL or BL.NONNULL |
|
|
|
|
DV_STATE | value | DV_CODED_TEXT [1] |
|
|
|
|
|
| is_terminal | Boolean [1] |
|
|
|
|
|
DV_IDENTIFIER | issuer | String [1] |
|
|
|
|
|
| id | String [1] |
|
|
|
|
|
| type | String [1] |
|
|
|
|
|
| assigner | String [1] |
|
|
|
|
|
|
|
|
|
|
|
|
|
DV_TEXT | value | String [1] |
|
|
|
|
|
| hyperlink | DV_URI [0..1] |
|
|
|
|
|
| mappings | List<TERM_MAPPING> |
|
|
|
|
|
| encoding | CODE_PHRASE [0..1] |
|
|
|
|
|
| language | CODE_PHRASE [0..1] |
|
|
|
|
|
TERM_MAPPING | match | Character [1] |
|
|
|
|
|
| purpose | DV_CODED_TEXT [0..1] |
|
|
|
|
|
| target | CODE_PHRASE [1] |
|
|
|
|
|
CODE_PHRASE | terminology_id | TERMINOLOGY_ID [1] |
|
|
|
|
|
| code_string | String [1] |
|
|
|
|
|
DV_CODED_TEXT | defining_code | CODE_PHRASE [1] |
|
|
|
|
|
DV_PARAGRAPH | items | List<DV_TEXT> [1..*] |
|
|
|
|
|
|
|
|
|
|
|
|
|
DV_ORDERED |
|
|
|
|
|
|
|
| normal_status | CODE_PHRASE [0..1] |
|
|
|
|
|
| normal_range | DV_INTERVAL<T> [0..1] |
|
|
|
|
|
| other_reference_ranges | List<REFERENCE_RANGE<T>> [0..1] |
|
|
|
|
|
DV_INTERVAL<T> |
|
|
|
|
|
|
|
| lower | T->DV_ORDERED [0..1] |
|
|
|
|
|
| upper | T->DV_ORDERED [0..1] |
|
|
|
|
|
| lower_included | Boolean |
|
|
|
|
|
| upper_included | Boolean |
|
|
|
|
|
| lower_unbounded | Boolean |
|
|
|
|
|
| upper_unbounded | Boolean |
|
|
|
|
|
REFERENCE_RANGE<T> | meaning | DV_TEXT [1] |
|
|
|
|
|
| range | DV_INTERVAL <T> [1] |
|
|
|
|
|
DV_QUANTIFIED | magnitude_status | String [0..1] |
|
|
|
|
|
DV_ORDINAL | value | Integer [1] |
|
|
|
|
|
| symbol | DV_CODED_TEXT [1] |
|
|
|
|
|
DV_AMOUNT |
|
|
|
|
|
|
|
| accuracy | Real [0..1] |
|
|
|
|
|
| accuracy_is_percent | Boolean [0..1] |
|
|
|
|
|
DV_COUNT |
|
| INT? |
|
|
|
|
| magnitude | Integer [1] |
|
|
|
|
|
DV_QUANTITY |
|
| REAL? |
|
|
|
|
| magnitude | Double [1] |
|
|
|
|
|
| precision | Integer [0..1] |
|
|
|
|
|
| units | String [1] |
|
|
|
|
|
DV_PROPORTION |
|
| RATIO? |
|
|
|
|
| numerator | Real [1] |
|
|
|
|
|
| denominator | Real [1] |
|
|
|
|
|
| type | Integer [1] |
|
|
|
|
|
| precision | Integer [0..1] |
|
|
| openEHR values: |
|
DV_DURATION | value | String [1] |
|
|
| ISO 8601 |
|
DV_ABSOLUTE_QUANTITY | accuracy | DV_AMOUNT [0..1] |
|
|
|
|
|
DV_DATE | value | String [1] | TS.DATE |
|
| ISO 8601 |
|
DV_TIME | value | String [1] | TS |
|
| ISO 8601 |
|
DV_DATE_TIME | value | String [1] | TS.DATE_TIME |
|
| ISO 8601 |
|
|
|
|
|
|
|
|
|
DV_TIME_SPECIFICATION |
|
|
|
|
|
|
|
| value | DV_PARSABLE [1] |
|
|
|
|
|
DV_PERIODIC_ |
|
| EIVL or PIVL |
|
| HL7 PIVL or EIVL syntax string |
|
DV_GENERAL_ |
|
|
|
|
| HL7 GTS syntax string |
|
|
|
|
|
|
|
|
|
DV_ENCAPSULATED |
|
|
|
|
|
|
|
| charset | CODE_PHRASE [0..1] | ED or subtype | charset | CODE [0..1] | codes: openEHR character sets |
|
| language | CODE_PHRASE [0..1] |
| language | CODE [0..1] | codes: openEHR languages |
|
DV_MULTIMEDIA |
|
|
|
|
|
|
|
| alternate_text | String |
|
|
|
|
|
| uri | DV_URI [0..1] |
| reference | TEL.URL [0..1] |
|
|
| data | Array <Octet> [0..1] |
| data | Binary [0..1] |
|
|
| thumbnail | DV_MULTIMEDIA [0..1] |
| thumbnail | ED [0..1] |
|
|
| media_type | CODE_PHRASE [1] |
| mediaType | CODE [0..1] | codes: openEHR media types |
|
| compression_algorithm | CODE_PHRASE [0..1] |
| compression | Compression [0..1] | codes: openEHR compression algorithms |
|
| integrity_check | Array <Octet> [0..1] |
| integrityCheck | Binary [0..1] |
|
|
| integrity_check_algorithm | CODE_PHRASE [0..1] |
| integrityCheckAlgorithm | integrityCheckAlgorithm [0..1] | codes: openEHR integrity check algorithms |
|
| size | Integer [1] |
|
|
|
|
|
DV_PARSABLE |
|
|
|
|
|
|
|
| value | String [1] |
| xml | XML |
|
|
| formalism | String [1] |
|
|
|
|
|
DV_URI | value | String [1] |
|
|
| legal W3C URI |
|
DV_EHR_URI |
|
|
|
|
| openEHR constrained version |
|
|
|
|
|
|
|
|
|
Mismatches
Model mismatches
...
This attribute is defined as follows in the ISO 13606-1 standard:
Panel |
---|
This attribute identifies one or more access control policies that specifically pertain to this RECORD_COMPONENT and which need to be communicated to the EHR Recipient to govern future access to it. The identifiers may refer to policy information included in this EHR_EXTRACT as defined in Part 4 of this standard, or to policies held in external policy servers to which the EHR Recipient has access. |
From part 4:
Panel |
---|
In the 13606 Part 1 Reference Model every RECORD_COMPONENT within the EHR_EXTRACT includes an optional Policy_ID attribute to permit references to such policies to be made at any level of granularity within the EHR containment hierarchy. Every RECORD_COMPONENT may therefore reference any number of access policies or consent declarations that define the intended necessary privileges and profiles of principals (users, agents, software, devices, delegated actors etc) for future access to it. |
This attribute is a good example of a refactored attribute. The intention in ISO 13606 is to mark each data node with the list of policies that apply to it. However, in an EHR system, the same information model is very unlikely to be used, for at least one very basic reason: if the policies relating to a given data item or document were to change, changes would be required to the document itself. Instead, source systems are much more likely to have a policy server that references data items using whatever internal identification system is available.
...
This attribute is defined as follows in ISO 13606-1
Panel |
---|
The sensitivity of this RECORD_COMPONENT, represented using the code set for this attribute defined in Part 4 of this standard. |
Part 4 contains the following:
Panel |
---|
In addition to the generic representation of EHR access policy information (Annex A), this standard therefore also defines a specification for a minimum basis for communicating the sensitivity of EHR data within an EHR_EXTRACT, by specifying the sensitivity of the RECORD_COMPONENTs within it according to the classification defined in clause 6.1 of this part standard. This classification corresponds to the various sub-domains of EHR data illustrated in Figure 3. |
This data item, and access policies in general have been discussed by the openEHR ARB in 2006. At the time it was thought that there might not be a single 'sensitivity' for a given data item, such as a document added to the EHR by an obstetrician indicating a woman's pregnancy. The patient in question may be happy for the GP to see this information, but not want it seen at all by her employer (which might be possible for large employers with their own health plans).
...
This attribute is probably the biggest challenge of the ISO 13606 model. ISO 13606-1 says the following.
Panel |
---|
It is important that each RECORD_COMPONENT be uniquely and consistently identified across multiple EHR_EXTRACTS, so that references to or between them remain valid. Examples of such references are semantic links, revision and attestation. The rc_id attribute is of data type Instance Identifier (II), which incorporates an ISO OID; II is currently considered internationally to be the most appropriate data type for persistent identifiers that are required to be globally unique. It is unlikely that contemporary EHR systems will have existing primary keys or internal identifiers that correspond directly to globally-unique II instances. However, an EHR Provider system that has been issued with an organisational OID might use its internal references to construct unique local extensions to that OID and thereby construct globally-unique rc_id values. |
The key requirement here is:
...
To implement the first approach above in openEHR, ids of the form used in openEHR URIs are used, i.e. COMPOSITION.uid + node path, since COMPOSITION.uid is globally unique (other approaches could be used involving a system identifier as well). COMPOSITION.uid is of type OBJECT_VERSION_ID, described as follows in the specification:
Panel |
---|
The string form of an OBJECT_VERSION_ID stored in its value attribute consists of three segments separated by double colons ("::"), i.e. (EBNF): |
An example is as follows:
Code Block |
---|
F7C5C7B7-75DB-4b39-9A1E-C0BA9BFDBDEC::87284370-2D4B-4e3d-A3F3-F303D2F4F34B::2
|
Note that the uid (first and second segments can also be of type ISO Oid, or a reverse internet domain name. This 3-part id globally identifies a versioned openEHR Composition in a distributed network where multiple institutions can create their own local updates from an initial common copy e.g. of medications list. To get to an interior node, a path will be required, of the typical form used in openEHR, from the root node down to the node in question. An example of such a path is:
Code Block |
---|
/content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1 and name/value='Pulse']/data/
events[at0003 and name/value='Any event']/data/items[at1005]
|
So the identifier to each node in a structure could be something like:
Code Block |
---|
F7C5C7B7-75DB-4b39-9A1E-C0BA9BFDBDEC::87284370-2D4B-4e3d-A3F3-F303D2F4F34B::2/content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/
items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1 and name/value='Pulse']/data/events[at0003 and name/value='Any event']/data/items[at1005]
|
...