Diploma Thesis. Section of Medical Information and Retrieval Systems. Medical University of Vienna. Supervised by

Transcription

1 Diploma Thesis Electronic health records (EHRs): Data export of health information systems based on the Entity-Attribute-Value model as CEN pren compliant EHR extracts by means of Archetypes Vienna, May 2, 2007 Section of Medical Information and Retrieval Systems Medical University of Vienna Supervised by Ao. Univ.-Prof. Dipl.-Ing. Dr. Georg Duftschmid by Christoph Rinner Severingasse 4/ Wien

2 Abstract The European Committee for Standardization (CEN) is currently working on a ve part European Standard (pren 13606) that denes an information architecture for communicating contents of electronic health records (EHRs). This standard enables health information systems to exchange EHR segments via electronic messages and web services in a semantically interoperable manner. It is based on the two-level modelling methodology, which separates knowledge from information. In part one of the standard the Reference Model is described. Instances of the Reference Model can represent all medical information that may be contained within an EHR. In part two the concept of Archetypes and a language to specify Archetypes are dened. Archetypes contain the knowledge, they act as "construction plans" for instances of the Reference Model. By using the Reference Model and Archetypes it is possible to exchange information in a semantically interoperable manner. ArchiMed is a clinical trial system developed at the Medical University of Vienna. It allows to input and to statistically analyse data, and further supports patient recruiting as well as interactive design of case report forms (CRFs). The data model used in ArchiMed is based on the Entity-Attribute-Value model design. In this work pre standard pren was applied to implement a proof-of-concept export layer to export existing medical data stored in the ArchiMed System in a semantically interoperable form, complying with this standard. An objective was to use standard XML tools. The export is split into two steps. First, the data from ArchiMed are published as a generic instance of the Reference Model, the so-called EHR extract. Then the EHR extract is transformed into a semantically interoperable instance of the Reference Model using an already existing "private diabetes data" Archetype. To dene the transformation without requiring programming skills a virtual adaptation of the Reference Model is proposed. This enables XML Schema to describe instances of the Reference Model and dene the transformation using existing visual tools. i

3 Kurzfassung Das Europäische Komitee für Normung (CEN) arbeitet an einem 5-teiligen Standard pren 13606, der eine Kommunikationsarchitektur zum Austausch von elektronischen Gesundheitsakten festlegt. Dieser Standard basiert auf einem Zwei-Schichten-Modell, bei dem Wissen und Information getrennt werden. Im ersten Teil dieses Standards wird das Referenzmodell vorgestellt. Instanzen des Referenzmodells dienen dazu, medizinische Information darzustellen. Im zweiten Teil des Standards wird das Konzept von Archetypen vorgestellt. Archetypen legen fest, wie Instanzen des Referenzmodells aufgebaut sein müssen, um bestimmtes medizinisches Wissen darzustellen. ArchiMed ist ein Studiensystem, das an der Besonderen Einrichtung für Medizinische Statistik und Informatik der Medizinischen Universität Wien entwickelt wurde. Es basiert auf dem Entity-Attribute-Value Model. Im Rahmen dieser Diplomarbeit werden existierende medizinische Daten aus ArchiMed, die in einem eigenen Datenformat gespeichert wurden, in einer semantisch interoperablen Form gemäÿ dieses Standards exportiert. Ziel war die Umsetzung mit Standard-XML- Tools. Die bestehenden Daten werden in zwei Schritten in die gewünschte Form gebracht. Im ersten Schritt werden die Daten als Instanz des pren Referenzmodells exportiert. Im zweiten Schritt wird diese generische Instanz in eine semantisch interoperable Instanz transformiert. Als Vorlage für die Transformation dient ein unabhängig entwickelter "private diabetes data"-archetyp. Um die Transformation ohne Programmierkenntnisse durchführen zu können, wird eine virtuelle Erweiterung der Referenzmodells vorgeschlagen. Diese ermöglicht, Instanzen des Referenzmodells mittels XML-Schema darzustellen und die Transformation mit bestehenden Tools visuell festzulegen. ii

4 Contents 1 Introduction Electronic Health Records Interoperability Health information systems Entity-Attribute-Value model design Standardisation of EHR Communication The CEN pren standard History of pren Structural overview of pren Reference Model Archetypes pren instances - EHR extracts Related work Pangea Proof-of-Concept EN based Electronic Healthcare Record Service The Oacis-GEHR transformation process OpenEHR persistence mechanisms Publication of relational data as archetyped EHR extracts Design objectives Methods to publish relational data as EHR extracts Methods to transform EHR extracts into archetyped EHR extracts The virtually extended Reference Model Publication of extended EHR extracts based on XML Schema Results The "private diabetes data" Archetype iii

5 Contents 5.2 ArchiMed Publication of relational data using PL/SQL XSLT generation Transformation Conformance declaration Discussion 71 7 Conclusion Future work List of Listings 76 List of Figures 78 List of Tables 78 Bibliography 83 iv

6 1 Introduction The goal of this thesis is to explore the practical applicability of pren [1] and its concepts to exchange medical data semantically interoperably. Dierent ways to implement a layer to export medical data from a health information system in a pren compliant format are analysed. A proposed solution was implemented based on Oracle PL/SQL, the PL/SQL DOM API, XSLT, and XML Schema. EHR extracts are described by means of XML Schemas and are transformed into Archetype-compliant EHR extracts using XSLT. The XSLT script used to transform the EHR extract into an archetyped EHR extract is created visually using the two XML Schemas. A method is presented that solves the "unique particle attribution" problem, which would otherwise preclude the description of an EHR extract by means of XML Schema. The resulting EHR extracts are deposited in a local repository. In the rst chapter dierent approaches to store and communicate Electronic Health Records are described. In chapter 2 the history, structure and underlying mechanisms of pren are explained. Chapter 3 describes four existing systems, which publish data compliant to two-level modelled information systems. In chapter 4 the objectives of this thesis are specied and a method to publish pren EHR extracts is presented. Chapter 5 describes how the method selected in the previous chapter is applied in a real scenario. Chapters 6 and 7 contain the discussion and conclusion. 1.1 Electronic Health Records The use of computers revolutionised the diagnosis and therapy in medical everyday life. Magnet Resonance Therapy and Computer Tomography would not be possible without the aid of computers. Computer aided surgery and computer aided diagnosis helped to improve the medical treatment signicantly. Another key element within the health sector that recently got a lot of attention is the Electronic Health Record (EHR). EHRs 1

7 1 Introduction contain patient information such as laboratory test, observations, diagnosis, treatments, therapies, patient identication, legal permissions, information on allergies etc. The International Organization for Standardization (ISO) 1 denes Electronic Health Records (EHRs) as repositories of information regarding the health status of a subject of care, in computer processable form [2]. This denition can be further rened. In [3] ve levels of EHRs are distinguished. ˆ Automated Record, contains patient information for administrative purposes and information on the location of the conventional record ˆ Computerised Medical Record, contains all documents belonging to a patient, yet for the most part scanned documents ˆ Electronic Medical Record (EMR), structural medical documents from one source ˆ Electronic Patient Record (EPR), sum of all structural medical documents from dierent locations and/or sources of a patient ˆ Electronic Health Record (EHR), additionally to the EPR the EHR is a lifelong record and additionally contains information entered from the patient personally The ISO denition of the EHR only includes the last three levels mentioned above. The European Union published an action plan eeurope 2005 [4] to achieve an "information society for all" based on a widely available broadband 2 infrastructure. An important part of the eeurope action plan is e-health. Since the 1990's the European Community spent one billion in e-health research programs. Due to these investments Europe has a leading position in the use of EHRs in primary care and deployment of health (smart) cards [5]. Challenges facing the European e-health sector are: ˆ Empowering health consumers: Health consumers have to be actively involved in decisions concerning their own health. Online resources to inform, monitor and support patients help to increase the quality of care and patient safety. ˆ Assisting health professionals: Medical errors could be avoided by making use of e-health systems. These systems allow fast and easy access to vital information 1http:// 2Broadband refers to telecommunication that provides multiple channels of data over a single communications medium, typically using some form of frequency or wave division multiplexing 2

8 1 Introduction and results of clinical treatments. Further they enable extraction of information for research, management, public health or other related statistics. ˆ Supporting health authorities and health managers: Increasing networking and easy access to data make the health sector more productive. Inecient and inappropriate treatment could be limited. Interoperability and interoperable EHRs are a key requirement to meet these challenges. Interoperability allows: ˆ seamless integration of heterogeneous systems ˆ secure and fast access to health data located in dierent places ˆ mobility of patients and cross border circulation The European roadmap for e-health started back in Some goals still have to be achieved. The member states should support deployment of information networks for e-health based on broadband, mobile infrastructures and grid technologies. E-Health should be promoted to reduce occupational accidents and illnesses and the access to health information for patients should be improved. By the end of 2009 a baseline for standardisation of e-health services is planned to be set. One major goal of the e-health initiative is to foster interoperability between systems. 1.2 Interoperability In the healthcare domain interoperability is the ability of dierent information systems and software applications to communicate, to exchange data accurately, eectively, and consistently and to use the information that has been exchanged [6]. The Institute of Electrical and Electronics Engineers USA (IEEE-USA) 3 believes that interoperability is one of the most critical concepts confronting the adoption and implementation of enhanced electronic information technologies [7]. Speaking of the EHR the main focus lies on sharing health records between dierent medical institutions, health information systems, health professionals and patients. It is not sucient to just send the result of a blood pressure measurement when sharing medical data. It also has to be clearly indicated from whom, by whom, when, where, where on the body, with 3http:// 3

9 1 Introduction which instrument, in what unit, etc. the measurement was taken. Additionally shared terminology and denitions have to be employed. In brief it has to be agreed on what is exchanged and how it is exchanged. The meaning and context of the information must not be lost. Currently, health information is stored in dierent medical information systems in a multitude of proprietary formats, resulting in a severe interoperability problem [8]. A goal should be to base EHRs on open standards to avoid copyright and trademarks. To achieve interoperability there is a need for standards to regulate the information exchange at the knowledge and system level. The two main levels of data interoperability are: ˆ functional interoperability: the ability of two or more systems to exchange information (so that it is human readable by the receiver) [2] and ˆ semantic interoperability: the ability for information shared by systems to be understood at the level of formally dened domain concepts (so that information is computer processable by the receiving system) [2]. Without standardisation it is not possible to achieve an unambiguous exchange of medical data [9]. 1.3 Health information systems An information system is a manual or computerised system that helps to organise, collect, store and present data and knowledge for decision making, progress reporting and for planning and evaluation. A special type of information system is the health information system, it is designed to manage the administrative and clinical aspects in the health care domain. Internationally three standard concepts for health information system architectures are in use [10]: ˆ component-oriented single model approach (e.g. ENV 13606) ˆ component-oriented dual model approach (HL7 CDA, pren 13606, openehr) ˆ multi model approach of component-oriented services Most current information systems use a single model approach, this means that domain concepts are hard-coded directly into the software and databases. This results in a mix 4

10 1 Introduction of knowledge and information in single model health information systems (see gure 1.1). ˆ Information: knowledge of a certain circumstance or an action (e.g. Patient XY has an arterial septal defect, 1cm x 3.5cm) ˆ Knowledge: knowledge of a consensus at a certain time and in a certain area of expertise regarding terminology, correlations and action guidelines (e.g. the arterial septum divides the right and left arterial chambers of the human heart) Figure 1.1: Information and Knowledge in the single model approach (adapted from [11]) The information is a statement about patient XY and does not apply to other people in general. On the other side the knowledge is not concerned with a single person, rather with general statements. When developing a single model approach information system, software developers and domain experts develop use cases. Within the use case "blood pressure" for example, the health professional tells the software developer what information is needed, the systolic and the diastolic pressure, the units in which it is measured (e.g. mm[hg]) and where it is measured (arm, leg etc.). Using these use cases the information system is implemented. The advantage of a single model approach is the relatively quick development. However, the knowledge in the medical domain and the knowledge about mechanisms in the human body is constantly growing. A shortcoming of the single model approach is that only use cases found during development are considered. In the medical domain thousands of concepts exist. In the Systematized Nomenclature of Medicine (SNOMED) healthcare concepts and 1.5 million semantic relation- 4http:// 5

11 1 Introduction ships are listed. The medical domain is open-ended. New knowledge is discovered, the knowledge is becoming more detailed, new relationships between knowledge are discovered or become relevant. Considering this it becomes obvious that it is very hard to keep hard-coded knowledge updated. If new use cases arise or concepts change, rebuilding, testing and re-deployment of systems become necessary. To overcome this problem the information level and the knowledge level are separated. This is called dual model approach (see gure 1.2). It was introduced by Beale [12] [13] and adopted by CEN/TC 251 in its recent pre standard pren [1]. Figure 1.2: Information and Knowledge in the dual model approach (adapted from [11]) The dual model approach splits the architecture of a health information system into two parts: 1. a generic part containing the information (Information Model) and 2. a dynamic part containing the knowledge (Archetypes). A two-level modelling approach simplies adjustments to the information system when new knowledge is gained in the health care domain. On the other side the development process is more comprehensive Information Model and Archetypes The rst level in the dual model approach contains all the non-volatile concepts (i.e. classes) of the domain. These concepts are transformed into a relatively small model, called Information Model. The Information Model has to be strong enough to describe 6

12 1 Introduction all valid entries of an EHR. To construct the Information Model its application domain has to be analysed and the resulting requirements have to be summarised. To get a future-proof system not all the requirements are modelled directly into the Information Model, only the non-volatile ones, i.e. the classes that stay unchanged over time. The Information Model is developed by programmers. The underlying concept of the Information Model can be compared to the concept of LEGO bricks. If a basic house is built with LEGO, only two "classes" of bricks, the square bricks and the tile bricks, are needed. LEGO bricks that look like a house could be used as well, yet for every small adaptation made to the house a new brick has to be made. If a new class for every medical concept has to be developed, one ends up writing millions of classes describing all the medical concepts in the Information Model. In LEGO some commonly used "classes" are already dened, for example gures, decorations etc., others like cars, houses etc. have to be built out of the basic classes. The Information Model has also concepts like "person" directly modelled. Other more volatile concepts (e.g. blood pressure) have to be built out of the basic classes dened in the Information Model. The Information Model is sucient to create information, the same way LEGO bricks are sucient to build something. The problem is how to dene the semantic of concepts not modelled in the Information Model. A dynamic knowledge model is needed. LEGO oers construction plans to dene how the simple bricks have to be arranged to build a house. In the dual model approach construction plans called Archetypes dene how the classes from the Information Model have to be arranged. Archetypes contain the dynamic knowledge. Whenever new concepts have to be represented by an instance of the Information Model, a new Archetype is dened showing how the basic classes have to be arranged. Figure 1.3 shows how information is represented using the dual model approach methodology. The Information Model is capable of representing all kind of medical data. The Archetype Model contains classes that allow to constrain the Information Model. An EHR is an instance of the Information Model. The knowledge how it has to be structured and validated is stored in an Archetype. Archetypes are instances of the Archetype Model. Archetypes do not add any new classes to the Information Model, they just describe valid patterns of the Information Model. 7

13 1 Introduction Figure 1.3: Archetype Model meta architecture Dual model approach health information systems Some health information systems are already based on the dual model approach methodology. Even though they are based on the same methodology, dierent implementations are possible. Dierent standards are based on the dual model approach. Depending on the standard, the amount of knowledge hard-coded in the Information Model is varying. In [11] the openehr framework and Aarhus EHR framework [14] are compared. Examples of dual model approach health information systems are: ˆ Aarhus EHR [15]: state-of-the-art EHR system for public hospitals in the county of Aarhus (Denmark). It is implemented as a client-server solution. It has a larger Information Model than openehr, which means that more knowledge is stored in the Information Model. 350 EDDs (Event Description Denitions) full the same task as Archetypes. ˆ proper [16]: A distributed system based on international standards. A modied version of the openehr Archetypes is used. ˆ UCLA DataServer 5 : A pass-through middleware to process clinical health information based on XML, HTML and XSL translation pipelines. 5http:// 8

14 1 Introduction 1.4 Entity-Attribute-Value model design Within relational databases dierent database schema designs to store medical data exist. One approach described in [17] to store medical data is called Entity-Attribute- Value (EAV) model design. The Entity-Attribute-Value model design is a specic data model design for relational databases. It is often used with medical data, because the Entity-Attribute-Value model design allows the number of parameters to grow without a need to redesign the database schema. In the Entity-Attribute-Value model design every single value is represented by a row in the database as shown in table (1.4). ID Label 1 Form 1 2 Form 2 Table 1.1: EAV forms table ID Form Var Table 1.2: EAV form position table ID Label 1 Na 2 Ca 3 Name 4 Surname Table 1.3: EAV variables table ID FoPo Value John 4 4 Doe Table 1.4: EAV data table The content of the two forms from table 1.1 can be selected combining the information stored in the three tables (1.2, 1.3, 1.4). The content of Form 1 can be seen in table 1.5 and of Form 2 in table 1.6. Ca Na Table 1.5: Content of Form 1 Name Surname John Doe Table 1.6: Content of Form 2 There are no arbitrary limits on the number of attributes per entity. The number of parameters can grow as the database evolves, without requiring a schema redesign. 9

15 1 Introduction If a new variable is introduced, it is sucient to add the new variable to table 1.3. This new variable can be used in any form by assigning a position in table 1.2 and the collected data in table Standardisation of EHR Communication Three elementary types to communicate health information can be distinguished. The addressed communication, where a message is sent to a known individual receiver, the directed communication, where the message can be retrieved by someone who is authorised by his role to do so, and the non-directed communication, where the message is sent to a repository and can be retrieved by authorised individuals when needed [18]. An example of the last communication type is the Integrating the Healthcare Enterprise (IHE) 6 Cross-Enterprise Document Sharing (XDS) technical framework, which is coarsely depicted in gure 1.4. The scenario assumed in this thesis is based on the nondirected communication and focuses on the publication of an EHR extract in a repository (see grey box in gure 1.4). Figure 1.4: Cross-Enterprise Document Sharing Diagram When exchanging complex messages between dierent systems, not only the type of communication has to be coordinated but also the semantics and the syntax of the messages sent. Standardisation of messages can be achieved by [19]: 6http:// 10

16 1 Introduction ˆ Communication standards: the mechanisms to communicate between information systems are dened using syntax and semantic of the message (e.g. HL7) ˆ Document standards: the structure and formalisation of the message are dened (e.g. DICOM, HL7 CDA) ˆ Data models: a domain specic data model is dened, from which message types can be derived (e.g. HL7 Reference Information Model) ˆ Architectural standards: valid messages are dened by restricting the software architecture (e.g. pren 13606, openehr) instead of the message itself Currently, several standards to structure and markup clinical content for the purpose of semantic interoperable exchange are under development. The next sections contain a short overview of communication standards. A more in-depth comparison can be found in [8] HL7 Clinical Document Architecture Health Level Seven (HL7) 7 Clinical Document Architecture Release Two (CDA R2) is a document markup standard based on the HL7 Reference Information Model (RIM). CDA, previously called Patient Record Architecture (PRA), species the structure and semantics of a clinical document for the purpose of exchange [20]. CDA documents are XML documents that can be viewed in every browser using a generic stylesheet. Additionally to the meaning from the RIM, terminologies such as SNOMED and Logical Observation Identiers Names and Codes (LOINC) 8 are used to allow machine processable meaning. The CDA is organised in three levels: 1. Unconstrained CDA specication 2. CDA specication with section-level templates applied 3. CDA specication with entry-level (and optionally section-level) templates applied Each level adds iteratively more markup to a clinical document. An example CDA document can be seen in listing 1.1. The root element of a CDA document is <ClinicalDocument> containing the CDA Header and the <structuredbody>. The body can contain recursively nested <section> 7http:// 8http:// 11

17 1 Introduction Listing 1.1: Major structural components of a CDA document [20] <ClinicalDocument>... CDA Header... <structuredbody> <section> <text>(a. k. a. " narrative block")</text> <observation>... </ observation> </ section> <section> <section>... </ section> </ section> </ structuredbody> </ ClinicalDocument> elements. CDA sections must contain the human readable content wrapped in a <text> element within the <section>. Only CDA Release 2 Level 3 documents are fully structured EHRs comparable to pren EHR extracts. A goal for the future should be to produce fully structured EHR extracts, containing no free text. Free text can not be interpreted without any additional knowledge openehr OpenEHR 9 is a not-for-prot foundation, founded in Its goals are to improve healthcare in the information society and to make the interoperable, life-long EHR a reality. The dual model approach by means of "Archetypes" was introduced by openehr. The rst level is a generic Reference Model containing few classes that are stable over time. In the second level specic medical concepts are dened using Archetypes. Archetypes dene accepted instances of the Reference Model. OpenEHR oers an architectural specication for a framework that allows to document any kind of clinical information gathered during a patients lifetime, ranging from laboratory data, images, diagnosis to treatments and therapies. It incorporates terminologies and classications such as SNOMED, LOINC and International Classication of Diseases (ICD) 10 to additionally enable semantic interoperability. The modular architecture allows to build future-proof, extensible EHRs. 9http:// 10http:// 12

18 1 Introduction The concepts used by openehr were adapted in pren However, as opposed to pren and the CDA, openehr is not an ocial standard PrEN PrEN builds the main focus of this thesis and is addressed in depth in chapter 2. 13

19 2 The CEN pren standard The European Committee for Standardization (CEN) 1 was founded in Its goal is to promote free trade, the safety of workers and consumers, interoperability of networks, environmental protection, exploitation of research and development programmes, and public procurement by producing technical standards. The standards are developed by "consensus building". They are based on voluntary agreement and voluntary work of participants representing the dierent parties of interest. So far CEN published standards and approved documents. Furthermore documents are being prepared (as of December 2005). These standards are handled by 277 technical committees. The Technical Committee for Medical Informatics (CEN/TC 251) 2 was founded in May 1990 and had its rst meeting in June Its aim is to develop standards in healthcare informatics. The work within CEN/TC 251 is carried out by 4 Working Groups (WGs): ˆ Information models (WG I) ˆ Terminology and knowledge representation (WG II) ˆ Security, Safety and Quality (WG III) ˆ Technology for Interoperability (WG IV) WG I is in charge of the pre standard pren History of pren PrEN has various predecessors. In 1995 the pre standard prenv 12265:1995 Electronic Healthcare Record Architecture (EHCR-A) was published. It was the rst CEN/TC 251 standard describing the basic architectural principals for representing the content and structure of an EHR. It was applicable to all EHRs. PrENV was 1http:// 2http:// 14

20 2 The CEN pren standard withdrawn in 1999 and replaced by ENV Electronic Healthcare Record Communication. ENV is a four part standard. The 1st part "Extended Architecture" is based on ENV It denes additional structural and semantic components to allow the content of a healthcare record to be constructed, used, shared and maintained. Part 2, "Domain Termlist", provides a set of measures to support interoperability between EHRs. Part 3, "Distribution Rules", species data objects to describe rules for distribution or sharing. It also establishes principles for security policies. The 4th part denes a set of messages to enable the communication of part or whole EHRs in response to a request message [21]. In December 2001 a new Task Force, EHRcom, was formed to review and revise the pre standard ENV The intention of this Task Force was to propose a revision that could be adopted by CEN as a formal standard (EN). The goal of the EHR communication standard proposed is to produce a rigorous and durable information architecture for representing EHRs, in order to support the interoperability of systems and components that need to interact with EHR services [1]: ˆ as discrete systems or as middleware components; ˆ to access, transfer, add or modify health record entries; ˆ exchanged via electronic messages or distributed objects; ˆ preserving the original clinical meaning intended by the author; ˆ reecting the condentiality of data as intended by the author and patient. 2.2 Structural overview of pren The revised standard pren proposed by CEN/TC 251 is based on the dual model approach methodology and is divided into ve parts. ˆ Part 1 - Reference Model [22] : The Reference Model describes the stable characteristics of an EHR. Instances of this model build the EHR contents that are exchanged. Instances of the Reference Model are called EHR extracts in the course of this thesis. ˆ Part 2 - Archetypes [23]: This part species the generic Archetype Model and the Archetype Denition Language (ADL) to specify Archetype instances. 15