1998x-xx-xx
1 (total no of pages)
/ EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG / CEN/TC 251/02-005
2002-02-26
CEN/TC 251
Health Informatics
Secretariat: SIS
TITLE/
SUBJECT: / CEN/TC 251 Task Force 13606:
Electronic Health Record Communication
Proposed Scope and Technical Approach
SOURCE: / Dipak Kalra
ACTION REQUIRED: / For comments
CEN TC/251/02-005EHRcom Scope and Technical Approach v1.0
CEN TC/251 Task Force 13606:
Electronic Health Record Communication
Proposed Scope and Technical Approach
This document presents the scope of the new CEN TC/251 EHRcom Task Force, and outlines the key Tasks that comprise its technical approach. The facilities proposed to support Task e-working are also described. The draft letter to invite input from industrial and other parties is appended with two accompanying annexes. Feedback is welcome on this proposal; please send an e-mail to .
Background
In December 2001 CEN TC/251 confirmed a new Task Force, EHRcom, to review and revise the four-part pre-standard ENV 13606 relating to Electronic Healthcare Record Communications.
ENV 13606: Electronic Healthcare Record Communication (1999)
Part 1: Extended Architecture
Part 2: Domain Termlist
Part 3: Distribution Rules
Part 4: Messages for the Exchange of Information
ENV 13606 was originally published in 1999 and, as with all pre-standards, intended for review and potential revision after three years. It is hoped that the result of such revision now by the Task Force can lead to a definitive standard (EN).
The timetable proposed for the EHRcom Task Force is shown below.
May 2002: INitial Report (INR)
Jan 2003: First Working Draft (FWD)
Jul2003: consolidated response to ENQuiries (ENQ)
Jan 2004: final draft For Formal Voting (FFV)
No funding has been made available to the Task Force.
Working Group 1 elected Dr Dipak Kalra from University College London, UK, the EHRcom Task Force Leader in February 2002. He is now in the process of confirming the principal participants and the initial work plan, as outlined in this document. The final version of this scope and technical approach document will be incorporated within the INR to be published in May 2002 for consideration by CEN in June 2002 (at the next TC/251 meeting in Madrid).
Scope of the new standard
The overall goal of the EHR communications standard proposed by the Task Force is:
to produce a rigorous and durable information architecture for representing the EHR, in order to support the interoperability of systems and components that need to interact with EHR services:
- as discrete systems or as middleware components;
- to access, transfer, add or modify health record entries;
- via electronic messages or distributed objects;
- preserving the original clinical meaning intended by the author;
- reflecting the confidentiality of that data as intended by the author and patient.
A more detailed description of the Task Force scope was published in N01-044 as the new Work Item proposal (Klein G, Freriks G. Health informatics – Electronic health record communication: revision of ENV 13606:1999 to a full European Standard. December 2001.)
This work item consists of the revision of the four part standard ENV 13606 to a full European standard (EN).
The general scope of this standard is to provide a definition of the essential elements to support the interoperability of software components or record systems providing or requiring access to electronic health record (EHR) data. The subject of the record or record extract to be communicated is an individual person, and the scope of the communication is predominantly with respect to that person’s care. However, the possibility of providing guidance or extension to the use of the record architecture for such circumstances where one record for a group of persons is appropriate, will be considered during the project. Uses of healthcare records for other purposes such as administration, management, research and epidemiology, which require aggregations of individual people’s records, are not the focus of this standard but such secondary uses could also find the standard useful.
The Architecture places no restrictions on the communication of the EHR with respect to the location, the means used, and the timing of the communication. Communication is defined as the act of imparting information, and this standard does not restrict how that should be done, permitting, for example the interchange mechanism to take the form of either a message or a system view using e.g. middleware with component technology.
The Architecture is therefore independent of organisation, (e.g. secondary or primary care records), and independent of temporal categories that are applied to records of care (e.g. episodic or longitudinal). The Extended Architecture also makes minimal assumptions regarding circumstances of its use. For example, it does not assume a particular decomposition of the healthcare domain nor does it assume that systems that might use this standard will be of a particular implementation type or configuration. In particular, the fact that this Reference Architecture is represented conceptually by an object-oriented notation does not require conformant instances to be implemented using object technology.
The revision of the ENV 13606 pre-standard will take into account the experiences of implementations of the standard and the following new standards developments:
- The principle of separating (1) a basic record reference architecture from (2) domain specific models, the latter that have been called archetypes.
- The CEN/TC 251 work on a standard for General purpose information components that in its turn is partly based on developments that have taken place in other organisations, for instance within the HL7 organisation for a reference information model.
This new revision by the Task Force needs to take into account the following factors.
1. The new standard needs to achieve a fine balance between being:
- a robust, rigorous and complete set of models meeting published requirements for generic health record information and the appropriate access to it; and
- practically implementable, neither overcomplicated nor specifying areas for which a definitive approach has not yet been established.
2. Since its publication much practical experience has been gained in attempting to refine and implement ENV 13606 across Europe, both by industry and in many pilot demonstrator settings. Much of this experience, and the important lessons learnt, have not yet been widely disseminated.
3. The R&D inputs on which ENV 13606 was based have moved forward since 1998 and important new contributions to the field should be taken into account in its revision.
4. 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.
5. “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.
6. There is wider international interest in this CEN work, and valuable experience from beyond Europe can helpfully contribute to this revision.
7. HL7 is engaged in a significant revision of its information models, with a partial overlap in purpose to this and other CEN activities.
General Approach
Since the announcement of the Task Force a number of parties have expressed concern that the new revision should not present a radically new information architecture for the EHR, but should aim to build on the existing ENV. Other views have been expressed that some aspects of that ENV were not easy to implement, were ambiguous, or considered unnecessarily complex.
The Task Force declared, at the February 2002 CEN meeting in Berlin, the intention to build on the existing ENV and to use implementation experience and new generic requirements as the basis for the inclusion of new constructs. It is also important for the work to remain focused on the EHR as the persistent longitudinal and potentially multi-enterprise or multi-national record of health and care provision relating to a single subject of care (the patient) in order to inform the subject’s future health care and to provide a medico-legal record of care that has been provided. Whilst an EHR service or system will need to interact with many other services or systems providing terminology, medical knowledge, guidelines, workflow, security, persons registries, billing etc. the Task Force scope should only touch on those areas if some persistent trace of such interactions is required in the EHR itself. The general principle of the Task Force should be, where appropriate, to rely upon the existence of such services and not arbitrarily to extend its scope to subsume these other significant areas of health informatics.
The Task Force has to balance the need for improvements and advances in the field to be taken into account with the need for changes to the existing ENV to be justified and of benefit for future interoperability. The eventual standard may offer a practical and useful contribution to the design of EHR systems but might only be realised as a common set of external interfaces or messages built on otherwise heterogeneous clinical systems. The level of prescription in the standard needs to take into account that the majority of deployed clinical systems will not be complete EHR systems for some years, and that the current levels of health ICT spending in most Member States is low in comparison with other industry sectors, offering only a modest opportunity for radical systems redesign.
One significant area of change in the existing ENV has already been proposed and has gained strong acceptance from many members of TC/251: the use of Archetypes. This form of metadata about the EHR has dual origins in work arising from the EU Project Synapses (1996-8) and subsequent parallel work of former GEHR collaborators working in Australia. These concepts have been harmonised through the OpenEHR Foundation. The work has been widely recognised as an important complement to the core Reference Model of the EHR, as a means of defining the domain specific hierarchies and templates to be used within healthcare and of specifying constraints that should be applied to the instantiation of the EHR at run time to ensure consistent data quality and the reliable sharing of EHR entries. The Archetype methodology serves as an important bridge between the normative requirements for representing the EHR and the natural and inherent diversity and evolving nature of clinical information, by providing a standardised way in which that diversity can be represented.
Another significant consideration is the present work of HL7 in developing the version 3 Reference Information Model, and the use of this to specify CMETs and HMDs. CEN TC/251 has already formed a relationship with this work, and a well-advanced CEN Project Team has developed a draft set of General Purpose Information Components (GPICs) that build on the RIM and map these to a number of existing CEN standards. The Task Force has proposed to utilise this work as the basis for exploring the appropriate information interface to HL7, in order to take advantage of the expertise that has already been acquired in Europe in this area and to ensure that the future TC/251 standardisation field remains internally consistent. For similar reasons, it has been informally agreed to work in collaboration with the new Task Force that has been proposed to revise the original HISA standard (ENV 12967).
The EHRcom Task Force has an exciting opportunity to take forward a good pre-standard, in the light of the current climate reinforcing the importance of well-informed clinical shared care, with health service organisations increasingly gravitating towards regional health care networks, and with increasing requirements of clinical information systems to support this kind of interoperability.
The EuroRec Institute and the OpenEHR Foundation have indicated their support to this Task Force, and our hope is that the publication of the standard by CEN can be partnered by the publication of educational materials, guidelines and one or more OpenSource reference implementations that demonstrate how the standard might be used in practice.
The members of the Task Force so far identified share in this belief that a good job can be done, and they are willing (enthusiastic!) to participate actively in achieving these goals despite the lack of any identified funds to date.
Work-plan approach
The general work-plan approach of each Task defined within the Task Force will need to recognise the cyclical relationship of industry implementation experience, new requirements and new R&D results to the standards-making process, as depicted below.
The cyclical evolution of specifications and standards
The most important first phase of the Task Force is to elicit inputs. Examples of these are given below.
§ 2 Implementation experience
- Industry – direct experience of implementing ENV 13606 based systems
- Industry fora e.g. via ProRec Centres and EHTEL
- National or regional EHR demonstrator sites
- The OpenEHR Foundation (combining EU and Australian record server and archetype implementations)
- Other academic ENV 13606 - based systems and prototypes
- Any other comprehensive and open EHR architectures in clinical use
§ 3 Health information stakeholders
- Patient groups and legislation
- Healthcare professional groups
- Regional and national policies and projects, taking healthcare delivery and scientific trends into account e.g. trends in bioinformatics
- Other CEN standards: e.g. GPIC, HISA, Categorial Structures, ContSys
- International health informatics standards e.g. HL7, OMG HDTF
- Requirements sources e.g. ISO 18308 (draft, incorporating requirements from GEHR, Synapses, EHCR-SupA, I4C, RICHE, Nucleus, SPRI, US sources and many other projects).
§ 4 R&D results
- EHCR SupA recommendations to CEN
- Synapses and SynEx federated health record services
- InterCare and PICNIC tele-health record systems
- I4C integrated cardiac records, based on ORCA
- HANSA and its ancestors
- HARP security and record components
- Many other projects….
Involving industry
As stressed earlier, important implementation lessons have been learned and probably the most critical liaison to nurture during the Task Force lifetime will be the link with industry, initially to gather this feedback and later to sound out reactions to proposals at an early stage.
§ 1 Feedback we need to gather from pilots
- Which parts of the standard have been tackled in your pilot/system?
- Which constructs (classes, sections etc. ) have actually been implemented?
- Which constructs were well-matched to your requirements, and which proved a poor fit?
- What additional/new requirements need to be addressed by the Task Force?
- Which classes and attributes were easy to understand and to implement?
- What obstacles did you experience (comprehension of the standard, software engineering of certain classes, practical deployment issues, performance etc.)?
- What changes to ENV 13606 would you recommend?
- Which features in ENV 13606 do you feel strongly about retaining?
A draft letter, in the form of a questionnaire, is appended to this document. Readers of this are welcome to forward this letter to any relevant organisation in order to elicit such feedback or for onward dissemination.
Technical Approach
In drawing on the structure of the existing pre-standard, and recognising the inclusion of the archetype methodology, the following core Tasks have been proposed by the Task Force leader. It is not to be assumed at this stage that each Task will give rise to an independent part of the new standard, nor even that Task outputs will all be normative. These Tasks represent significant areas of work requiring different expertise and drawing on different areas of existing normative and non-normative background work. The goals of each Task presented here are the proposal of the Task Force leader, and on which discussion is welcome.
Reference Model (Task RM)
Task Manager (WGI) Torbjørn Nystadnes
To define a generic information model for representing the electronic health record of any one patient, as a refinement of ENV 13606 part 1, drawing on implementation feedback and relevant work in HL7 as incorporated into the GPIC standard.
Archetype Model (Task AM)
Task Manager (WGI) Dipak Kalra
To define a generic information model for representing the definition of individual instances of Archetypes. This work will draw particularly on work arising from the EU Synapses project and from Australia, now integrated through OpenEHR.
Archetype Generation (Task AG)
Task Manager (WGII) Jean Marie Rodrigues
WGI Liaison Angelo Rossi Mori
To generate a wide range of Archetypes reflecting a diversity of clinical requirements and settings, as a "starter set" for adopters and to illustrate how other clinical domains might similarly be represented (for example by health professional groups). It will be relevant to draw on CEN TC/251 WGI standards such as GPICs, WG II standards such as Categorial Structures and on OpenEHR examples. It is proposed at this stage to leave open the decision about whether any Archetypes should be published in the Normative part of the standard. These might be provided only for guidance to assist developers in different countries and other contexts to develop their own Archetypes.
Terminology Support (Task TS)
Task Manager (WGI) Angelo Rossi Mori
WGII Liaison Jean Marie Rodrigues
Both the Reference Model and the Archetype Model will include attributes whose values should themselves be drawn from enumerated lists, whether normative or informative. Some values might appropriately be defined by external terminology systems. This Task will identify which lists are appropriate and provide enumerations of them, drawing on the previous Domain Termlist part of ENV 13606 and subsequent work in Working Group II.
Security Features (Task SF)
Task Manager (WGIII) Bernd Blobel
WGI Liaison David Lloyd
To define those information model concepts that need to be reflected within individual EHR instances to enable suitable interaction with the security components that are anticipated to be required in any future EHR deployment. This is likely to include information to: