openEHR logo

openEHR EHR Platform Conformance

Issuer: openEHR Specification Program

Release: latest

Status: DEVELOPMENT

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: conformance

openEHR components
© 2017 - 2018 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: www.openehr.org

Amendment Record

Issue Details Raiser Completed

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

0.7.1

Updates and new diagrams for SUT section; Adjust some test sets.

T Beale

17 Mar 2017

0.7.0

Major rework based on openEHR Patform SM.

openEHR SEC

18 Oct 2017

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 www.openehr.org/releases/CNF/latest/openehr_platform_conformance.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

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 products whose semantics are based on openEHR Foundation specifications. 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. It does not cover applications or modelling tools.

A conformance point is understood as a testable capability of a system that relates to a business function. For example, conformance points for an EHR persistence service (aka Clinical Data Repository, or CDR) may include 'create EHR', 'update EHR', 'versioning' etc. Conformance points are based on openEHR Platform Abstract Service Model API calls.

One or more methods of testing each conformance point is described in this specification. Conformance testing is based on comparing system behaviour 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 under test is accessed via one or more concrete protocol APIs, each of which is defined in the relevant openEHR Specification.

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.

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.

Non-functional

BASIC-SEC

Basic security features.

BASIC-PRIV

Basic privacy features.

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 Test Report
====================

+==========+=============+===============+=============================+==================+=====+======+
|SUT       |openEHR      |Capability     |Conformance point            |Test              |REST |proto-|
|Component |Component    |(PROFILE)      |                             |Case              |     |buf   |
+==========+=============+===============+=============================+==================+=====+======+
|ACME CDR  |EHR          |EHR Operations |I_EHR_SERVICE.               |                  |     |      |
|          |persistence  |               |create_ehr()                 |tc_ehr-create     |pass |pass  |
|          |             +---------------+-----------------------------+------------------+-----+------+
|          |             |Versioning     |I_EHR_COMPOSITION.           |                  |     |      |
|          |             |               |get_versioned_composition()  |tc_ehr-vers       |pass |pass  |
|          |             |               +-----------------------------+------------------+-----+------+
|          |             |               |I_EHR_CONTRIBUTION.          |tc_ehr-ctrb_smpl  |pass |pass  |
|          |             |               |commit_contribution()        |tc_ehr-ctrb_cplx  |FAIL |FAIL  |
+----------+-------------+---------------+-----------------------------+------------------+-----+------+
|                                      . . . .                                                         |
+----------+-------------+---------------+-----------------------------+------------------+-----+------+
|etc       |etc          |etc            |etc                          |etc               |pass |n/a   |
+==========+=============+===============+=============================+==================+=====+======+


PROFILE REPORT
==============

+==============+================+====================================+===========+========+
|SUT           |openEHR         |Capability                          |Required   |Result  |
|Component     |Component       |                                    |in profile |        |
+==============+================+====================================+===========+========+
|ACME K-base   |Definitions     |ADL 1.4 archetype provisioning      |   Y       |pass    |
|              |                |ADL 1.4 OPT provisioning            |   Y       |pass    |
|              |                |Query provisioning                  |   Y       |pass    |
+--------------+----------------+------------------------------------+-----------+--------+
|ACME CDR      |EHR             |EHR Operations                      |   Y       |pass    |
|              |persistence     |EHR Status                          |   Y       |pass    |
|              |                |Composition Operations              |   Y       |pass    |
|              |                |Directory Operations                |   Y       |pass    |
|              |                |Change Sets                         |   Y       |pass    |
|              |                |Versioning                          |   Y       |pass    |
+--------------+----------------+------------------------------------+-----------+--------+
|ACME Konsole  |Admin           |Activity Report                     |   OPT     |FAIL    |
|              |                |Physical Delete                     |   N       |pass    |
|              |                |EHR Archive                         |   OPT     |pass    |
|                           .   .   .   .   .                                             |
|              |                |Signing                             |   OPT     |pass    |
+--------------+----------------+------------------------------------+-----------+--------+

5. Evaluation Environment

Conformance evaluation relies on a 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 tested according to this conformance specification.

5.1. System Under Test (SUT)

5.1.1. General description

The totality of what is provided for conformance testing according to this specification is known as the system under test, or SUT. It is assumed that any such system has a platform architecture, consisting of one or more product components that are exposed via corresponding native service APIs, and that the component semantics and API are based on published openEHR specifications.

It is also assumed that native APIs are network-accessible via one or more communications protocols, each with an appropriate protocol adapter. Such protocols include the text-based, such as SOAP/WSDL and REST, as well as the many binary protocols, including Google Protocol Buffers, Apache Thrift, Avro, Kafka, ZeroC ICE, and Advanced Message Queueing Protocol (AMPQ). (At an implementation level, the native API of each software component is of course visible e.g. a Java .jar, .Net assembly, Linux .so library etc, but conformance testing does not address such interfaces). The general model is shown below.

sut model
Figure 1. Component Model

In the above, there are two test targets for any given component in the SUT, i.e. two aspects of a component for which conformance is to be determined:

  • Semantic: the formal, transactional semantics of the component’s exposed functions and procedures when called;

  • Interface(s): the concrete interfaces provided by the component.

The former needs to be tested to determine if the component does what it is functionally intended to do, and is documented in terms of abstract interface definitions that include pre-conditions, post-conditions and exceptions. The latter is tested to determine that the concrete means of accessing the component provided by its developer do indeed provide that access correctly, and conform to accepted norms of the relevant kind of service interface (i.e. REST, AMPQ etc).

To establish a common basis for naming and describing components of an openEHR Platform, the openEHR Platform Abstract Service Model may be used. This defines a standard set of openEHR component names along with definitions of the transactional semantics of each component, i.e. the 'semantic' test target referred to above. A product’s own component names need not correspond to the openEHR component names of course, but for the purpose of testing the logical mapping of the two should be provided by a developer.

Each of the concrete protocol interfaces is defined by its own specification, for example the openEHR REST API specification, and may be regarded as a product component, for which conformance testing may be conducted. No assumption is made that any given product supports any particular protocol(s), although a minimal set of REST APIs on components such as the System Log is likely to be useful for testing purposes.

The following figure illustrates a typical platform product, consisting of components and protocol interfaces as described above. Part or all of the platform (back-end) of such a product is provided for testing according to this specification.

conformance sut
Figure 2. Conformance System Under Test

As a consequence of the above, the conformance test schedule defined by this specification consists of tests for both native component semantics, and for whichever concrete protocol interfaces are provided. From a practical point of view, the testing is always conducted via the concrete interfaces (i.e. REST, SOAP, protobuf etc) as appropriate to the particular product. Thus, for a product that implements the openEHR REST APIs, the SUT environment is of the following form:

conformance sut rest
Figure 3. System Under Test - REST

In the test environment, a test application with the appropriate protocol client(s) is used to exercise the SUT. A system log viewer and a data viewer may be provided as part of the product in order to facilitate human interaction with the system, but these are not obligatory.

In the same fashion, the SUT for a product that exposes APIs using Google Protocol Buffers might look as follows.

conformance sut protobuf
Figure 4. System Under Test - Protocol Buffers

Other combinations of components and protocols may of course occur in the SUT and testing applications.

5.1.2. Platform Abstract Service Model

The formal transactional interface to a product’s openEHR components is specified by the openEHR Platform Abstract Service Model, which defines a set of services and for each component, as shown below.

SM platform model
Figure 5. Platform Abstract Service Model

The functions defined on these interfaces constitute the functional conformance points of this specification. For example, the conformance point for the logical 'create EHR' operation is defined by the functions create_ehr(), create_ehr_with_id(), create_ehr_for_subject(), create_ehr_for_subject_with_id() defined on the service interface I_EHR_SERVICE shown in the above diagram. Information conformance (i.e. conformance to the types stated in service call arguments and return values) is primarily defined by the openEHR specifications for the relevant components, i.e. RM (Reference Model) etc, however, a small number of service model-specific information structures are defined by the service specification.

Any given SUT is not assumed to implement all of these interfaces, or the underlying components. However, the components for which conformance is to be tested are assumed to be testable via the relevant interfaces above.

Real products may of course provide alternative forms of some services, e.g. System Log, Administrative interface and so on.

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

This section contains the schedule according to which conformance claims can be made for a a product. The conformance test schedule is divided into functional and non-functional parts, for which the structures are slightly different.

Functional conformance is on the basis of product component, i.e. 'EHR persistence', 'Querying' etc, each corresponding to a named block on the above SUT diagram. Each product component has one table in this schedule. Formal conformance points, defined in terms of calls in the relevant component service interface, are listed in the second column of the table. The first column groups conformance points under 'capability', which is understood as a marketing term reflecting coarse-grained functionality, and is used as the basis for conformance profiles described in the next section.

The remaining columns but one describe each 'semantic' conformance point, and define the logic of a conformance test case for it, expressed as Java-like pseudo-code. In many cases, one test script may be used to test multiple conformance points.

The final column(s) provides the implementation of the test case for REST web services over HTTP. Each other protocol will result in a new column on the right.

The following illustrates the conformance table structure for functional components.

Capability Conformance Point
(Service Model call)
Description Test case script REST script

Claimed capability
of the component.

Testable characteristic
defined in terms of
abstract service model call.

Description of conformance point.

Logical test case
script (pseudo-code)

REST API test script
(postman)

For the small number of system non-functional characteristics for which conformance is defined here, the table structure is the same. However, conformance points are not formally defined by the openEHR Service Model, but informally defined by this specification.

6.2. Functional Conformance

6.2.1. Definitions Component

Specifications:

Capability Conformance Point
(Service Model call)
Description Test case script REST script

ADL 1.4 Archetype
provisioning

I_DEFINITION_ADL14
.upload_archetype()

Upload an ADL 1.4 archetype

tc_def-adl14_prov

postman

I_DEFINITION_ADL14
.get_archetype()

Get an ADL 1.4 archetype by archetype_id

I_DEFINITION_ADL14
.list_all_archetypes()

List all available ADL 1.4 archetypes

ADL 1.4
OPT
provisioning

I_DEFINITION_ADL14
.upload_opt()

Upload an ADL 1.4-based OPT

tc_def-opt14_prov

postman

I_DEFINITION_ADL14
.get_opt()

Get template by template_id

I_DEFINITION_ADL14
.list_all_opts()

List all available Operational Templates

ADL2
Archetype
provisioning

I_DEFINITION_ADL2
.upload_artefact()

Upload an ADL 2 archetype

tc_def-adl2_prov

postman

I_DEFINITION_ADL2
.get_artefact()

Get an ADL 2 archetype by archetype_id

I_DEFINITION_ADL2
.list_all_archetypes()

List all available ADL 2 archetypes

ADL2
OPT
provisioning

I_DEFINITION_ADL2
.upload_artefact()

Upload an OPT2 template.

I_DEFINITION_ADL2
.get_artefact()

Get OPT2 template by template_id.

I_DEFINITION_ADL2
.list_all_opts()

List all available OPT2 templates.

Query
provisioning

I_DEFINITION_QUERY
.register_query()

Register a query under an optional name.

tc_def-qry_prov

postman

I_DEFINITION_QUERY
.list_all_queries()

List all registered queries.

I_DEFINITION_QUERY
.list_all_matching_queries()

List registered queries matching a pattern.

I_DEFINITION_QUERY
.delete_query()

Delete a query.

6.2.2. EHR Persistence Component

Specifications:

Capability Conformance Point
(Service Model call)
Description Test case script REST script

EHR Operations

I_EHR_SERVICE
.create_ehr()

Create a new EHR; EHR id generated by system

tc_ehr-create

postman

I_EHR_SERVICE
.create_ehr_with_id()

Create new EHR with the specified EHR id

tc_ehr-create_id

postman

I_EHR_SERVICE
.create_ehr_for_subject()

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

tc_ehr-create_sub

postman

I_EHR_SERVICE
.create_ehr_for_subject_with_id()

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

tc_ehr-create_sub_id

postman

I_EHR_SERVICE
.get_ehr()

Get EHR with the specified EHR identifier.

I_EHR_SERVICE
.get_ehrs_for_subject()

Get EHR(s) for specified subject.

tc_ehr-get_sub

postman

EHR Status

I_EHR_STATUS
.get_ehr_status()

Get EHR modifiable and queryable status.

tc_ehr-status

postman

I_EHR_STATUS
.get_ehr_status_at_time()

Get Ehr status at specified time

I_EHR_STATUS
.clear_ehr_modifiable()

Set EHR to non-modifiable.

I_EHR_STATUS
.clear_ehr_queryable()

Set EHR to non-queryable.

I_EHR_STATUS
.set_ehr_modifiable()

Set EHR to modifiable.

I_EHR_STATUS
.set_ehr_queryable()

Set EHR to queryable.

I_EHR_STATUS
.update_other_details()

Update other EHR status details.

Composition Operations

I_EHR_COMPOSITION
.create_composition()

Create a new Composition.

tc_ehr-comp

postman

I_EHR_COMPOSITION
.get_composition()

Get Composition by id.

I_EHR_COMPOSITION
.get_composition_at_time()

Get Composition at specified time.

I_EHR_COMPOSITION
.update_composition()

Create a new version of a Composition.

I_EHR_COMPOSITION
.delete_composition()

Logically delete a Composition.

Directory Operations

I_EHR_DIRECTORY
.create_directory()

Create new directory in EHR.

tc_ehr-dir

postman

I_EHR_DIRECTORY
.get_directory()

Get Directory, current version.

I_EHR_DIRECTORY
.get_directory_at_time()

Get Directory at specified time.

I_EHR_DIRECTORY
.update_directory()

Update EHR directory.

I_EHR_DIRECTORY
.delete_directory()

Delete EHR directory.

Change sets

I_EHR_CONTRIBUTION
.commit_contribution()

Commit Contribution with one Composition.

tc_ehr-ctrb_smpl

postman

Commit Contribution with new Compositions, Directory.

tc_ehr-ctrb_cplx

postman

Commit mixed update Contribution with new, changed, deleted items.

tc_ehr-ctrb_mix

postman

I_EHR_CONTRIBUTION
.get_contribution()

Get Contribution.

tc_ehr-ctrb_get

postman

I_EHR_CONTRIBUTION
.list_all_contributions()

List Contributions

tc_ehr-ctrb_list

postman

Versioning

I_EHR_STATUS
.get_versioned_ehr_status()

Get Versioned Ehr status

tc_ehr-vers

postman

I_EHR_STATUS
.get_ehr_status_at_version()

Get Ehr status at version

I_EHR_DIRECTORY
.get_versioned_directory()

Get Versioned Directory

I_EHR_DIRECTORY
.get_directory_at_version()

Get Directory at version

I_EHR_COMPOSITION
.get_versioned_composition()

Get Versioned Composition

I_EHR_COMPOSITION
.get_composition_at_version()

Get Composition at version

Archetype
Validation

I_EHR_COMPOSITION
.create_composition()

Attempt to create new Composition; reject invalid archetype structure.

tc_ehr-arch_val

postman

I_EHR_COMPOSITION
.create_composition()

Attempt to create new Composition; reject invalid archetype.

I_EHR_COMPOSITION
.update_composition()

Attempt to update Composition; reject invalid archetype structure.

I_EHR_COMPOSITION
.update_composition()

Attempt to update Composition; reject invalid archetype.

6.2.3. Demographic Persistence Component

Specifications:

Capability Conformance Point
(Service Model call)
Description Test case script REST script

Party
Operations

I_DEMOGRAPHIC_SERVICE
.create_party()

Create a new Party; Party id generated by system.

tc_dem-party

postman

I_PARTY
.get_party()

Retrieve a Party, current version.

I_PARTY
.get_party_at_time()

Retrieve a Party, at a specified time.

I_PARTY
.update_party()

Update a Party.

I_PARTY
.delete_party()

Delete a Party.

Party
Relationship
Operations

I_DEMOGRAPHIC_SERVICE
.create_party_relationship()

Create a new Party relationship; Relationship id generated by system.

tc_dem-party_rel

postman

I_PARTY_RELATIONSHIP
.get_party_relationship()

Retrieve a Party relationship, current version.

I_PARTY_RELATIONSHIP
.get_party_relationship_at_time()

Retrieve a Party relationship, at a specified time.

I_PARTY_RELATIONSHIP
.update_party_relationship()

Update a Party relationship.

I_PARTY_RELATIONSHIP
.delete_party_relationship()

Delete a Party relationship.

Versioning

I_PARTY
.get_party_at_version()

Retrieve a Party, current version.

tc_dem-vers

postman

I_PARTY_RELATIONSHIP
.get_party_relationship_at_version()

Retrieve a Party relationship, current version.

Archetype
Validation

I_DEMOGRAPHIC_SERVICE
.create_party()

Attempt to create new Party; reject invalid archetype structure.

tc_dem-arch_val

postman

Attempt to create new Party; reject invalid archetype.

I_PARTY_SERVICE
.update_party()

Attempt to update Party; reject invalid archetype structure.

Attempt to update Party; reject invalid archetype.

6.2.4. Querying Component

Specifications:

Capability Conformance Point
(Service Model call)
Description Test case script REST script

AQL Basic

I_QUERY_SERVICE
.execute_stored_query()

Execute a simple stored patient query.

tc_aql-stor_basic

postman

I_QUERY_SERVICE
.execute_ad_hoc_query()

Execute a simple ad hoc patient query.

tc_aql-adhoc_basic

postman

AQL Advanced

I_QUERY_SERVICE
.execute_stored_query()

Execute a complex stored patient query.

tc_aql-stor_cplx

postman

I_QUERY_SERVICE
.execute_stored_query()

Execute a complex stored population query.

tc_aql-pop_cplx

postman

AQL &
Terminology

I_QUERY_SERVICE
.execute_stored_query()

Execute a stored query that interfaces with terminology service.

tc_aql-stor_term

postman

6.2.5. Admin Product Component

Specifications:

Capability Conformance Point
(Service Model call)
Description Test case script REST script

Activity Report

I_ADMIN_SERVICE
.list_contributions()

List Contributions in a time interval.

tc_adm-actv_rpt

postman

I_ADMIN_SERVICE
.contribution_count()

Get number of Contributions in a time interval.

I_ADMIN_SERVICE
.versioned_composition_count()

List Versioned Compositions in a time interval.

I_ADMIN_SERVICE
.composition_version_count()

Get number of Composition versions in a time interval.

Physical Deletion

I_ADMIN_SERVICE
.physical_ehr_delete()

Physically delete an EHR.

tc_adm-ehr_del

postman

I_ADMIN_SERVICE
.physical_party_delete()

Physically delete a Party.

tc_adm-party_del

postman

EHR Dump/Load

I_ADMIN_DUMP_LOAD
.export_ehrs()

Export all EHRs from EHR service.

tc_adm-dump_load

postman

I_ADMIN_DUMP_LOAD
.load_ehrs()

Populate the EHR service from a file archive.

EHR Archive

I_ADMIN_ARCHIVE
.archive_ehrs()

Archive selected EHRs from EHR service.

tc_adm-arcv_ehrs

postman

Demographic Archive

I_ADMIN_ARCHIVE
.archive_parties()

Archive selected Parties and relationships from Demographic service.

tc_adm-arcv_party

postman

6.2.6. Messaging Component

Specifications:

Capability Conformance Point
(Service Model call)
Description Test case script REST script

EHR Extract

I_EHR_EXTRACT
.export_ehr()

Export whole EHR for one subject.

tc_msg-extr_ehr

postman

I_EHR_EXTRACT
.export_ehr_extract()

Export an extract for an EHR.

tc_msg-extr_extr

postman

I_EHR_EXTRACT
.export_ehrs()

Export multiple whole EHRs in Extract form.

tc_msg-extr_ehrs

postman

I_EHR_EXTRACT
.export_ehr_extracts()

Export extracts of multiple EHRs.

tc_msg-extr_extrs

postman

TDD

I_TDD
.import_tdd()

Import a TDD for one EHR.

tc_msg-tdd_ehr

postman

I_TDD
.import_tdds()

Import a TDDs for multiple EHRs.

tc_msg-tdd_ehrs

postman

6.2.7. REST API Component

Specifications:

Product
Component
Capability Description Test case Script REST Script

DEFINITION API

I_DEFINITION_ADL14
I_DEFINITION_ADL2
I_DEFINITION_QUERY

Exercise all functions & arguments

tc_api-rest_def

postman

EHR API

I_EHR_SERVICE

Exercise all functions & arguments

tc_api-rest_ehr

postman

DEMOGRAPHIC API

I_DEMOGRAPHIC_SERVICE

Exercise all functions & arguments

tc_api-rest_dem

postman

QUERY API

I_QUERY_SERVICE

Exercise all functions & arguments

tc_api-rest_qry

postman

ADMIN API

I_ADMIN_SERVICE
I_ADMIN_DUMP_LOAD
I_ADMIN_ARCHIVE

Exercise all functions & arguments

tc_api-rest_adm

postman

MESSAGE API

I_EHR_EXTRACT
I_TDD

Exercise all functions & arguments

tc_api-rest_msg

postman

6.3. Non-Functional Conformance

6.3.1. Security and Privacy

Specifications:

Capability Conformance Point Description Test case script REST script

Signing

I_EHR_COMPOSITION
.create_composition()

Create a new signed Composition.

tc_secpriv-sign

postman

Anonymous EHRs

I_EHR_COMPOSITION
.create_composition()
I_DEMOGRAPHIC_SERVICE
.create_party()

Create a new EHR, Demographic Party, and external link.

tc_secpriv-anon_ehr

postman

7. Profiles

The schedule above describes capabilities of openEHR platform products that can be tested against the published specifiations. 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.

Producers of tender specifications and procuring organsations should create the Profile(s) they require. This should be done by adopting either the CORE or STANDARD base profiles and then adding in the set of options required.

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

Definitions

ADL 1.4 Archetype
provisioning

ADL 1.4 OPT
provisioning

ADL 2 Archetype
provisioning

ADL 2 OPT
provisioning

Query
provisioning

EHR
Persistence

EHR Operations

EHR Status

Composition
Operations

Directory
Operations

Change sets

Versioning

Archetype
Validation

Demographic
Persistence

Party Operations

Party
Relationship
Operations

Archetype
validation

Querying

AQL basic

AQL advanced

AQL & terminology

Admin

Activity Report

Physical Deletion

EHR Dump/Load

Bulk EHR load

EHR Archive

Demographic Archive

Messaging

EHR Extract

TDS

REST APIs

DEFINITION API

EHR API

DEMOGRAPHIC API

QUERY API

ADMIN API

MESSAGE API

7.1.2. Non-Functional

Product Attribute Capability CORE STANDARD OPTIONS

Security &
Privacy

Signing

Anonymous EHRs

7.1.3. Other Non-Functional

Product Attribute Values

External Data Format

XML, JSON