Problem statement

The notion of a 'system' has not been clearly defined in openEHR to date, and has changed since the original specifications were published. 

We need:

• a definition, that takes account of cloud, multi-tenancy, openEHR solutions used as gateways or caches and so on
• definition of 'system_id' in the specs
• guidance on use of system id in version ids, REST APIs and other contexts

It is proposed to add content developed here to the Architecture Overview in BASE release 1.0.4

Design Concepts

What is a 'system'?

The term 'system' is used in various places in the openEHR specifications e.g. where the 'creating system' needs to be identified for an EHR, system id in the branched versioning model and so on. The original concept was that an openEHR 'system' refers to the back-end platform environment, that is to say a single EHR +/- demographics environment. Today we might call this an 'openEHR platform instance' or similar.

In older-style site-based architectures, the location of the 'system' is clear - it is physically and logically in the customer (health provider) location.

Enterprise System is the kind of system we are talking about here. Enterprise System is an overall combination of computerhardware and software that a business uses to organize and run its operations. For example, an integrated enterprise system will generally handle more than one operation for a company to facilitate its business and management reporting needs http://www.businessdictionary.com/definition/enterprise-system.html

In more modern virtualised / cloud-based architectures, the 'system' may physically reside in a multi-tenanted virtualised infrastructure similar to Amazon or a similar provider (typically not Amazon but a national or at least EU data centre provider). In this case, the domain name should still relate to the health provider or other customer - it has nothing to do with the virtualisation or cloud suppliers.

System Identifier

The purpose of using a system id in the openEHR specifications is primarily to determine:

• where an EHR was originally created (typically some hospital, or maybe a national summary health record) and
• where imported data were created, by use of the virtual versioning approach defined in the Change Control model of the specifications.

The system should be identified by a reverse internet domain name, e.g. no.helse-bergen.xyz might be a hospital in Bergen. The internet domain relates to the installation, not the vendor of the system, and as such is usually going to be based on a health provider domain.

Normally, domain names (and thus reverse domain names) are reliable and hard to fake in a secure environment, due to the reasonably tight control of the global DNS, so they are a reasonable way of identifying the origin of EHRs and EHR data (and other data, e.g. demographic) within openEHR environments, including where synchronisation needs to be implemented.

We may need to improve and/or clarify the specifications to better explain the 'system' concept.