SIST EN 13606-1:2008
(Main)Health informatics - Electronic health record communication - Part 1: Reference model
Health informatics - Electronic health record communication - Part 1: Reference model
This European Standard specifies the communication of part or all of the electronic health record (EHR) of a single identified subject of care between EHR systems, or between EHR systems and a centralised EHR data repository.
It may also be used for EHR communication between an EHR system or repository and clinical applications or middleware components (such as decision support components) that need to access or provide EHR data.
This European Standard will predominantly be used to support the direct care given to identifiable individuals, or to support population monitoring systems such as disease registries and public health surveillance. Uses of health records for other purposes such as teaching, clinical audit, administration and reporting, service management, research and epidemiology, which often require anonymisation or aggregation of individual records, are not the focus of this European Standard but such secondary uses might also find the standard useful.
This Part 1 of the multipart series is an Information Viewpoint specification as defined by the Open Distributed Processing – Reference model: Overview (ISO/IEC 10746-1). This European Standard is not intended to specify the internal architecture or database design of EHR systems.
Medizinische Informatik - Kommunikation von Patientendaten in elektronischer Form - Teil 1: Referenzmodell
Informatique de santé - Dossier de santé informatisé et communication - Partie 1: Modele de référence
La présente norme spécifie la communication de tout ou partie du dossier informatisé de santé (DIS) d'un seul sujet de soins identifié entre systèmes de DIS, ou entre des systèmes de DIS et un réceptacle de données de DIS centralisé.
Elle peut également être utilisée pour la communication de DIS entre un système ou réceptacle de DIS et des applications médicales ou composants intergiciels (tels que des composants d'aide à la prise de décision) nécessitant d'avoir d'accès aux ou de fournir des données DIS.
La présente Norme européenne est destinée à être principalement utilisée pour prendre en charge les soins directs dispensés à des personnes identifiables, ou les systèmes d'observation de la population tels que les registres de maladies et l'observation de la santé publique. L’utilisation des dossiers de santé pour d’autres finalités telles que l'enseignement, l'évaluation médicale, l’administration et l'établissement de rapports, la gestion des services de santé, la recherche et l’épidémiologie, qui nécessitent l’agrégation de dossiers individuels de personnes physiques ne constitue pas l’objet de la présente Norme européenne ; néanmoins, ces applications secondaires sont susceptibles de trouver un intérêt à cette norme.
La présente partie 1 de cette norme constituée de plusieurs parties est une spécification édictée d'un point de vue informationnel tel que défini dans la norme "Traitement réparti ouvert - Modèle de référence : présentation générale" (ISO/CEI 10746-1). La présente Norme européenne n’a pas pour vocation de spécifier l’architecture interne ou la conception de la base de données des systèmes de DIS.
Zdravstvena informatika - Komunikacija z elektronskimi zapisi na področju zdravstva - 1. del: Referenčni model
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Health informatics - Electronic health record communication - Part 1: Reference modelSRGURþMXInformatique de santé - Dossier de santé informatisé et communication - Partie 1: Modele de référenceMedizinische Informatik - Kommunikation von Patientendaten in elektronischer Form - Teil 1: ReferenzmodellTa slovenski standard je istoveten z:EN 13606-1:2007SIST EN 13606-1:2008en35.240.80Uporabniške rešitve IT v zdravstveni tehnikiIT applications in health care technologyICS:SIST ENV 13606-1:20031DGRPHãþDSLOVENSKI
STANDARDSIST EN 13606-1:200801-februar-2008
EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 13606-1February 2007ICS 35.240.80Supersedes ENV 13606-1:2000
English VersionHealth informatics - Electronic health record communication -Part 1: Reference modelInformatique de santé - Dossier de santé informatisé etcommunication - Partie 1: Modèle de référenceMedizinische Informatik - Kommunikation vonPatientendaten in elektronischer Form - Teil 1:ReferenzmodellThis European Standard was approved by CEN on 15 December 2006.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this EuropeanStandard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such nationalstandards may be obtained on application to the CEN Management Centre or to any CEN member.This European Standard exists in three official versions (English, French, German). A version in any other language made by translationunder the responsibility of a CEN member into its own language and notified to the CEN Management Centre has the same status as theofficial versions.CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2007 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 13606-1:2007: E
EN 13606-1:2007 (E) 2 Contents Page Foreword.4 Introduction.5 1 Scope.24 2 Normative references.24 3 Terms and definitions.24 4 Abbreviations.29 5 Conformance (normative).30 5.1 EHR System conformance.30 5.2 Member State conformance.31 6 Reference Model.32 6.1 Index to Packages.32 6.2 Package: EXTRACT Package.33 6.3 Package: DEMOGRAPHICS Package.47 6.4 Package: SUPPORT Package.54 6.5 Primitive Data Types.62 Annex A (informative)
UML profile.63 Annex B (informative)
Relationship to other standards.65 Annex C (informative)
Clinical Example.77 Annex D (informative)
Mapping to statements of requirement.90 Bibliography.96
EN 13606-1:2007 (E) 3 List of Figures and Tables Page Table 1 — Main hierarchy components of the EHR Extract Reference Model.8 Figure 1 — Diagram of the EHR Extract hierarchy (part 1).9 Figure 2 — Diagram of the EHR Extract hierarchy (part 2).9 Figure 3 — UML Class Diagram of Extract Package.34 Figure 4 — UML Class Diagram of the Demographics Package.47 Figure 5 — UML Class Diagram of Support Package.54 Figure 6 — UML Class Diagram of Primitives Package.62 Table B.1 — Mapping of CONTSYS to EN 13606-1.66 Table B.2 — Mapping of HISA to EN 13606-1.68 Table B.5 — Mapping of XDS Folder to EN 13606-1.71 Table B.6 — Mapping of ENV 13606-1 to EN 13606-1.71
EN 13606-1:2007 (E) 4 Foreword This document (EN 13606-1:2007) has been prepared by Technical Committee CEN/TC251 “Health informatics”, the secretariat of which is held by NEN. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by August 2007, and conflicting national standards shall be withdrawn at the latest by August 2007. This document supersedes ENV 13606-1:2000. This multipart standard under the general heading Health informatics – Electronic health record communication consists of the following parts: Part 1: Reference model Part 2: Archetypes interchange specification Part 3: Reference archetypes and term lists Part 4: Security Part 5: Messages for exchange According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EN 13606-1:2007 (E) 5 Introduction The overall goal of this European Standard is to define a rigorous and stable information architecture for communicating part or all of the Electronic Health Record (EHR) of a single subject of care (patient). This is to support the interoperability of systems and components that need to communicate (access, transfer, add or modify) EHR data via electronic messages or as distributed objects: • preserving the original clinical meaning intended by the author; • reflecting the confidentiality of that data as intended by the author and patient. This European Standard is not intended to specify the internal architecture or database design of EHR systems or components. Nor is it intended to prescribe the kinds of clinical applications that might request or contribute EHR data in particular settings, domains or specialities. For this reason, the information model proposed here is called the EHR Extract, and might be used to define a message, an XML document or schema, or an object interface. The information model in this European Standard is an ISO RM-ODP Information Viewpoint of the EHR Extract. This European Standard considers the EHR to be the persistent longitudinal and potentially multi-enterprise or multi-national record of health and care provision relating to a single subject of care (the patient), created and stored in one or more physical systems in order to inform the subject’s future health care and to provide a medico-legal record of care that has been provided. Whilst an EHR service or system will need to interact with many other services or systems providing terminology, medical knowledge, guidelines, workflow, security, persons registries, billing etc. this European Standard has only touched on those areas if some persistent trace of such interactions is required in the EHR itself, and requires specific features in the reference model to allow their communication. This European Standard may offer a practical and useful contribution to the design of EHR systems but will primarily be realised as a common set of external interfaces or messages built on otherwise heterogeneous clinical systems. Technical approach This European Standard has drawn on the practical experience that has been gained in implementing its European predecessor, ENV 13606, other EHR-related standards and specifications, commercial systems and demonstrator pilots in the communication of whole or part of patients’ EHRs, and on fifteen years of research findings in the field. This European Standard builds on ENV 13606, updating it in order to make it more rigorous and complete, to accommodate new requirements identified, to incorporate a robust means of applying the generic models to individual clinical domains, and to enable communication using HL7 version
3 messages. A mapping from the existing prestandard is also provided to support implementers of existing conformant systems. The technical approach to producing this European Standard has taken into account several contemporary areas of requirement. a. In addition to a traditional message-based communication between isolated clinical systems, the Electronic Health Record will in some cases be implemented as a middleware component (a record server) using distributed object technology and/or web services. b.
“Customers” of such record services will be not only other electronic health record systems but also other middleware services such as security components, workflow systems, alerting and decision support services and other medical knowledge agents. c. There is wide international interest in this work, and this European Standard has been drafted jointly through CEN and ISO with significant input from many member countries.
EN 13606-1:2007 (E) 6 d. Mapping to HL7 version 3 has been considered an important goal, to enable conformance to this European Standard within an HL7 version 3 environment. e. The R&D inputs on which ENV 13606 was based have moved forward since 1999 and important new contributions to the field have been taken into account. The openEHR foundation, integrating threads of R&D in Europe and Australia, is one such example.
Given the diversity of deployed EHR systems, this European Standard has made most features of EHR communication optional rather than mandatory. However, some degree of prescription is required to make EHR Extracts safely processable by an EHR recipient system, which is reflected through mandatory properties within the models in Parts 1, 2, and 4 of this series, and through normative term lists (defined in Part 3 of this series). This European Standard will, in practice, usually be adopted alongside other health informatics standards that define particular aspects of health data representation. Annex B explains how this European Standard can be used alongside key complementary standards, including the HL7 Version 3 Reference Information Model (RIM), EN 14822-1, EN 14822-2, EN 14822-3, CEN/TS 14822-4 (GPIC), prEN 12967 (HISA) and prEN13940 (CONTSYS). The Dual Model approach The challenge for EHR interoperability is to devise a generalised approach to representing every conceivable kind of health record data structure in a consistent way. This needs to cater for records arising from any profession, speciality or service, whilst recognising that the clinical data sets, value sets, templates etc. required by different health care domains will be diverse, complex and will change frequently as clinical practice and medical knowledge advance. This requirement is part of the widely acknowledged health informatics challenge of semantic interoperability. The approach adopted by this European Standard distinguishes a Reference Model, defined in this European Standard and used to represent the generic properties of health record information, and Archetypes (conforming to an Archetype Model, defined in Part 2 of this series), which are meta-data used to define patterns for the specific characteristics of the clinical data that represents the requirements of each particular profession, speciality or service. The Reference Model represents the global characteristics of health record components, how they are aggregated, and the context information required to meet ethical, legal and provenance requirements. This model defines the set of classes that form the generic building blocks of the EHR. It reflects the stable characteristics of an electronic health record, and would be embedded in a distributed (federated) EHR environment as specific messages or interfaces (as specified in Part 5 of this series). This generic information model needs to be complemented by a formal method of communicating and sharing the organisational structure of predefined classes of EHR fragment corresponding to sets of record components made in particular clinical situations. These are effectively pre-coordinated combinations of named RECORD_COMPONENT hierarchies that are agreed within a community in order to ensure interoperability, data consistency and data quality. An Archetype is the formal definition of prescribed combinations of the building-block classes defined in the Reference Model for particular clinical domains or organisations. An archetype is a formal expression of a distinct, domain-level concept, expressed in the form of constraints on data whose instances conform to the reference model. For an EHR_Extract as defined in this European Standard, an archetype instance specifies (and effectively constrains) a particular hierarchy of RECORD_COMPONENT sub-classes, defining or constraining their names and other relevant attribute values, optionality and multiplicity at any point in the hierarchy, the data types and value ranges that ELEMENT data values may take, and other constraints. This European Standard recognises that archetypes might be used to support communication between some EHR systems in the future, or might be used as a knowledge specification by some EHR system external interfaces when mapping parts of an EHR to an EHR_EXTRACT, or might not be used at all between some
EN 13606-1:2007 (E) 7 EHR systems. The use of archetypes is therefore supported, but not made mandatory, by this European Standard. A specification for communicating archetypes is defined by Part 2 of this series. Requirements basis for this European Standard From the early 1990's it was recognised that a generic representation is required for the communication of arbitrary health record information between systems, and in Europe this has resulted in a succession of EU sponsored R&D projects and two generations of CEN health informatics standards prior to this one. These projects and standards have sought to define the generic characteristics of EHR information and to embody these in information models and message models that could provide a standard interface between clinical systems. The vision of such work has been to enable diverse and specialist clinical systems to exchange whole or parts of a person’s EHR in a standardised way that can rigorously and generically represent the data values and contextual organisation of the information in any originating system. A complementary goal has been to accommodate the evolving nature of medical knowledge and the inherent diversity of clinical practice. Many investigations of user and enterprise requirements for the EHR have taken place over this period, which have sought to span the information needs of diverse specialties across primary, secondary and tertiary care, between professions and across countries. These requirements have been distilled and analysed by expert groups, mainly within Europe, in order to identify the basic information that needs to be accommodated within an EHR information architecture to: • capture faithfully the original meaning intended by the author of a record entry or set of entries; • provide a framework appropriate to the needs of professionals and enterprises to analyse and interpret EHRs on an individual or population basis; • incorporate the necessary medico-legal constructs to support the safe and relevant communication of EHR entries between professionals working on the same or different sites. This work includes the GEHR, EHCR-SupA, Synapses, I4C and Nora projects and work by SPRI. These key requirements publications are listed in the Bibliography. These requirements have recently been consolidated on the international stage within an ISO Technical Specification, ISO/TS 18308. In this Reference Model the key EHR contextual requirements for such faithfulness are related to a set of logical building block classes, with suitable attributes proposed for each level in the EHR Extract hierarchy. ISO/TS 18308 has been adopted as the reference set of requirements to underpin the features within this EHR communications Reference Model, and a mapping of these requirements statements to the constructs in the Reference Model is given in Annex D. Overview of the EHR Extract record hierarchy The information in a health record is inherently hierarchical. Clinical observations, reasoning and intentions can have a simple or a more complex structure. They are generally organised under headings, and contained in “documents” such as consultation notes, letters and reports. These documents are usually filed in folders, and a patient may have more than one folder within a healthcare enterprise (e.g. medical, nursing, obstetric). The EHR Extract Reference Model needs to reflect this hierarchical structure and organisation, meeting published requirements in order to be faithful to the original clinical context and to ensure meaning is preserved when records are communicated between heterogeneous clinical systems. To do this, the model formally sub-divides the EHR hierarchy into parts that have been found to provide a consistent mapping to the ways in which individual EHRs are organised within heterogeneous EHR systems. These parts are summarised in Table 1 below.
EN 13606-1:2007 (E) 8 Table 1 — Main hierarchy components of the EHR Extract Reference Model EHR HIERARCHY
COMPONENT DESCRIPTION EXAMPLES EHR_EXTRACT The top-level container of part or all of the EHR of a single subject of care, for communication between an EHR Provider system and an EHR Recipient. (Not applicable) FOLDER The high level organisation within an EHR, dividing it into compartments relating to care provided for a single condition, by a clinical team or institution, or over a fixed time period such as an episode of care. Diabetes care, Schizophrenia, Cholecystectomy, Paediatrics, St Mungo’s Hospital, GP Folder, Episodes 2000-2001, Italy.
COMPOSITION The set of information committed to one EHR by one agent, as a result of a single clinical encounter or record documentation session. Progress note, Laboratory test result form, Radiology report, Referral letter, Clinic visit, Clinic letter, Discharge summary, Functional health assessment, Diabetes review. SECTION EHR data within a COMPOSITION that belongs under one clinical heading, usually reflecting the flow of information gathering during a clinical encounter, or structured for the benefit of future human readership. Reason for encounter, Past history, Family history, Allergy information, Subjective symptoms, Objective findings, Analysis, Plan, Treatment, Diet, Posture, Abdominal examination, Retinal examination. ENTRY The information recorded in an EHR as a result of one clinical action, one observation, one clinical interpretation, or an intention. This is also known as a clinical statement. A symptom, an observation, one test result, a prescribed drug, an allergy reaction, a diagnosis, a differential diagnosis, a differential white cell count, blood pressure measurement. CLUSTER The means of organising nested multi-part data structures such as time series, and to represent the columns of a table.
Audiogram results, electro-encephalogram interpretation, weighted differential diagnoses. ELEMENT The leaf node of the EHR hierarchy, containing a single data value. Systolic blood pressure, heart rate, drug name, symptom, body weight.
An EHR_EXTRACT contains EHR data as COMPOSITIONs, optionally organised by a FOLDER hierarchy. COMPOSITIONs contain ENTRYs, optionally contained within a SECTION hierarchy. ENTRYs contain ELEMENTS, optionally contained within a CLUSTER hierarchy.
EN 13606-1:2007 (E) 9
Figure 1 — Diagram of the EHR Extract hierarchy (part 1)
Figure 2 — Diagram of the EHR Extract hierarchy (part 2)
EN 13606-1:2007 (E) 10 Description of the main Reference Model classes EHR_EXTRACT The EHR_EXTRACT is used to represent part or all of the health record information extracted from an EHR Provider system for the purposes of communication to an EHR Recipient (which might be another EHR system, a clinical data repository, a client application or a middleware service such as an electronic guideline component), and supporting the faithful inclusion of the communicated data in the receiving system. The EHR_EXTRACT class contains attributes to identify the subject of care whose record this is, the EHR Provider system from which it has been derived and the identifier of that subject’s EHR in that system, and optionally the agent responsible for creating it. The EHR_EXTRACT contains the EHR data, in three parts. 1) a set of COMPOSITIONs; 2) optionally, a directory of FOLDERs that provide a high-level grouping and organising of the COMPOSITIONs; 3) optionally, a set of demographic descriptors for each of the persons, organisations, devices or software components that are identified within (1) and (2) above. This approach allows such entities to be referenced uniquely via an identifier within the body of the EHR, without repetition of the descriptive details each time, and also ensures that any EHR_EXTRACT can be interpreted in isolation if the recipient system does not have access to the services needed to decode the entity identifiers used by the EHR Provider. A formal mechanism is defined in Part 4 of this series for including access policy information within the EHR_EXTRACT. This is intended to inform the EHR Recipient about the wishes of the subject of care and of healthcare providers for how future access requests for the data should be managed. The EHR_EXTRACT also contains a summary of the filter or selection criteria by which this EHR_EXTRACT was created. This may or may not correspond directly to the criteria in the EHR Request, and provides a record of the kind of subset this EHR_EXTRACT is of the overall EHR held by the EHR Provider. This might be of importance if the EHR_EXTRACT is retained intact by the EHR Provider or EHR Recipient, and subsequently accessed by agents that do not have access to the original EHR request. For example, this class can specify if this EHR_EXTRACT is limited to the most recent version of each COMPOSITION (as required for most clinical care purposes) or if it includes all historic versions (which might be required for legal purposes). It might specify the maximum level of sensitivity of the data (implying that data that is more sensitive than this level may exist and have been filtered out), or that multi-media objects have been excluded to limit its total size. If the EHR_EXTRACT was created by selecting particular categories of clinical data (for example, only laboratory data) then this may be indicated through a list of the archetypes that were included in the selection criteria. An option exists to include additional criteria (expressed as strings); this may be used to provide additional human readable information about this EHR_EXTRACT or may be used for locally agreed computer-interpretable constraint information.
EN 13606-1:2007 (E) 11 RECORD_COMPONENT The main building block classes that are used to construct the EHR data hierarchy within an EHR_EXTRACT are kinds of RECORD_COMPONENT. This is an abstract class, the super-class of all of the concrete nodes in the EHR hierarchy: FOLDER, COMPOSITION, SECTION, ENTRY, CLUSTER, ELEMENT, and also the super-class for two other abstract class nodes: CONTENT and ITEM. RECORD_COMPONENT defines the information properties that are common to all of these building blocks, including: • the unique identifier that was issued to this EHR node by the EHR system in which it was first committed (its originating EHR system); other holders of this RECORD_COMPONENT need to retain this attribute value to ensure that any subsequent extracts are always consistently identified; • the clinical name, used in its originating EHR system to label this part of the EHR data; • optionally a standardised coded concept to which the name has been mapped to support the semantic interoperability of equivalent EHR instances even if these have been given different clinical names by different EHR systems; • the identifier of the archetype node to which this RECORD_COMPONENT conforms, to be used by archetype enabled-EHR systems or if archetypes have been used when mapping the data into the EHR_EXTRACT format; • a sensitivity code and references to access control policies that should be used by the EHR Recipient to govern future access to the data; • support for Links between any Record Components. When generating an EHR_EXTRACT conformant to this European Standard the EHR provider system might, in some situations, need to introduce a RECORD_COMPONENT into the hierarchy that does not have a direct correspondence with any original data in the EHR system. The synthesised attribute of RECORD_COMPONENT permits the exporting EHR provider system to indicate that a RECORD_COMPONENT has been created within the EHR_EXTRACT for this purpose. Health record entries often refer to other pre-existing entries, and include them as "copies". A common example of this is a discharge summary, which might include copies of several parts of an inpatient stay record such as the admission circumstances, the main diagnoses, principal interventions and treatments. In most cases the EHR_EXTRACT needs to contain these referenced RECORD_COMPONENTS explicitly by value, so that each COMPOSITION can be interpreted by the EHR Recipient. However, it is important medico-legally also to communicate that these entries are copies, and that they originate from a different part of that subject’s EHR. The optional attribute original_parent_ref may be used to represent the rc_id of the original parent RECORD_COMPONENT if the data is a copy. Any RECORD_COMPONENT may include audit data about when and by whom it was committed in its originating EHR system. Each revised version of a RECORD_COMPONENT may document the version status, the reason for the revision and the identifier of the preceding version. However, for data protection reasons it is usually advised that previous (erroneous) versions of an EHR are not communicated as part of normal clinical shared care, but only in circumstances where an EHR transfer is being made for legal reasons. It is important that each RECORD_COMPONENT be uniquely and consistently identified across multiple EHR_EXTRACTS, so that references to or between them remaining valid. Examples of such references are semantic links, revision and attestation. The rc_id attribute is of data type Instance Identifier (II), which incorporates an ISO OID; II is currently considered internationally to be the most appropriate data type for persistent identifiers that are required to be globally unique. It is unlikely that contemporary EHR systems will have existing primary keys or internal identifiers that correspond directly to globally-unique II instances. However, an EHR Provider system that has been issued with an organisational OID might use its internal references to construct unique local extensions to that OID
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.