Temporal Components in Architectures of Electronic Health Records W. Gall , G. Duftschmid, W. Dorda
Section on Medical Information and Retrieval Systems Core Unit for Medical Statistics and Informatics Medical School of Vienna Spitalgasse 23, A-1090 Vienna, Austria {walter.gall, georg.duftschmid, wolfgang.dorda}@meduniwien.ac.at www.meduniwien.ac.at/imc/
Correspondence to:
Walter Gall Section on Medical Information and Retrieval Systems Core Unit for Medical Statistics and Informatics Medical School of Vienna Spitalgasse 23, A-1090 Vienna, Austria Tel.: +43-1-40400 / 6694 Fax.: +43-1-40400 / 6697 Email:
[email protected]
1
Summary
Objectives: Our objectives were to study temporal components in architectures for electronic health records (EHRs). Temporal components are of crucial importance in the development of architectures for EHRs. Unambiguous modeling of temporal structures is essential in order to exchange and re-use medical data. Methods: We investigated three important approaches to standardize the EHR architecture developed by the organizations CEN, HL7 and openEHR with regard to the specification of temporal components. Furthermore, we analyzed how temporal structures such as time series can be developed from the basic data types. Results: The three models fulfill most requirements for temporal components in EHRs. Complex forms of temporal information such as time series can be created in all of these models. This is achieved through different concepts: by generic components on the one hand, and pre-defined specific structures on the other. In the process of harmonization between the three organizations, temporal structures and variables were also adjusted in respect of their interoperability. Conclusions: The reference models of EHRs are generic by nature and give the user substantial freedom in many respects, including the process of modeling temporal structures. The creation of temporal components for specific clinical concepts also requires semantic models. Modeling the constraints of general models, by means of so-called archetypes, will be the next step to exchange medical data in a structured and unambiguous manner.
Keywords (MeSH) Medical Records Systems, Computerized; Models; Standards; Time
2
1 Introduction Standardization of electronic health record (EHR) architectures is a prerequisite to exchange health records or parts of health records between institutes and countries efficiently. In order to use the information collected in various systems for purposes such as patient care, clinical research, quality management or health care, it is necessary to exchange uniformly structured patient data. It also is a precondition for the integration of data. The dimension of time must be taken into account in the development of EHR architectures. This dimension is of major importance in the documentation and analysis of health data. As a rule, statements about patient-related medical issues are only significant in their temporal context. To a certain extent temporal components are the “screws” of patient records that “hinge medical statements together” (e.g., “the complications occurred two to three weeks after the operation”). However, several problems arise when one takes the dimension of time into account. On the one hand the problems concern the dimension of time as such; on the other hand they concern its medical application. Quite often temporal concepts are apparently trivial. Even basic structural elements such as time points and time intervals possess different characteristics. In the medical sector the main problem lies in the re-application of data that were originally collected for a different purpose. Medical data are frequently modeled and registered for an initial purpose (e.g., the anamnesis), and then passed on or re-used for other purposes (such as further treatment, analysis, quality assurance, etc.). In order to interpret and re-use computerassisted data correctly, the temporal information contained therein must be structured explicitly and formulated unambiguously.
2 Objectives Although very well developed temporal models are available today [1], comprehensive support of the dimension of time is yet to be fully achieved in the development of EHR architectures [2]. The existing implemented systems use different ways to represent temporal structures and relations (e.g., discrete or continuous representation of time, different numbers of attributes for imprecise temporal data, different interpretations of temporal relations such
3
as “overlaps”). Only few existing temporal concepts are in general use, most have not yet been standardized. We investigated the extent to which temporal concepts have been realized in standardized architectures of EHRs. We analyzed the specification of basic temporal data types and how more complex temporal structures, such as time series, can be developed from these. There is cooperation between the major organizations for the purpose of harmonizing the models. This gives rise to the question of the exchangeability of temporal information between the models.
3 Methods In the present study we investigated three important approaches to standardize EHR architectures. We analyzed the architectures of the organizations CEN/TC 251 [3], HL7 [4] and openEHR [5], which are described in the following. •
CEN ENV 13606: The European Prestandard ENV 13606 [6] is entitled Electronic Healthcare Record Communication and consists of four parts: Extended architecture, Domain term list, Distribution rules, and Messages for the exchange of information. It was approved by CEN [3] in June 1999 as a prospective standard for provisional application. Currently, the Prestandard is undergoing a review and revision process that might finally lead to its adoption as a formal standard in 2004. As indicated by the general title, ENV 13606 is concerned with how to communicate parts of, or an entire, EHR between systems. For this purpose, it provides a set of architectural components from which an EHR communication may be constructed. In order to provide the most recent information, the following analysis is based on the most recent working version of the review process [7].
•
HL7 CDA: The Health Level Seven (HL7) standardization consortium [4] has released a series of standards for the exchange of healthcare information. Their newest work item is entitled HL7 Version 3 [8] and is currently still a draft. The Clinical Document Architecture (CDA) standard [9] which is part of Version 3, focuses on the representation and exchange of clinical documents. It provides a set of specifications for the representation of documents, which are organized in a hierarchy of three levels with increasing semantic expressiveness. Levels two and three which are currently still in the planning phase will refer to the so-called Reference Information Model (RIM) [10], to 4
build the components of clinical documents and, thus, EHR data. We therefore focus our attention on the RIM (version 2.04). •
openEHR: The openEHR foundation [5] pursues a similar goal as the CEN with its ENV 13606 standard. It provides an open information architecture that formally expresses a set of requirements about EHRs. One objective of openEHR is to support the exchange of EHRs between institutions. The openEHR methodology is based on two different tiers of modeling, namely the information tier and the archetype tier. All elements of an EHR are instances of the information model. Archetypes constrain the possible instantiations of the information model by describing predefined valid combinations of instances. In other words, for each clinical concept that is to be included in the EHR (e.g., blood pressure), a corresponding archetype may be defined, which prescribes how to apply the classes of the information model to represent this concept. Our analyses are based on the openEHR EHR Information Model, revision. 4.4.1 [11].
All three models contain temporal components in different classes. Our analysis was focused on the most important temporal data types, structures and variables. The following aspects of each model were analyzed: a) Which data types are available to specify temporal information, in which classes are they defined, or from which sources have they been derived respectively? b) How are time series modeled? Time series are frequently used constructs in medical concepts, for instance during the prescription of medications. c) How are the following important temporal variables defined: valid time of a fact, total time of clinical activity and transaction time?
4 Results Referring to the questions (a),(b) and (c) of section 2, the following temporal components are available in the EHR architectures of CEN, HL7 and openEHR.
4.1 CEN ENV 13606 a) The data types used in the model of CEN are established in the technical specification TS/14796 [12]. Here Primitive Data Types and Time Interval Types have been specified: 5
(1) Primitive data types (Date, Time and Combinations) are based on the ISO standard for the representation of date and time (ISO8601) [13]. This ISO standard specifies all variants of the basic data types. (2) Time Interval types include three kinds of time intervals. The simple Interval of Time (IVL) may, in principle, be formed by four possible combinations of the starting time point, ending time point, and duration. In addition to the simple time interval, two further time interval types are defined: the Periodic Interval of Time (PIVL) – which may be related to the calendar (“the 5th of every month) or not (“for 2 hours every 5 days”) - and the Event Related Periodic Interval of Time (EIVL) (“pain always occurs 2 hours after breakfast”). b) The valid time of facts is defined as a simple time interval in CEN. However, sets of time intervals and, consequently, time series can be formed by using clusters and elements. This is very generic and gives rise to the problem of excessive freedom of design for the user. c) The following important time variables are specified in the following classes: the valid time of a fact as the variable obs_time of the class Item (abstract super class of data entries in the EHR), the total time of clinical activity as the session_time variable of the class Clinical_Session (contains contextual information about the clinical session that led to the storage of an EHR component) and the transaction time as the time_committed variable of the class Audit_Info (contains meta data about the storage and revision of EHR components).
4.2 HL7 CDA a) The model of HL7 does not use the ISO specification for basic temporal data types but its own specification (Data Types - Abstract Specification [14]). The Point in Time is the central temporal data type and specializes the abstract data type Quantity (QTY). It is used to determine the Interval of Point in Time (IVL). Furthermore, like CEN the specification also includes the Periodic Interval of Time (PIVL) and the Event Related Periodic Interval of Time (EIVL). In addition, the data type General Time Specification (GTS) is defined. Nearly all possible temporal structures can be composed with this data type.
6
b) In HL7, time series can be modeled by the use of the data type GTS. A GTS is a general set of points in time. It can generate all validity periods of a fact. Additionally, so-called Periodic Hulls can be created, which aggregate several periodic time intervals. c) The RIM of HL7 is composed of six “back-bone” classes. The class Act is a record of something that “is being done, has been done, can be done or is intended or requested to be done”. This class is also responsible for the documentation of all events. In this class the valid time of a fact is represented by the effectiveTime variable, and the total time of clinical activity through the activityTime variable. Furthermore, the availableTime variable in this class serves to document when a unit of information was first available in a system.
4.3 openEHR a) The model of openEHR does not use the ISO specification for basic time data types but its own specification (openEHR DataTpes Information Model [15]). This specification includes all basic data types such as DV_world_time, DV_date, DV_time, DV_date_time and DV_duration. For date and time, which are often partial, special data types such as DV_partial_date and DV_partial_time are defined. Apart from these data types the model includes
data
types
that
fulfill
other
requirements,
such
as
the
DV_general_time_specification which specifies time points according to a general syntax (based
on
the
HL7v3
GTS
data
type),
and
periodic
events
(DV_periodic_time_specification) that may be event-linked (“after breakfast”) or calendar-linked (“every Tuesday from 11:00 to 11:30 a.m.”). b) Time series may be formed with the class History. This class is defined in the specification for data structures [16]. A history can be represented by single events or event series. Each event may again be represented as complex structures. Hereby predefined structures such as lists or tables can be used. c) The valid time of a fact is represented by the variable origin (Type DV_Date_Time) of the class History, and the offset (Type DV_Duration) of the class Event. The total time of a clinical activity is represented by the variable time of the class Clinical_Context (and Event_Context). The transaction time is modeled at a general level (version of a record) through the variable time_committed within the class Version_Audit while it can be modeled at a more specific level (e.g., Item, Element) through the class Feeder_Audit.
7
5 Discussion The general time data types of the ISO8601 standard [13] have been directly taken over only by CEN; the other two organizations specify their own data types. Nevertheless, the various possibilities of representation of the basic data types of the ISO constitute a basis for temporal data types in all models. For instance, representation with reduced precision (e.g., the date “2004-10”, which, in terms of granularity, is expressed only in months) truncated representations (e.g., “-W-5” for the 5th day of the implied week) and differences between local time and Coordinated Universal Time (e.g., “15:30:00+04” with a deviation of four hours) are possible. These numerous possibilities of representation require software modules that are able to verify and process the large number of variants in a standardized way. In the current versions of the architectures, most requirements for temporal components that are included in the Requirements for an Electronic Health Record Reference Architecture of the ISO (ISO/TS18308) [17] have been implemented. Using the specified data types and basic structures, the majority of complex time concepts such as time series can be realized. All models allow the formulation of partial dates and times and time zones. In openEHR, specific reference is made to fulfillment of the time-related ISO requirements in the document openEHR / ISO 18308 Conformance Statement Revision 1.4 [18]. The requirements for time components (STR 3.7 to STR 3.14.) are nearly completely fulfilled. A few are still missing, such as the requirement of being able to represent time down to the fine granularity of milliseconds (STR3.12 in [17]). In the process of harmonizing the three organizations, time specifications were also modified in respect of their interoperability. For instance, in the CEN model the variable related date and time was split into two variables, namely obs_time and session_time, in order to be compatible with the other standards. Table 1 shows how the three most important time-related variables, valid time of a fact, total time of clinical activity and transaction time of the three standards correspond with each other.
Table 1
8
6 Conclusion Time is a crucial dimension in medical documentation. Uniform models are required to exchange and analyze time-related facts. EHR architectures provide a basis for exchangeable and integrable health records. Although similar goals are pursued in the fulfillment of temporal requirements and despite the fact that harmonizations between the organizations have been achieved, the models differ in respect of their basic concepts as well as details in the realization of temporal structures. For concrete modeling of clinical concepts, semantic specifications are still lacking. The three architectures presented here are partly very generic and allow a large degree of freedom for the purpose of construction. Unambiguous modeling of exchangeable data also requires the possibility to constrain the possible applications of components of the EHR model. This is taken into account in the archetype-approach. This promising 2-model approach originates from openEHR and is now being pursued by HL7 and CEN as well. An important basis for such semantic modeling of temporal components was provided by “Time standards for healthcare specific problems”, a European pre-standard created for the medical sector as early as in 1996 [19]. This pre-standard contains a semantic model for the formulation of structured temporal statements. It defines permitted combinations of relationships between time-related statements and the calendar, as well as mutual relationships between time-related statements. For instance, an episode can be related to a time interval through the comparator “during”. Furthermore, this time standard of CEN includes the classification of systems according to their ability to process and provide temporal information. For instance, the classification LRC(2) means that all relative temporal statements (symptoms after the operation) in a documentation can be traced back to absolute temporal data. These classifications offer very valuable information about potential partner systems, particularly during the exchange of medical data. It may be concluded that although well developed temporal concepts are available today, the exchange and re-application of all time-related health data in a standardized and structured manner is still a distant goal. However, efforts to harmonize the architectures of EHR models are a very important step in the right direction. 9
Acknowledgment The authors wish to thank Lukas Gerhold for his valuable suggestions.
References 1. Shahar Y, Combi C. Timing is everything. Time-oriented clinical information systems. West J Med 1998; 168(2):105-13. 2. Grimson J. Delivering the electronic healthcare record for the 21st century. Int J Med Inf 2001; 64(2-3):111-27. 3. European Standardization of Health Informatics, CEN/TC251. http://www.centc251.org/. 4. Health Level Seven, Inc. http://www.hl7.org. 5. openEHR Community. http://www.openehr.org. 6. CEN/TC 251. ENV 13606-1, Health informatics - Electronic healthcare record communication - Part 1: Extended architecture, 2000. 7. CEN/TC 251. prEN 13606-1:2004(E), Health informatics - Electronic health record communication – Part 1: Reference model, Version 2.1c, 2004. 8. Beeler G. HL7 version 3--an object-oriented methodology for collaborative standards development. Int J Med Inf 1998; 48(1-3), 151-61. 9. Dolin RH, Alschuler L, Beebe C, Biron PV, Boyer SL, Essin D, et al. The HL7 Clinical Document Architecture. J Am Med Inform Assoc 2001; 8(6):552-69. 10. HL7. HL7 Reference Information Model (RIM), Version 2.04; 2004. http://www.hl7.org/library/data-model/RIM/C30204/rim.htm. 11. openEHR. The openEHR EHR Information Model – Revision 4.4.1; 2004. http://www.openehr.org/repositories/spec-0.9_D/release-0.9/publishing/architecture/ reference_model/ehr/im/ehr_im-4_4_1.pdf 12. CEN/TC 251. TS 14796, Health informatics - Data types, 2003. 13. ISO. ISO8601:2000(E), Data elements and interchange formats – Information interchange - Representation of dates and times, Second edition, 2000.
10
14. HL7. HL7 Version 3 Standard, Data Types - Abstract Specification; 2004. http://www.hl7.org/v3ballot/html/foundationdocuments/helpfiles/datatypes.htm. 15. openEHR. The openEHR Data Types Information Model – Revision 1.8; 2004. http://www.openehr.org/repositories/spec-0.9_D/release-0.9/publishing/architecture/ reference_model/data_types/im/data_types_im-1_8.pdf. 16. openEHR. The openEHR Data Structures Information Model – Revision 1.4; 2004. http://www.openehr.org/repositories/spec-0.9_D/release-0.9/publishing/architecture/ reference_model/data_structures/im/data_structures_im-1_4.pdf 17. ISO. ISO/TS18308, Requirements for an Electronic Health Record Reference Architecture, Technical Specifications, 2002. 18. openEHR. The openEHR / ISO 18308 Conformance Statement – Revision 1.4; 2003. http://www.openehr.org/repositories/spec-0.9_D/release-0.9/publishing/requirements/ conformance/iso18308/iso18303_conformance-1_4.pdf. 19. Ceusters W, Buekens F, DeMoor G, Bernauer J, DeKeyser L, Surjan G. TSMI: a CEN/TC251 standard for time specific problems in healthcare informatics and telematics. Int J Med Inf 1997; 46(2):87-101.
11
Table 1: Conformance of time variables in the EHR models of CEN, HL7 and openEHR. The classes in which the variables have been defined are given in parentheses.
Name of variable Description
CEN
HL7
openEHR
Valid time of a fact
obs_time
effectiveTime
origin + offset
(Item)
(Act)
(History)
Total time of clinical activity
session_time
time activityTime
(Clinical_session
(Clincal_context (Act)
) Transaction time
) availabilityTim
time_committed
time_committed e
(Audit_info)
(Version_audit) (Act)
12
