A Case for Enterprise Interoperability in Healthcare IT: Personal Health Record Systems
Mustafa Yuksela,b,Asuman Dogaca, Enis Erkelc, Cebrail Taskinc, Anil Yalcinkayac, Ibrahim Kiremitcic
a Software Research Development and Consultancy Ltd. (SRDC)
bDept. of ComputerEng., Middle EastTechnicalUniversity (METU)
cTurk Telekom Group R&D
Corresponding Author:
Prof. Dr. Asuman Dogac
SRDC Ltd., ODTU Teknokent Silikon Blok, 1. Kat No:14
06800 Cankaya/Ankara Turkey
Tel: +90-312-2101393
Fax: +90-312-2101837
email:
Abstract
The PHR systems need to be integrated with a wide variety of healthcare IT systems including EHRs, electronic medical devices and clinical decision support services to get their full benefit. It is not possible to sustain the integration of PHRs with other healthcare IT systems in a proprietary way; this integration has to be achieved by exploiting the promising interoperability standards and profiles. This chapter provides a survey and analysis of the interoperability standards and profiles that can be used to integrate PHRs with a variety of healthcare applications and medical data resources, including EHR systems to enable access of a patient to his own medical data generated by healthcare professionals; personal medical devices to obtain the patient’s instant physiological status; the clinical decision support services for patient-physician shared decision making.
1Introduction
The Personal Health Record (PHR) systems have evolved from Web pages where patients entered their own data manually to the systems giving patients access to their electronic health records (EHRs) from a healthcare provider. The latter is called a provider-tethered PHR system, and the data from a healthcare provider’s information system such as an EHR or a laboratory system is entered into the PHRs automatically via the data exchange interfaces established among these systems. There are also employer/payer portals providing patients access to claims data and more recently third party PHR systems such as Microsoft HealthVault [1] that provides a secure storage for PHR data together with data exchange interfaces so that third parties can develop applications to upload patient data from a specific system or source, for example, home health devices.
The intent of all of these systems is to give patients better access to their own healthcare data [2]. The PHR is defined as “a tool for collecting, tracking and sharing important, up-to-date information about an individual’s health or the health of someone in their care” [3]. It typically contains information about an individual’s diagnoses, medications, allergies, procedures, lab test results, immunization records and other personal health information. Many PHR systems also provide linkages to convenience tools such as requesting appointments, requesting prescription renewals, asking billing questions and communication tools to assist the patient in connecting with various healthcare professionals.
However, currently all this integration is achieved mostly in a proprietary way and in a fragmented fashion rather than using the standard interfaces. Given the existing semantic and technical diversity of eHealth platforms, each integration effort with a new system will be an expensive process unless standard interfaces are used for data exchange.
In this chapter, we present a survey and analysis of interoperability standards to connect the PHR systems to healthcare applications and medical data resources including EHR systems, personal medical devices and clinical decision support services. Some of these standards are specifically developed for the PHR systems; some are general standards that can also be used in the PHR systems. Additionally, because PHR systems contain a summary of EHR data, some EHR standards directly apply. For the sake of completeness, we present an analysis of all these standards as they apply to the PHR systems.
The chapter is organized as follows: A motivating example is presented in Section 2. Section 3 gives a classification of the PHR interoperability standards. Section 4 describes the EHR-PHR interoperability content standards and profiles. Section 5 classifies the terminology systems based on the underlying structure and the knowledge representation formalism which determine the way they express the semantics and hence help with the interoperability. Section 6 introduces the medical device interoperability standards and profiles for importing medical device data to patient’s PHR. The standards relevant for clinical decision support services are covered in Section 7. Finally, Section 8 concludes the chapter.
2A Motivating Example
Mr. Smith visits his general practitioner (GP) with the symptoms of pain in his joints. The results of laboratory tests as well as radiographs indicate rheumatoid arthritis with high risk of damage in the joints. The GP refers the patient to a rheumatologist in the local hospital.
The local hospital that Mr. Smith is referred to has a care management system for rheumatoid arthritis, which provides a care plan for shared decision making between the physician and the patient to help them monitor the progress jointly. The care plan is a workflow based on “National clinical guideline for management and treatment of rheumatoid arthritis in adults”, and it is processed and visualized through a clinical decision support service.
Mr. Smith decides to enroll in this program, and a care plan is created for him using this guideline, which specifies all the decision, action, branch and synchronization steps including medical tests, medications, home monitoring and follow-up appointments recommended for the care of his condition. To execute these steps, the care management workflow needs to retrieve data from the Electronic Medical Record (EMR) system at the GP’s office; the Electronic Health Record (EHR) system at the hospital; the Laboratory Information System (LIS) at the local lab, and from the PHR of the patient. Fortunately for Mr. Smith, his PHR system provides a single point of access and control to all this information because it is interoperable with all the mentioned systems based on relevant standards. Additionally, the consent management mechanism of the PHR controls access to this data according to his privacy consent.
The rheumatologist goes over the steps of the care plan and describes them to Mr. Smith. He also wants Mr. Smith to record the symptoms and signs of the disease, his emotional state and side effects of the medications to his PHR.
At his next appointment with the GP, standard physical exam reveals that Mr. Smith suffers from hypertension, which is the side effect of his arthritis medication. For hypertension control, the GP recommends him benazepril. The PHR system of Mr. Smith has standard interfaces to external decision support services, one of which checks drug-to-drug interactions. When this medication record appears in his PHR, the drug-to-drug interaction checker recommends medication replacement because his current drug for rheumatoid arthritis, namely ibuprofen, might decrease the antihypertensive efficacy of benazepril. The rheumatologist replaces the drug and recommends blood pressure measurements to Mr. Smith four times daily. The PHR system uses standard interfaces for importing medical device data and therefore the off-the-shelf blood pressure device he purchases is capable of automatically uploading his measurements to his PHR so that both the patient himself and the GP can follow the results.
The GP monitors remotely both the progress of the care plan, the measurements provided by the medical device and status updates provided by Mr. Smith, and confirms that everything is under control. He motivates Mr. Smith through the instant messaging service of the PHR for his continuous dedication to the care plan, and notifies him for his next regular appointment.
3Classification of the Interoperability Standards for the PHR Systems
PHRs are not only electronic repositories of health information controlled or accessed by patients. They are also integrated with a wide variety of healthcare information technology systems. Therefore, the interoperability standards for the PHR systems can be categorized according to the systems they are communicating with: (i) Electronic Health Record standards, (ii) Personal Medical Device standards, and (iii) Clinical Decision Support Service (CDSS) standards.
It should be noted that the interoperabilityof IT systems can be assessed on different layers, from the lowest physical layer in the ISO/OSI model to the behavior ofthe system as perceived by the end users. It is feasible to organize these into three major layers in the case of interoperability of healthcare IT systems: the communication layer, the content layer and the business process layer. The communication layer covers the messaging specifications that are built on top of the application layer of the ISO/OSI model or the TCP/IP model, such as HL7 SOAP Web Services Profile; or rarely some lower layers such as the OSI session layer in the case of HL7 Minimal Lower Layer Protocol (MLLP). The contentlayer involves the format of the exchanged clinical messages and documents as well as their semantics expressed through the clinical terminology systems used.The business process layer involves the choreography of the interactions among the healthcare IT systems, by defining high-level transactions and then binding them to specific standards from the communication layer and content models from the content layer.
This article focuses mainly on the standards in the content layer. It also covers the profiling approach that corresponds to the business process layer as described above. The communication layer is not directly within the scope of the article, as it is built on top of very well known standards such as Web services and used similarly in other domains. However, relevant healthcare communication standards are referred within interoperability profiles.
4PHR-EHR Interoperability Standards
4.1PHR/EHR Content Standards
A PHR contains the summary of the patient’s EHR data. Therefore PHR content standards, just like EHR content standards [4], define document structures consisting of document components such as sections, entries and data elements and are in fact based on the EHR content standards most of the time.
One of the most widely used standards that define PHR summary data is the E2369-05 Standard Specification for Continuity of Care Record (CCR) [5] by the American Society for Testing and Materials (ASTM) International. CCR defines a core data set for the most relevant administrative, demographic, and clinical information facts about a patient’s healthcare, covering one or more healthcare encounters. It contains various sections such as patient demographics, insurance information, diagnosis and problem list, medications, allergies and care plan. CCR specification has its own XML schema definition; but it is also used in constraining other EHR content standards to obtain PHR/EHR content templates.
Generic EHR content standards that can also be used for EHR-PHR interoperability include HL7 Clinical Document Architecture, Release 2 (CDA)[6], ISO/CEN 13606-1: Reference model[7] and openEHR[8]. Unlike CCR, all these standards define quite generic structures such as folder, section, entry, observation and substance administration that can be used to represent any kind of clinical statement. The specialization of these generic structures is done by refining their semantics through the use of coded terms and/or free text explanations. For example, a 13606-1 section can be declared to be an allergies section by setting its name (free text) and meaning (coded value) attributes accordingly. Formal expressions of such specializations result in content templates as explained in Section 4.3.
Another PHR content standard is the HealthVault Thing Types that are defined by Microsoft. Instead of using the existing content standards, Microsoft preferred defining a simple proprietary XML syntax for each possible clinical statement (e.g. blood glucose measurement, body dimension, insulin injection, etc.). Yet, the underlying information model of these Thing Types is compatible with the data types and structures of the well-known standards such as CCR and CDA which facilitates the interchange of clinical data complying with these standards in HealthVault.
4.2Analysis of PHR/EHR Content Standards
All PHR/EHR content standards serve similar purposes, that is, consistent and machine processable representation of healthcare information. The main distinguishing property among various content standards is the specificity (expressivity) of the underlying information model; that is, how generic or specific their schemas are.
Table 1 Comparison of PHR/EHR content schema expressivities
Totally generic schema / Semi-generic schema / Specialized schemaISO/CEN 13606, openEHR / HL7 CDA R2, ASTM CCR / HealthVault Thing Types
ISO/CEN 13606 and openEHR provide the most generic schema. It is possible to represent any kind of clinical statement with the combination of just three classes, namely Entry, Cluster and Element. HL7 CDA R2, on the other hand, has multiple structures each specialized for a group of medical activities; hence it has a more specialized schema. It has nine entry classes derived from the HL7 v3 Reference Information Model (RIM) [9], such as Act, Observation, SubstanceAdministration and Encounter. It is possible to classify ASTM CCR schema similarly with CDA. Some CCR classes like Immunization, Plan and Alert are more specific than CDA classes but still, there are no dedicated structures for representing individual medical events such as blood pressure or insulin injection, which are provided by HealthVault.
The advantage of a specialized schema such as HealthVault is that it is self-explanatory and easy to implement at first. However, in the long run, they might create maintenance issues for the implementers because each time the information model of a dedicated clinical event is modified or a new one is created, the syntax completely changesas well. Consider for instance, a Web service endpoint that accepts HL7 CDA R2 documents; this single endpoint can accept any CDA document, perform XSD validation on it, and then invoke the corresponding validation procedure according to the content, actually according to the content template (Section 4.3). When there is a change in the content template, the endpoint stays the same and the validation rules are modified. This is not easily achievable with specialized schemas.
The disadvantage of the generic and semi-generic schemas is that the footprint of clinical documents can become quite large.There can be many repeating constructs and attributes for representing a very simple medical event, especially with fully generic schemas. Therefore, it is better to have at least some common structures for modeling a group of medical activities, as in the case of CDA. Even with CDA, the experience shows that it is not easy to deal with tens of attributes just for modeling a diagnosis with an ICD-10 code for instance. In order to overcome these issues, recently greenCDA [10] has been proposed by the HL7 CDA community. greenCDA is the strategy of hiding certain CDA complexities such as fixed attributes (e.g. classCode, moodCode) and generic XML tags by introducing an intermediary XML schema with clinically meaningful XML element and attribute names, such as resultId, procedureType and problemCode. This intermediary schema is supported with transformation rules expressed in XSLT to automatically convert greenCDA instances to valid CDA instances. It is more meaningful to implement greenCDA together with content templates such as Continuity of Care Document (CCD) and Patient Care Coordination (PCC) templates (Section 4.3). The first release of greenCDA implementation guide by HL7 provides an intermediary greenCDA schema conforming to Health Information Technology Standards Panel (HITSP) C32/C83 content modules [11] and generating CDA instancesthrough transformation that comply with the corresponding CCD templates.
Finally regarding the analysis of existing PHR/EHR content standards, in order to foster unique representation and hence interoperability, there has to be a normative computer processable schema of a content standard. To remain technology independent, ISO/CEN states that compliance to 13606 standard is achieved by implementing the 13606 UML model. However, because XML is the de facto data exchange standard, it would be good to have a normative XML Implementation Technology Specification of the 13606 UML model. In this way, when two 13606 implementing systems need to interoperate, the implementers can directly skip interoperability at the syntactic level and concentrate on the actual clinical content. It should be noted that, although it is not official, there is an XML schema of ISO/CEN 13606for the last two years, maintained by the EN 13606 Association [12].
4.3PHR/EHR Content Templates
The content templates are built on top of the well-accepted content standards to further refine these standards by: (i) restricting the alternative hierarchical structures to be used within the instances, (ii) constraining optionality and cardinality of some elements, (iii) defining the code systems and codes used to classify parts of the content and also (iv) describing the specific data elements that are included.
One of the most prominent PHR content templates, namely Continuity of Care Document (CCD) [13] is defined by constraining an EHR content standard, namely, HL7 Clinical Document Architecture, Release 2 (CDA) with requirements set forward in ASTM CCR. CCD defines a single document template, but there are several section templates and clinical statement templates to be used within this main document template. IHE Patient Care Coordination (PCC) Technical Framework further details and multiplies the CCD templates at the document, section and clinical statement levels according to the content module requirements of its integration profiles such as Exchange of Personal Health Record Content (XPHR) [14] and Query for Existing Data (QED) [15]. For example, currently PCC has six main document templates (Discharge Summary, Medical Document, Medical Summary, PHR Extract, PHR Update, Scanned Document) in comparison to the single CCD document template. Similarly, HITSP has defined CDA content modules that reuse and further restrict the IHE PCC templates and the underlying CCD templates according to the requirements in the US[16]. In December 2011, within the US Office of the National Coordinator’s (ONC) Standards and Interoperability (S&I) Framework, through the joint efforts of HL7, IHE, ONC and the Health Story Project, the Consolidated CDA Templates guide [17] was released as the single source incorporating and harmonizing CDA templates from CCD, PCC, HITSP C32, HL7 Health Story guides and Stage 1 Meaningful Use. Consolidated CDA is by far the most comprehensive and complete single source library of CDA templates, which makes it very valuable for CDA implementers all over the world.