VA View Module 3: Health Data Exchange Standards, Privacy and Information Security

VA View Module 3: Health Data Exchange Standards, Privacy and Information Security

Introduction

[Paul Nichol, MD. National Director of Medical Informatics, VHA]

Welcome to Module Three of Health Informatics 101, a course for VA staff, brought to you by Bellevue College and our own Health Informatics Initiative. In Module One, you learned a little about the field of health informatics in general and the kind of roles that it includes. In Module Two, you learned about electronic health records and consumer health informatics and had an introduction to some of the standards that are involved.

[Health Informatics 101 Module Three - Key Topics: Health Data Exchange Standards, Privacy and Security]

In Module Three, we will spend more time talking in specifics about health data interchange standards as well as privacy and information security. These are foundational, cornerstone issues for the appropriate implementation and optimization of our information systems. We're really way past a time where it's okay to have information about a patient confined within an institutional database. To really fulfill the VA goal of being a patient-centered organization, we need to have all the information about a patient aligned around that patient and not the various organizations in which they may have received care. Health information exchange standards are one way that we ensure that we collect all the information in a way that makes it available as well as understandable when we receive it.

[Congratulations, you have completed this video!]

[To continue, please select one of the topics to the left.]

Health Data Exchange Standards

As VA Employees, I hope I don't have to remind you about the importance of privacy and information security; we certainly are reminded of it on a regular basis and in annual update to take in this area. But it never hurts to get a refresher in this area and I think the course may offer some different perspectives on this from what we frequently see in the VA. The initial discussion on the health data interchange standards really focuses on HL7, the organization that is probably the best known, most widely recognized in the health data standards. HL7 stands for "Health Level 7," which is the layer in an information model developed by the International Organization for Standardization that supports applications.

It is an international group and it mostly requires voluntary support to keep it going. It is tough work; the standards have to be very detailed and meticulous, very specific, and then have to be agreed upon by a large number of individuals before they can actually be published and agreed to. The process of gaining that consensus is called balloting, and it is a very formal process that allows for multiple levels of review before any standard is actually enacted. VA staff have been very involved with standards development organizations like HL7. Many have served as chair of working groups in HL7 and participate actively in the development of standards. One way to ensure that you can comply with a standard that is published is to help its creation, and the VA brings a lot of experience, both from longstanding use of computer systems and information systems as well as being a pioneer in trying to implement many of these standards. We really contribute significantly to the development of these kinds of standards. So why are they so important? Well, if you think of receiving a letter, for example, you know by looking at it what the return address is, the date, the salutation, the content, and who signed it.

But, a computer requires direction to know how to put information in context. If you got a letter that was in a foreign language or perhaps in characters that you didn't recognize, how would you know how to interpret it? And, if you did recognize the letters or numbers, but they were not in English or a language familiar to you, how would you know how to interpret it? So, the standards that HL7 includes define how a message should be formatted and how a computer should interpret it. It's critical so that information can be exchanged between one organization and another or one system and another, and also interpreted in the same way.

It is important that the meaning that the sender had is the same meaning that is derived by the person who received the message. And, this is not always easy. It requires a fair amount of very detailed specification. I'm sure that in the lecture and the examples, you'll get some flavor for how detailed these messages can be. The VA, as I said, has been quite involved and uses many of the different aspects of HL7 standards. One of the conceptual standards is called the HL7 Reference Information Model (RIM). And the VA has created the Veterans Information Model (VIM) based on the RIM and uses that in our Health Data Repository (HDR).

The Health Data Repository also uses a Unified Modeling Language (UML) and various class diagrams to represent the information in the HDR. The Unified Modeling Language, which you will learn about in more detail, allows not only interaction with the HL7 Standard, but also allows information in the HDR and using the VIM to interact with a variety of other standards. The HL7 Clinical Document Architecture (CDA) is another aspect of HL7 standards that the VA uses extensively. Our Virtual Lifetime Electronic Record effort is really pioneering the use of HL7 CDA and you may hear the terms AHIC, American Health Information Community, or HITSP, Health Information Technology Standards Panels, which have developed specific use cases for how the HL7 Clinical Document Architecture should be applied to specific instances. Many of these involve reporting lab tests or receiving care in a continuity of care manner.

There are a number of documents in the Continuity of Care Record (CCR) and the clinical Continuity of Care Document (CCD) are examples of how this has evolved over time. HL7 provides document standards called HL7 Clinical Document Architecture. These document standards are applied through our Virtual Lifetime Electronic Record efforts. The CDA requires further constraints to be placed on it and to be applied to specific use cases.

The American Health Information Community, AHIC, and the Health Information Technology Standards Panel, HITSP, provides specific use cases for things like continuity of care, reporting of lab results, and other specific examples of how information is to be used. The HL7 Clinical Document Architecture then defines the kinds of elements and the relationship of those elements in documents such as a C32 or a C83, which are representations of a Continuity of Care Record or a Continuity of Care Document, which are two different standards applied to continuity of care information that might be important when a patient moves from one healthcare location to another. So, we have a lot of experience and really the VLER (Virtual Lifetime Electronic Record) effort which is now piloting health information exchange between VA, DoD, and the private community in a number of different locations is really at the forefront of implementing these kinds of standards.

Health Data Exchange Standards (continued)

There are also application standards, the HL7 CCOW (Clinical Context Object Workgroup) Standard, is used to maintain context among applications that might be used, the VA has implemented a version of this to allow you to open records from within CPRS and links so that the application knows both who you are and which patient you're dealing with. Applications like VistA Web and others that you may access from CPRS use a form of CCOW interaction to maintain clinical context.

The Electronic Health Record (Systems) Functional Model (EHR-S FM) is another aspect that HL7 has developed and this is a model that tries to elaborate a number of the requirements and capabilities that need to be present in an electronic record system. The DoD used the HL7 EHR Reference Model extensively as they were doing an analysis of alternatives for DoD systems. In addition to the functionality defined by HL7, they identified several thousand additional extensions or additional capabilities.

The VA is looking at the work they have done and looking at how we can also use the HL7 Reference Model as we go forward with our Integrated Electronic Health Record (iEHR) effort with DoD.

[HL7 Messaging Standards]

The bulk of the lecture and I think what HL7 is most known for are the messaging standards.

[HL7 v2]

You'll learn about HL7v2 and v3. HL7v2 is a standard that was really created in the late 1980s to support interoperability among the electrical systems and computer systems within a hospital setting. They're up to HL7v2.6 and thinking about HL7v2.7, fortunately the newer versions are backwards compatible. The HL7v2 standard is used extensively with the VA.

In 2006, an interface handbook was published for our Text Integration Utility (TIU) that allows uploading of information from other software such as COTS products or commercial off the shelf products, that may be integrated within CPRS and that continue to evolve. I recently reviewed an issue brief for radiology in which they were updating from v2.3 to v2.4 to take advantage of some additional capabilities that are in that specification. As you're probably aware, within VA we are increasing the number of systems that interact with VistA and CPRS that were developed outside of the VA.

We have Clinical Information Systems (CIS) in the ICUs; we have Anesthesia Record Keepers (ARK) in the OR (Operating Room); we have PACS (Picture Archiving and Communication System) systems in radiology. All these systems need to be able to communicate with VistA. Most of that communication is done through HL7 messaging. Interestingly, our VA systems and initial VistA systems were developed before the standard was available and internally within VistA many of the different packages that make up the full suite of VistA functionality communicate with each other through remote procedure calls and a broker that helps to triage these internal messages. But, once we get outside of the core VistA applications, we increasingly are using HL7 messaging to ensure compatibility.

Health Data Exchange Standards (continued)

I think I mentioned that standards development can be somewhat challenging. The initial HL7v2 standard was to support hospital workflows.

[HL7 v3]

In 1995, work began on the HL7v3 standard specifications, which were intended to support all clinical workflows. After 10 years, the initial standards were published in 2005. The HL7v3 encompasses many of the types of standards that I mentioned previously, including the Clinical Document Architecture and the Reference Information Model, both of which the VA has used extensively in projects such as the Health Data Repository and our Virtual Lifetime Electronic Record initiatives (VLER). We're learning a lot from the VLER activities and it's important to recognize that these standards are constantly evolving, being modified, and the lessons that we learn through actually trying to use the standards and implement them across different organizations provide really valuable feedback, going back to HL7 and similar organizations to further refine and improve on the standards that they have published.

[DICOM Standard]

The other standard that you will discuss in this module is the DICOM standard, the Digital Imaging Communication Standard. Many people associate this with images in radiology, but it in fact is very important for other types of medical images as well. You're probably aware that within the VA, we have both VistA Imaging as well as PACS, or picture archiving systems, from multiple vendors that have to communicate back to VistA Imaging, so that clinicians can view these images through remote image views or through VistA Imaging at the desktop. It's important that the images be DICOM compliant, and that's one of the ways we ensure that these images can be read across multiple systems.

We also have a number of other programs that use the DICOM standard. Teleretinal imaging captures images for screening for diabetic retinopathy, and allows those images to be transmitted to a central reading location for interpretation and feedback to the referring provider. We also have a teledermatology program those images similarly are best if they adhere to a DICOM standards.

[IEEE]

Among the other standards and standards development among organizations that will be covered in this module is the IEEE, Institute of Electrical and Electronics Engineers. This is an organization that has been around for a long time and has promulgated standards in multiple different areas. Some of the ones that you may find of most interest are those that are from personal health data and personal health devices.

This is increasingly important as we move care from the hospital, to the clinic, to the home, and increasingly rely on the devices that the patient has in their home for their communication and information. Adherence to IEEE standards is one way that we ensure the information is compatible when we bring it into our VistA systems. The importance of carefully implementing and rigorously adhering to the standards that are discussed in this module really cannot be overstated. We are moving into an environment in which we will increasingly have systems that are made up of government-developed software, commercial off-the-shelf software, increasingly we hope, open-source applications.

For all these different applications from different developers to work together, it's critically important that we define the standards that we're using and ensure that those who want to work with us adhere to them. This is particularly important in our work with the Department of Defense because the integrated electronic health record architecture includes a common information interoperability framework. As Mr. Baker (VA Chief Information Officer) said in a recent meeting, "It's absolutely critical that we get this right, it's the foundation on which a lot of the other applications and functionality depends and it really boils down to being sure that we get the framework right, the information model, and the appropriate application of the correct standards to support it."