EN 13606-1:2007

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

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

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.

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

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.

Figure 1 — Diagram of the EHR Extract hierarchy (part 1)
Figure 2 — Diagram of the EHR Extract hierarchy (part 2)

CEN/TS 14796 in favour of this new standard. In doing so, it will need to provide a mapping correspondence to the new data type standard, and this mapping will also need to be used in order to adopt the new data types alongside EN 13606-1. In order to support the adoption of this European Standard more widely internationally than the jurisdiction of
CEN/TS 14967, the set of attribute data types actually used within this reference model (other than the data value of ELEMENT) are explicitly included in this European Standard in a Support Package. These should also be deprecated in favour of ISO data types once published.
...