Techniques for ensuring interoperability in an Electronic health Record

Techniques for ensuring interoperability in an Electronic health Record Author: Ovidiu Petru STAN 1. INTRODUCTION Electronic Health Records (EHRs) have a tremendous potential to improve health outcomes but, given the fact that they contain and work with socio-demographical and medical data, it is imperative to provide a high level of security and accuracy. EHRs should contain all the significant events of a person s health history, from minor issues to the most critical medical situations and has to be available at least the entire life of the patient [1]. Nothing is allowed to be excluded or deleted. Generally the medical information systems that exist nowadays in Romania store the clinical information in their own format and they don t guarantee that after the exchange of the information, the original meaning of the medical records was kept. In papers [2] and [3] it is described why the standardization in this field is important and crucial to reduce medical errors caused by wrong data interpretation and representation. Taking into consideration the issues of common terminology and coding systems, integration and interoperability, security and reliability, it is obvious that solid and well agreed standards are needed. Because the medical information has to be accessible anytime from everywhere and without regard to where the patient lives or travels the medical information systems must allow the transfer of medical records between different medical units, but without modifying their original medical meaning. Therefore, a medical information system should provide a high level of semantic interoperability. This avoids fragmentation of health data, overloads the databases with the same information, provides a high quality of healthcare and reduces the cost of patient care [4]. The term Interoperability is defined by The Institute of Electrical and Electronics as the ability of two or more systems or components to exchange and use the information that has been exchanged [5]. This definition encompasses two separate ideas: the first one is the exchange of the information - technical interoperability - so that it is human readable by the receiver and the second one is the ability to understand and to use the information - semantic interoperability. These concepts are interdependent and we need both of them to bring significant benefits. In fact, in order to achieve semantic interoperability we need primarily the technical interoperability. In medical informatics field, the European Commission brings forward three types of interoperability [6]: "interoperability of electronic health record systems": the data exchanged is both computer and human readable information and knowledge

"cross-border interoperability": interoperability between different countries and their entire territories "semantic interoperability": the precise meaning intended by the original author is understandable by any other system or application 2. CORE CONCEPTS 2.1 openehr Specifications The openehr Specifications are developed by an independent nonprofit community. The aims of the foundation are to facilitate the creation and sharing of health records by consumers and clinicians via open-source and standard-based implementations. The registered online community is composed of 1200 members from 75 different countries. It publishes evolving EHR design specifications, strongly underpinned by live clinical demonstrators, using a multimodel approach, including archetypes [7]. The key innovation of the openehr architecture is the two level modeling structures obtained by separating record keeping concerns from clinical data collection using archetypes. The first level, Reference Model, is used to represent the generic properties of health record information. It represents the global characteristics of health record components, the way they are aggregated and the context information required to meet ethical, legal and provenance requirements. This model defines the set of classes forming the generic building blocks of the EHR. It reflects the stable characteristics of an electronic health record [7]. The second level, Archetypes and Templates, are meta-data used to define patterns for the specific characteristics of the clinical data representing the requirements of each particular profession, specialty or service. This level creates a semantic link to the terminologies, clinical guidelines and classifications in the EHRs. The Archetypes are developed by medical staff and, basically, represent a set of constraints on the openehr Reference Model. Archetypes are all expressed in the same formalism. In general, they are defined for wide re-use; however, they can be specialized to include local particularities. They can accommodate any number of natural languages and terminologies [8]. The Template is a locally usable definition which composes archetypes into larger structures often corresponding to a screen form, document, report or message. A template may add further local constraints on the archetypes it mentions, including removing or mandating optional sections, and may define default values. The Template Object Model (TOM) defines the template [11]. The Archetype Object Model (AOM) describes the object model equivalent, in terms of a UML model. It is a generic model, meaning that it can be used to express archetypes for any reference model in a standard way and it defines the semantic of an archetype [9]. Archetype Definition Language (ADL) is a formal language for expressing archetypes developed by openehr and it was also adopted by the European Committee for Standardization (CEN) [10]. In paper [7] is presented in detail the architecture of a correct and efficient openehr based information system. 2.2 EN/ISO-13606 - Electronic Health Record Communication

For the health data communication, there are two important standards: HL7 and EN/ISO 13606. While HL7 is well known worldwide, the EN/ISO-13606 is a European Communication Standard and the first part of it is an ISO Communication Standard and it is derived from the Electronic Health Record Communication Standard ENV13606. Currently this standard is under development at the Technical Committee on Health Informatics of the CEN (CEN/TC 251) and describes the information architecture for interoperability of systems and components needed to communicate (access, transfer, add or modify) EHR data via electronic messages or as distributed objects. As presented in paper [12], it is a five part standard: The Reference Model, Archetype Interchange Specification, Reference Archetypes and Term Lists, Security Features and Exchange Models. This new Electronic Health Record Communication Standard is an extract of openehr and, according to a report of the European Union, complies with the highest level of interoperability [6]. Taking into consideration that EN/ISO 13606 represents a subset of the full openehr specifications, a system based on openehr information model can easily comply with EN/ISO 13606 communication standard and can solve the semantic gap between health professionals and IT professionals (Fig 1). The dual model architecture of openehr and EN/ISO 13606 also influenced the Clinical Document Architecture of HL7. INFORMATION Repository EHR 0101 EHR 0101 EHR 0101 SEMANTIC GAP KNOWLEDGE WORDS MEDICAL TERMS CLINICAL CONCEPTS REFERENCE MODEL ARCHETYPES ONTOLOGY TERMINOLOGY Figure 1 Semantic gap solved by the two level modelling structures 2.3 General Clinical Observation File (GCOF) The General Clinical Observation File, created in the Romanian healthcare system, represents the medical file for recording the evolution of the patient s state in a continuous hospitalization episode. An episode denotes the period while a patient is hospitalized, without interruption and in the same ward. The content of the GCOF is controlled by the Ministry of Public Health. This file contains two sections: the first one contains demographic information and the second one consists of medical data. In the demographic section are fields like name, address, occupation, identity card number, personal identity number, phone number etc. and in the medical section are included all the medical information from the general health state at the admission to epicrisis (diagnostics, treatments, laboratory tests, exams, etc.) 3. PLATFORM ARCHITECTURE

Functionally, the platform architecture can be viewed from two separate perspectives: the first involves a local level, corresponding to a medical unit, while the second the national level representing the whole medical system of country. 3.1 Local level The software architecture at local level refers to the components and functionality that will be reflected in a medical unit in Romania. The design is composed of three levels: the Data level, the Logical management level and the Presentation level (Fig 2). PostgreSQL Server DATA LEVEL EHR 0101 EHR 0101 EHR 0101 PostgreSQL Connector LOGICAL MANAGEMENT LEVEL Template Data Object (TDO) Composition Smarty+ XSLT PRESENTATION LEVEL User/Browser/Workstation Figure 2. Local level structure The connection between the Data level and the Logical management level is insured by the PostgreSQL connector, while Smarty and the XSLT Processor supply the communication between the last two levels. I chose to use PostgreSQL Database Server because of its greatest advantage: stable and efficient support for working with XML documents. It offers a special xml data type used to store XML data. Its advantage over storing XML data in a text field is that it checks the input values. Besides storing well-formed documents, xml data type can store content fragments, which can have more than one top-level element or character node. Because the archetypes and templates of this application are saved in xml format, they will be stored as xml data type. Along with this support, PostgreSQL also offers a set of functions to perform type-safe operations on XML documents. They enable to produce a value of type xml from character data, producing character string type values from xml and safe processing of the xml documents. These functions have the advantage of being stable, unlike the corresponding ones offered by Mysql 5.1 It is also recommended for the present application because it is highly scalable both in the quantity of data

it can manage and in the number of concurrent users it can work with. It is used in collaboration with PHP5. Data level store system information s in a secure environment. Besides information s from GCOF (medical or demographic) data level manages openehr artifacts such as archetypes and templates. In order to fulfill the system security, demographic information is stored separately from patient s medical data. We therefore have three databases: DESP: store and manage the patient s medical data. Demographic: store and manage the patient s demographic data Index: the role of this database is to ensure a connection between the unique demographic identifier and the medical data identifier of a patient. This database is an encrypted one. Logical management level provides mechanisms and processes for: Create and store operational templates Create the composition. Save form data in composition and then save composition in database. Search and display patient medical file. Validate data before saving. An Operational Template (OPT) represents a dynamically created object based on an openehr Template (OET) in combination with the openehr Archetypes. The medical record is displayed on the interface by applying an XSLT on the XML format of the OPT which renders an HTML form. All XML documents are validated using XSD files (XML Schema Definition). The presentation level is used to present and to acquire data to the user. Basically, this level represents the user interface. The separation of the Logical Management Level and Presentation Level represents the separation of the application code and graphic interface. Figure 3 shows the steps that are needed to complete the process of collecting and saving data in a composition. The first step is a database search for openehr archetypes and templates, then are realized the operational template. The HTML form is presented on the screen after applying an XSLT file. After a user inserts information (demographical or medical) is validated and saved in composition type object that are associated with folders. Finally the composition and folders objects are saved in the database. Figure 3 Runtime example

3.2 National level The national level presents how to interconnect different local unit systems to create a national network. Our platform is based on a National Reference Registry and a National Archetype Repository (Fig. 4). For communication we use the EN/ISO 13606 standard. The National Archetypes Repository contains all necessary archetypes defined at national level in openehr format. These are used to ensure the highest semantic interoperability level. For speed and stability reasons, each archetype is saved locally. When changes occur within an archetype, a new version will be created and the old one will not be deleted but it will be used for compatible older records. All the medical units are notified about this change through a SOAP message, so they can download the new version. National Archetype Repository National Reference Registry Archetype definitions Patient references Medial Unit 1 (local level) Patient data Medical Unit 2 (local level) Figure 4 National level architecture The National Reference Registry is an index server storing links to patient data. This is the most important component and it contains demographic and certain medical data (ex: allergies, insurance type, epicrisis). This approach has the advantages that it avoids overloading the system with data. However, a minimum of information must be doubled on the national level because, in the worst case scenario, there may be a time when a link to the medical facility that has the information cannot be determined. The information stored in this repository can be changed according to law. The national reference registry will also contain information regarding the medical unit that stores patient data. Combining this information, an electronic healthcare record about a patient is created. This repository will also meet openehr specification. This means that every change in a patient file will be saved in an audit field. In order to create an EHR for a patient the following steps needs to be proceeded: As seen in figure 5, the medical unit 1 connects to the national references register and requests data for patient. The National References Register checks if the medical unit 1 has access rights within the system so that it can access the patient s data. If the right conditions aren't met, the access will be denied. In case the Medical Unit 1 has the right to connect to the system, the National References Register will send a message, to the other linked medical units in the net, demanding the data of a specific patient.

The Medical Unit 2, checks if the access is legitimate and - if so - it will send the patients data to the National Reference Register. On this same occasion, various updates can be made concerning the demographic and medical data, if needed. The National References Register combines the demographic as well as the medical data of a patient, that exist in the system, in a message in the form of EHR_EXTRACT, specific to the EN/ISO 13606 standard, adding in this message all the other data locations of the patient. If there aren't found any locations, an empty EHR_EXTRACT will be submitted. If the message received from the National Reference Registry contains a reference towards Medical Unit 2, it means that this particular Medical Unit holds data on that specific patient, while Unit 1 needs the whole medical file of the patient, then Medical Unit 2 will connect directly to Medical Unit 1 The Medical Unit 2 checks if the Medical Unit 1 has the right to access the medical information and if so it will send the requested data. Medial Unit 1 (local level) National Reference Registry Medical Unit 2 (local level) Request patient data Unauthorized access Request patient data Unauthorized access Send patient data Send patient data Figure 5 Communication sequence between a medical units and the National Reference Registry.

3. PROBLEMS and SOLUTIONS An important problem was to match every concept from the GCOF with an archetype or element from openehr archetypes. Even though most of them was found in the international database of the openehr Foundation, some fields from the GCOF, that are particular to the Romanian healthcare system, had to be develop and implement. All the archetypes that were created or extend in this process follow the openehr specifications. The next step was to divide the GCOF in smaller pieces, each represent or correspond to an openehr template. In total eighteen different templates were created to record demographic data, exam results, patient transfers, admission and discharge ward, treatments, surgical events, etc. All this was created following the patient s path through a hospitalization episode. Another problem was that the openehr templates only contain references to the elements which must be excluded from the archetypes. The combination of templates and archetypes on the fly is inefficient due to the high processing cost. The solution was the creation of.opt operational templates which are kept in the database. The standard format for defining the archetypes is the ADL (Archetype Definition Language) and the one for querying is the AQL (Archetype Query Language). To use these formats it would have been necessary to implement an ADL as well as an AQL parser, which in turn would have been an expensive undertaking as far as performance is concerned. Therefore the XML format of an archetype was used for storing while xpath was used for querying. The standard language used to specify the templates is the TDL (Template Definition Language), however, the specifications for this are yet to be finished within the openehr documentation. The XML template format was used here as well. Another critical issue of this project is the two-way conversion between the openehr and EN/ISO 13606 standards. The main problem was that the exact requirements for an accurate conversion were not yet defined but left to the standard users to decide upon. Moreover, keeping in mind that the data types EN/ISO 13606 are ISO 21090 types based, it becomes necessary to create a mapping between the openehr and ISO 21090 data types. The EHR Extract EN/ISO 13606- part 1 model resembles a simplified form of the openehr reference model. A major difference refers to the representation of the ENTRY data type: openehr works with several ENTRY data types while EN/ISO 13606 only works with a single one. An algorithm for the twoway conversion between the two standards encompasses two mapping types: Predefined classes and attribute conversions; A genetic algorithm for conversion between ENTRY type representations. The conversion between the openehr and EN/ISO 13606 is used by applying a XSLT implemented filter over the record data that exists in the databases as the XML version of the openehr format. After the conversion, the data is wrapped in a SOAP message and transmitted to the requesting medical unit for interpretation. Keeping in mind that a medical information system should provide data loss, the system does not allow deleting health record information. These system s users have rights only to the extent of interrogation, modification and adding. In case of a mistake being made while filing in the files, the correction may be done by updating, not deleting the file. So, logical deletion is achieved by marking the data in such way that it only appears deleted (but actually remains).

4. CONCLUSION This paper is a response to the need of the Romanian healthcare system to improve its services. According to the 2009 European Health Consumer Index, Romania is on the 32th place from 33 states compared. According to this index, our country has a very low score because healthcare personnel do not have access to healthcare records in an electronic format. Out of the 446 hospitals in Romania, only in 93 of them information systems exist. The major drawbacks of the existing software solutions are: incompatibility with the patients steps during a hospitalization episode, incompatibility among themselves and impossibility of medical information exchange [13]. An adoption of the EHRs in Romania will immediately increase the quality of the medical services. This platform addresses a way to standardize the usage of medical concepts that are common around the world, but also elements that are specific to the Romanian healthcare systems (managing the clinical data from the GCOF). Even if it is adapted to the Romanian healthcare systems, it can be easily modified to any healthcare. The main goal of this project is to achieve interconnection systems used in medical units in order to achieve the exchange of medical data of patients. Communication must be made remotely over the Internet from any location. A computer system must be able to access a patient's medical data stored by any other system. The concept of this project is meant to create a solution that serves patients throughout the medical system and for effective operation in a high security environment. Looking at the global level, it might seem hard to implement it with reasonable price and time, but the advantage being so great and important it deserves it. REFERENCES [1] The Healthcare Information and Management Systems Society (HIMSS), EHR definition [2] Beale Thomas, Health Information Standards Manifesto, White Paper Press, 2001 [3] Rahil Qamar, Semantic Mapping of Clinical Model Data to Biomedical Terminologies to Facilitate Interoperability, Manchester Info press, 2008 [4] Tang Christian, Key Capabilities of an Electronic Health Record System, National Academy Press, 2003; [5] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990 [6] European Commission Commission Recommendation of 2 July 2008 on cross-border interoperability of electronic health record systems [7] T. Beale, S. Heard, openehr Architecture - Architecture Overview, 12 April 2007 [8] T. Beale, S Heard, Archetype Definitions and Principles, 14 March 2007 [9] T. Beale, Archetype Object Model, 20 March 2007 [10] T. Beale, S Heard, Archetype Definition Language - ADL 1.4, 13 March 2007 [11] T. Beale, S Heard, The Template Object Model (TOM), 13 March 2007 [12] Eichelberg Marco, Aden Thomas, Riesmeier Jörg, Dogac Asyman, Laleci Gorkce, Electronic Healthcare Record Standards A Brief Overview, ACM, 2005 [13] Euro Health Consumer Index 2009 Report, Health Consumer Powerhouse