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: www.openehr.org

Amendment Record

Issue Details Raiser Completed

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

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.

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. Conformance points are based on openEHR Platform Service Model 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 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.

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              |Result  |
|Component     |Component    |(PROFILE)      |                             |Case              |        |
+==============+=============+===============+=============================+==================+========+
|ACME CDR      |EHR          |EHR Operations |I_EHR_SERVICE.               |                  |        |
|              |persistence  |               |create_ehr()                 |tc_ehr-create     |pass    |
|              |             +---------------+-----------------------------+------------------+--------+
|              |             |Versioning     |I_EHR_COMPOSITION.           |                  |        |
|              |             |               |get_versioned_composition()  |tc_ehr-vers       |pass    |
|              |             |               +-----------------------------+------------------+--------+
|              |             |               |I_EHR_CONTRIBUTION.          |tc_ehr-ctrb_smpl  |pass    |
|              |             |               |commit_contribution()        |tc_ehr-ctrb_cplx  |FAIL    |
+--------------+-------------+---------------+-----------------------------+------------------+--------+
|                                          . . . .                                                     |
+--------------+-------------+---------------+-----------------------------+------------------+--------+
|etc           |etc          |etc            |etc                          |etc               |        |
+==============+=============+===============+=============================+==================+========+


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)

It is assumed that any system provided to be tested for conformance under this specification has a platform architecture, i.e. consisting of one or more product components that are exposed via corresponding services, and that the component semantics 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 components.

The service interface of any component can be understood at two levels: an abstract formal interface, and one or more implementation technology interfaces. The former is defined in terms of a formal service model, which is considered normative in openEHR, and is understood as expressing the formal, transactional semantics of each component.

At an implementation technology level, the service model may be directly exposed as a software component interface e.g. a Java .jar, .Net assembly, Linux .so library etc. Such programming models will usually implement the transactional interfaces in a direct sense, and can thus be considered concrete implementations of the service model.

The transactional service model will also usually be available via one or more web protocol interfaces in the form of WSDL/SOAP and/or REST APIs. Any such interface is assumed to connect to the underlying transactional interface. A REST API is assumed to exist for the purposes of conformance testing. Accordingly, the formal expression of test cases that exercise underlying service calls is in the form of scripts based on the REST API.

Each of the concretely available implementation technology interfaces is also regarded as a product component, for which conformance testing may be conducted.

Note
this may be augmented in the future by an equivalent set of test cases for WSDL/SOAP and other API technologies.

In addition, in order to enable testing to take place, various tools are recommended, including a system log viewer, a data viewer and a test application.

The following figure illustrates the test environment, based on currently available specifications. As further specifications are published, the extent of coverage of testing will grow.

conformance sut
Figure 1. Conformance System Under Test

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.

The following sections describe the elements of this environment in more detail.

5.1.1. Normative Platform Service Model

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

SM platform model
Figure 2. Normative openEHR Platform

The functions defined on these interfaces constitute the formal 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.1.2. REST APIs

As a practical measure for the purposes of undertaking testing, this specification assumes that service interfaces to be tested are concretely accessible by the openEHR REST APIs. For this reason, the openEHR REST APIs are assumed to be implemented by the system to an extent sufficient 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. In some cases, more than one alternative REST API call can be used to exercise the same underlying service call.

The openEHR REST APIs handle data in two ways: canonical openEHR XML, based on the 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 is the JSON defined, details?

5.1.3. Testing Tools

In order to conduct tests in reasonable way, some further informal assumptions are made about the SUT, as follows:

  • it has a system logger, 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;

  • it may have 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.

Neither of these tools are assumed to conform to any particular specification.

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. 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, and is used as the basis for conformance profiles described in the next section. The remaining columns describe each conformance point, and provide a way of testing it. In many cases, one test script may be used to test multiple conformance points.

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

ADL 2 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

ADL 2 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
.clear_ehr_modifiable()

Set EHR to non-modifiable.

I_EHR_STATUS
.clear_ehr_queryable()

Set EHR to non-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 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
.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_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_STATUS
.get_ehr_status_at_time()

Get Ehr status at time

I_EHR_DIRECTORY
.get_versioned_directory()

Get Versioned Directory

I_EHR_DIRECTORY
.get_directory_at_version()

Get Directory at version

I_EHR_DIRECTORY
.get_directory_at_time()

Get Directory at time

I_EHR_COMPOSITION
.get_versioned_composition()

Get Versioned Composition

I_EHR_COMPOSITION
.get_composition_at_version()

Get Composition at version

I_EHR_COMPOSITION
.get_composition_at_time()

Get Composition version at time

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, current version.

I_PARTY
.get_party_at_version()

Retrieve a Party, current version.

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
.update_party_relationship()

Update a Party relationship.

I_PARTY_RELATIONSHIP
.delete_party_relationship()

Delete a Party relationship.

Archetype
Validation

I_DEMOGRAPHIC_SERVICE
.create_party()

Attempt to create new Party; reject invalid archetype structure.

tc_dem-arch_val

postman

I_DEMOGRAPHIC_SERVICE
.create_party()

Attempt to create new Party; reject invalid archetype.

I_PARTY_SERVICE
.update_party()

Attempt to update Party; reject invalid archetype structure.

I_PARTY_SERVICE
.update_party()

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-def

postman

EHR API

I_EHR_SERVICE

Exercise all functions & arguments

tc_api-ehr

postman

DEMOGRAPHIC API

I_DEMOGRAPHIC_SERVICE

Exercise all functions & arguments

tc_api-dem

postman

QUERY API

I_QUERY_SERVICE

Exercise all functions & arguments

tc_api-qry

postman

ADMIN API

I_ADMIN_SERVICE
I_ADMIN_DUMP_LOAD
I_ADMIN_ARCHIVE

Exercise all functions & arguments

tc_api-adm

postman

MESSAGE API

I_EHR_EXTRACT
I_TDD

Exercise all functions & arguments

tc_api-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 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.

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