《BS-EN-13606-2-2007.pdf》由会员分享，可在线阅读，更多相关《BS-EN-13606-2-2007.pdf（134页珍藏版）》请在三一文库上搜索。
1、BRITISH STANDARD BS EN 13606-2:2007 Health informatics Electronic health record communication Part 2: Archetypes interchange specification The European Standard EN 13606-2:2007 has the status of a British Standard ICS 35.240.80 ? Licensed Copy: London South Bank University, London South Bank Univers
2、ity, Sat Sep 01 03:06:13 GMT+00:00 2007, Uncontrolled Copy, (c) BSI BS EN 13606-2:2007 This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 August 2007 BSI 2007 ISBN 978 0 580 53673 1 National foreword This British Standard is the UK implementa
3、tion 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 obtained on request to its secretary. This publication
4、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 publication Amd. No. DateComments Licensed Copy: London South Bank Univ
5、ersity, London South Bank University, Sat Sep 01 03:06:13 GMT+00:00 2007, Uncontrolled Copy, (c) BSI EUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN 13606-2 August 2007 ICS 35.240.80 English Version Health informatics - Electronic health record communication - Part 2: Archetypes interchange spe
6、cification Informatique de sant - Dossier de sant informatis communicant - Spcification des changes des archtypes Medizinische Informatik - Kommunikation von Patientendaten in elektronischer Form - Teil 2: Spezifikation fr den Austausch von Archetypen This European Standard was approved by CEN on 21
7、 June 2007. CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be o
8、btained 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 translation under the responsibility of a CEN member into its own language and notified to the CEN Man
9、agement Centre has the same status as the official 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, N
10、orway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG Management Centre: rue de Stassart, 36 B-1050 Brussels 2007 CENAll rights of exploitation in any f
11、orm and by any means reserved worldwide for CEN national Members. Ref. No. EN 13606-2:2007: E Licensed Copy: London South Bank University, London South Bank University, Sat Sep 01 03:06:13 GMT+00:00 2007, Uncontrolled Copy, (c) BSI EN 13606-2:2007 (E) Contents Page Foreword .4 0 Introduction5 0.1 Ar
12、chetypes.5 0.2 Archetype Repositories6 0.3 Communicating Archetypes.6 0.4 Overview of the Archetype Model6 0.5 Overview of ADL13 0.6 Clinical examples of archetypes16 1 Scope16 2 Conformance16 3 Normative references16 4 Terms and definitions .17 5 Symbols and abbreviations18 6 Archetype Representati
13、on 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 Introduction26 7.2 Overview.29 7.3 The Archetype Pack
14、age33 7.4 The Archetype Description Package.35 7.5 The Constraint Model Package39 7.6 The Assertion Package.46 7.7 The Primitive Package 50 7.8 The Ontology Package56 7.9 The Domain Extensions Package58 7.10 The Support Package60 7.11 Generic Types Package69 7.12 Domain-specific Extensions (Informat
15、ive)70 8 Archetype Definition Language (ADL) 71 8.1 dADL - Data ADL71 8.2 cADL - Constraint ADL89 8.3 Assertions114 8.4 ADL Paths.118 8.5 ADL - Archetype Definition Language.119 2 Licensed Copy: London South Bank University, London South Bank University, Sat Sep 01 03:06:13 GMT+00:00 2007, Uncontrol
16、led Copy, (c) BSI EN 13606-2:2007 (E) Bibliography130 Figures Figure 1 ADL Archetype Structure 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
17、 Description Package . 35 Figure 7 Constraint Model Package 39 Figure 8 Assertion Package 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
18、 70 3 Licensed Copy: London South Bank University, London South Bank University, Sat Sep 01 03:06:13 GMT+00:00 2007, Uncontrolled Copy, (c) BSI EN 13606-2:2007 (E) Foreword This document (EN 13606-2:2007) has been prepared by Technical Committee CEN/TC 251 “Health informatics”, the secretariat of wh
19、ich 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 withdrawn at the latest by February 2008. This document will supersede ENV 1360
20、6-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 3: Reference archetypes and term lists Part 4: Security Part 5: Exchange mo
21、dels 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, It
22、aly, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. 4 Licensed Copy: London South Bank University, London South Bank University, Sat Sep 01 03:06:13 GMT+00:00 2007, Uncontrolled Copy, (c) BSI EN
23、 13606-2:2007 (E) 0 Introduction Comprehensive, multi-enterprise 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,
24、specialties or enterprises. This requires that EHR data from diverse 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 representati
25、on has to be sufficiently generic and rich to represent any conceivable 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 Refer
26、ence Model that is suitable for all kinds of data and data structures 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 e
27、ven if its organisation and the nature of the clinical content 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 tha
28、t will be communicated via the Reference Model, so that equivalent 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 inte
29、roperability is therefore 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, templ
30、ates 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 stan
31、dard distinguishes a Reference Model, used to represent the generic 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 pa
32、rticular profession, speciality or service. The Reference Model 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. I
33、n this standard, the Reference Model is defined in Part 1. 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 mes
34、sages or interfaces (as specified in Part 5 of this standard). 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 defin
35、ed in Part 1 of this standard, an archetype 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 ra
36、nges that ELEMENT data values may take, and may include other dependency 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, ind
37、ividual archetype instances may be revised or succeeded by others 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
38、the purposes of this interoperability standard, no assumption is 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 Licensed Copy: London South Bank University, London South Bank University, Sat Sep 01 03:06:
39、13 GMT+00:00 2007, Uncontrolled Copy, (c) BSI 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 Reference Model defined in Part 1 of this standard has attributes that can be used to specify the arc
40、hetype 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 conforms. The meaning attribute, in the case of archetyped data, refers to the primary concept to which
41、 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 archetype-related attributes are optional in that model. It is recognised that the international adopti
42、on 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 activities. The total set needed on a national basis is presently unknown, but there might eventually
43、 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 embodiments of best practice. However, “de facto” sources of agreed clinical data structures might also inc
44、lude: 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, pop-up lists and look-up tables used by these systems; shared-care data sets, messages and reports
45、 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 pre-coordinated terms in terminology systems. Despite this list of de facto ways in which clinical d
46、ata 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, in support of consistent (good quality) health care record-keeping and the semantic interoperabili
47、ty 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 this approach to contribute to the pursuit of quality evidence-based clinical practice. In the future
48、 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 standard specifies the requirements for a comprehensive and interoperable archetype representation, and d
49、efines 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 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 m