A Mapping of the Victorian Electronic Records Strategy Schema to openehr

VERS openehr Mapping Commentary A Mapping of the Victorian Electronic Records Strategy Schema to openehr Electronic Health Records: Achieving an Effective and Ethical Legal and Recordkeeping Framework Australian Research Council Discovery Grant, DP0208109 2002-05 School of Law Deakin University, School of Information Management and Systems Faculty of Information Technology and Faculty of Law Monash University, Australia Rob Meredith School of Information Management & Systems, Monash University Rob.Meredith@infotech.monash.edu.au January, 2004

Introduction This document is a commentary on a comparison between the Victorian Electronic Records Strategy (VERS) and the openehr electronic health records standard. VERS documents the Victorian State Government s requirements for electronic records submitted to the Public Records Office of Victoria, and forms the basis for other electronic records systems to be used by other branches of the Government. The specification can be found at http://www.prov.vic.gov.au/vers/welcome.htm. openehr is an open standard for the design of electronic health records systems. Consisting of a number of models specifying the data required by compliant systems for various aspects of a medical records system, it is still a work in progress, in that a number of the proposed models are yet to be released to the public. Documentation for the current models can be found at http://www.openehr.org/. Purpose The purpose of this document is to provide an overview of the results of the VERSopenEHR mapping. It should be read in conjunction with the mapping document itself (VERS-EHR.xls), as well as the VERS and openehr documentation itself (see below). This document highlights some of the main issues that have been identified as a result of the mapping process, but doesn t claim to be a comprehensive list of limitations of openehr from a record-keeping perspective. Document Versions The following document versions were used for the mapping process: VERS: [VERS1] Public Records Office Victoria (2003) Management of Electronic Records, PROS 99/007, Version 2.0, available at http://www.prov.vic.gov.au/vers/standards/pros9907vers2/pdf/99-7_ver2-0.pdf [VERS2] Public Records Office Victoria (2003) Advice 9: Introduction to the Victorian Electronic Records Strategy (VERS), PROS 99/007, Version 2.0, available at http://www.prov.vic.gov.au/vers/standards/pros9907vers2/pdf/99-7_advice_ver_2-0.pdf [VERS3] Public Records Office Victoria (2003) Specification 1: System Requirements for Preserving Electronic Records, PROS 99/007, Version 2.0, available at 1_Std_ver_2-0.pdf [VERS4] Public Records Office Victoria (2003) Specification 2: VERS Metadata Scheme, PROS 99/007, Version 2.0, available at 2_Std_ver2-0.pdf [VERS5] Public Records Office Victoria (2003) Specification 3: VERS Standard Electronic Record Format, PROS 99/007, Version 2.0, available at 3_Std_ver_2-0.pdf 1

[VERS6] Public Records Office Victoria (2003) Specification 4: VERS Long Term Preservation Formats, PROS 99/007, Version 2.0, available at 4_Std_ver_2-0.pdf [VERS7] Public Records Office Victoria (2003) Specification 5: Export of Electronic Records to PROV, PROS 99/007, Version 2.0, available at 5_Std_ver_2-0.pdf openehr: [EHR1] Beale, T., Heard, S., Kalra, D., & Lloyd, D. (2002) The openehr Technical Roadmap, The openehr Foundation, Revision 1.2 [EHR2] Beale, T., Goodchild, A., & Heard, S. (2002) Design Principles for the EHR, The openehr Foundation, Revision 2.4 [EHR3] Beale, T. (2002) The openehr Modelling Guide, The openehr Foundation, Revision 1.0 [EHR4] Beale, T., Heard, S., Kalra, D., & Lloyd, D. (Eds.) (2003) The openehr EHR Reference Model, The openehr Foundation, Revision 4.3.2 [EHR5] Beale, T., Heard, S., Kalra, D., & Lloyd, D. (Eds.) (2003) The openehr Common Reference Model, The openehr Foundation, Revision 1.4.4 [EHR6] Beale, T., Heard, S., Kalra, D., & Lloyd, D. (Eds.) (2003) The openehr Data Types Reference Model, The openehr Foundation, Revision 1.7.3 [EHR7] Beale, T., Heard, S., Kalra, D., & Lloyd, D. (Eds.) (2003) The openehr Data Structures Reference Model, The openehr Foundation, Revision 1.3.1 [EHR8] Beale, T., Heard, S., Kalra, D., & Lloyd, D. (Eds.) (2003) The openehr Demographic Reference Model, The openehr Foundation, Revision 1.4.1 [EHR9] Beale, T., Heard, S., Kalra, D., & Lloyd, D. (Eds.) (2003) The openehr Support Reference Model, The openehr Foundation, Revision 0.9.3 [EHR10] Beale, T., Heard, S., Kalra, D., & Lloyd, D. (Eds.) (2003) The openehr EHR_EXTRACT Reference Model, The openehr Foundation, Revision 1.3.2 Methodology A direct mapping of VERS to openehr is not possible for a number of reasons, the first being that the two models are intended for quite different purposes. VERS was developed with the needs of the Victorian Public Records Office in mind, that is, the needs of that office to be able to accept, for archival preservation and storage, records in electronic format from a number of agencies. openehr, on the other hand, is a logical model unrelated directly to any physical system, designed to manage patient health data. Whilst the two overlap (they are both concerned with record-keeping), there are broad areas of incompatibility. 2

The method adopted, therefore, has been to derive the requirements for records from the VERS documentation. These include system requirements, metadata and other aspects of record-keeping. Rather than directly mapping to openehr elements, the task is to determine whether a system implementing openehr either directly supports, or could be made to support, the derived VERS requirements. For example, a particular VERS Metadata item may not necessarily exist within an openehr model, but it might be reasonable to assume that if asked, the operator of an openehr system might be able to generate the metadata item asked for in VERS. There are therefore a number of levels of compatibility: Full, Implementation Dependent, Derivable (not directly supported, but reasonable to assume that the data could be generated), Partial, and Not Supported. Finally, some elements of VERS are listed as deprecated those elements have not been mapped, but they have been included in the mapping spreadsheet for completeness. The mapping spreadsheet, VERS-EHR.xls, has been structured in the same manner as the VERS documentation. For each document, a separate worksheet has been created that lists, on the left, the record-keeping requirements derived from that document. The next column specifies the level of compliance by openehr with that requirement. Where necessary, commentary has been provided in the next column. Main Findings A good summary of the overall support offered by openehr for the VERS requirements can be found in the worksheet relating to the VERS System Requirements document [VERS3]. The requirements listed in this document outline the requirements of a good electronic record-keeping system. This sheet is reproduced below: Requirements derived from VERS System Requirements Specification Record Authenticity Record Integrity Document Conversion Metadata Capture Modifying information associated with Records and Folders Documenting the History of the Records and Folders Reliability Refresh Record Transfer openehr Compliance Depends on Access Control Models, yet to be documented Partial Not applicable Partial Full Partial (record creation and modification, but not access) Depends on implementation Depends on implementation Not applicable Table 1 - VERS System Requirements & openehr Compliance Inapplicability of parts of VERS As can be seen from the table above, some sections of the VERS specification are not applicable to a mapping with openehr. The purpose of VERS is partly to specify for client organisations of the public records office the format of electronic records to be provided for long term preservationl. A compliant system owned by a client will be able to generate an electronic object (VEO) which is then able to be sent to the public records office for storage. Requirements specifically designed for long term preservation such as 3

the ability to convert documents to a VEO compliant format, and the ability to transfer this to the Public Records Office of Victoria are not the principal design specifications of openehr. Altough, as recorded below, openehr has components that comply with VERS. Most VERS Metadata Elements Fully Supported or Derivable The main area of relevance for openehr is the VERS metadata scheme [VERS4]. By mapping the schemas documented in the various openehr models, it has been possible to highlight a number of areas of difference. It should be noted that, whilst openehr doesn t provide complete compliance with the VERS metadata, the majority of metadata elements required in VERS are supported, at least to the point where they can be derived from an openehr system. Aspects of the VERS metadata such as the structuring of records and descriptions of their contents are fully supported by openehr. Those areas of VERS that receive the least amount of support, however, tend to relate to record-keeping business functions. Given the recordkeeping needs, however, of the medical industry, where long term, authentic and secure records are vital, the seriousness of these shortcomings should not be overlooked. These record keeping aspects are as follows: Rights Management The most glaring omission from openehr as it stands in the documents used for this comparison is the area of the control of use and access to records. Section 9.2 of Design Principles for the EHR [EHR2] states that the following five principles should underlie any openehr system (see [EHR2] for precise definitions): Authentication Confidentiality Integrity Availability Non-Repudiation Whilst these principles are worthwhile, the inclusion of these into the overall openehr model base is a work in progress. Section 9.2 itself has a number of sections marked To Be Continued, and the model that would contain most of the security functionality, Access Control (see Figure 2 openehr Model Family, page 10, [EHR1]) has yet to be released to the public. As a result, large sections relating to rights management in VERS, comprising VERS metadata elements M25-M31, M135-M151, and M154, are unable to be mapped as they may, or may not be supported by a subsequent version of openehr. Audit Trails Broadly speaking, openehr has a relatively rigorous audit trail mechanism in place. It provides support for the logging of the creation, modification and deletion of records, and ensures that all previous versions of a record are available if needed. It achieves this by implementing a chain of records representing the different versions of an individual record over time, beginning with the initial creation of the record, and allowing for a record to be flagged as deleted, rather than physically removing it at the end of its life. 4

This same concept is utilised in VERS with its modified VEO object (see [VERS3]). However, VERS also goes further in tracking not only the creation, modification and deletion of records, but their access as well, through the use of the following metadata elements (see [VERS3]: M73 Object Content.Record.Use History.Use.Use Date/Time M74 Object Content.Record.Use History.Use.Use Type M75 Object Content.Record.Use History.Use.Use Description This ensures that even if a user has legitimate rights to access a record for some purpose (rights management), all access to that record outside of the scope of that purpose is logged. This is an important privacy mechanism, missing in openehr. Whilst it is conceivable, and even likely, that the developer of an electronic health record system based compliant with openehr would incorporate such functionality, this is by no means guaranteed by the standard. Since privacy and accountability are vital aspects of the medical industry, it is surprising that logging of record access has been omitted in openehr. Scheduling of Specific Record Keeping Actions VERS includes a mechanism for the scheduling and logging of actions to be undertaken in regard to the preservation and disposal of a record. The following metadata elements are incorporated into VERS for record preservation (see [VERS3]): M78 Object Content.Record.Preservation History.Action.Action Date/Time M79 Object Content.Record.Preservation History.Action.Action Type M80 Object Content.Record.Preservation History.Action.Action Description M81 Object Content.Record.Preservation History.Next Action M82 Object Content.Record.Preservation History.Next Action Due Whilst the following manage record disposal: M89 Object Content.Record.Disposal.Disposal Authorisation M90 Object Content.Record.Disposal.Sentence M91 Object Content.Record.Disposal.Disposal Action Due M92 Object Content.Record.Disposal.Disposal Status Of these metadata elements, only M92 Disposal Status can at least be derived from an openehr system (by determining whether or not a record still exists and is accessible). Mandates for Record Keeping Activities Related to the issue of the management of record keeping activities, VERS supports the logging of the mandate used by a record-keeper to undertake an action in relation to a record. For example, a particular action, such as the deletion of a record, may be mandated by legislation, or some organisational policy. VERS incorporates the following metadata elements to implement this (see [VERS3]): M94 Object Content.Record.Mandate.Mandate Type M95 Object Content.Record.Mandate.Refers To 5

M96 Object Content.Record.Mandate.Mandate Name M97 Object Content.Record.Mandate.Mandate Reference M98 Object Content.Record.Mandate.Requirement Whilst the tracking of a mandate may not be as important as the logging of access to a record, or the management of record-keeping activities, the capture and logging of the mandate related to record-keeping activities is never-the-less important for ensuring the integrity and legality of the record, especially in long term time frames. None of these elements are supported by openehr in regard to records-management activities. Long Term Preservation of Records One of the strengths of VERS is that it has been designed with an emphasis on the long term preservation of records and their metadata. VERS mandates, for example, the use of common, standard encoding techniques such as Adobe s open, ubiquitous, even if proprietary portable document format (PDF), ASCII text, TIFF images and standard compression algorithms [VERS6]. It also specifies standard media such as 63 or 74 minute CD-R as opposed to 80 minute CDs or CD-RW formats [VERS7]. VERS also specifically prohibits the encryption of records to ensure their long-term accessibility. openehr, on the other hand, does not deal well with the issue of long-term preservation of records. openehr does have, as one of its stated aims, the long-term accessibility of health records (see section 9.4, page 88 of [EHR2]), and references concepts of selfdocumentation, self-containment and record structure extensibility, which are in common with long term preservation models. It also recognises a number of strategies by which this can be achieved (from [EHR2], page 88): Preservation of the original system Emulation of the original system on a new platform Migration of the data to a new system Encapsulation of the older data within the new format However, this being said, openehr sidesteps the issue of long-term preservation by arguing that the method of ensuring this principle is one of enterprise policy ([EHR2], p. 88) that is, it is up to the system developers/builders to derive an acceptable solution. This is further compounded when it is considered that data encryption is a likely tool for system developers to be used for ensuring security and privacy of health records, although encryption is not specifically incorporated into the openehr specification. Encryption is acceptable for transmission but not storage. There is a tension between the long-term access needs for health records (>100 years), and the security and privacy requirements placed upon system owners and operators. By placing the burden upon developers to devise a suitable long-term archival mechanism, with some justification (openehr doesn t claim to be a system requirements specification document), openehr leaves this important issue somewhat up to chance. 6

Conclusion In general, based upon this comparison with the record-keeping requirements of VERS, openehr has a moderately good level of support for basic record-keeping principles. Certainly the introductory documentation to openehr including the technical roadmap [EHR1] and the Design Principles [EHR2] outline a sound treatment of the recordkeeping aspects of electronic health records systems. Where the model currently falls down, however, is primarily in managing record-keeping activities (such as scheduling and the logging of record-keeping mandates) and in extending the audit trail to include record access as use in addition to creation, modification and deletion. openehr also sidesteps the important issue of the long term preservation of records by leaving the most important aspects of the mechanism for ensuring this up to system developers. Despite addressing the majority of record-keeping issues in the EHR context, these aspects of openehr reflect, perhaps, the fact that record-keepers have not had a strong influence on the development of the standard. Inclusion of input from record-keeping experts is an important task that the openehr Foundation should turn its attention to. Further work will be needed when the Access Control models for openehr are made available, at which time, the rights management aspects of VERS can be compared for a more detailed assessment of the security and access control features of openehr. 7