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.
- There are different kinds of systems that can comply with the openEHR specs
- Systems can implement parts of the openEHR spec that are specific to that kind of system
- 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
- Conformance will be verified mainly using REST APIs, though there are openEHR components that don't have an official API yet, like Demographics
- 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 | |
| EHR_STATUS | ehr | |
| FOLDER | common.directory | |
| COMPOSITION | composition | |
| EVENT_CONTEXT | composition | |
| VERSIONED_EHR_STATUS | ehr | |
| VERSIONED_FOLDER | common.directory | |
| VERSIONED_COMPOSITION | ehr | |
| 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 | |
| INSTRUCTION_DETAILS | 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_RELATIONSHIP | 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: https://specifications.openehr.org/releases/ITS-REST/Release-1.0.2/ehr.html#directory
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: https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html
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: https://specifications.openehr.org/releases/SM/latest/openehr_platform.html
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.