Page Comparison

...

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.

...

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.

...

The following illustrates the landscape structure on its own.

...

What is a 'service'?

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:

...

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.

...

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.

Focal Entity

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)

Partially Populated

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.

...

Service Descriptions