AN OVERVIEW OF INTEROPERABILITY STANDARDS FOR ELECTRONIC HEALTH RECORDS

Transcription

1 Integrated Design and Process Technology, IDPT-2007 Printed in the United States of America, June, Society for Design and Process Science AN OVERVIEW OF INTEROPERABILITY STANDARDS FOR ELECTRONIC HEALTH RECORDS A. Begoyan University of Westminster School of Informatics Department of Information Systems 115 New Cavendish Street, London, W1W 6UW ABSTRACT This paper gives an overview of the interoperability standards for Electronic Healthcare Records (EHRs) which are offered by the world leading standard bodies: European Committee for Standardisation (CEN), International Organization for Standardization (ISO), Health Level Seven (HL7) and Digital Imaging and Communications in Medicine (DICOM). We have taken information available in the original standards text as the bases of our research. We outline what each of these standards offer and we compare the way they address the interoperability of EHRs. INTRODUCTION Healthcare information systems have grown rapidly in the last decade. They moved from isolated software systems in hospitals or primary care organizations, towards solutions which support a continuous medical process and (i) include multiple healthcare professionals and institutions, (ii) utilize ubiquitous computing healthcare environments and (iii) embrace technological advances, typical of the domain of today s pervasive software applications. It is not a surprise that in such an interactive environment, we need to look at the information sharing amongst healthcare software systems. This requires that all relevant patient clinical data is available and correct, thus supporting healthcare professionals at any time, any place and improving the quality and delivery of healthcare. We have witnessed a proliferation of solutions for effective EHR (Dumay, 2002), (van Ginneken 2002), (Giusse, 2003), (Ueckert, 2003), (Valdes, 2004), (Kuhn, 2001), (Hsyien-Chi, 2007). We are now in a specific situation characterized by: (a) Heterogeneities in hardware and software solutions that support healthcare software applications as a consequence of their evolution from the early 1960s; (b) Heterogeneities in the structure, purpose and deployment of EHR in terms of their suitability for a variety of healthcare systems that are growing in each country in the world. Heterogeneities in healthcare software applications from (a) above are typical of heterogeneities in any other problem domain, where a variety of platforms, systems, databases, software applications, technologies etc exist. From this point of view, healthcare software systems do not differ from any other. However, heterogeneity of EHRs across healthcare systems from (b) above is a bigger problem. EHRs differ from application to application and from country to country. This means that the structure of EHRs and the methods used for exchanging their content may vary significantly, thus becoming an obstacle for sharing medical data or medical records and developing software applications that support (i)-(iii) above. The expected answer is in the standardization of EHRs structure, content and the way of exchanging them, as described in (Gross, 2005), (Kalra, 2006), (Bossen, 2006). There are initiatives from North America and European countries to engage their organizations and bodies responsible for standardization in general, with the EHR standardization. Thus we have various EHR standards which differ from country to country and which cover different issues of EHR standardization. On top of that, these standards are not very stable. There are a number of reasons for that. Standards are constantly evolving and changing, and the content and structure of EHRs is also changing in parallel due to technology and science advancement, thus pushing changes within applications built upon such EHRs outside their initial domains and purposes (Beale, 2002). Even if we have achieved a certain level of EHR standardization, the advancement of medial science would demand further changes in existing EHR standards. For example, medical science is currently placing great emphasis on genomics, which requires the integration of biomedical information with the EHR. If the current EHR structure has not already incorporated biomedical information it will have to be done soon. Therefore, standardization of the EHR needs to be reviewed on a regular basis to asses the current situation within the EHR standardization, and take steps to make EHR standards future proof or adaptable to inevitable changes (Medisell, 2004). 1

2 Healthcare informatics is full of various standards that help us to structure many aspects of healthcare software systems: from their architectures, software applications built from them to semantics stored within and structures of EHR. In this paper we overview standards for the interoperability of EHRs which exist across North America and Europe. We are interested in a particular aspect of interoperability between diverse healthcare systems, which should be able to exchange information about patients and their medical history stored within EHRs (Bott, 2004). Therefore: We are interested in software engineering solutions that can alleviate interoperability problems in healthcare software applications, which depend on the data structures of EHRs. Thus any interoperability standard on EHR could be a starting point when building such applications. We have learned that in spite of various initiatives for achieving the interoperability in healthcare software applications through data sharing, such as e-gif (Cabinet Office, 2005) in the UK, current EHRs are simply not equipped with data items, which are essential if we want to share them across healthcare institutions (Slevin et al., 2005) (Akram et al., 2007). Five year ago the UK government initiated the National Program for Information Technology (NPfIT, 2004), which has already approved the development of a centralized healthcare (patient) database for the UK National Heath Service. Which standards on EHRs would they follow, if any? In order to review the situation within standards, which deals with the interoperability of EHRs, we started with the European standardization committee and its Interoperability working group IV within Technical Committee 251 (CEN/TC 251). They list the following standardization bodies responsible for EHR. ISO is an International Organization for Standardization which is currently a network of the national standards institutes of 157 countries. They work on the basis of one member per country, with a Central Secretariat in Geneva, Switzerland, that coordinates the system. ISO produces EHR standards that are limited to the structure and function of the EHR and the system that processes EHR. CEN is a European Committee for Standardisation. It is involved in developing multi-disciplinary standards including health care systems and their interoperability. CEN covers European Union (EU) countries and some affiliated countries outside the EU. HL7 stands for Health Level Seven. It is one of the several American National Standards Institute (ANSI) - accredited Standards Developing Organizations, which operates in the healthcare arena. It covers America, some European and Asian countries and Australia. Its purpose is to provide standards for data exchange between different types of healthcare computer applications. HL7 s domain includes clinical and administrative data. Its headquarters is in Ann Arbor, Michigan. DICOM Digital Imaging and Communications in Medicine is an association of medical industry and medical professional organizations, working under the umbrella of the National Electrical Manufacturers Association (NEMA). They have delivered DICOM, which is a de facto standard for medical image communication (DICOM). This standard allows an independent exchange between medical images and related information. The purpose of this paper is to briefly overview the current situation within standards that regulate the interoperability of EHRs and to learn the outcomes of such standardizations. These outcomes then can be adopted when software applications that deal with heterogeneities are designed. We would also like to see if there are any components within such standardizations which lead towards future-proof EHRs. This paper is structured as follows. In the next section we define and discuss EHRs, their interoperability and prerequisites for their semantic interoperability. In the four sections that follow we discuss four EHR standards: ISO/TR 20514, ISO/TS 18308, ISO/TR derived by ISO; CEN13606 and its five parts from CEN; Version 2x and Version3x from HL7; and two standards from DICOM - Web Access to DICOM Persistent Objects and DICOM Structured Reporting. We briefly touch the harmonization between standards, and conclude in the last section. DEFINITIONS OF EHR AND INTEROPERABILITY The definition of EHR varies from standard to standard. According to CEN/TC251 Health Informatics, EHR is a healthcare record in a computer readable format. According to ISO/TR the basic-generic EHR is healthcare record in a computer processable format, which encapsulates readability but extends this to include the notion that information in the EHR must be amenable to programmatic manipulation and therefore to automatic processing (ISO TC 215, ISO/TR 20514, 2005). EHR systems are defined uniformly across CEN and ISO: as system[s] for recording, retrieving and manipulating information in electronic health records. Interoperability of EHR as defined in ISO (ISO TC 215, ISO/TR 20514, 2005) is the ability of two or more applications being able to communicate in an effective manner without compromising the content of the transmitted EHR. They claim that it is important to develop national and international standards for EHR interoperability to be able to: (1) share patient health information between health professionals in a multidisciplinary shared-care environment: (2) share patient health information between organizations within an 2

3 enterprise, a regional or national health system, or across national borders and (3) support interoperability between software from different vendors. There are two types of interoperability that are relevant in this context. The ISO Technical Report (ISO TC 215, ISO/TR 20514, 2005) defines these as Functional interoperability and Semantic interoperability. Functional interoperability deals with the exchange of information between two or more systems in a format that is readable by humans. Semantic interoperability deals with the exchange of information between systems in a format that is computer processable by the receiving system. We could not find within the Technical Report explicitly listed prerequisites for achieving Semantic Interoperability. Thus we have to refer to the conference paper (Schloeffel P., 2004) which states that there are four prerequisites that need to be fulfilled in order to achieve semantic interoperability: a) a standardized EHR Reference Model. This deals with the semantics of EHR information structures; b) a standardized service interface. This deals with the semantics of interfaces between EHR and other services: c) a standardized set of domain-specific concept models. This deals with archetypes and templates for different domain concepts: d) standardized terminologies. This defines the language that is used in archetypes. (The first two prerequisites also apply to functional interoperability.) INTERNATIONAL STANDARDS ORGANISATION ISO s Technical Committee ISO/TC 215, which deals with Health Informatics, is an international standards body, whose aim is to achieve compatibility and interoperability between independent healthcare systems. This is a relatively new standards body, which has produced a set of new standards as well as using other international standards from HL7, DICOM and CEN as the basis for their standards. ISO has already published 37 standards relating to different aspects in the field of medical informatics across 22 countries, including the UK. The standards produced by ISO/TC 215 are being observed in 20 countries including Central America, Europe, Asia and the Middle East. The following three sub-sections will introduce three standards ISO/TR 20514, ISO/TS and ISO/TR which are concerned with the EHR interoperability. ISO/TR EHR Definition, Scope and Context. ISO/TR is a standard that defines the content of the EHR, its structure and the context in which the EHR is used. It also gives definitions of the terminology used. ISO/TR defines the EHR structure through basic-generic EHR (ISO TC 215, ISO/TR 20514, 2005). Thus, it allows the broadest applicability of the given EHR structure to a wide range of existing and future types of EHRs and EHR systems. This, in turn, provides support for legislative and access control requirements that would be applicable to all forms of EHR. The basicgeneric EHR definition is supplemented by the detailed definition which is stated in 1 and 2 below: 1. The ability to share patient health information between authorized users of the EHR. 2. The ability to supporting continuing, efficient and quality integrated health care. According to (ISO/TR 20514, 2005), the sharing of EHR information can take place at three different levels: LEVEL1 is between different clinical disciplines or other users, who could be using the same application but require different or ad hoc organization of EHRs. LEVEL2 is between different applications at a single EHR node. (An EHR node is a physical location where EHRs are stored and maintained.) LEVEL3 is across different EHR nodes. When EHRs are capable of being shared at LEVEL3 then the EHRs are called Integrated Care EHRs (ICEHR). ISO/TS Requirements for an EHR Reference Architecture. This is a new standard that gives requirements for the architecture of EHR systems and not the specification for such architectures (ISO TC 215, ISO/TS 18308, 2004). It specifies the assembling and collating of clinical and technical requirements for EHR architecture to support usage, sharing and exchanging of EHRs across different countries, different health sectors and different models of healthcare delivery. The main users of this standard will be developers of EHR architecture standards such as CEN EN13606 and other reference architectures such as openehr (Eichelberg et el, 2005), (openehr). ISO TR Interoperability and Compatibility in Messaging and Communication Standards. This standard describes the main requirements for achieving interoperability and compatibility in trusted health information interchange between software applications and systems in healthcare. The standard specifies the interoperability needs of the healthcare community for the subject of care, the healthcare professional, the healthcare provider organization, its business units and the incorporated delivery network. It also provides a criterion for developers and implementers of standards for messaging and communication in the healthcare domain. It lays down the foundation for the health information interchange to be as trustful as possible (ISO TR 18307). CEN CEN s Technical Committee CEN/TC 251 deals with the production of Standards in Health Informatics. It has produced the only comprehensive EHR interoperability standard in the world called CEN

4 CEN13606 CEN has been previously published as a prestandard named ENV in 1999 (Kalra and Ingram, 2006). It was not as successfully implemented as expected due to various weaknesses, such as the outdated architectural concepts of applications that support EHRs, that were recommended by the standard (Eichelberg et el, 2005). In 2001, CEN/TC updated ENV13606 and adopted the openehr archetype methodology defined by the openehr Foundation to make it a full European Standard EHR (Schloeffel P., 2004), (The OpenEHR Foundation). The result of this work is in CEN pren CEN pren13606 has been adopted by 48 countries as at CEN EN13606 is a five-part standard as defined in pren :2006 (CEN/TC 251, 2006) and consists of a Reference Model, an Archetype Interchange Specification, a Reference Archetypes and Term Lists, Security Features, and Exchange Models. The standard defines an architecture for communicating part or all of the EHRs of a single patient, making sure that (i) the original clinical meaning intended by the author of the record is preserved and (ii) the confidentiality of the data as intended by the author and the patient is not breached. It does not specify the internal structure or database design/schema of the EHR. Part One - The Reference Model. The Reference Model defines the generic building blocks of the EHR by representing the global characteristics of health record components. It shows how they are aggregated, and how the context information within the record s components meets ethical, legal and provenance requirements. In order to support communication between various EHR systems, the standard recommends archetypes, i.e. the use of meta-data (Frankel, 2006), but they are not mandatory. The archetypes are definitions of prescribed combination of the building-block classes defined in the Reference Model for particular clinical domains or organizations (CEN/TC 251, 2006). This standard may also be used for communication between an EHR system and repositories found in clinical applications, or between middleware components responsible for accessing or providing EHR data. Furthermore, the standard may be applied for the communication of individual patient records (i.e. a single identifiable subject) to an EHR system or a centralized EHR data repository. Anonymization or aggregation of individual patient records within EHR systems are not the focus of this standard. The Reference Model consists of four packages Extract, Demographics, Support and Primitive. (CEN/TC 251, pren :2006). The Extract package defines the EHR_EXTRACT class in an EHR structure, which is the root directory of the Reference Model, and data structures for EHR content. The Demographics package provides a data set of specific entities, which are defined only once and then used within the EHR_EXTRACT by the means of dedicated class instance identifiers. The whole purpose of this package is to give a sufficient description of each entity within an EHR system for human interpretation and to allow the identification of entities between EHR_Recepient and its own demographic server. We do not summarize what Support and Primitives packages contain because it was very difficult to follow the text available in the standard. Part two - Archetype Interchange Specification The wide-scale sharing of EHR records and their meaningful analysis across distributed computing sites requires that the equivalent clinical information is represented consistently, i.e. when the clinical data structures are communicated via the Reference Model, it should have the same semantic meaning. This addresses the semantic and schematic heterogeneities in the repositories of EHR systems. Archetypes introduced in this part have the role of addressing the challenges of semantic interoperability. EHR systems should be able to cater for any professionals, specialities or services within healthcare systems, despite the fact that healthcare domains are different, complex and prone to frequent changes. Thus the Reference Model represents the generic properties of EHR information, and Archetypes (i.e. meta-data) define patterns for the specific characteristics of the clinical data that represent the requirements of each particular profession, speciality or service. Archetype instances conform to a formal model available at Archetype Model pren :2005(e)6. Archetypes may also be used within EHR systems to manage the EHR data, which belong to a certain data repository. It is assumed that the original EHR data, if not already archetyped, may be mapped to a set of archetypes, if needed, when generating the construct, i.e. EHR_EXTRACT (pren ) Archetype Repositories contain many archetypes that that have been derived from different sources of EHRs. Thus despite the fact that different sources of clinical data inputs, and data types detectable in such inputs, have been identified, the formats in which these clinical data structures are represented remain interoperable across a variety of EHR systems. Consequently, the use of standardized archetypes ensures an interoperable way of representing and sharing the specification of archetypes, in support of keeping EHRs consistent and the semantic interoperability of shared EHRs. Communicating Archetypes specifies requirements for a comprehensive and interoperable archetype representation, and defines the Object Distributed 4

5 Processing (ODP) Information Viewpoint representation for the Archetype Model. It also gives an optional archetype interchange format called Archetype Definition Language (ADL). Archetypes expressed in ADL will be compatible with HL7 Refined Message Information Models (R-MIMs) and Common Message Element Types (CMETs) (Garde, 2007). This part (Communicating Archetypes) of the standard doesn t require that EHR models are archetype pren :2005 compliant. However it does require that these archetypes are capable of being mapped to the Archetype Model in order to support EHR communication and interoperability within an EHR-sharing community. Part three - Reference Archetypes and Term Lists This part specifies data objects for describing rules for distribution or the sharing of EHRs in whole or in part by establishing general principles for the interaction of EHRs with other components and mechanisms within an EHR application. The standard also establishes ways of creating information with associated security attributes (ANSI, 2006). Part four: Security Requirements and Distribution rules This part addresses aspects of data safety and security in the context of exchanging patient related medical information. It does this by specifying security requirements and mechanisms for managing access-rights to components of an EHR of a patient. It also defines mechanisms for auditing accesses to an EHR. The implementation and usability of the security functions of an EHR system is supported through the provision of easily implementable but course-grained general access policies, as well as mechanisms for defining fine-grained, individual access policies (ANSI, 2005). Part five: Exchange Models This part describes a set of models that form the basis of message-based or service-based communication. Parts four has already passed approval by CEN but the final draft is yet to be produced and this part has temporarily been put on hold. HL7 The term HL7 is used both: i) as a name for the organization and ii) as a set of messaging standards (Version 2.x and Version 3.x). The HL7 organization focuses on the interface requirements that are needed by the entire health care organization, when communicating healthcare data within or outside its healthcare systems. HL7 standards are the most successful messaging standards in the healthcare industry. It is a protocol that consists of standardized grammar and vocabulary. HL7 standards work by assuming that an event in the real world of healthcare systems creates the need for data to flow amongst various systems. This will be initiated by a trigger, which in the HL7 standard is equal to a Trigger Event (Eichelberg et al., 2005). When an event occurs in an HL7 compliant system a message is passed to the requesting application as EDA (Electronic Data Interchange) by gathering the relevant data from the applications (Ericson, 2004). The HL7 standard supports two message protocols: Version2 and Version3. HL7 Version2 The most widely used HL7 Version2 protocol is limited to the exchange of messages between medical information systems. It was not developed following any methodology to ensure that all parts of the standard are developed consistently. HL7 Version2 does not support interoperability between healthcare applications very successfully. The main reason for this is the lack of a precisely defined underlying information model structure, plus definitions for many data fields are vague and overloaded with optional data fields (Eichelberg et el, 2005). However, by not defining a detailed information model, the HL7 version2 standard allows greater flexibility, which immediately triggers the problem of interoperability. Applications participating in communication using HL7 version2 must therefore have mutual agreements to achieve interoperability. HL7 Version3 HL7 Version3 is an improvement from the previous Version2 by being more focused on specific contexts, terminology, models and conceptual definitions and relationships. Its underlying information model, called the Reference Information Model (RIM), is objectoriented and the proposal for the Clinical Document Architecture (CDA) for exchanging clinical documents across healthcare systems uses Extensible Markup Language (XML) to encode the documents (HL7 2.5, 2000) (InterfaceWare). Thus the CDA defines the structure and semantics of medical documents that are to be exchanged and CDA documents use data types specified in the HL7 RIM. The CDA consists of 3 levels (HL7 CDA). Each of them takes the mark up of the previous level and adds more mark up to compose a clinical document. However, this does not change the clinical content of the document (HL7 CDA Release 1.0, 2000)(HL7 Standards). Level1 consists of a Coded Header and a Body. The Coded Header defines the semantics of each entry in the document. The Body contains clinical data in an unstructured test format or it can consist of nested data such as paragraphs, lists and tables. Level2 models observations and instructions within each heading, thus making it possible to constrain the structure and content of the document through templates. This increases 5

6 interoperability by using agreed templates between heterogeneous healthcare systems. Level3 provides completely structured documents where each element of the document is adequately coded for machine processing. The CDA HL7 is not strictly an EHR standard, but forms its sub-component, that has already been harmonized with the equivalent structure in CEN13606 and openehr (HL7 EHR 2004). Thus HL7 and CEN cooperate and the current areas of harmonization include data types from (a) HL7 Templates (b) HL7 CDA, (c) CEN13606 Reference Models, and (d) CEN/openEHR archetypes (Schloeffel P., 2004). Digital Imaging and Communications in Medicine (DICOM) DICOM is the de facto standard for medical image communication. It uses binary encoding with hierarchical lists of data elements identified by numerical tags and a complex DICOM-specific application level network protocol (DICOM, 2007). There are two DICOM-based EHR standards available: 1. Web Access to DICOM Persistent Objects (WADO) 2. DICOM Structured Reporting. WADO is a cooperative standard between DICOM (DICOM Supplement ) and ISO (ISO ). This standard was created to enable and maintain international standards for the communication of biomedical diagnostic and therapeutic information in disciplines that use digital images and associated data. WADO defines a Web based service that can be used to retrieve persistent objects via HTTP or HTTPS from a Web server. The Web client has to specify the DICOM object that has to be retrieved. This will be done through unique identifiers available at the instance level of the DICOM information model. The web client may also request a specific data type to be sent via the web server. The web server will convert the existing DICOM object into a readily presentable format to be sent. The DICOM object can also be made anonymous before it is sent. This is a very useful feature for teaching purposes and clinical studies. WADO doesn t support query mechanisms. A WADO server will return a DICOM Structured Reporting Document to the client in the HTML format if requested. If not, the format will be dependent on the current implementation of the server. WADO uses a simple approach for accessing particular DICOM objects without requiring the client to be DICOM compatible. It is very easy to implement applications supporting WADO as they can be implemented by using readily available components such as Web browsers, servers and DICOM viewers (Eichelberg et el, 2005). DICOM Structured Reporting is a general model for encoding medical reports in a structured way. This is done using DICOM s tag-based format. It allows for current DICOM infrastructure network services to be used to archive and to communicate, and to digitally sign structured reports without making significant changes to the existing systems. To improve interoperability in practice, DICOM Structured Reporting specifies a document structure along with its class definitions and constraints for different medical applications. It defines templates that need to be used for this purpose. The collection of the standard templates, context groups and codes is called the DICOM Content Mapping Resource. It is important to note that DICOM does not specify how a Structured Reporting Document is rendered by an application, as this is regarded to be out of the scope of the standard (Eichelberg et el, 2005). HARMONIZATION BETWEEN STANDARDS Harmonization between standards and in some cases their convergence, is very important for the future interoperability of health information systems within and between countries. As we have already mentioned in the previous section, current areas of harmonization include data types: the HL7CDA and CEN Reference Models and CEN/openEHR archetypes with HL7 Templates. The OpenEHR Reference Model uses the CEN13606 Reference Model, which in turn is used in HL7CDA. So, it is quite visible that some harmonization has already taking place. There are also sporadic reports across EU countries that highlight their individual attempts to comply with CEN initiatives, thus recommending harmonization locally (SIST). A detailed rationale for the harmonization of EHR standards is available in the white paper about the HL7 EHR System Functional Model (HL7, 2004). CONCLUSION It was very difficult to prepare an overview of EHR interoperability standards that could have provided better reading than this paper offers. It was also extremely challenging to extract information that can be called an overview of standards from such a variety of sources, where almost none of them are written for wider healthcare or computing research communities. There are a few published papers, which have helped us to interpret the texts found in published standards correctly and which have been crucial to understanding a variety of issues covered in these standards. Thus any organizations, healthcare institutions or software developers willing to include these standards in order to achieve the interoperability of EHR systems, will face the same difficulties as we have had in collecting relevant material and understanding how to apply it. One of the solutions is to employ professionals who can interpret the standards so that they can be understood by software developers and healthcare professionals. 6

7 We do not wish to criticize the organizations which have produced these standards but we do think that their contribution towards solving the interoperability of EHR systems is enormous. However, it has become quite obvious that there is no consistency or coherence in what these standards cover: some of them are concerned with the content and structure of EHRs and others deal with access services to such records. It is easy to claim that the main purpose of EHR standards is to facilitate improvements in the five areas of interoperability, safety/security, quality/reliability, efficiency /effectiveness, and communication. However, when they advocate how to achieve comprehensive EHR in practice, they advise to join together multiple clinical applications and their specially tailored databases (HL7 EHR, 2004) (ISO TC 215, Draft 2002). This means that EHRs from diverse systems must be capable of being mapped to and from single comprehensive representation. Furthermore, this common representation is expected to be generic enough to represent any kind of health record which might be a partial or complete EHR being communicated. We know how difficult is to address the semantic and schematic heterogeneities in software applications that rely on data stored in structured and semi-structured repositories and databases which are often heterogeneous. Thus it is a surprise that none of these standards took into account experiences from software engineering and database communities, which have tried to alleviate the interoperability problems since the early 1990s. For example, requiring uniformity in heterogeneous database systems diminishes their individual autonomy and discourages their heterogeneities, which is exactly what we have to have in modern pervasive and ubiquitous healthcare environments, served by EHRs. Having said that, HL7 version3 can be considered to be the foundation of future integrated health care environments. By combining HL7 version3 and the CEN ENV standard, organizations can get a complete standard solution for the introduction of Information Communication Technology into the health care domain. There is definitely a space for integration between various healthcare systems and applications, which can be achieved by providing a transparent exchange of health care information. From this point of view, all the standards meet this specification. However, from the software engineering perspective, interoperation of such a system is more complex than standards could define. It is not possible to favor one standard over the other. They are all quite similar in what they cover, however at different stages of their evolution. There will always be organizations that will be using incompatible EHR standards. The only solution will be when full semantic interoperability is reached. REFERENCES Akram A., Juric R., Ranganathan M., Slevin L., Databases for facilitating data sharing in The UK NHS, accepted for Integrated Design and Process Technology, ANSI, 2005, Health Informatics - Electronic health record communication - Part 4: Security requirements and distribution rules, version pren :2005, ANSI, USA. ANSI, 2006, Health informatics - Electronic health record communication - Part 3: Reference archetypes and term lists, version pren :2006, ANSI, USA Beale T., 2002, Archetypes: Constraint-based Domain Models for Future-proof Information Systems, Deep Thought Informatics PTY, LTD Mooloolah, Qld, Australia. Bossen C., 2006, Representations at Work: A National Standard for Electronic Health Records. Proceedings of the th anniversary conference on Computer supported cooperative work, Banff, Alberta, Canada, pp Bott O.J., 2004, The Electronic Health Record Standardisation and Implementation, 2 nd OpenECG Workshop, Berlin, Institute for Medical Informatics, Cabinet Office, 2005, e-gif e-government Interoperability Framework, Technical Standards Catalogue Version ent.asp?docnum=957, CEN/TC 251, pren :2006, Health Informatics Electronic Health Record communication, Part 1: Reference Model, European Standard. CEN/TC 251, ENV , 1999, Electronic healthcare record communication Part1: Extended architecture, Committee European Normalisation, Health Informatics Technical Committee. CEN/TC 251, pren , 2005, Health Informatics - Electronic health record communication Part 2: Archetypes. CEN/TC 251, pren , 2006, Health informatics Service architecture Part 3: Computational viewpoint, CEN/TC 251, Working Group IV Technology for Interoperability, DICOM, 2004, Part1: Introduction and Overview, PS3.1. National Electrical Manufacturers Association, Virginia, USA DICOM, 2007, Part 2: Conformance, PS , National Electrical Manufacturers Association, Virginia, USA DICOM, Supplement 85, Web access to DICOM persistent objects (WADO). Joint DICOM 7

8 Standards Committee, ISO TC215 Ad Hoc Working Group on WADO. Dumay A.C, Ferkins G., 2002, Towards developing a coherent healthcare information infrastructure, Studies in Health ogynformatics, Vol93, pp 1-7. Eichelberg M., Aden T., Riesmeier J., Dogac A., Laleci G., 2005, A Survey and Analysis of Electronic Healthcare Record Standards, ACM Computing surveys, Vol37(4), pp Ericson N, 2004, Health Care Agent, Frankel H., 2006, Archetypes: Update, 10 th conference HL7, Australia. Garde S, Knaup P, Hovenga EJS, Heard S, 2007, Towards Semantic Interoperability for Electronic Health Records: Domain Knowledge Governance for openehr Archetypes, Methods of Information in Medicine, Vol.46,(1). Giuse D.A., Kuhn K.A., 2003, Health information systems challenges: the Heidelberg conference and the future, International Journal of Medical Informatics, Vol.69 (3), pp Gross G., 2005, Lack of standards hinders electronic health records. Interoperability concerns loom large., IDGNS. Health Level7. HL7, 2004, EHR System Functional Model: A Major Development Towards Consensus on Electronic Health Record System Functionality, A White Paper. Health Level Seven, Inc. HL7, 2005, Application Protocol for Electronic Data Exchange in Healthcare Environments, Version2.5. HL7, 2000, The HL7 Version 3 Standard: Clinical Data Architecture, CDA Release 1.0. Hsyien-Chi W., Yuh-Shan H., Wen-Shan J., Hsien- Chang L., Yi-Hsin E.H., 2007, Scientific production of electronic health record research, , Computer Methods and Programs in Biomedicine, Vol.86, pp InterfaceWare, ISO, TC 215, 2002, EHR ad hoc Task Group, Standards requirements for the EHR, Draft d_isowg1_e_ehr_taskgroup.pdf ISO, /index.html ISO TC215, ISO/TR 20514, 2005, Health Informatics Electronic health record Definition, scope, and context, ISO, Geneva, Switzerland. ISO 17432, 2004, Health Informatics Messages and Communication Web Access to DICOM Persistent Objects, ISO, Geneva, Switzerland. ISO/TR 18307, 2001, Health Informatics Interoperability and Compatibility in messaging and communication standards Key characteristics., ISO, Geneva, Switzerland. Kalra D., Ingram D, Electronic Health Records, Centre for Health Informatics and Multiprofessional Education, UCL, London, UK Kalra D., 2006, Electronic Health Record Standards, IMIA Yearbook of Medical Informatics, pp Kuhn K.A., Giuse D.A., 2001, From hospital information systems to health information systems, problems, challenges perspectives, Methods of Information in Medicine. Vol. 40(4), pp Medisell, 2002, Interoperability with EPR systems: Standards, Technologies & Trends, Information Society Technologies. NEMA, National Electrical Manufacturers Association. NPfIT, 2004, National Program for IT, Care Record Development Board, Ethics Advisory Group, Ethical Principles docs/crdb_ethical_prin.pdf openehr, EHR Standards, The OpenEHR Foundation, Schloeffel P., 2004, Current EHR Developments: An Australian and International Perspective. Health Informatics New Zealand Conference (HINZ2004), Wellington, New Zealand. Schloeffel P., Jeselon P., 2002, Standards requirements for the EHR, Discussion Paper, Draft 1.2. SIST, Slovenian Institute for Standardization, Ljubljana, Slovenia, Slevin, L., Dagdeviren, H., Juric, R., and Akram A., (2005) "Supporting Quality Indicators in the UK National Health Service", In Proceedings of the 27 th International Conference on Information Technology Interfaces, ITI 2005 (Cavtat, Dubrovnik, Croatia, June 2005). Ueckert F., Goerz M., Ataian M., Tessmann S., Prokosch H.U., 2003, Empowerment of patients and communication with health care professionals through an electronic health record, International Journal of Medical Informatics, Vol.70 (2-3), pp Valdes I., Kibbe D.C., Tolleseon G., Kunik M.E., Petersen L.A., 2004, Barriers to proliferation of electronic medical records, Informatics in Primary Care, Vol.12, No 1, pp3-9. Van Ginneken A.M., 2002, The computerized patient record balancing effort and benefit., International Journal of Medical Informatics, Vol.65 (2002),pp