As part of building services for e-health, we have to consider what a comprehensive services landscape would look like, as a guide to future work in openEHR and elsewhere. This page makes a new proposal, based on recent perspectives, notably: cloud; clinical process; universal terminology.
The following illustrates an initial version of this landscape. In this diagram, all labelled boxes represent logical transactional services (i.e. the concrete interfaces may be REST, SOAP, messages or multiple). Cylinders denote important persistence services. This diagram does not attempt to identify all or even most possible services - just some important ones. It is more intended to suggest a services 'space' in which different kinds of service can be situated, according to various dimensions of the service.
Things that are not on this diagram but are assumed to exist:
pervasive security services
integration engines
generic service bus
numerous services to do with special facilities, such as Lab, Radiology and so on.
applications. However, we might think about adding a few applications to make it easier to understand what the services are doing.
The approach here is meant to be future-looking, and goes beyond current specifications, including the Conformance 'System under test', the Platform Abstract Service Model, and the REST APIs.
There is no intention here to define precise APIs, nor to imply a specific API technology such as REST, SOAP, RPC etc. These are questions for dedicated standardisation and implementation activities.
Other reference architectures / maps for services in e-health are as follows:
The HSSP Services Reference Architecture from HL7 and OMG.
Readers who know of other such resources, please post in comments below and we'll add them.
If you would like to react by proposing adjusted versions of this diagram, feel free to do so - the original .xml file for draw.io is here. Otherwise, feel free to add to this page, or comment below.
The following illustrates the landscape structure on its own.
In the sense intended here, a 'service' is an exposed software component with a defined API consisting of logical functions and procedures required for the purpose of the service. For example, the EHR service in the diagram below corresponds to the notion of a generic service for creating and accessing persisted clinical data, with functions of the following kind:
hasEhr (ehrId): Boolean
createEhr (ehrId)
retrieveEhrData (ehrId, itemId, ...): EhrItem
A single logical function or procedure has the following form:
Type someFunction (Type arg1, Type arg2, ...)
pre-conditions: <boolean expression>
post-conditions: <boolean expression>
exceptions: {<exception>}
someProcedure (Type arg1, Type arg2, ...)
pre-conditions: <boolean expression>
post-conditions: <boolean expression>
exceptions: {<exception>} |
Generally speaking, the Types are assumed to come from relevant reference information model(s), although they may also be defined as part of the API itself.
Many services can be understood as a transactional interface to data. For example, the logical API procedure createEhr() above causes a change in underlying persistence store (a new EHR), while the logical function hasEhr() enables the persistent store to be interrogated for presence of an EHR. This kind of interface is a CRUD level interface. Higher level interfaces are also useful, and usually more interesting to application developers. For example, the 'Medications List' service in the diagram below may be designed in terms of transactions on a logical medication list, such as:
MedicationList listMedications (status, ...)
addMedication (MedDescription mDesc; ...)
suspendMedication (MedId medId; ...)
etc
Such higher-level services normally implement their functions in terms of calls to lower-level services, eventually CRUD services.
The following levels of deployment are proposed:
Provider org: Healthcare provider organisation - services required to run the connected facilities of a provider; usually, hospitals, GP clinics, specialists, etc are separated providers from an IT point of view, except for HMO style organisations, which may function as fully connected entities.
Care Network: services that support patient-centric healthcare in the locus of patient service by clinics, hospitals, GPs etc. There might be more than one regional level, e.g. counties, states etc. A 'city' level EHR system, such as in Stockholm, and more recently being developed in Leeds and Manchester in the UK is a regional system in the sense of the landcscape described here. This might also be a full-service HMO like the US VHA or Kaiser Permanente
National: services that operate at a whole-of-healthcare system level.
It is proposed that ideally, shareable patient data exists at a regional level - i.e. supporting a 'single-source of truth' model of patient data and transactional interfaces to things like medication list. Where wider access is needed, e.g. cross-border etc, it is assumed that relevant services at the National level (or even super national level) provide federated views of regional services and data, as well as applying relevant legislation-based rules for data sharing.
Currently, regional or city systems are relatively rare, and many services that ultimately should exist at regional level exist only at the Provider level. In terms of the landscape diagram shown here, one can imagine the dividing line between Provider org and regional levels as starting where the regional/national dividing line is, and moving up over time.
A breakdown into key semantic levels is as follows:
Analytics: retrieval, querying and use of data for any purpose, including health analytics, business analysis, research etc
Process - logistic: administrative level of process that enables healthcare providers to see patients in the appropriate time and place
Process - planning: clinical level of planning, typically driven by guidelines and pathways
Patient information: information about the patient, including longitudinal 'managed lists' (medications, problems, vaccinations etc), events, results, etc
Data services: services that support CRUD operations on healthcare data.
Services are also separated with respect to their different 'focal entity' - what kind of entity do they primarily deal with?
Patient: services targetted to patient data, process, etc.
HCP: services that are have a healthcare professional view, e.g. nurse task list, doctor's appointment book
Enterprise: services that correspond to whole-of-enterprise - e.g. booking system, patient admin etc
Knowledge: services that provide access to knowledge resources
System: services that enable users to access health IT system(s)
The following shows a partially populated form of the above, with some of the key openEHR, terminology and IHE services. It is not meant in any way to be 'complete' - no single diagram could achieve that - but the idea is to get the key common services on the map, in the right places. This particularly applies to working out services that apply at different levels, and appropriate federation relationships, e.g. an appointments service inside a healthcare facility will need to connect to a national booking service.
Name | Focal Entity | Deployment level | Description | Notes |
|---|---|---|---|---|
Task Planning | patient plan | Provider org, regional | Add, retrieve and obtain current status of Task Plans | |
Medications list | patient medication list | Provider org, regional | Transactons and queries on patient single source of truth medication list | |
EHR | patient clinical data | Provider org, regional | CRUD-level operations on EHR data | |