Interoperability within Health & Social Care Systems
1. Introduction:
The purpose of this short paper is to provide a set of ‘working’ definitions for the
concept of interoperability within the Health and Social Care setting such that
standards developers and appraisers of the submitted standards share a
common understanding of what has become a complex and evolving concept.
Agreement upon a common definition and its context is important not because we
disagree but because we all use the same term presuming that we share a
common understanding when in fact we do not. Such misunderstandings may
lead to a failure in system to system interoperability at best or at worst to put
patient safety at risk.
The requirement to define and understand what is meant by interoperability
arises because there is a desire to harness the potential benefits to patients of
enhanced communication technologies and the processing power of computers
that can aid and support the diagnoses, treatment and management of our
patients.
A recent review1 identified 65 definitions for interoperability from standards
development organisations, health care organisations, professional societies and
government agencies of which two thirds were from health related institutions.
Analysis of these definitions identified substantial differences; however three
principle types of interoperability could be distinguished, in order of least to
greatest interoperability from system to system:
Technical Interoperability
Semantic Interoperability
Process Interoperability.
Let us imagine a situation in which a clinician has been cloned in such a way that
they both share the same level of clinical knowledge and experience. A patient is
presented to them and following a complete and thorough discussion with the
patient about his family, social and clinical history followed by a thorough physical
examination both clinicians share a common, detailed understanding of the
patient, their presenting complaints and physical findings.
Given that these 2 clinicians are clones of each other we would like to believe
that they would each request the same investigations, interpret these
investigations in the same way and propose a treatment plan that was identical.
These 2 clinicians are now separated such that they are in different locations.
The patient returns to one of the clinicians with a different complaint. The
clinician takes a history and carries out an examination and records the detail of
his findings and orders some investigations. At this point the patient moves
location and his care is transferred to the second of the cloned clinicians. The first
clinician sends to the second clinician all the detail about the recent encounter
with the patient. The second clinician receives the results of the investigations,
makes a diagnosis and proposes a treatment plan.
1
Coming to Terms: Scoping interoperability for Health Care. Health Level Seven (2007)
P Amos
1
Interoperability within Health and Social Care Systems V1.0
30/01/2008
Because both clinicians have identical knowledge and experience and both share
the full details about the patient they are able to make the same diagnosis and
propose identical treatment plans even though they may be separated by
distance and time.
The purpose of understanding and defining system to system interoperability is to
be able to describe a series of ‘levels’ where the highest level replicates the level
of interoperability that has been attained by the 2 cloned clinicians described
above, i.e. the 2 systems share the complete set of data about the patient and
are programmed to arrive at the same diagnosis and propose the same treatment
plan without human intervention.
No interoperability between systems; i.e. 2 different stand alone systems, could
be characterised as a situation in which the 2 clinicians and patient all spoke
different languages and where the 2 clinicians had no shared knowledge and
experience.
Clearly with the current level of computer processing power, sophistication of
software and ability to interface and interoperate the options open to us know lie
somewhere between these two extremes.
The remainder of this paper explains the context of use for each of the three
identified types of interoperability, proposes a definition, and identifies some of
the implications for data set developers and appraisers.
2. Technical Interoperability:
When two clinical professionals communicate with each other about a patient it is
on the basis of a shared understanding of the clinical domain and a shared
knowledge of the context in which the clinical investigations, procedures and
findings are described. Where the clinical professionals are separated by time
and/or place the communication takes place through the medium of the written
word using a shared common language and may be presented in a standard
format such as an agreed layout for a referral letter, discharge summary or
clinical note in the patients’ record.
The advent of communication technology enabled this information to be
communicated electronically with others.
Within the scope of technical
interoperability there are a number of ‘levels’ of system sophistication:
A hand written referral letter is faxed to the receiving clinician
An email is sent from the referring to the receiving clinician
A coded management or clinical data set is extracted from the host
system into an Excel spreadsheet which is sent as an attachment to the
receiving system where it is aggregated into the host database.
An extract from a local clinical system is sent in an xml document using a
standard messaging protocol which is then incorporated into the host
clinical system
In each of the examples quoted above the system acts simply as the conveyor of
the data. It neither ‘understands’ the data nor is it capable of converting or
processing the data into information. The ability of the receiver to interpret the
data received depends upon the completeness of the data sent, the use of a
common language and a shared knowledge and understanding of the domain,
whether clinical or managerial.
P Amos
2
Interoperability within Health and Social Care Systems V1.0
30/01/2008
Communication between systems sufficient to satisfy technical interoperability
must adopt technical standards to ensure that the data is conveyed (exchanged)
from one system to another without change or corruption.
Adherence to the Open Standards Interconnection (OSI) model to level 6
and 7
Standards that describe the interface between systems
Standards that describe the electronic message content and format
(EDIFACT & HL7)
The meaning and context of the data cannot be understood or further processed
by the system and must be interpreted by the receiver. The receiver is
dependent upon the narrative and/or the structure that is associated with the data
to understand the context and meaning. Where this does not exist within the sent
message or where the system only preserves the data and not its context and
structure the receiver can only rely upon the integrity of the individual data items.
Technical interoperability also supports coded information using standard
classifications such as ICD-10/OPCS, early forms of Read Codes etc. which may
be sent using early messaging standards such as HL7 v2 and EDIFAT. These
are suitable to support the communication of clinical and management data as
described above and data for secondary purposes but with the limitations already
described.
Proposed Definition:
“Technical Interoperability” means the ability of two or more systems to exchange
data accurately, effectively, securely, and consistently such that the relationship
between the data items is preserved between the sending and receiving system
The proposed definition supports the requirements described above but also
adds the requirement for preservation of the relationship between data items.
Many definitions of technical interoperability simply state that the data should be
‘useful’, however useful is not defined. It is proposed that the relationship
between the data items is important to make the data useful and to offer a degree
of patient safety.
Having established the context and definition of Technical Interoperability it is
possible to draw up a list of requirements for the developer against which the
appraiser can check for conformance.
A clearly defined scope and purpose for the dataset that excludes system
processing of the data that aims to add data or create information
The adoption of ISB HaSC approved national and international technical
and message standards, such as Hl7. Clearly stating the version and
version date of the standards used.
Where appropriate the adoption of ISB HaSC approved standard
classifications, such as ICD, OPCS4 and Read Codes. Clearly stating the
version and version date of the standards used.
Clearly defined data items (elements) and associated value sets that have
the appropriate professional sign off and which adhere to guidance set out
P Amos
3
Interoperability within Health and Social Care Systems V1.0
30/01/2008
in ISO 11179 and are consistent with eGIF, NHS Data Dictionary and the
NHS Reference Information Model (RIM)
A clearly defined maintenance and updating process which takes account
of the updating cycles of the standards referred to above and includes
liaison and sign off from all of the relevant stakeholders
Specification, implementation and user guidance that clearly identifies
what standards have been adopted within the data set, gives guidance on
its implementation and use and defines a set of conformance criteria
against which the user can be performance managed
3. Semantic Interoperability:
Technical interoperability supports the exchange of data accurately and
consistently. The next leap of interoperability exchanges not just data but the
meaning of that data such that the meaning and context of that information
remains complete. As with technical interoperability, semantic interoperability
includes within it a number of increasingly sophisticated levels of interoperability.
At its simplest a faxed letter between clinicians, if appropriately detailed may be
sufficient to convey to the receiving clinician all that is necessary to fully
understand the meaning and context of the clinical situation. In this example
semantic interoperability exists at the human level and the system is operating at
the technical interoperability level.
Examples of the kinds of functionality that a semantically interoperable system
might support include:
The ability to create and exchange patient information in such a ways as
to clearly convey to the receiving system the exact context and meaning
of the record when it was created. i.e. not just the blood pressure reading
but the state of the patient at the time of the observation, the position of
the patient during the procedure and the device that was used to take the
measurement. For a biochemical finding one might also receive the
laboratory reference range and an indication of whether the reading was
normal or abnormal for the sex and age of the patient.
Administrative functions such as call and recall for cervical smears and
immunisations. This requires the system to be able to identify whether a
cervical smear or immunisation has occurred in the past and then
calculating whether the elapse time is outside or inside the accepted norm
for recall.
Allergy alerts - the system is aware of the patient’s allergy and will alert
the prescribing clinician should they try to prescribe a drug that contains
an ingredient that the patient is know to be allergic.
Drug contraindications – the system is able to identify all of the
contraindications to a particular course of treatment and then search the
patient’s record to ascertain whether they have any, and then alert the
clinician to the possibility that a contraindication exists.
In order for systems to be able to support semantic interoperability it is necessary
to adhere to the standards required to support technical interoperability and in
addition the following:
P Amos
4
Interoperability within Health and Social Care Systems V1.0
30/01/2008
a shared clinical terminology with defined concepts and an ability to
further refine and qualify these concepts according to an agreed set of
implementation guidelines
a shared model of context
a shared record architecture
a shared messaging infrastructure
Where systems do not share these common attributes there will be a requirement
for a mapping between the terminology/models implemented by each individual
communicating system.
Wherever such a mapping is required there is
opportunity for errors and therefore increased clinical risk to patients arises.
Where ever possible this situation should be avoided.
As the level of system to system semantic interoperability increases there is a
requirement for the sending system to have recorded within the patient record the
appropriate level of detail. Therefore, in the example of the blood pressure
reading above the sending system will need to have recorded the device and
position of the patient when the blood pressure was taken.
The recording burden may be reduced by using a standard set of pre-populated
values, in the form of a template, which would account for the standard method of
carrying out the procedure. Any variation from the standard would require the
recording of additional data.
Proposed Definition
Semantic Interoperability" means the ability to communicate and exchange
information accurately, effectively, securely, and consistently between different
information technology systems, software applications, and networks in various
settings, and exchange data such that clinical or operational purpose, context
and meaning of the information are preserved and unaltered.
The system will be capable of utilising this information to provide simple and
complex alerts and interface with decision support applications.
The demands upon data set and system developers increase as the level of
system to system semantic interoperability increases. The adherence to
standard terminologies, models of context, record structures and architectures
becomes paramount.
Having established the context and definition of Semantic Interoperability it is
possible to draw up a list of requirements for the developer against which the
appraiser can check for conformance:
A clearly defined scope and purpose for the dataset that may include
system processing of the data that aims to provide system alerts and/or
interface with decision support systems
The adoption of ISB HaSC approved national and international technical
standards for models of context, record architecture, and message
standards, such as Hl7. Clearly stating the version and version date of
the standards used.
P Amos
5
Interoperability within Health and Social Care Systems V1.0
30/01/2008
The adoption of ISB HaSC approved standard clinical terminologies such
as SNOMED CT, drugs databases and knowledge bases. Clearly stating
the version and version date of the standards used.
Clearly defined data items (elements) and associated value sets that have
the appropriate professional sign off and which adhere to guidance set out
in ISO 11179 and where appropriate consistent with eGIF, NHS Data
Dictionary and the NHS Reference Information Model (RIM)
Evidence that these data items can be derived from the operational
electronic health record and/or the mechanisms that would be put in place
to ensure that the appropriate level of detail is collected.
A specification of the behaviour expected of the sending and receiving
system in the event that there is insufficient data to support the proposed
task
Where data item values are obtained by applying an algorithm such as
working out the age of the patient from the date of birth, or establishing
whether a haemoglobin level is appropriate for the patients age and sex it
will be necessary to identify the core data items (including, if appropriate,
qualifiers and context), the algorithm used and how the developer intends
to measure conformance on operational systems
A clearly defined maintenance and updating process which takes account
of the updating cycles of the standards referred to above and includes
liaison and sign off from all of the relevant stakeholders
Specification, implementation and user guidance that clearly identifies
what standards have been adopted within the data set, gives guidance on
its implementation and use, and defines a set of conformance criteria.
4. Process Interoperability:
Although no examples of process interoperability currently exist within the
healthcare domain a number of academic institutions have postulated that it
should be possible to build upon the semantic interoperable system such that the
information can be processed into a sequence of system prompts and behaviours
that can co-ordinate the work process of the care team.
In the emergency clinical situation a patient who has been identified by the
ambulance paramedic will have had his vital signs taken and entered into the
ambulance based clinical system along with the history of acute haematemesis.
The ambulance system will communicate this information to the hospital A&E
system that retrieves the patients’ hospital records and identifies that the patient
has previously attended the hospital with bleeding oesophageal varices.
An automatic order is made to haematology for the appropriate blood and fresh
frozen plasma to be delivered to A&E ready for a potential transfusion and the
resuscitation team informed to be ready to resuscitate the patient and introduce a
Sengstaken-Blakemore tube.
The A&E system will have available for the receiving clinician a summary of the
patients previous history along with the latest available key blood results from a
recently attended outpatient appointment. The system may also alert the
clinician to any pre-existing disorders, allergy and HIV status.
P Amos
6
Interoperability within Health and Social Care Systems V1.0
30/01/2008
Proposed Definition
“Process Interoperability" means the ability to communicate and exchange
information accurately, effectively, securely, and consistently between different
information technology systems, software applications, and networks in various
settings, and exchange data such that clinical or operational purpose, context
and meaning of the information are preserved and unaltered.
The system will be capable of utilizing this information to provide simple and
complex alerts and interface with decision support applications and in addition
will be capable of filtering and summarising information and presenting this to the
clinical team along with triggers that support work processes and care plans.
The system requirements and adherence to standards to support process
interoperability will include all of those listed for technical and semantic
interoperability.
The primary difference between semantic and process interoperability is the
systems ability to respond to an agreed set of pre-conditions in a predictable and
consistent way.
As such systems currently do not exist within health care one can only make an
informed judgement as to the data set requirements and specification of system
behaviours that the developer would need to provide and against which the
appraiser can check for conformance. What follows is a fist pass at this list:
A clearly defined scope and purpose for the proposed system prompt or
behaviour
A set of pre-conditions that trigger the system prompt or behaviour
A specification of the behaviour expected of the sending and receiving
system in the event that there is insufficient data to support the proposed
prompt or system behaviour
A data set for each of the identified pre-conditions – the specification for
the data set must fulfil all of those requirements set out for semantic
interoperability
A set of conformance criteria against which the system can be tested
P Amos
7
Interoperability within Health and Social Care Systems V1.0
30/01/2008
Bibliography
Aguilar. A, Semantic Interoperability in the Context of e-Health. Digital Enterprise
Research Institute, National University of Ireland, Galway, Ireland. 2005
C41SR Levels of Information Systems Interoperability (LISA) Interoperability Working
Group, Department of Defense. Washingto D.C., 1998
Coming to Terms: Scoping Interoperability for Health Care. Health Level Seven 2007
Garde, S. Knaup, P. Hovenga, E. J. S. Heard, S. Towards Semantic Interoperability
for Electronic Health Records. Methods Inf Med 3/2007
IEEE STD 610.12, and IEEE Standard Computer Dictionary: A Compilation of IEEE
Standard Computer Glossaries. IEEE Standards, New York, 1990.
IEEE-USA. Interoperability for the National Health Information Network.
Statement by the Board of Directors of IEEE_USA. 2005
Position
Rossi Mori, A. Consorti, F. Ricci, F. L. Sharing Clinical Information. Principles and
Task-orientated Solutions. Proceedings of “EuroRec 01”, the 4th European Working
Conference on Electronic Health Records. 2001
Tolk, A. Muguira, J. A. The levels of Conceptual Interoperability Model 2003 Fall
Simulation Interoperability Workshop Orland, Florida. 2003
Webopedia. The 7 Layers of the OSI Model
http://webopedia.internet.com/quick_ref/OSI_Layers.asp
Wikipedia. Definition of Interoperability
http://en.wikipedia.org/wiki/Semantic_interoperability
Wikipedia. Definition of Interoperability
http://en.wikipedia.org/wiki/Interoperability
P Amos
8
Interoperability within Health and Social Care Systems V1.0
30/01/2008