Integration Package

The design basis for connecting existing systems to openEHR is founded upon a clear separation of the syntactic and semantic transformations required on data. The syntactic transformation converts source data from its original form (or whatever intermediate form it may have been converted to) to a format obeying a special class in the openEHR reference model, but whose logical structure and semantics are controlled by 'integration' archetypes so as to mimic the design of the source data. This step brings the data into the openEHR computational context. The second step causes transformation on this intermediate openEHR data into data which are a) instances of the main openEHR reference model, and b) obey 'designed' clinical archetypes.

The additional elements of the openEHR architecture which make this transformation possible are:

The figure below illustrates the rm.integration package, which contains a single class GENERIC_ENTRY. Unlike other classes in the openEHR reference model, GENERIC_ENTRY contains no hard-wired attributes at all, only one generic attribute, data. No assumptions at all are made about the actual shape of such data.

A number of useful consequences follow from this modelling approach. Firstly, instances of GENERIC_ENTRY will contain attributes inherited from the LOCATABLE class, including archetype_node_id, and are thus archetypable in the same way as all other classes in the openEHR reference model. The LOCATABLE attribute feeder_audit is also inherited, and may be used to mark every node of data with relevant meta-data from the source system record or message. Secondly, as a subtype of CONTENT_ITEM, GENERIC_ENTRY is a valid value for COMPOSITION.content. This is a completely desirable situation, since the same rules apply to GENERIC_ENTRY as to other content: instances can only be committed to the record as part of a COMPOSITION instance. GENERIC_ENTRY data are thus audit-trailed and versioned in the normal way. Thirdly, GENERIC_ENTRY instances can occur within a hierarchy of SECTIONs, which is useful for data sources which have headings or section equivalents (this is quite common in hospital information systems containing physician notes). Lastly, in common with all other openEHR data, design-time paths can be constructed for archetypes of GENERIC_ENTRY, while runtime paths can be extracted from data based on such archetypes. These path sets can be used for writing the data transformation rules.

It should be remembered that while GENERIC_ENTRY provides a standardised syntactic form for externally sourced data within openEHR, it provides no semantic coherence. This is particularly true for GENERIC_ENTRY instances sourced from numerous data sources: there is no guarantee that the GENERIC_ENTRY representations of "cholesterol result" from system A will be congruent with those sourced from system B. It is not even required that the data sources be vastly different for this problem to occur. Examples of messages can be found coming from different pathology laboratories, which obey the same minor version of HL7v2 (e.g. 2.3.1) and supposedly implement the same message type (e.g. "complete blood picture") but which differ in actual structure and content. The consequence of this situation is that GENERIC_ENTRY data cannot in general be safely used for clinical computation (e.g. decision support), and will not in general even support reliable clinical querying. In other words, a repository of GENERIC_ENTRYs (within appropriate COMPOSITION structures) does not constitute a reliable or interoperable health record - it can only be considered a standardised health information data store whose primary purpose is as the input to or output of semantic conversion processes, or for other auditing or non-clinical data management purposes.

The GENERIC_ENTRY class provides a way to represent data from non-openEHR systems that implement the openEHR Extract specification in order to either communicate with openEHR systems, or to communicate with other systems also implementing the openEHR Extract specification.

The GENERIC_ENTRY class provides a convenient basis for making openEHR systems ISO 13606- compliant, which in turn gives openEHR a gateway capability in heterogeneous environments where ISO 13606 is being used to communicate data. A ISO 13606 EHR Extract can be converted to a series of COMPOSITIONs containing GENERIC_ENTRY objects which obey appropriate integration archetypes; this data can then be semantically converted into orthodox openEHR objects for integration into a coherent EHR. Similarly, openEHR data can be converted into the GENERIC_ENTRY-based intermediate form for further conversion into ISO 13606 EHR Extracts.