openEHR conformance

Atomik complies with the openEHR specifications at different levels. At CaboLabs we have been working on the openEHR Conformance Verification are for the last 4 years, in fact our work was taken as the foundation for the official openEHR Conformance specification which is currently a DRAFT.

As part of our work in the Conformance Verification area, we have designed the openEHR Conformance Framework which is wider in scope than the current openEHR Conformance spec, and we think is the foundation for a formal openEHR Software Certification Program.

There are some lessons learned from working on the conformance area for a long time.

  1. There are different kinds of systems that can comply with the openEHR specs
  2. Systems can implement parts of the openEHR spec that are specific to that kind of system
  3. There are different levels of compliance based on the specs implemented and how deviated from the specs those implementations are. Based on this a Conformance Score can be implemented, a higher score means the implementation is more strict against the specification, a lower score means no implementation or a higher deviation from the specs
  4. Conformance will be verified mainly using REST APIs, though there are openEHR components that don't have an official API yet, like Demographics
  5. openEHR implementations should publish a Conformance Statement document that formally declares how the openEHR specifications were implemented in a certain system, this practice is very common for imaginology software that implements DICOM, and should be common practice for openEHR too

Atomik Conformance

Tihs is an informal conformance documentation, we are actually putting together automated tests with reporting so we can run the Conformance Verification tests and provide a clear picture of what openEHR specs are implemented in Atomik, show without any bias at which level Atomik complies with the openEHR specs, and detect any deviation from the specs that should be documented or should be fixed in the future. Our goal is to grant our customers that when they use Atomik, they are actually being compliant with the openEHR specifications with a very high Conformance Score.

openEHR Information Model Conformance

TL;DR; the only classes that are not suppoted right now by Atomik are EHR_EXTRACT and IMPORTED_VERSION.

RM type Package Notes
EHR ehr
COMPOSITION composition
EVENT_CONTEXT composition
CONTRIBUTION common.change_control
ORIGINAL_VERSION common.change_control
SECTION content.navigation
OBSERVATION content.entry
EVALUATION content.entry
INSTRUCTION content.entry
ACTION content.entry
ADMIN_ENTRY content.entry
ACTIVITY content.entry
ISM_TRANSITION content.entry
HISTORY data_structures.history
POINT_EVENT data_structures.history
INTERVAL_EVENT data_structures.history
PERSON demographic
GROUP demographic
ORGANISATION demographic
AGENT demographic
ROLE demographic
PARTY_IDENTITY demographic
CONTACT demographic
ITEM_TREE data_structures.item_structure
ITEM_LIST data_structures.item_structure
ITEM_TABLE data_structures.item_structure
ITEM_SINGLE data_structures.item_structure
CLUSTER data_structures.representation
ELEMENT data_structures.representation
ARCHETYPED common.archetyped
AUDIT_DETAILS common.generic
PARTY_PROXY common.generic
DV_BOOLEAN data_types.basic
DV_IDENTIFIER data_types.basic
DV_TEXT data_types.text
DV_CODED_TEXT data_types.text
CODE_PHRASE data_types.text
DV_ORDINAL data_types.quantity
DV_INTERVAL data_types.quantity
DV_PROPORTION data_types.quantity
DV_QUANTITY data_types.quantity
DV_COUNT data_types.quantity
DV_DATE data_types.quantity.date_time
DV_TIME data_types.quantity.date_time
DV_DATE_TIME data_types.quantity.date_time
DV_DURATION data_types.quantity.date_time
DV_MULTIMEDIA data_types.encapsulated Allows to save binary data or external references to binary data like DICOM studies with WADO or WADO-RS URLs. For extensive use of multimedia resources, it's recommended to use an external repository with references from the openEHR CDR.
DV_PARSABLE data_types.encapsulated
DV_URI data_types.uri
DV_EHR_URI data_types.uri

The following classes are not implemented due the lack of support on modeling tools and use cases for storing data for them: DV_STATE, DV_PARAGRAPH, TERM_MAPPING, REFERNCE_RANGE. If a customer requires support for any of those classes, we are able to add them.

openEHR AOM / ADL Conformance

Atomik doesn't use Archetypes directly, it uses Templates in the form of Operational Templates (OPT). So it doesn't need to support ADL. The AOM implemenation has all the classes needed to load, process and save an OPT, and it's based on AOM 1.4. We don't have plans to implement AOM 2 in our current roadmap.

openEHR TOM Conformance

Template Object Model (TOM) is kind of a virtual specification that was never formalized but it's used in practice to define, manage and share Operational Templates between openEHR systems. The TOM is basically AOM 1.4 as the base model and XML Schemas (ITS artifacts) that represent the serialization format for Operational Templates. This is what is implemented by Atomik, because it works just with OPTs.

openEHR REST API Conformance

Atomik complies with the EHR API, including the following resources: EHR, EHR_STATUS, CONTRIBUTION, COMPOSITION and DIRECTORY. Atomik implementds the openEHR REST API release 1.0.2.

A note about querying: Atomik doesn't implement AQL, it implements a different querying formalism called Simple Archetype Query Model (SAQM) that doesn't rely on a specific syntax, and it's portable between different vendors. AQL is not 100% portable because the specification focus too much on the syntax, but very little on the internal processes involved in the query execution. We are working on the SAQM spec which will be publicly available for anyone that wants to implement an alternative query formalism for openEHR CDRs. A related note about this is that the Query component of the openEHR service layer is that is accepts different query formalisms, AQL being the only official one (for now). Though a harmonization between the Service Model and the REST API specs should be done so this aspect of supporting a variable formalism for querying an openEHR CDR is formally defined there.

Spec reference:

openEHR Architectural Components Conformance

Atomik conforms with the EHR and Demographic openEHR components, allowing managing the clinical record and the party record, including relationships, roles, identity and contact information.

Atomik supports the openEHR terminology component, which is for internal use on specific data points, and supports semantic conditions based on external terminologies (right now focused on SNOMED CT). This last characteristics could be extended to integrate also terminological data validation (verifying codes are correct in records committed by a client system to Atomik).

Spec reference:

openEHR Service Model Conformance

The openEHR Service Model (SM) is an exercise of formalizing a service layer independently of its implementation, so it's a more generic specification than the REST API, and the REST API spec should have bindings to each component, type and operation defined in the SM. Unluckily the SM spec was created after the REST API spec was released, so there is some harmonization work needed in that area to be able to formalize how conformance against the SM is documented and verified (this is explained in the openEHR Conformance Framework we designed).

Spec reference:

openEHR Versioning Conformance

openEHR defines a very generic way of versioning any top-level type descending from LOCATABLE (COMPOSITION, EHR_STATUS, FOLDER and PARTY), which is based on branching. This way of versioning requires complex processes of forking/branching and merging that are quite unusual in a clinical environment. So we chose to constraint even more the versioning capabilities to a more realistic use case that would be more common in clinical environments, this is linear versioning. That means there is no "branching" or "merging", just "create next version", which generates a version list instead of a tree, like: v1, v2, v3, and so on.

openEHR Data Validation Conformance

openEHR data validation involves two levels: syntactic and semantic. Syntactic validation is verifying conformance of the exchange formats (JSON/XML) against the official canonical JSON and XML Schemas [1][2].

The semantic validation happens once the exchange payloads are validated and parsed into RM instances, which are validated against the structures, constraints and terminology present in the corresponding Operational Template. Note there is no formal specification on how the semantic data validation errors should be reported. Our approach is to report the client where the error is located in the data, by returning a data path, and which constraint was violated, by returning a template path. Atomik also returns a data validation error message to provide the details about what went wrong, so clients have all the information they need to know what happened, so the can fix the issues and recommit the data.