SIST EN 13606-2:2008

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Health informatics - Electronic health record communication - Part 2: Archetypes interchange specificationZdravstvena informatika - Komunikacija z elektronskimi zapisi v zdravstvenem varstvu - 2. del: ArhetipiInformatique de santé - Dossier de santé informatisé communicant - Spécification des échanges des archétypesMedizinische Informatik - Kommunikation von Patientendaten in elektronischer Form - Teil 2: ArchetypenTa slovenski standard je istoveten z:EN 13606-2:2007SIST EN 13606-2:2008en35.240.80Uporabniške rešitve IT v zdravstveni tehnikiIT applications in health care technologyICS:SIST ENV 13606-2:20031DGRPHãþDSLOVENSKI
STANDARDSIST EN 13606-2:200801-februar-2008







EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 13606-2August 2007ICS 35.240.80 English VersionHealth informatics - Electronic health record communication -Part 2: Archetypes interchange specificationInformatique de santé - Dossier de santé informatisécommunicant - Spécification des échanges des archétypesMedizinische Informatik - Kommunikation vonPatientendaten in elektronischer Form - Teil 2:Spezifikation für 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 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-2:2007: E



EN 13606-2:2007 (E) Contents Page Foreword.4 0 Introduction.5 0.1 Archetypes.5 0.2 Archetype Repositories.6 0.3 Communicating Archetypes.6 0.4 Overview of the Archetype Model.6 0.5 Overview of ADL.13 0.6 Clinical examples of archetypes.16 1 Scope.16 2 Conformance.16 3 Normative references.16 4 Terms and definitions.17 5 Symbols and abbreviations.18 6 Archetype Representation Requirements.19 6.1 General.19 6.2 Archetype definition, description and publication information.19 6.3 Archetype node constraints.21 6.4 Data Value constraints.23 6.5 Profile in relation to EN 13606-1 Reference Model.24 7 Archetype Model.26 7.1 Introduction.26 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 Package.56 7.9 The Domain Extensions Package.58 7.10 The Support Package.60 7.11 Generic Types Package.69 7.12 Domain-specific Extensions (Informative).70 8 Archetype Definition Language (ADL).71 8.1 dADL - Data ADL.71 8.2 cADL - Constraint ADL.89 8.3 Assertions.114 8.4 ADL Paths.118 8.5 ADL - Archetype Definition Language.119 2



EN 13606-2:2007 (E) Bibliography.130
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 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.70
3



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 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 withdrawn 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 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, 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. 4



EN 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, 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 representation 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 Reference 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 even 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 that 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 interoperability 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, 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 standard 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 particular 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. In 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 messages 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 defined 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 ranges 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, individual 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 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



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 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 conforms. 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 archetype-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 activities. 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 embodiments 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, 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 pre-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, 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 this 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 standard 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 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-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 archetype 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 descriptive information describes the archetype itself (regardless of whether it has been committed to a repository of any kind).
The archetype definition, the `main' part of the archetype model, is an instance of a C_COMPLEX_OBJECT, since the root of the constraint structure of an archetype shall always take the form of a constraint on a non-primitive object type. The fourth main part of the archetype model, the ontology, is represented by its own class, and is what allows the archetypes to be natural language- and terminology-neutral.
An enumeration class, VALIDITY_KIND is also included in the Archetype package. This is intended to be used as the type of any attribute in this constraint model whose value is logically `mandatory', `optional', or `disallowed'. It is used in this model in the classes C_Date, C_Time and C_Date_Time Archetypes contain some natural language elements, including the description and ontology definitions. Every archetype is therefore created in some original language, which is recorded in the original_language attribute of the ARCHETYPE class. An archetype is translated by doing the following: • translating every language-dependent element to the new language; • adding a new TRANSLATION_DETAILS instance to ARCHETYPE.translations, containing details about the translator, organisation, quality assurance and so on. The languages_available function provides a complete list of languages in the archetype. The Archetype Definition The main definitional part of an archetype consists of alternate layers of object and attribute constraining nodes, each containing the next level of nodes. In this section, the word `attribute' refers to any data property of a class, regardless of whether regarded as a `relationship' (i.e. association, aggregation, or composition) or `primitive' (i.e. value) attribute. At the leaves are primitive object constrainer nodes constraining primitive types such as String, Integer etc. There are also nodes that represent internal references to other nodes, constraint reference nodes that refer to a text constraint in the constraint binding part of the archetype ontology, and archetype constraint nodes, which represent constraints on other archetypes allowed to appear at a given point. The full list of node types is as follows: • C_complex_object: any interior node representing a constraint on instances of some non-primitive type, e.g. ENTRY, SECTION ; • C_attribute: a node representing a constraint on an attribute (i.e. UML `relationship' or `primitive attribute') in an object type; • C_primitive_object: an node representing a constraint on a primitive (built-in) object type; • Archetype_internal_ref: a node that refers to a previously defined object node in the same archetype. The reference is made using a path; • Constraint_ref: a node that refers to a constraint on (usually) a text or coded term entity, which appears in the ontology section of the archetype, and in ADL, is referred to with an "acNNNN" code. The constraint is expressed in terms of a query on an external entity, usually a terminology or ontology; • Archetype_slot: a node whose statements define a constraint that determines which other archetypes may appear at that point in the current archetype. Logically it has the same semantics as a C_COMPLEX_OBJECT, except that the constraints are expressed in another archetype, not the current one. The Archetype Description 7



EN 13606-2:2007 (E) What is normally considered the `meta-data' of an archetype, i.e. its author, date of creation, purpose, and other descriptive items, is described by the ARCHETYPE_DESCRIPTION and ARCHETYPE_DESCRIPTION_ITEM classes. The parts of this that are in natural language, and therefore may require translated versions, are represented in instances of the ARCHETYPE_DESCRIPTION_ITEM class. If an ARCHETYPE_DESCRIPTION has more than one ARCHETYPE_DESCRIPTION_ITEM, each of these should carry exactly the same information in a different natural language.
When an archetype is translated for use in another language environment, each ARCHETYPE_DESCRIPTION_ITEM needs to be copied and translated into the new language. The AUDIT_DETAILS class is concerned with the creation and modification of the archetype in a repository. Each instance of this class in an actual archetype represents one act of committal to the repository, with the attributes documenting who, when and why. NOTE Revision of an archetype should be limited to modification of the descriptive information, adding language translations and/or term bindings. If the definition part of an archetype is no longer valid it should instead be replaced with a new archetype to ensure that corresponding EHR data instances each conform to the same archetype specification. The Archetype Ontology All linguistic entities are defined in the ontology part of the archetype. There are four major parts in an archetype ontology: term definitions, constraint definitions, term bindings and constraint bindings. The former two define the meanings of various terms and textual constraints which occur in the archetype; they are indexed with unique identifiers, which are used within the archetype definition body. The latter two ontology sections describe the mappings of terms used internally to external terminologies. Archetype Specialisation Archetypes may be specialised: an archetype is considered a specialisation of another archetype if it specifies that archetype as its parent, and only makes changes to its definition such that its constraints are `narrower' than those of the parent. Any data created via the use of the specialised archetype shall be conformant both to it and to its parent.
Every archetype has a `specialisation depth'. Archetypes with no specialisation parent have depth 0, and specialised archetypes add one level to their depth for each step down a hierarchy required to reach them. Archetype Composition Archetypes may be composed to form larger structures semantically equivalent to a single large archetype. Archetype slots are the means of composition, and are themselves defined in terms of constraints.
Data types and the Support package The model is dependent on three groups of assumed types, whose names and assumed semantics are described by ISO/IEC 11404. The first group comprises the most basic types: • Any • Boolean • Character • Integer • Real • Double • String The second is the assumed library types: 8



EN 13606-2:2007 (E) • Date • Time • Date_Time • Duration These types are supported in most implementation technologies, including XML, Java and other programming languages. They are not defined in this specification, allowing them to be mapped to the most appropriate concrete types in each implementation technology.
The third group is the Generic types: • List
(ordered, duplicates allowed) • Set
(unordered, no duplicates) • Hash (keyed list of items of any type) • Interval (interval of instances of any ordered type) Although these types are supported in most implementation technologies, they are not yet represented in UML. The semantics of these types is therefore defined in the Generic_Types package of the UML model. The remaining necessary types are defined in the Support Package of the Archetype Model. • ARCHETYPE_ID
• HIER_OBJECT_ID • TERMINOLOGY_ID • CODE_PHRASE • CODED_TEXT The support package also includes two enumeration classes to provide controlled datasets needed by this part standard. The Constraint Model Package Any archetype definition is an instance of a C_COMPLEX_OBJECT, which expresses constraints on a class in the underlying Reference Model (Part 1 of this standard), recorded in the attribute rm_type_name. A C_COMPLEX_OBJECT consists of attributes of type C_ATTRIBUTE, which are constraints on the attributes (i.e. any property, including relationships) of that Reference Model class. Accordingly, each C_ATTRIBUTE records the name of the constrained attribute (in rm_attribute_name), the existence and cardinality expressed by the constraint (depending on whether the attribute it constrains is a multiple or single relationship), and the constraint on the object to which this C_ATTRIBUTE refers via its children attribute (according to its reference model) in the form of further C_OBJECTs. The key subtypes of C_OBJECT, are:
• C_COMPLEX_OBJECT; • C_PRIMITIVE_OBJECT;
• ARCHETYPE_SLOT.
ARCHETYPE_INTERNAL_REF and CONSTRAINT_REF are used to express, respectively, a `slot' where further archetypes may be used to continue describing constraints; a reference to a part of the current archetype that expresses exactly the same constraints needed at another point; and a reference to a constraint on a constraint defined in the archetype ontology, which in turn points to an external knowledge resource, such as a terminology. The effect of the model is to create archetype description structures that are a hierarchical alternation of object and attribute constraints. The repeated object/attribute hierarchical structure of an archetype provides the basis for using paths to reference any node in an archetype. Archetype paths follow a syntax that is a subset of the W3C Xpath syntax. 9



EN 13606-2:2007 (E) All Node Types All nodes in an archetype constraint structure are instances of the supertype ARCHETYPE_CONSTRAINT, which provides a number of
...