EN 13606-2-2007 en Health informatics - Electronic health record communication - Part 2 Archetypes interchange specification《健康信息学 电子健康记录信息 第2部分 原型交换规范》.pdf

《EN 13606-2-2007 en Health informatics - Electronic health record communication - Part 2 Archetypes interchange specification《健康信息学 电子健康记录信息 第2部分 原型交换规范》.pdf》由会员分享，可在线阅读，更多相关《EN 13606-2-2007 en Health informatics - Electronic health record communication - Part 2 Archetypes interchange specification《健康信息学 电子健康记录信息 第2部分 原型交换规范》.pdf（134页珍藏版）》请在麦多课文档分享上搜索。

1、BRITISH STANDARDBS EN 13606-2:2007Health informatics Electronic health record communication Part 2: Archetypes interchange specificationThe European Standard EN 13606-2:2007 has the status of a British StandardICS 35.240.80g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48

2、g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g44g42g43g55g3g47g36g58BS EN 13606-2:2007This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 August 2007 BSI 2007ISBN 978 0 580 53673 1National

3、 forewordThis British Standard is the UK implementation of EN 13606-2:2007. It supersedes DD ENV 13606-2:2000 which is withdrawn. The UK participation in its preparation was entrusted to Technical Committee IST/35, Health informatics.A list of organizations represented on this committee can be obtai

4、ned on request to its secretary.This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application.Compliance with a British Standard cannot confer immunity from legal obligations.Amendments issued since publicationAmd. No. Date

5、 CommentsEUROPEAN STANDARDNORME EUROPENNEEUROPISCHE NORMEN 13606-2August 2007ICS 35.240.80English VersionHealth informatics - Electronic health record communication -Part 2: Archetypes interchange specificationInformatique de sant - Dossier de sant informatiscommunicant - Spcification des changes de

6、s archtypesMedizinische Informatik - Kommunikation vonPatientendaten in elektronischer Form - Teil 2:Spezifikation fr den Austausch von ArchetypenThis European Standard was approved by CEN on 21 June 2007.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the c

7、onditions 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 thr

8、ee 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 Aus

9、tria, 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 COMMIT

10、TEE FOR STANDARDIZATIONCOMIT EUROPEN DE NORMALISATIONEUROPISCHES KOMITEE FR NORMUNGManagement Centre: rue de Stassart, 36 B-1050 Brussels 2007 CEN All rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 13606-2:2007: EEN 13606-2:2007 (E) Content

11、s Page Foreword .4 0 Introduction5 0.1 Archetypes .5 0.2 Archetype Repositories 6 0.3 Communicating Archetypes.6 0.4 Overview of the Archetype Model6 0.5 Overview of ADL13 0.6 Clinical examples of archetypes16 1 Scope 16 2 Conformance16 3 Normative references16 4 Terms and definitions .17 5 Symbols

12、and abbreviations18 6 Archetype Representation Requirements.19 6.1 General .19 6.2 Archetype definition, description and publication information19 6.3 Archetype node constraints.21 6.4 Data Value constraints23 6.5 Profile in relation to EN 13606-1 Reference Model.24 7 Archetype Model26 7.1 Introduct

13、ion26 7.2 Overview.29 7.3 The Archetype Package 33 7.4 The Archetype Description Package .35 7.5 The Constraint Model Package 39 7.6 The Assertion Package .46 7.7 The Primitive Package 50 7.8 The Ontology Package56 7.9 The Domain Extensions Package 58 7.10 The Support Package60 7.11 Generic Types Pa

14、ckage 69 7.12 Domain-specific Extensions (Informative)70 8 Archetype Definition Language (ADL) 71 8.1 dADL - Data ADL71 8.2 cADL - Constraint ADL89 8.3 Assertions 114 8.4 ADL Paths.118 8.5 ADL - Archetype Definition Language.119 2 EN 13606-2:2007 (E) Bibliography130 Figures Figure 1 ADL Archetype St

15、ructure 14 Figure 2 Package structure. 28 Figure 3 Overview of the main part of the Archetype Model Part 1. 29 Figure 4 Overview of the Archetype Model - Part 2 30 Figure 5 Archetype Package. 33 Figure 6 Archetype Description Package . 35 Figure 7 Constraint Model Package 39 Figure 8 Assertion Packa

16、ge 46 Figure 9 Primitive Package. 50 Figure 10 Ontology Package 56 Figure 11 Domain Extensions Package 58 Figure 12 Support Package 60 Figure 13 Generic Types Package . 69 Figure 14 Example Domain-specific package 70 3 EN 13606-2:2007 (E) Foreword This document (EN 13606-2:2007) has been prepared by

17、 Technical Committee CEN/TC 251 “Health informatics”, the secretariat of which is held by NEN. This document shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by February 2008 and conflicting national standards shall be with

18、drawn at the latest by February 2008. This document will supersede ENV 13606-2: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

19、3: Reference archetypes and term lists Part 4: Security Part 5: Exchange models 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, Denmar

20、k, 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. 4 EN 13606-2:2007 (E) 0 Introduction Comprehensive, multi-enterpris

21、e and longitudinal electronic health records will often in practice be achieved through the joining up of multiple clinical applications, databases (and increasingly devices) that are each tailored to the needs of individual conditions, specialties or enterprises. This requires that EHR data from di

22、verse systems be capable of being mapped to and from a single comprehensive representation, which is used to underpin interfaces and messages within a distributed network (federation) of EHR systems and services. This common representation has to be sufficiently generic and rich to represent any con

23、ceivable health record data, comprising part or all of an EHR (or a set of EHRs) being communicated. The approach adopted in this standard, underpinned by international research on the EHR, has been to define a rigorous and generic Reference Model that is suitable for all kinds of data and data stru

24、ctures within an EHR, and in which all labelling and context information is an integral part of each construct. An EHR Extract will contain all of the names, structure and context required for it to be interpreted faithfully on receipt even if its organisation and the nature of the clinical content

25、have not been “agreed” in advance. However the wide-scale sharing of health records, and their meaningful analysis across distributed sites, also requires that a consistent approach is used for the clinical (semantic) data structures that will be communicated via the Reference Model, so that equival

26、ent clinical information is represented consistently. This is necessary in order for clinical applications and analysis tools safely to process EHR data that have come from heterogeneous sources. 0.1 Archetypes The challenge for EHR interoperability is therefore to devise a generalised approach to r

27、epresenting 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 div

28、erse, 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 standard distinguishes a Reference Model, used to represent the gen

29、eric properties of health record information, and Archetypes (conforming to an Archetype Model), which are meta-data used to define patterns for the specific characteristics of the clinical data that represent the requirements of each particular profession, speciality or service. The Reference Model

30、 is specified as an ODP Information Viewpoint model, representing the global characteristics of health record components, how they are aggregated, and the context information required to meet ethical, legal and provenance requirements. In this standard, the Reference Model is defined in Part 1. This

31、 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 standard).

32、Archetypes are effectively pre-coordinated combinations of named RECORD_COMPONENT hierarchies that are agreed within a community in order to ensure semantic interoperability, data consistency and data quality. For an EHR_Extract as defined in Part 1 of this standard, an archetype specifies (and effe

33、ctively 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 may include other d

34、ependency constraints. Archetype instances themselves conform to a formal model, known as an Archetype Model (which is a constraint model, also specified as an ODP Information Viewpoint Model). Although the Archetype Model is stable, individual archetype instances may be revised or succeeded by othe

35、rs as clinical practice evolves. Version control ensures that new revisions do not invalidate data created with previous revisions. Archetypes may be used within EHR systems to govern the EHR data committed to a repository. However, for the purposes of this interoperability standard, no assumption i

36、s made about the use of archetypes within the EHR Provider system whenever this standard is used for EHR communication. It is assumed that the 5 EN 13606-2:2007 (E) original EHR data, if not already archetyped, may be mapped to a set of archetypes, if desired, when generating the EHR_EXTRACT. The Re

37、ference Model defined in Part 1 of this standard has attributes that can be used to specify the archetype to which any RECORD_COMPONENT within an EHR_EXTRACT conforms. The class RECORD_COMPONENT includes an attribute archetype_id to identify the archetype and node to which that RECORD_COMPONENT conf

38、orms. The meaning attribute, in the case of archetyped data, refers to the primary concept to which the corresponding archetype node relates. However, it should be noted that Part 1 does not require that archetypes are used to govern the hierarchy of RECORD_COMPONENTS within an EHR_EXTRACT: the arch

39、etype-related attributes are optional in that model. It is recognised that the international adoption of an archetype approach will be gradual, and may take some years. 0.2 Archetype Repositories The range of archetypes required within a shared EHR community will depend upon its range of clinical ac

40、tivities. The total set needed on a national basis is presently unknown, but there might eventually be several thousand archetypes globally. The ideal sources of knowledge for developing such archetype definitions will be clinical guidelines, care pathways, scientific publications and other embodime

41、nts of best practice. However, “de facto” sources of agreed clinical data structures might also include: the data schemata (models) of existing clinical systems; the lay-out of computer screen forms used by these systems for data entry and for the display of analyses performed; data-entry templates,

42、 pop-up lists and look-up tables used by these systems; shared-care data sets, messages and reports used locally and nationally; the structure of forms used for the documentation of clinical consultations or summaries within paper records; health information used in secondary data collections; the p

43、re-coordinated terms in terminology systems. Despite this list of de facto ways in which clinical data structures are currently represented, these formats are very rarely interoperable. The use of standardised archetypes provides an interoperable way of representing and sharing these specifications,

44、 in support of consistent (good quality) health care record-keeping and the semantic interoperability of shared EHRs. In the longer term, it is anticipated that the involvement of national health services, academic organisations and professional bodies in the development of archetypes will enable th

45、is approach to contribute to the pursuit of quality evidence-based clinical practice. In the future regional or national public domain libraries of archetype definitions might be accessed via the Internet, and downloaded for local use within EHR systems. 0.3 Communicating Archetypes This part standa

46、rd specifies the requirements for a comprehensive and interoperable archetype representation, and defines the ODP Information Viewpoint representation for the Archetype Model and an optional archetype interchange format called Archetype Definition Language (ADL). This standard does not require that

47、any particular model be adopted as the internal architecture of archetype repositories, services or components used to author, store or deploy archetypes in collaboration with EHR services. It does require that these archetypes are capable of being mapped to the Archetype Model defined in this part-

48、standard in order to support EHR communication and interoperability within an EHR-sharing community. 0.4 Overview of the Archetype Model This section provides a general informative description of the model that is specified in Clause 7 of this part standard. 6 EN 13606-2:2007 (E) The overall archety

49、pe model consists of identifying information, a description (its meta-data), a definition (expressed in terms of constraints on instances of an object model), and an ontology. Identifying information and lifecycle state are part of the ARCHETYPE class. The archetype description is separated into revision history information and descriptive information about the archetype. Revision history information is concerned with the committal of the archetype to a repository, and takes the form of a list of audit trail items, while descript