Ed Hammond Discusses the Need for Increased Data Sharing and the Development of Collaborative Health Care Industry Standards
Barry Jacobs: What is changing in terms of standards in clinical transformation?
Ed
Hammond: The big change is an awareness of the need for standards by a broader
set of people. The second change is a recognition by the industry that quality
and patient safety require the use of data standards and connectivity between
groups and data.
BJ: Are master files, codes, and identifiers part of the barrier to successfully collaborating with varying technologies?
EH: Let me preface this by saying that there are two kinds of standards. One is the capital "S" type of standard where there is a formal process to create the standard. The other is the little "s" type of standard, which are shared norms that do not necessarily go through a formalized process.
For several reasons, codes and terminology do not go through standards processes. One reason is that defining terminology is an ongoing process. We continue to add terms because we have new knowledge. We've always had a lack of control over terminology because of its changing nature, and this is the greatest barrier to sharing data that there is.
Master files are one of the ways in which we exchange data. Almost every institution, has it's own local terminology that is mapped onto another terminology for some specific purpose. At the present time, for example, at Duke, we still use multiple terminologies, and what we try to do is create files that define those terminologies.
A dominating reason for mapping to a particular terminology is the fact that it's required for reimbursement. But the code commonly used in the United States for reimbursement cannot create an electronic health record — a database, if you will. It simply does not have the granularity required to create a clinical database.
IDs, like "providers," "facilities," and "health care plans," are also badly needed. In some of the existing systems, for example, the same physician will have four or five different associated IDs. Moreover, those identifiers change as they go from one institution to another. So when you're trying to track a patient through a physician, it becomes extremely difficult to do so because of the differences in providers, and from state to state it varies tremendously as well. There is a need for employee, provider, facility, and health care identifiers, and in my opinion there strongly needs to be an identifier for individuals.
There are also data dictionaries. We use a data dictionary, which might be perceived to be a master file, to define a number of things, including the identification of all the providers at Duke, as well as the terminology that's used for everything from diagnosis to medications to laboratory tests.
Typically, those master files map from one terminology to another. For example, using HL7, there are standards one can use to update those master files automatically. Ideally, if one terminology changes, that information is sent to update the master file, and users of that terminology then update their own systems.
That's a less than desirable system though, for a number of reasons. One, it's an added expense. Two, even though it's computerized, we have never been able to solve the synchronization problem of keeping both vocabularies and the mapping of vocabularies updated in real time. Third is the fact that if mapping is required, that means that the terminologies you're using must have a different meaning, because if they were the same you wouldn't need to map; you'd use one signifier. So there is a loss of information. I think there's somewhere between a 10 and 20 percent loss of information in mapping from one terminology to another.
BJ: Is collaboration increasing, and will that help create a useable medical record?
EH: In the United States several groups work together loosely in an organization called the Healthcare Information Standards Board, and the overseer of that board is the American National Standards Institute. The NCPDP (National Council for Prescription Drug Programs) is fairly well restricted to the pharmacy in terms of prescription data and reimbursement for drugs. DICOM (Digital Imaging and Communications in Medicine) is the imaging standard; HL7 is the clinical messaging standard; and X12 is the transaction standard. There is an increasing amount of interaction between the standards organizations.
At the HL7 meeting, for example, you will find strong participation from IEEE (Institute of Electrical & Electronics Engineers) and from DICOM. There is some interaction between HL7 and X12. But that's a process that's been under way now for almost four years, and it's the kind of thing that one would think should take six months.
Having so many standards organizations does confuse the marketplace. I've got a matrix that takes most of the different kinds of standards and shows that most groups dabble in something that could be conceived as an overlap with other standards and thus creates some confusion. For example, ASTM (American Society for Testing and Materials) is working on document standards that are competitive with what HL7 is doing. DICOM is creating document standards as well. The good news is that DICOM and HL7 now have begun to work together and are moving some of the DICOM document standards into the framework of HL7.
I've begun to conceive of five standards categories. The first level of standards that you need are the kinds of things that are not health-specific, but are things like TCP/IP (Transmission Control Protocol/Internet Protocol) and XML (eXtensible Markup Language). These are communication standards that apply to a broad set of industries.
The second kind of standards have to do with the identification of data. One of the major problems we have is the fact that somebody can send us something, a data element, and we have no idea what it really is. The reason is that the data types are different; some places collect one kind of data, others collect another. We have no easy way of modeling complex data elements. As an example, as far as I know, there are no good standards for moving microbiology data around. It's a complicated structure with complicated coding. It's conditional. It depends on the nature of the results.
There's a whole family of standards that relate to defining and understanding data. For example, unstable angina probably has as many as 50 different kinds of definitions, and there clearly aren't 50 types of unstable angina. The same with essential hypertension — name almost anything and you'll see the same terminology confusion.
The third level is the messaging standard. Here again you get into the semantics of what those words mean. For many people, "messaging" is a precise HL7 standard. It's almost a symbol-delimited ASCII character string that's zipped from one place to the other. To me, the concept of messaging is that there is an exchange of data. It may be an Internet standard; it may be Web-based. But essentially, the standard is to move data from one place to the other place, in a controlled fashion, driven by trigger events and well-defined scenarios.
The fourth area is the electronic health record, and I think it's very fuzzy as to what kinds of standards are going to be required for the electronic health record. There are people who think that the internal architecture of the electronic health record should be standardized. I simply think that will never happen, because I think it is always going to be a proprietary function that the vendors are going to do their own way. There are some external architecture standards that I think need to exist.
The fifth area really has to do with things like decision support and clinical guidelines. Effectively, these are knowledge standards and representation and access to query. My views as to what is contained in support and guidelines continues to develop as I continue to think about and discuss it.
The standards that we've addressed thus far, have been the so-called messaging standards. There are still some pieces of the data standard — and certainly terminology is one — that we have yet to get our hands on.
BJ: What advice do you have for CXOs who are trying to build new clinical systems using innovative technologies and are grappling with data standards — where should they seek knowledge?
EH: I think they need to have a broad and general understanding of what standards are: What they do, what they cost, and how they are used. HL7 does tutorials, but most of those tutorials are aimed at people that already have some concept of what standards are about. The broader community is generally not aware that we've made reasonably good progress in the development of standards.
The vendors have for the most part adopted standards, but again there are issues that need to be addressed. The certification issue, in my opinion, is something that needs to be put into place now. The reason for certification is, in spite of the fact that most vendors support HL7, if you really look at what they do, it's not a perfect use of HL7. They cheat. They use the standard in a way that it was not intended for - to meet the need of a particular business application. That works pretty good for that instance, but when you move to another location, you can't use that data interchange, and you have to rewrite the program. You lose the reuse value.
The transition to standards is a very interesting one, because in HL7, for example, the community at large uses versions 2.1, 2.2, 2.3 and 2.4. Now version 2.5 is out. How you get everybody up-to-date is a question of economics, process, and tool sets. Hopefully we will begin to see an increase in the number of educational opportunities to instruct people in the use of standards.
If we're trying to stay current so we can continue to move all of this ahead, the real issue is who is going to pay for it? The user? The vendor? The government?
