SIST EN 13606-3:2008

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Health informatics - Electronic health record communication - Part 3: Reference archetypes and term listsGUDYVWYHQHPInformatique de la santé - Communication des dossiers de santé informatisés - Partie 3: Archétypes de référence et listes de termesMedizinische Informatik - Kommunikation von Patientendaten in elektronischer Form - Teil 3: Referenzarchetypen und Begriffslisten35.240.80Uporabniške rešitve IT v zdravstveni tehnikiIT applications in health care technologyICS:SIST EN 13606-3:2008enTa slovenski standard je istoveten z:EN 13606-3:200801-junij-2008SIST EN 13606-3:2008SLOVENSKI
STANDARDSIST ENV 13606-3:20031DGRPHãþD







EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 13606-3March 2008ICS 35.240.80Supersedes ENV 13606-3:2000
English VersionHealth informatics - Electronic health record communication -Part 3: Reference archetypes and term listsInformatique de la santé - Communication des dossiers desanté informatisés - Partie 3: Archétypes de référence etlistes de termesMedizinische Informatik - Kommunikation vonPatientendaten in elektronischer Form - Teil 3:Referenzarchetypen und BegriffslistenThis European Standard was approved by CEN on 28 February 2008.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© 2008 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 13606-3:2008: E



EN 13606-3:2008 (E) 2 Contents Page Foreword.3 Introduction.4 0.1 Summary.4 0.2 Term Lists.4 0.3 Reference Archetypes.4 1 Scope.5 2 Terms and definitions.5 3 Abbreviations.6 4 Conformance.6 5 Term lists.7 5.1 Introduction.7 5.2 Termlist SUBJECT_CATEGORY, Class ENTRY, attribute subject_of_information_category.7 5.3 Termlist ITEM_CATEGORY, Class ITEM, attribute item_category.8 5.4 Termlist VERSION_STATUS, Class AUDIT_INFO, attribute version_status.9 5.5 Termlist MODE, Class FUNCTIONAL_ROLE, attribute mode.10 5.6 Termlist ACT_STATUS, Class ENTRY, attribute act_status.11 5.7 Termlist LINK_NATURE, Class LINK, attribute nature.12 5.8 Termlist LINK_ROLE, Optional term list for LINK attribute role (Informative).13 5.8.1 Introduction.13 5.8.2 Optional term list for LINK attribute role (Informative).13 5.8.3 Mapping of extended term list to ENV13606-2 categories of Link (Informative).16 5.8.4 Mapping of extended term list to HL7 act.Relationship codes (Informative).17 5.9 Termlist STRUCTURE_TYPE, Class CLUSTER, attribute structure_type.19 Annex A (informative)
Reference archetypes.20 A.1 Introduction to the openEHR and HL7 mapping archetypes.20 A.2 openEHR ENTRY archetypes.21 A.2.1 Introduction.21 A.2.2 openEHR ENTRY.23 A.2.3 openEHR Evaluation.24 A.2.4 openEHR Observation.25 A.2.5 openEHR Instruction.26 A.2.6 openEHR Action.27 A.3 HL7 Version 3 entry archetypes.28 A.3.1 Introduction.28 A.3.2 HL7 Observation Act.28 A.3.3 HL7 Procedure Act.30 A.3.4 HL7 Substance Administration Act.31 A.3.5 HL7 Supply Act.32 A.3.6 HL7 Act.33 A.3.7 HL7 Encounter Act.34 A.4 Code set for RECORD_COMPONENT.meaning attribute.35 Annex B (informative)
Clinical example of the mapping between HL7 v3 and ISO 13606.37 B.1 Introduction.37 B.2 HL7 v3 representation of the Barthel Index.37 B.3 Table of correspondence between HL7 v3 and ISO 13606 for the Barthel Index.38



EN 13606-3:2008 (E) 3 Foreword This document (EN 13606-3:2008) has been prepared by Technical Committee CEN/TC 251 “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 September 2008, and conflicting national standards shall be withdrawn at the latest by September 2008. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights. This document supersedes ENV 13606-3:2000. 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 the United Kingdom.



EN 13606-3:2008 (E) 4 Introduction 0.1 Summary Part 3 of the 13606 standards series contains two kinds of specifications: 1 normative set of (coded) term lists that each defines a controlled vocabulary for a Reference Model attribute that is defined in Part 1 of this standard series; 2 informative set of Reference Archetypes: expressed as mappings that each specifies how the Part 1 Reference Model should be used to represent information originating from:
o set of HL7 version 3 Acts that form part of the Clinical Statement Domain Message Information Model; o specialisations of ENTRY that are defined in the openEHR Reference Model. 0.2 Term Lists Each term list is referenced by its corresponding attribute as an invariant constraint in Part 1 of this standard series, by referring to its term list name. For each term list, every code value is accompanied by a phrase and description; however, in each case it is the code that is to be used as the Reference Model attribute value. Language translations of the phrase and description will therefore not affect the instances of RECORD_COMPONENT that are communicated using this standard.
Should any future revision prove necessary for these term lists, a technical revision of this standard will be required. Such a revised standard shall specify an updated Reference Model identifier that shall then be used as the value of the rm_id of an EHR_EXTRACT, to inform the recipient of the version of this standard that was used in its creation.
A cross-mapping of the term list for LINK.role to HL7 actRelationship codes is also provided for the convenience of those wishing to adopt or interface this standard with HL7 version 3. This is part of a longer-term vocabulary harmonisation project between the health informatics standards development organizations (SDO’s), and might therefore be extended in the future via other publications, such as the planned HL7-13606 Implementation Guide (see below). It is therefore informative in this standard. 0.3 Reference Archetypes Each Reference Archetype is represented in this standard as a mapping correspondence table to indicate the way in which the ITEM structure within a 13606 Part 1 ENTRY is to be used to represent the classes and attributes of relevant HL7 v3 and openEHR classes. These two external models have been chosen for inclusion as these are the most likely internationally-used source models from which fine-grained clinical data may need to be transformed into this standard for communication. These Reference Archetypes are included as an aid to those adopting this standard and wishing to transform Electronic Health Record (her) data from existing HL7 v3 or openEHR instances or messages. It is recognised that full two-way interoperability between these various representations requires more detail, including rich vocabulary and data type harmonisation, and a corresponding set of technical artefacts such as eXtensible Markup Language (XML) Schemata and Extensible Stylesheet Language Transformation (XSLT) scripts. Such interoperability is very much the goal of current SDO harmonisation efforts, and will be published as an HL7-13606 Implementation Guide, possibly as an open-access and regularly updated resource. However, the outstanding work required to achieve this level of interoperability might take up to another year from when this standard is expected to be published. It has therefore been decided to offer what does exist towards harmonisation in an informative form within this standard, as an aid to those already needing to make such data transformations. A worked example of the HL7 v3 to ISO 13606 mapping is given in Annex B.



EN 13606-3:2008 (E) 5 1 Scope This Standard addresses the communication of part or all of electronic health records (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, or as the representation of EHR data within a distributed (federated) record system.
This Standard, Part 3 of the 13606 EHR Communications Standard Series, defines term lists that each specify the set of values that particular attributes of the Reference Model defined in Part 1 of this Series may take. It also defines informative Reference Archetypes that correspond to ENTRY-level compound data structures within the Reference Models of openEHR and HL7 Version 3, to enable those instances to be represented within a consistent structure when communicated using this standard. 2 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 archetype instance individual metadata class instance of an Archetype Model, specifying the clinical concept and the value constraints that apply to one class of Record Component instances in an electronic health record extract 3.2 clinical information information about a person, relevant to his or her health or health care 3.3 committed information that has been persisted within an electronic health record system and which constitutes part of the electronic health record for a subject of care 3.4 committer agent (party, device or software) whose direct actions have resulted in data being committed to an electronic health record 3.5 composer agent (party, device or software) responsible for creating, synthesising or organising information that is committed to an electronic health record 3.6 electronic health record extract part or all of the electronic health record for a subject of care, communicated in compliance with EN 13606 3.7 electronic health record system system for recording, retrieving and manipulating information in electronic health records
3.8 entries health record data in general (clinical observations, statements, reasoning, intentions, plans or actions) without particular specification of their formal representation, hierarchical organisation or of the particular Record Component class(es) that might be used to represent them 3.9 patient synonym for a subject of care



EN 13606-3:2008 (E) 6 3.10 Record Component part of the electronic health record extract of a single subject of care, represented as a node within a hierarchical data structure conforming to EN 13606 3.11 state (of a process) condition or situation during the lifecycle of an object during which it satisfies some condition, performs some activity or waits for some event [ISO/TS 18308:2004] 3.12 subject of care person scheduled to receive, receiving, or having received health care 3 Abbreviations CEN Comité Européen de Normalisation (European Committee for Standardization)
CEN/ TC 251 CEN Technical Committee 251
EHR Electronic Health Record
EU European Union
HISA Health Information Systems Architecture
HL7 Health Level Seven
ISO International Organization for Standardization
UML Unified Modelling Language
XML Extensible Mark-up Language 4 Conformance When electronic health record information is to be communicated using the 13606 Standard Series and where an attribute of the Reference Model defined in Part 1 of this series requires a value to be taken from a bounded set of codes from a named term list, the code shall be one of those defined in Clause 5 of this standard for the correspondingly-named term list.



EN 13606-3:2008 (E) 7 5 Term lists 5.1 Introduction The Reference Model defined in Part 1 of this standard series defines several attributes whose values are to be selected from a fixed list of values. This section defines those value lists (term lists) for each of those attributes. Attributes not included in this section (or defined in Part 4 of this series) may take any value that conforms to the data type and invariant specifications defined in Part 1 of this series. 5.2 Termlist SUBJECT_CATEGORY, Class ENTRY, attribute subject_of_information_category This attribute provides a coarse-grained definition of the person who is the subject of an ENTRY. The default value is DS00 (the patient or subject of care). A more fine-grained definition of the information subject (such as the precise relative with a family history) can be specified through the ENTRY.subject_of_information.relationship attribute. Code Meaning Description DS00 subject of care subject of care DS01 relative of subject of care any human relative, without limitation to biological or adoptive relatives DS02 foetus or neonate or infant baby or babies being described by an ENTRY in the EHR of the mother DS03 mother mother of a foetus or neonate, if being described in the EHR of a baby (e.g. during pregnancy) DS04 donor donor of an organ or body specimen being described by an ENTRY in the EHR of the recipient DS05 unrelated person any other person not related to the subject of care, such as an employer, friend, carer
NOTE If ENTRY.subject_of_information_category is null, the value DS00 is assumed.



EN 13606-3:2008 (E) 8
5.3 Termlist ITEM_CATEGORY, Class ITEM, attribute item_category Some kinds of ENTRY might have a complex internal data structure, comprised of the main values of interest and other kinds of context. This optional attribute in the Reference Model permits the communication of the category of information for each ELEMENT or CLUSTER. This may be of value to a receiving EHR system, to enable easier processing of the data.
Code Meaning Description IC01 Principal or ‘core’ value The CLUSTERS or ELEMENTS that contain the main values that are the subject of the ENTRY IC02 Supplementary/complementary details about the value Contextual information that most users would regard as necessary to interpret the core values IC03 Patient state/circumstances Contextual information about the subject of care’s circumstances when an observation is made e.g. fasting, standing IC04 Method details Contextual information about the method of an observation, such as the technique or device used IC05 Clinical reasoning Any explanatory information provided by the author to explain a clinical decision or interpretation, other than a specific reference to a protocol of guideline or knowledge source IC06 Protocol/guideline A description, reference or explanation of any protocol or guideline that informed the ENTRY (e.g. to perform an observation, or initiate a plan of care) IC07 Knowledge source A reference to any external knowledge source, such as a web site or medical text, that explains or amplifies a clinical decision IC08 Presentation Any information about how the values in the ENTRY should be presented; image rendering information is one example
IC09 Assertion status To indicate that the ELEMENT contains a value that indicates the presence/absence, normality/abnormality of the core values (e.g. if the core value is a questionnaire question and the ELEMENT contains the yes/no answer)



EN 13606-3:2008 (E) 9
5.4 Termlist VERSION_STATUS, Class AUDIT_INFO, attribute version_status This attribute is used to indicate the status of a particular version of a RECORD_COMPONENT. This attribute is optional, and if no value is provided it is to be assumed that the RECORD_COMPONENT is the first definitive version corresponding to code value VER01. In all cases, the new version of a RECORD_COMPONENT shall replace the former version, as specified in Part 1 of this series.
Code Meaning Description VER00 Draft The version is known at the time of committal to be incomplete (because additional information is expected later) or if the necessary authorisations have not been made, VER00 implies that the EHR_recipient might in future expect to receive a more definitive updated version of this RECORD_COMPONENT VER01 Finished The version is committed with the intention of being a final version, with no anticipated reason for revision
VER02 Update The version is an update of the previous version, usually by adding supplementary information that was not available at the time of committal NOTE 1 Revision is intended for additions usually to be made by the original author within a short time frame, and not for recoding an evolving clinical story VER03 Correction The version corrects errors made in the recording of the previous version VER04 Deletion The version logically deletes the previous version (e.g. if the RECORD_COMPONENT had been placed in the wrong patient’s EHR) NOTE 2 If AUDIT_INFO.version_status is null, the value VER01 is assumed.



EN 13606-3:2008 (E) 10
5.5 Termlist MODE, Class FUNCTIONAL_ROLE, attribute mode This attribute is used to describe the physical or electronic means by which an entity has participated in the provision or documentation of health care. This term list is taken from the corresponding code set in EN 14822-2, for the attribute mode, except that codes have been added for use within an EHR Extract. Code Meaning Description EN14822-2 term MOD01 electronic data Participation by non-human-language based electronic signal ELECTRONIC MOD02 verbal Participation by voice communication VERBAL MOD03 dictated Participation by pre-recorded voice. Communication is limited to one direction (from the recorder to recipient) DICTATED MOD04 face-to-face Participation by voice communication where parties speak to each other directly FACE MOD05 telephone Participation by voice communication where the voices of the communicating parties are transported over an electronic medium PHONE MOD06 videoconferencing Participation by voice and visual communication where the voices and images of the communicating parties are transported over an electronic medium
VIDEOCONF MOD07 written Participation by human language recorded on a physical material WRITTEN MOD08 email Participation by text or diagrams transmitted over an electronic mail system EMAIL MOD09 telefax Participation by text or diagrams printed on paper that have been transmitted over a fax device FAX MOD10 handwritten Participation by text or diagrams printed on paper or other recording medium HANDWRITTEN MOD11 typewritten Participation by text or diagrams printed on paper or other recording medium where the recording was performed using a typewriter, typesetter, computer or similar mechanism
TYPEWRITTEN MOD12 physical presence Participation by direct action where subject and actor are in the same location. (The participation involves more than communication) PHYSICAL MOD13 remote presence Participation by direct action where subject and actor are in separate locations, and the actions of the actor are transmitted by electronic or mechanical means. (The participation involves more than communication) REMOTE NOTE If FUNCTIONAL_ROLE.mode is null, the value MOD04 is assumed.



EN 13606-3:2008 (E) 11
5.6 Termlist ACT_STATUS, Class ENTRY, attribute act_status This term list is identical to the act status values in the HISA standard EN 12967, except that codes have been added for use within an EHR Extract. Formal definitions of these terms are given in the HISA standard, and their mapping to HL7 appropriate act.Status and mood.Code values. Code Meaning ACT01 Foreseen ACT02 Requested ACT03 Accepted ACT04 Booked ACT05 Planned ACT06 Ready ACT07 In progress ACT08 Completed ACT09 Reported ACT10 Terminated ACT11 Forwarded ACT12 Suspended ACT13 Annulled-Cancelled ACT14 Annulled-Rejected ACT15 Substituted



EN 13606-3:2008 (E) 12 5.7 Termlist LINK_NATURE, Class LINK, attribute nature The LINK class contains two coded-value attributes to communicate the semantics of the relationship between the source and target RECORD_COMPONENTS. The nature attribute, which is mandatory in Part 1 of this standard series, is intended to be a coarse-grained category that can be used to enable interoperability between sender and receiver. The role attribute, which is optional in Part 1 of this series, provides for a more specific description of the actual role played by the target in relation to the source. This latter attribute may be populated from any suitable terminology, and therefore might support human readership better than interoperable automated processing. This standard requires that the nature attribute must be a value taken from the mandatory term list defined in Section 6.7. This standard offers a term list for the role attribute, in Section 5.8, but it is not required that this be used. Code Meaning Description LINK-A0 is related to A generic category for any link, the details of which will be given by the value of LINK.role. LINK-B0 is confirmed by or authorised by The target link contains a COMPOSITION, SECTION or ENTRY that acts as the legal or authoritative basis for the activity documented in the source RECORD_COMPONENT, or is a declaration of intent to provide (or not to provide) requested care. This Link is to be used to connect two RECORD_COMPONENTS, as opposed to the inclusion of a corroborating or authorising participant as an identified party within a single COMPOSITION or ENTRY.
LINK-C0 is related to the same problem or health issue The target RECORD_COMPONENT documents health or health care that pertains to the same clinical situation as the source component. One of the two might be defining a problem for which the other is a manifestation, or the relationship might for example be cause and effect, stages in an evolving clinical history, a different interpretation of an observation, a clinical indication or contraindication. LINK-D0 is related to the same plan of care, act or episode The source and the target RECORD_COMPONENTs are each documenting parts of the same plan of care, act or episode. One or the other might be defining the same plan of care, act or episode, or both might be related milestones. LINK-E0 is a related documentation
The target RECORD_COMPONENT is an alternative documentary form of the source component, such as re-expression of the same clinical information or additional supplementary explanatory information. NOTE A further understanding of each of these categories may be obtained by reviewing the detailed terms proposed for each, as values of LINK.role in section 6.8 below.



EN 13606-3:2008 (E) 13
5.8 Termlist LINK_ROLE, Optional term list for LINK attribute role (Informative) 5.8.1 Introduction Each of the link terms in the list is a sub-category of a corresponding term in the table of Section 6.7, where that correspondence is indicated by the first letter after the code string “LINK-“ e.g. the term LINK-A1 is a subcategory of term LINK-A0. If a term in the list is used for the LINK.role attribute, the appropriate corresponding LINK.nature attribute value must be used from Section 6.7. 5.8.2 Optional term list for LINK attribute role (Informative) Code Meaning Description LINK-A1 unspecified link The term is used when no semantic information is available for the Link in the EHR system from which the EXTRACT has been created.
LINK-A2 suggests (tentatively related to) The interpretation expressed in the target component is a possible cause or outcome of the findings documented in the source component. LINK-A2i is suggested by The inverse relationship of LINK-A2. LINK-A3 re-occurrence or repeat of The source component documents a clinical situation which, in the opinion of the composer, is a repeat occurrence of the clinical situation documented in the target. This is intended for re-occurrences of real world situations, not repeated documentation of the same real-world event. LINK-B1 endorses (agrees with, confirms, verifies) The interpretation expressed in the source component provides confirmatory evidence or a confirmatory opinion of the interpretation expressed in the target component. LINK-B2 disagrees with (e.g. another opinion) The interpretation expressed in the source component disproves or disagrees with the interpretation expressed in the target component. LINK-B3 permits (sanctions, authorises) The source component documents pe
...