openEHR logo

openEHR EHR Platform Conformance

Issuer: openEHR Specification Program

Release: latest

Status: DEVELOPMENT

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: conformance

© 2017 - 2017 The openEHR Foundation

The openEHR Foundation is an independent, non-profit community organisation, facilitating the sharing of health records by consumers and clinicians via open-source, standards-based implementations.

Licence

image Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/

Support

Issues: https://openehr.atlassian.net/browse/SPECPR/
Web: http://www.openehr.org/

Amendment Record

Issue Details Raiser Completed

R E L E A S E     1.?.?

0.6.2

Updates to REST API at 25 Aug 2017. Added glossary. Improved SUT diagram.

T Beale,
S Iancu

26 Aug 2017

0.6.1

Major rework from SEC call 9 Aug 2017.

C Chevalley,
H Frankel,
S Iancu,
B Lah,
B Naess,
T Beale

11 Aug 2017

0.5.0

SPECCNF-1: Initial Writing.

B Naess,
I McNicoll,
P Pazos,
T Beale

01 Jun 2017

Acknowledgements

This specification was developed and is maintained by the openEHR Specifications Editorial Committee (SEC).

Trademarks

  • 'openEHR' is a trademark of the openEHR Foundation

1. Preface

1.1. Purpose

This document describes the openEHR EHR System Conformance Definition, which states a test schedule and content of tests to be used to determine the conformance of EHR solutions to openEHR EHR specifications. The audience of this document includes:

  • Software development organisations developing EHR systems;

  • Customer organisations.

Useful references for reading this document include:

1.3. Status

This specification is in the DEVELOPMENT state. The development version of this document can be found at http://www.openehr.org/releases/CNF/latest/conformance_definition.html.

Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:

TBD: (example To Be Determined paragraph)

Users are encouraged to comment on and/or advise on these paragraphs as well as the main content. Feedback should be provided either on the technical mailing list, or on the specifications issue tracker.

2. Glossary of Terms and Acronyms

The following terms and acronyms are used in this document.

Term Meaning

API

Application Programmer Interface.

CDS

Clinical Decision Support.

REST

{https://en.wikipedia.org/wiki}/Representational_state_transfer[Representational state transfer], a type of web service. REST-compliant Web services allow requesting systems to access and manipulate textual representations of Web resources using a uniform and predefined set of stateless operations.

SUT

System under test.

3. Overview

Conformance testing is used as the basis of product certification, and has the following goals:

  • Tendering: enable tendering authorities to state formal criteria for compliance in tenders

  • Protection for solution developers: enables bona fide vendors and other developers to prove the quality of their solutions compared to other offerings claiming conformance

  • Protection for procurement: provides a way of ensuring that purchased solutions can be contractually guaranteed to perform in certain ways

3.1. Scope

This specification describes the conformance points for openEHR platform systems whose semantics are specified by the openEHR Foundation. Such systems typically include data services (i.e. persistence & querying) along with various options dependent on the orientation of the product and its maturity; these may include integration capabilities, domain services (e.g. guidelines, planning) and so on.

A conformance point is understood as a testable capability of a system that relates to a business-relevant capability. For example, conformance points for an EHR persistence service (aka Clinical Data Repository, or CDR) may include 'create EHR', 'update EHR', 'versioning' etc.

One or more methods of testing each conformance point is described in this specification. Conformance testing is based on comparing system behaviour and data to the relevant openEHR published specifications.

Fine-grained system capabilities naturally aggregate in various ways to produce specific coarse-grained business-relevant profiles, such as for a 'minimally viable openEHR system' and so on. In order to provide the customer side with a means of determining what constitute sensible sets of requirements, the specification defines a set of profiles.

The scope of this specification is limited to the following:

  • (specific) functional capabilities of systems;

  • limited non-functional capabilities, including:

    • external data format used by exposed APIs;

    • Security and Privacy.

The system being tested is accessed via various openEHR REST APIs which must be minimally implemented i.e. sufficiently for the test cases to be exercised.

This specification does not cover claims to other non-functional characteristics such as capacity, performance, availability, or consistency of systems. It is however recommended that supply agreements for operational solutions include criteria for these factors, as relevant to the situation. As a guide, the following criteria should be considered:

  • Capacity: capacity of system in terms of:

    • data volume:

      • number of active EHRs supported for a given reported latency;

      • number of archived EHRs supported;

    • user load:

      • number of concurrent committers for a given reported latency;

      • number of concurrent readers for a given reported latency;

  • Performance: tested performance of system in terms of reported transaction processing rates;

  • Availability: tested latency of system with respect to standard queries over time.

It may be possible to develop a band-based rating sytem for capacity. Performance, availability, consistency and related characteristics may be assessed using a framework that takes account of the CAP and / or PACELC theorems.

Specific applications are also outside the scope of this specification, however, it is assumed that in order for solutions to be testable, a minimal generic viewing tool is provided to enable viewing or data and other testable events.

4. Conformance Certificate

An openEHR Conformance Certificate consists of a rating in the Functional and Content dimensions, and a detailed report. The ratings are as follows:

Characteristics Levels Description

Functional

CORE

Core functionality required for operational deployment.

STANDARD

More comprehensive capabilities useful in a 'standard' EHR operational environment.

OPTIONS

Optional features required in specific circumstances.

Security and privacy

xxx

xxx

xxx

xx

External data format

Canonical XML

openEHR Canonical XML, defined by published XSDs

Canonical JSON

openEHR Canonical XML, defined by published transform of XML

An awarded certificate for a typical system will look as follows:

openEHR Conformance Certificate
===============================

Solution:       BestEHR release 2.4
                details ...
Vendor:         ACME EHR systems LLC, Maxperformancia
Assessor:       openEHR Foundation
Infrastructure: openEHR CNF-test WS 1.5.0 on AWS ...
                System under test on AWS ...
Date:           12 April 2017

Certified conformance
=====================
Functional:     CORE, Extras
Sec & Priv:     xxx
Ext Data Fmt:   XML, JSON


Detailed Report
===============

+================+===================+================+====================+==============+===========+
|SUT Component   |Product Component  |Capability      |Conformance point   |Tests         |Result     |
+================+===================+================+====================+==============+===========+
|ACME CDR        |EHR persistence    |Versioning      |Contribution commit |EHR-VER-01    |pass       |
|                |                   |                |new                 |EHR-VER-02    |pass       |
|                |                   |                |                    |EHR-VER-03    |FAIL       |
|                |                   |                +--------------------+--------------+-----------+
|                |                   |                |Contribution commit |EHR-VER-09    |pass       |
|                |                   |                |changed             |EHR-VER-11    |pass       |
+----------------+-------------------+----------------+--------------------+--------------+-----------+
|                                            . . . .                                                  |
+----------------+-------------------+----------------+--------------------+--------------+-----------+
|etc             |etc                |etc             |etc                 |etc           |           |
+----------------+-------------------+----------------+--------------------+--------------+-----------+

5. Evaluation Environment

Conformance evaluation relies on some normative idea of systems that may be tested against a set of specifications on which they claim to be based. This section describes the assumptions that are made about systems that may be reasonably tested according to this conformance specification.

5.1. System Under Test (SUT)

It is assumed that any system provided to be tested for conformance to this specification is of a platform nature, i.e. consisting of one or more product components that are exposed via corresponding services, and that the components are based on published openEHR specifications. Consequently, certain types of components are assumed and named in this specification, e.g. 'EHR persistence', 'Demographic persistence', 'Querying' and so on. These need not correspond to the product’s own names for these things.

The functionality assumed to be in these components is indirectly defined by the openEHR REST APIs, and directly defined by the openEHR specifications designated as relevant to each call. For this reason, the openEHR REST APIs are assumed to be implemented by the system to a sufficient extent for performing the tests (i.e. not all calls in the full REST APIs are required for the conformance testing described here.) Which calls are required is indicated in the Conformance Schedule below.

The openEHR REST APIs handle data in two ways: canonical openEHR XML, based on published XML schemas (XSDs), and a JSON equivalent, which is defined as a standard transform of openEHR object structures. The providers of the SUT may opt for either format, and are only required to implement one.

ISSUE: where defined, details?

A further assumption about an openEHR platform is that it writes to a system log service, which may be external or part of the product, and if it exists, is accessible in the test environment via an appropriate interface or viewer tool. Typically this service would be based on the IHE ATNA specification, but need not be.

Lastly it is assumed that there may be a generic data viewer available, i.e. a web application that be used in a normal brower that enables the data and other state in the principal services to be viewed in a generic way, as an aid to API-based testing.

The following figure illustrates the notional openEHR Platform assumed in any SUT.

openEHR platform conformance
Figure 1. Assumed openEHR Platform

In the above, elements with solid outlines are required, while elements with dashed outlines are those that may or may not be part of a given product. The generic portal is not considered part of the system under test, but an additional tool available to facilitate testing. Any actual system under test will normally consist of the mandatory parts plus one or more other components germane to the intended product function.

5.2. Manual Testing

TBD

5.3. Automated Testing

Automated conformance testing is performed by the interaction of the openEHR CNF-test web service with a system under test. A test configuration indicates which conformance claims are to be tested (e.g. functional=CORE; content=STANDARD+OPTIONS), and appropriate sets of tests are executed. The result is a detailed test report, together with the highest conformance levels reached in the requested categories.

6. Conformance Schedule

6.1. Overview

The following table shows the schedule according to which functional conformance claims can be made for a product component, corresponding to a block of the same name on the above diagram. Each product component has one table.

6.1.1. Understanding the conformance tables

Capability Conformance Point Description Test script REST script

Claimed capability
of the component

Testable characteristic
within this capability

description of conformance point.

Logical structure of
Test Case

REST API test script
(postman)

6.2. Conformance Test Tables

6.2.1. Archetype / Template Definitions

Specifications:

Capability Conformance Point Description Test script

ADL 1.4 Archetype
provisioning

Upload archetype

Upload an archetype to the server

DEF:upload archetype * N;
DEF:list archetypes

Get archetype

Get archetype by archetype_id DEF:get archetype by id

List archetypes

List all available archetypes on the system

OPT 1.4 Operational
Template
provisioning

Upload template

Upload a template to the server

DEF:upload template * N;
DEF:list templates

Get template

Get template by template_id DEF:get template by id

List templates

List all available templates on the system

6.2.2. EHR Persistence Component

Specifications:

Capability Conformance Point Description Test script REST script

EHR Repository

Create EHR

Create a new EHR; EHR id generated by system

create_ehr

postman script

Create EHR with EHR id

Create new EHR with the specified EHR id

create_ehr_with_id

postman script

Create EHR for subject

Create new EHR with the specified subject id; EHR id generated by system

create_ehr_for_subject

postman script

Create EHR with EHR id and subject id

Create new EHR with the specified EHR id and subject id.

create_ehr_with_id_and_subject

postman script

Get EHR

Get EHR with the specified EHR identifier.

Get EHRs for subject

Get EHR(s) for specified subject.

get_ehrs_for_subject

EHR Retrieve and Modify

Get EHR active status

Get EHR_STATUS.is_modifiable

Get EHR queryable status

Get EHR_STATUS.is_queryable

Set EHR inactive

Update EHR_STATUS.is_modifiable to False

Set EHR non-queryable

Update EHR_STATUS.is_queryable to False

Set EHR status details

Update EHR_STATUS.other_details

Composition Retrieve and Modify

Create Composition

Create new COMPOSITION with implicit Contribution

create_composition

Get Composition by id

Get COMPOSITION by id

Get Composition at time

Get COMPOSITION at time

Update Composition

Create a new version of a COMPOSITION

Delete Composition

Logically delete a COMPOSITION

Directory Retrieve and Modify

Create directory

Update directory

Change sets

Commit simple change set

Commit CONTRIBUTION with COMPOSITION

Commit mixed content change set

Commit CONTRIBUTION with multiple COMPOSITIONs , DIRECTORY

Commit mixed update change set

Commit CONTRIBUTION with COMPOSITION add, updated, deleted

Get change set

Get CONTRIBUTION by id

List Change Sets

List Contributions

Versioning

Get Versioned Ehr status

Get Ehr_status version by id

Get Ehr_status version at time

Get Versioned Directory

Get Directory version by id

Get Directory version at time

Get Versioned Composition

Get Composition version by id

Get Composition version at time

Archetype
validation

Accept valid content

xxx

Reject invalid archetype

xxx

Reject invalid content

xxx

Logging

Log creates

xxx

Log updates

xxx

Log reads

xxx

6.2.3. Demographic Persistence Component

Specifications:

Capability Conformance Point Test script

Demographic data

Create Party

DEM:create party;
DEM:retrieve party;
regression diff

Update PARTY

DEM:create party;
DEM:retrieve party;
DEM:update party;
DEM:retrieve party;
regression diff

Retrieve PARTY

xxx

Versioning

Commit Party group
change set

xxx

Archetype
validation

Accept valid content

DEM:create_xxx;
check sys log

Reject invalid
archetype

DEM:create_xxx;
check sys log

Reject invalid content

DEM:create_xxx;
check sys log

Logging

Log creates

DEM:create_xxx;
check sys log

Log updates

DEM:commit_xxx;
check sys log

Log reads

DEM:retrieve_xxx;
check sys log

TODO: In theory we could include Integration Entries (Integration IM), but I don’t think anyone uses them. I suspect that spec should be retired.

6.2.4. Messaging Component

Specifications:

Capability Conformance Point Test script

EHR Extract

Export openEHR Extract
1 patient

EHRX:

Export openEHR Extract
w/ versions

EHRX:

Export openEHR Extract
multiple patients

EHRX:

Export generic Extract
1 patient

EHRX:

Export whole
patient record

EHRX:

Template Data
Schema (TDS)

TDD commit

TDD:

6.2.5. Querying Product Component

Specifications:

  • latest/AQL.html[AQL specification]

Capability Conformance
point
Access Method Test Script

Stored queries

Store query

DEFINITIONS API

DEF:create stored query;
DEF:get stored query;
DEF:list stored queries

Delete query

DEFINITIONS API

DEF:create stored query;
DEF:delete stored query;
DEF:get stored query;
DEF:list stored queries

AQL basic

Patient-centric

QUERY API

EHR:commit composition x N;
QRY:execute ad hoc query
regression.

AQL advanced

Patient-centric

QUERY API

EHR:commit composition x N;
AQL:create stored query;
QRY:execute stored query;
QRY:execute ad hoc query;
regression.

Population query

QUERY API

EHR:commit composition x N;
AQL:create stored query;
QRY:execute stored query;
QRY:execute ad hoc query;
regression.

AQL +
terminology

Patient-centric

QUERY API

EHR:commit composition x N;
AQL:create stored query;
QRY:execute stored query;
QRY:execute ad hoc query;
regression.

Population query

QUERY API

EHR:commit composition x N;
AQL:create stored query;
QRY:execute stored query;
QRY:execute ad hoc query;
regression.

6.2.6. Admin Product Component

Specifications:

  • xxx

Capability Conformance Point Access method Test script

List transactions

List CONTRIBUTIONs
since time

ADMIN API

ADM:

Transaction
statistics

Get CONTRIBUTION
count since time

ADMIN API

ADM:

Get COMPOSITIONs
add/mod/del
since time

ADMIN API

ADM:

Bulk EHR Export

Export all EHRs

ADMIN API

EHR:create EHR x N; + ; EHR:commit composition x N;
ADM:export;
file test / diff

Bulk EHR Load

Load complete file

ADMIN API

ADM:load;
ADM:retrieve x N

Archive EHRs

Archive EHRs by
identifier

ADMIN API

ADM:archive;
review archive; confirm status on
archived EHRs

Physical EHR
delete

Delete EHR by
identifier

ADMIN API

ADM:delete_ehr

Physical
Demographics
delete

Delete PARTY by
identifier

ADMIN API

ADM:delete_party

6.2.7. API Product Component

Specifications:

  • xxx

Product
Component
Capability Conformance
point
Access Method

Test Script

REST APIs

DEFINITIONS API

???

DEFINITIONS API

Exercise all functions
& arguments

EHR API

???

EHR API

Exercise all functions
& arguments

DEMOGRAPHIC API

???

DEMOGRAPHIC API

Exercise all functions
& arguments

QUERY API

???

QUERY API

Exercise all functions
& arguments

CDS API

???

CDS API

Exercise functions
& arguments

ADMIN API

???

ADMIN API

Exercise functions
& arguments

TDD API

???

TDD API

Exercise functions
& arguments

6.2.8. Non-Functional Characteristics

Specifications:

Product Attribute Capability Conformance
point
Access Method Test Script

Security &
Privacy

Signing

???

xxx API

Commit/Retrieve
data regression

Anonymous EHRs

???

EHR API

Commit/query

Info Consent

???

xxx API

Commit/Retrieve
data regression

6.2.9. Tools

Tools supplied with an openEHR EHR solution should include:

  • generic EHR viewer - a generic web portal for viewing EHR data in generic form.

7. Profiles

The schedule above describes capabilities of openEHR platform products that can be tested against the published specifiations via the REST APIs. These capabilities are grouped into profiles to provide a guide to what constitutes the required functionality for particular category of solution.

A profile may be defined logically as a particular list of capabilities from the above schedule that may be combined to specify a particular kind of solution. For example, an openEHR Demographics product would treat most or all of the Demographic capabilities as mandatory, along with support for definitions, logging etc.

This specification defines a set of 'default profiles' intended as a guide for determining the minimum capabilities to specify in order to obtain certain basic levels of functionality.

7.1. Default Profiles

The profiles used below are as follows:

  • CORE: a minimal functional openEHR platform implementation that enables the storage and retrieval of openEHR EHR data;

  • STANDARD: a 'standard' configuration of capabilities that adds AQL querying and logging to the CORE;

  • OPTIONS: components that are considered optional for non-specialised solutions.

In order to obtain CORE or STANDARD conformance, all mentioned capabilities must be met in testing. The OPTIONS profile is a catch-all pseudo-profile that covers all testable capabilities not included in CORE or STANDARD; OPTIONS is obtained if any optional capability is passed in testing.

7.1.1. Functional

Product Component Capability CORE STANDARD OPTIONS

EHR
Persistence

OPT 1.4

EHR data

Versioning

Archetype
validation

Logging

Demographic
Persistence

Demographic data

?

Versioning

?

Archetype
validation

?

Logging

?

Messaging

EHR Extract

?

TDS

?

Querying

Stored queries

AQL basic

AQL advanced

?

AQL + terminology

?

Admin

List transactions

?

Transaction
statistics

?

Bulk EHR export

?

Bulk EHR load

?

Archive EHRs

?

Delete EHRs

?

Delete Demographics

?

APIs

DEFINITIONS REST API

EHR REST API

DEMOGRAPHIC REST API

?

QUERY REST API

CDS REST API

?

ADMIN REST API

?

TDD REST API

?

Application
services

GDL

?

Task Planning

?

7.1.2. Non-Functional

Product Attribute Capability CORE STANDARD OPTIONS

Security &
Privacy

Signing

Anonymous EHRs

Info Consent

?

7.1.3. Other Non-Functional

Product Attribute Values

External Data Format

XML, JSON