Interoperability within Health & Social Care Systems

Transcription

1 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 review 1 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 30/01/2008

2 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 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 30/01/2008

3 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 30/01/2008

4 in ISO 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 30/01/2008

5 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 30/01/2008

6 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 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 30/01/2008

7 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 30/01/2008

8 Bibliography Aguilar. A, Semantic Interoperability in the Context of e-health. Digital Enterprise Research Institute, National University of Ireland, Galway, Ireland 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 , and IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. IEEE Standards, New York, IEEE-USA. Interoperability for the National Health Information Network. Statement by the Board of Directors of IEEE_USA Position Rossi Mori, A. Consorti, F. Ricci, F. L. Sharing Clinical Information. Principles and Task-orientated Solutions. Proceedings of EuroRec 01, the 4 th European Working Conference on Electronic Health Records Tolk, A. Muguira, J. A. The levels of Conceptual Interoperability Model 2003 Fall Simulation Interoperability Workshop Orland, Florida Webopedia. The 7 Layers of the OSI Model Wikipedia. Definition of Interoperability Wikipedia. Definition of Interoperability P Amos 8 30/01/2008