Hubert H. Humphrey Building
Room 705A
200 Independence Avenue, SW
Washington, DC 20201Proceedings By:
CASET Associates, Ltd.
10201 Lee Highway Suite 160
Fairfax, VA 22030
(703) 352-0091
Jeffrey S. Blair, M.B.A., Co-chair
Simon P. Cohn, M.D., M.P.H, FACP, Co-Chair
Kathleen A. Frawley, J.D., M.S., RRA
Kathleen Fyffe, M.H.A.
Clement Joseph McDonald, M.D.
Staff:
J. Michael Fitzmaurice, Ph.D., Co-Lead Staff
Mel Greberman, M.D., M.P.H.
Stanley Griffith, M.D.
Col. Lynn Ray
James Scanlon
William Yasnoff, M.D., Ph.D.
Guest Speakers:
Gary Beatty, Mayo Foundation
George "Woody" Beeler, Jr., M.D., Mayo Foundation
Robert H. Dolin, M.D., Kaiser Permanente
Jack Harrington, Hewlett-Packard
Charles Meyer, McKesson/HBOC
Doug Pratt, SMS
Wes Rishel, Wes Rishel Consulting
Mark, J. Sharfarman, OACIS
Abdul-Malik Shakir, The Huntington Group
Rachael Sokolowski, Magnolia Technologies
Harold Solbrig, 3M Health Care
As is traditional, I wanted to begin the meeting with introductions.
[Introductions were made.]
Thank you all for being here. I think it will be a very interesting next day and a half.
The Health Insurance Portability and Accountability Act charges the secretary with adopting standards for specified administrative transaction and elements for such transactions, and supporting standards to enable health information to be exchanged electronically. The purpose is to improve the efficiency and effectiveness of the health care system by encouraging the establishment of standards and requirements for electronic transmission of certain health information.
Now HIPAA also directs the National Committee to assist and advise the secretary, and to study the issues related to adoption of uniform data standards for patient medical record information, and the electronic exchange of such information, and to report to the secretary not later than four years after the date of enactment of this legislation, recommendations and legislative proposals for such standards in electronic exchange.
This is really the focus of this next day and a half, to begin to discuss those issues. As a work group of the National Committee, this group has a responsibility for studying issues and preparing the committee report for August 2000. This is one of a series of hearings planned for this year to investigate the issues, and the way the federal government should play. Certainly, we expect this hearing will help provide direction to the committee in the preparation of the congressionally mandated report.
Jeff and I want to thank the testifiers. We know you have very busy schedules, and we want to thank everyone for coming. We hope that your words will be of help as the committee begins its task today.
The focus of today's hearing is on message format standards, and to elicit the facts and recommendation of standards developers and users in relationship to our task. Now before we begin the first, Jeff, do you want to make any comments?
So that you will notice that this morning is viewed as an educational session. This afternoon we will have other SDOs available, other vendors available. Then of course tomorrow we're going to be changing subjects and hitting the quality of data issue. So that's the only thing that I wanted to add. Simon, why don't you go ahead?
DR. COHN: Well, as Jeff commented, obviously this morning is focused on HL7. We want to thank you all for coming. This is really meant to be education, and so we're going to spend some time with you updating us on your thoughts and issues around HL7. Then we'll have a chance for a round table presentation.
With that, Woody Beeler, would you like to start out?
We each are prepared to accept questions in stream, if that's your want, but as well we anticipate a broader question and answer session in each of our pieces as gone forward.
The HL7 panel that is assembled today is interesting in part because it represents two-thirds of the HL7 cross-section, that is to say providers and consultants. Two of the four of us are each from large health care providers, and two who are consultants. On this afternoon's vendor panel you will also have people who are very active in HL7, who are on the vendor side, and that really completes the HL7 cross-section of membership.
The topics we would like to discuss today are indicated on the next handout. They go into first of all, the requirements for patient record information, and bit about what we mean by model-based interoperability standards. Following that, individual speakers will speak to the reference model, vocabularies, clinical templates, the patient record architecture, XML documents, messages, and the like.
Simultaneously, however, we are all cognizant of the questions that you posed in the call to this meeting, as it were, and I believe that each of us will speak in our own way to the questions that the committee posed. We will do so both obviously from our individual perspectives, wherever it is we are coming from, as the saying goes. But also we will attempt to reflect what we think the HL7 response is.
I couch that in qualified terms, because clearly it is difficult for any organization to have a formal answer to some of these questions. Indeed, you are probably better served looking at what HL7 is doing, to see how HL7 would respond to each of the questions you ask. In other words, what is the importance of models? I think the HL7 focus on models will tell you what the organizational response is to that. We will attempt today to provide the rationale for that position.
I would like to open up a bit with what is patient medical record information? My summary straightforwardly is that it is data about the events and findings that characterize an individual's health status and health care. The question of how detailed that is depends really upon the use. It might be fully specific, that is to say sufficient to take a role in a patient's health history, or it may be summarized data or aggregated with data from other individuals.
Where is it used? It depends on who we ask, obviously. It could be within an institution, which might be as small as an individual's office, moving up to a clinic, a hospital, or even a major medical center. It is also used across institutions in a single integrated health care system. This, I think, is becoming increasingly important as organization shift and move, as health care systems are formed, and in some cases as we hear of late, separating again.
The information certainly is used between systems for patient referral. Last but certainly not least, it is used at all levels, private agencies, local, state, and federal levels for the process of overseeing and managing patient care and the patient care process, as well as for monitoring public health.
So there is a full panoply of opportunities for patient medical information, and obviously each of those applications brings about its own requirements for the information itself.
What functions does it serve? In simple terms I take the position that any information that is managed, particularly information that is managed as actively as patient medical record information is probably there for decision making. I think this true regardless of what industry you are in. There are very few information repositories that people worry about where ultimately the goal of the information is not to make decisions. Even with your bank account the issue isn't how much money I have, but how what can I do with the money I have, and what decisions am I going to make?
So the fundamental requirement for patient medical record information must be decision making. Initially, clinical decision making and support of the care of the patient. That is the role of a CPR, computer-based patient record, or clinical repository.
Secondly, it is to facilitate the management or decision making about the health care process. To make an efficient health care system that we can offer to individuals. Finally, it supports decision support in the assessment and management of health care and of health maintenance services.
The question was posed in the meeting brochure is how comparable does the data need to be? I'm taking a strong, somewhat binary approach to this. I think some of my colleague may argue that there are more shades of this. My observation though is that any degradation in the comparability of this information threatens correct decision making. It doesn't make it impossible, but it certainly makes it harder, and the more the degradation occurs, the tougher the decision making gets. Incorrect decisions are at best wasteful, and at worst can be life threatening in health care.
The comparability of the data is only partially about precision and accuracy of the data. The real issue, as I think you'll hear from me and the rest of the group this morning, is the common semantic understanding of the information. If you don't know what it means, you can't compare it. Once you know what it means, then accuracy and precision come to bear, but only at that point.
Why then do we worry about data interchange standards? I would posit that it is impossible to carry out any of these decision making functions in any of the settings that I described without communicating data between disparate computer systems. This is not something peculiar to health care. This has to do as much with the dynamics of the information technology industry as it does with the dynamics and change of the health care industry.
The core issue then is interoperability. The definition that I have selected from the IEEE is that interoperability is, "the ability of two or more systems or components to exchange information and to use the information that has been exchanged." There are really two fundamentally distinct, not quite separate distinct actions in that.
The first is the ability to exchange the information, which I term functional interoperability. That is, the ability of two computer systems to function together. The second is the ability to use the exchanged information in an intelligent fashion. This we are terming semantic interoperability. I run the risk of anthropomorphizing of computers, but if the first is the ability of them to work together, the second is the ability of the computers to think together. The problem of interoperability is not solved unless you solve both functional and semantic interoperability issues.
Another premise underlying the standards process is that we, as an industry, in fact, most industries are dependent upon commercial software purchased and used by the health care provider. That is to say that there will be a disparate set of solutions simply because the buying decisions, the opportunities of the providers and practitioners differ, and therefore the systems they choose will differ.
Thus, the data environment that we are looking at finds data and software designs from the private sector trying to support independent clinical repositories within institutions, and within health care systems. In order for these systems to interoperate then, they must have a common understanding of a few core principles.
The first is of a data model. The second is of the data representation or vocabulary. Third is the notion of when to communicate. What is it that is going to cause them to communicate, to undertake communication? Fourth is security. Only after that do you begin to worry about the specific of how am I going to implement that in specific technologies and specific syntaxes.
Another observation about interoperability comes from the ISO TR9007 standard, which observes that "any meaningful exchange of utterances depends upon the prior existence of an agreed upon set of semantic and syntactic rules." It is both the semantic and the syntactic agreement that is necessary for good standards.
If you look at the communication problem, you may recall that a number of years ago the International Standards Organization, ISO, posed a seven layer model. The next slide that I have uses I think a five layer model, but it is fundamentally a similar set of concepts. At the base you must have a channel to carry the communications. These might be even documents, but if you are talking electronically, it's computer to computer, it's certainly network connections, satellite links, and the like.
The next level up are a set of services that manage that communication link on behalf of the computer applications. Things like TCP, Telnet, FTP sessions and the like.
Then there needs to be a syntax for the communication. This is where you get into questions such as ASN.1, HL7 syntax, XML, X12, interface definition languages and the like.
Layered upon that are the semantics of the communication. These are the things that convey the actual meaning of the message via a set of symbols or codes that are transferred. By the way, I should be crediting Harold Solbrig. That comes from a slide for a piece he did for a white paper that is being pulled together.
Within the semantics of communications you have three things you need to specify at minimum. Those are: the nouns -- you need to understand what it is you are talking about, what are the things you are communicating about; the adjectives or the descriptors and relationships between those nouns; and finally, the verbs -- what are the actions that you want to have take place, how do you want to affect them?
The HL7 specifications have, over time, tended to address the upper layers of this structure. It has focused on the semantics communication, a syntax for communication, and only later, more recently, specific services to accomplish the communication.
We believe in fact that that's the most effective place to devote the energies of an organization such as HL7, because it is at this layer that the difference between health care computing and general information technology is ratified. For the lower levels we can rely on the core technologies, but the other levels health needs to address the problem itself.
Let me speak a bit about HL7. It was founded about 12 years ago I guess now. In fact, I observed to someone we run the risk of becoming 13 year olds, and I don't know whether that's a safe thing to admit in public. If those of you who have children who are not yet 13 year olds, have a lot to learn. Those of you who are well past it, isn't it fun to have it behind us?
Anyway, we were founded by a group of health care providers and vendors in early 1987 specifically to develop and publish protocols specifications for application level communications. We set out to develop a prototype standard in 1987. In fact, Version 1 was done within 11 months. The first production standard occurred about a year later in 1988, and it's been followed by Versions 2.1 through 2.3.1, published in 1990 through -- well, actually 2.3.1 is actually about a month yet. It has been balloted. It has not yet been published.
We were accredited as a standards developing organization by ANSI in 1994, with the result of Versions 2.2 and the 2.3 standards are all "American national standards."
HL7 itself is a not-for-profit organization. We have 450 organizational members who bring to the table about 1,700 individual members, either people who are solo members, or participants from those organizations. As I indicated earlier, our membership is made up of providers, vendors, and consultants. We have been attracting on the order of 400 people to each of our working group meetings, which are held three times a year.
Of late, over the last three years we have set up the international affiliate organizations in seven countries; three in Europe, Canada, and three in the Pacific.
HL7 standards were always a problem to understand where they were used until last year when CHIME conducted a survey of CIOs of health care organizations, and reported that 80 percent said they used HL7; another 13.5 percent of those planned to implement in the near future. For the CIOs in the hospitals with over 400 beds, the penetration rate was in excess of 95 percent. Moreover, the standards portion of the 2.3 standards have been formally adopted at the federal level in Australia, and in several provinces in Canada.
Well, HL7 grew up in the Version 2 series, culminating in 2.3.1, but as you have heard in the past, and will hear more of today, we are definitely into Version 3. Why is that? What is different? Why is it important to us? Well, simply it is recognition of the change. The change that is occurring in health care. The change that is occurring in technology, and the need for the standards to remain abreast of them. If standards only ever followed the common practice of the day, and don't attempt to lead, they will always be behind times. With the information technology cycles we have today, that will only get worse.
HL7 2.x is widely used, as I indicated. It has broad functional coverage, and is based on an older messaging paradigm. It has managed to expand its use quite widely, in part because of it is highly adaptable. We provided a standard that had a great deal of optionality, a broad set of choices for users to take. We stayed away from the technology, so they could implement any technology they wanted.
Back 10 or 12 years ago there weren't very many good coding systems, we told them to go ahead and pick out whatever coding system you need. This meant that people were able to pick up the HL7 standard, tailor it and adapt it and implement it wherever they wanted, but each implementation is different. Each implementation made different decisions about which options to use, about which code sets to use, and that made it more difficult for them to go forward. They did the semantic analysis, but they did it independently, organization by organization.
What Version 3 attempts to do is step to up those issues prospectively, rather than retrospectively. We want to build Version 3 on a consensus, reference information model. We want to build Version 3 on agreed upon vocabularies and vocabulary terms. We want it to be adaptable to current and future information technologies.
We do want, as I indicated, vocabulary level interoperability, and an explicit performance model. We would like to be able to test whether or not the application really does HL7 messaging according to the specifications, not just according to what the vendor thinks it ought to do.
Finally, we want to build on a strongly accepted and increasingly capable set of industry-based technologies. We want to take advantage of some of the specification capabilities that those standards have.
So Version 3 then is a new form of standards. It is not only messaging standards, the things we have always done, it is also document standards, as Bob Dolin will talk about. It is component standards. It is medical logic representation standards, the Arden syntax.
But it is also a new way of developing standards within HL7. In effect, we have re-engineered ourselves to move forward. We found a new way to do our business, and I believe at this point, two plus years later, we can assert that it has been successful.
As a standard then, it is a communication framework that separates information content definition from transmission formats. It includes the patient record architecture to support sharing and reuse of documents. It facilitates the use of external coding systems and terminologies.
Later, Wes Rishel will talk a bit about a clinical template project to allow HL7 participants to define specific clinical content for exchange both with Version 2 and Version 3 messages. As I said, we have components for clinical work communications and for work station integration, and certainly for medical logic representation.
Version 3 as a process is a whole new approach for HL7 to develop these standards. It is model and repository-based, and I'll outline that in just a moment. It provides specific coupling of the events, things that happen in the health care world to not only the messages that flow, but the specific data elements, and the specific options for those data elements within the messages themselves.
It gives us increased detail, clarity, and precision of specification. It will give us finer granularity in the message, and thus facilitate interoperability and testing. It does have explicit inclusion of standard vocabularies and terminologies, something that Version 2 did not do.
Our Version 3 process involves four design phases, and then the application of those. The first analysis phase is the development of use case models, understanding what is the rationale for the purpose of the standard component we are specifying.
The second phase, and the one that has really been dominate in many ways is that of developing an information model; the reference information models we call it. Recognizing that HL7 works in committees, this is a distributed process that the organization then harmonizes, as Abdul-Malik Shakir will outline a bit later.
The third phase begins to be design, which is the interaction. Who is going to communicate what to whom, and for what purpose, and given what trigger event.
The fourth phase is a bit of a misnomer. It is called message design, but really what it is, is the assemblage of an information structure that supports a particular requirement. If you are doing clinical messaging, yes, it is a message structure. On the other hand, if you are doing other elements, it may be something else.
For example, it might be provide the variable definitions needed for curly brackets in the Arden syntax. Or it could be the basis for a document type definition if you are doing DTDs in SGML. As I said, certainly it will form the basis for message types if you are doing the more traditional HL7 messaging.
All of these models and all of these specifications will be captured in a single database or repository, which will allow us to manage this, being the environment, and to assure that each of the uses of the models indeed conforms to the models that have reported.
As I mentioned before, semantics are the core issue. I'd like to give you just a brief example of where the nouns, adjectives, and verbs of communication can fall apart. What does it mean when I say a patient's pending physician? Do you think I mean a single individual or all of the people involved in the case? Or if I send a patient identifier, am I talking about a social security number, a medical record number, a shared MPI number of some sort?
If I say that my action is dependent upon the end of the current episode, is this a period of time the patient undergoes care in a given day, the period they spend as an inpatient, or perhaps the period of time when the patient is diagnosed with the same health condition.
Needless to say, there are correct answers to this. There are probably as many correct answers to these questions as there are people in the room. When I posed this question on a list server recently, I got back at least half a dozen very forceful assured answers as to what the correct response was. Each was correct in their context.
The goal of HL7 with the information model is not to specify what your context should be, but to specify a common context so that you can understand how yours relates to the common one. Each organization can have its own independent information model, its own approach to understanding these issues, but they also need to understand a common mapping, and that's the role of the information model.
In the vocabulary world, Stan Huff uses this example, and I am not the scientist in this area that he is, but fundamentally this is an example of three messages with the same code values, ABO Group and Type O, being reported for three different observations. The problem is that they don't mean the same thing. They are the same code values, but in one case it is simply a type applied within a typing test. The second it is a blood type, and finally is a ABO type, including the notion of OPOS.
So if you don't understand which vocabularies you are working with, if you don't understand the terms you picking with, the code values do you precious little good. We might be able to interpret these given some of the clues that are in the names, but it's unlikely that our computers could do so.
Thus, what HL7 is about is common semantic models, whether it is a reference information model or a vocabulary. The key is to build these things on domain expertise. Drawing upon the expertise that HL7 can attract in its committees or with its collaborators, the vocabulary developers that the professional societies bring in build a strong set of common semantic understanding, and only then apply it to the challenges of messaging, document structures, clinical template, Arden syntax, and the like.
I'm going to flip to the next slide. I'm going to summarize this quickly here, but I think these are points we would like to go back over with you at the end as well. The real challenge in standards is expertise. There are experts out there who can help you specify a standard, and they are willing to participate. It takes time to do so.
There is very little that one can do to speed up that process, because these folks, by and large, are out there doing it. They are the ones who are faced with the reality of informatics day in and day out. They are health care practitioners, they are software developers. They come from vendors and health care consultants. They are there, and they are willing to help.
HL7 has, I believe, demonstrated a strong and I think reassuring ability to attract the expertise, to get the folks to a meeting, to get them engaged, to get them excited about the process. Logistics are a problem. They are the not very hidden cost of standards. It has to do with the core issues of facilitating meetings, documenting what is done, including models, publishing these things, coordinating meetings, and so forth.
Later on Abdul-Malik I believe will talk about our RIM harmonization process. This is a process that HL7 felt was very important to the success of its Version 3 standards. It's so important that we have invested on the order of $100,000 a year for each of the last three years in RIM harmonization. By and large, this is money that has come from our reserves.
I think it's reasonable for HL7 to have done to kick start Version 3, but obviously the reserves are finite, and this is a challenge that we face going forward, and I think that any attempt to coordinate and collaborate on vocabulary models and the like must step up to. I submit that it's less the issue of getting the expert there, than in helping the expert get there, and supporting them when they are together.
The question of what might the government do? My simple response is be supportive and not directive. The marketplace will always be the most effective director, and there are numerous examples in the past of where governments both nationally and internationally have attempted to mandate standards that have gone nowhere.
I believe that there are opportunities to provide support through the standards developers for development and collaboration in models, development and maintenance of a vocabulary mapping, the collection and publication of vocabularies and terminology mapping.
I think the government should avoid the temptation to focus on the current "hot" technology. These things are changing must faster than any of us can track them. Attempting to pin a particular health care approach on a particular set of technologies does not make sense. It makes much more sense to establish a foundation for semantic interoperability, make sure that that is in place and durable, and then let the surrounding technology change as it will, and certainly it will.
That's the end of my piece. I remind you to continue to remember Isaac Asimov's challenge which is that, "No sensible decision today can be made without taking into account not only the world as it is, but the world as it will be." I believe that what HL7 is attempting to do is to define the core requirements of health care so that we can deal with the world as it will be, however it will be.
Thank you.
DR. COHN: Woody, thank you very much. I appreciate it. We'll I guess have questions after we have had all of the presentations.
Our next speaker is Abdul-Malik Shakir, formerly of Kaiser Permanente, and now with the Huntington Group.
[Brief recess due to technical difficulties.]
But these are the questions I have been asked to address:
So I have spent a lot of time trying to get information out of systems, and from one system to another system, and faced those challenges. So that's the perspective that I come from. Being the co-chair in HL7's Model and Methodology Technical Committee, I am very focused on the modeling activity. In that committee I focus on the methodology. How it is it that we go about building the model.
As a board member, I focus on the Organization Relation Subcommittee. In that committee what we try to do is build relationships between HL7 and other standard setting bodies. I was former co-chair of X12 Business and Information Modeling, and I was formerly the information administrator at Kaiser Permanente.
I like collaboration, and I believe that models help in that collaboration. So much of what I will say today is focused on the collaborative nature of modeling. Some of it will be purely from the HL7 perspective, but most of it is generally applied.
I would like to make assertions, and I make five of them. Rather than read them here, I'll go over them one by one with some diagrams that I think tries to illustrate them. The first one is that models can help improve communication. It helps improve communication by allowing us to express ourselves in an unambiguous way.
I have two talking heads here. One says, "Do you football?" He is thinking American football. The other person answers, "Yes, I do play football," but he's thinking what most Americans would have called soccer. So these people are exchanging words, but they are attaching different meanings to the words. So the communication is not that effective, because they are not explicitly stating what their assumptions are.
Information modeling is a language. It actually allows you to express yourself in an unambiguous way so that your understanding and your assumptions about the information you are about to exchange is clear and up front. It doesn't mean that you necessarily agree with the person who may have a different model.
The information models allow us to identify where there may be conflicts in our understandings. Because we both expressed our understanding in an unambiguous way, we now have in front of us evidence about differences in our understanding, and now can begin the discussions to reconcile those differences.
Information models also provide a facility for identifying gaps that each of us may have in our understanding. It's my contention that no one has the complete view of a health care information domain; not HL7, not X12, not Kaiser Permanente, not the Department of Defense, not even the collection in this room, although there is well represented knowledge about health care. We need a process for gaining understanding from everyone who is affected, and reconciling the differences and gaps that may exist in those understandings.
Now how does this fit into HL7? HL7 has developed a reference information model. This model is used to expect the information content for the collective work of the HL7 working group. Essentially, the entire contents of the model is developed by the HL7 technical committees. The technical committees look at the models as they are developing, going through their message development cycle, and identify where there are data that needs to be exchanged in messages, and assess whether that data is already represented in the HL7 information model. And whether it is represented in a way that they wish to convey their understanding.
Through a collaborative process that we refer to as harmonization, the committees come together and debate and reconcile the differences in their understanding until we have a complete, coherent, shared view represented in the information model. The HL7 international affiliates have a voter representation in that harmonization process, so not only HL7-US, but HL7-International also participates in that harmonization activity.
HL7 also has a formal process for recognizing contributions to the model that are suggested externally, particularly those suggested by ANSI accreditated standard setting organizations. We have had relationships with X12, with NCPDP, with DICOM, welcoming them to contribute content to the model, and have a process for them to do so.
The next slide shows what model harmonization is about. In the bottom of the diagram there are three separate information models, each of which we refer to as domain information models. So within one domain the model has decided that there are three concepts, A, B, and C. In the second domain the model has decided there are three concepts, B, C, and X.
We go through a harmonization process where we bring the views together, reconcile their differences, and come up with yet a combined view. This combined view is often different than any of the submissions, but draws its content entirely from its submissions. It is possible to map from the ending model, back to the original submissions.
With this model harmonization, it allows each of the technical committees to have their view for their domain of space, and yet have the shared view that shows the entire picture of HL7. Those domain information models can come from HL7 technical committees. Again, they can be submitted as changes from our international sets, or from ANSI accredits SDOs.
What models exist? There are many. There are business and information models that are maintained by ANSI accredited SDOs. I know HL7 has one. I know X12 has one. There are other SDOs that I know were about to create information models. I don't know where they are on those, but HL7 and X12 have been communicating to one another on their modeling activities for quite some time now.
There are business and information models that are maintained by international standard setting bodies, CEN and EDIFACT. There are business and information models maintained by national health organizations, Canada and Australia. Business and information models are maintained by large health care concerns like Kaiser Permanente and the Department of Defense.
Business and information models are also maintained by large health care software vendors, IDX and HBOC and others. And there is a whole collection of undocumented business information models within the head of health care stakeholders, you, me, and others. So models exist; several of them.
How do models help the PMRI? I think my soap box is already pointed to where I think they help. They improve communication. The sharing of models helps us to identify and reconcile differences in our understanding, gaps in our understanding, and overlaps.
I think the main purpose that models serve, however, is in my last point. It allows disparate organizations to collaborate on the documentation of the PMRI, while ignoring syntax and technology implications. The models are independent of any syntax you are going to be using for conveying information from one system to another. It's also completely independent of any technologies that might be used. So it's the perfect form for collaboration and facilitates that collaboration.
Are there any impediments? Certainly there are. One is that some organizations view their business and information models as proprietary and competitive, and are unwilling to share them. So there are some views that organizations have that they are unwilling to share, so that we can reconcile those differences.
The information models must be coordinated with the vocabulary domain, and have linkages to activities and behavior models. An information model on its own does not provide all the semantic richness. One must also develop vocabularies, and link those vocabularies to the information model. They are separate endeavors, but very well interlaced.
It's also important that the model be attached to behavior models so that you understand the events that to the exchange of information, and the state transitions that the classes in the model might undergo.
Proven support for harmonization of multiple large models is very limited. In fact, HL7 has had to take it upon itself to build much of the tooling necessary to do its harmonization.
Some aspects of the model need to be adjusted to accommodate local variations. There are always local variants, cultural, legal, and historical differences that exist. While I may call it an elevator, someone else will call it a lift, depending on where they are from. We need to recognize that those are two of the same things, it's only the locale that is making a difference.
There are a few vendors, and even fewer standard development organizations using a model-driven approach to developing their products. Although there are many organizations that create information models, and use it as a means for documenting their understanding, there are very few who actually have incorporated the model into the development process.
HL7's Version 3 cannot go forward without the modeling. It is integral to the development effort. The modeling effort within X12 has been more in the form of documentation. It has helped to create consistency within the implementation guides and such, but it is not integral to the actual development of the transaction.
There are vendors that also have information models that they market, but don't incorporate those models into their very products. So we need for models to begin to be actually used in the development of products.
The ability to make cross-references between distinct models is very difficult. As the models change, the cross-references between them change. It is costly to maintain those cross-references.
The cost associated with harmonizing multiple views into a single comprehensive reference model is very high. As Woody says, HL7 has been spending to the tune of $100,000 a year for the last three years doing that very thing, and probably could have spent more, if it only had it.
Can the private sector overcome the impediments? I chose to answer this question by giving examples of things that are happening in the private sector, that are attempting to get over these. As far as overcoming the objection of a model being proprietary or a competitive advantage, the HL7 developed a process where organizations were able to contribute their models as seeds to the HL7 RIM, and still protect their anonymity and their intellectual property.
The models were viewed by a very small audience, an audience of one. No record was kept of what portions of that model ended up in that RIM, and there is no traceability from the RIM back to those source models. So there anonymity and intellectual property is maintained.
There are many who chose to have their name shared, so we know that there were some 12 or 13 different organizations who contributed their models, and they were given recognition for them. But no one can trace the contents of the RIM back to those sources.
HL7 has also integrated modeling with vocabulary development. It has made modeling an integral part of its message development methodology. So within HL7 modeling is part of the development, and modeling is incorporated with the work that HL7 is doing on vocabulary. The two are inseparable.
Data and information model tools are beginning to address the issues of multiple models. With the advent of UML as a de facto standard for object modeling, many of the tool vendors are now beginning to adopt that specification. Also IDEF(?) being adopted as an ANSI standard for modeling. There are many tool vendors that are going there. So the variations in modeling languages is beginning to sink around either UML or IDEF, and as a result, the tool vendors are now able to provide some support for harmonization.
Meta-data repositories and data transformation tools I think will play a role. As I work in the data warehousing area, I find these tools are being very useful as far as maintaining the cross-references between source systems and target databases. I think they may be useful tools for maintaining cross-references between models as well.
HL7 has taken upon itself to build an elaborate set of model management tools to support harmonization. Hopefully, there will be tools available on the shelf that we can acquire, because our toolsmith has a hard time keeping up with all of the requirements for changes. Especially when he is also the chair of HL7.
The funding to support the administrative cost associated with harmonization is limited. HL7's ability to maintain its current level of support of harmonization cannot be sustained indefinitely. So these are some of the things the private sector has done to try overcome the impediments I have identified.
So what role should the federal government play? One is to participate in model harmonization efforts sponsored by SDOs like HL7 and X12. I know that we have had the Health Care Financing Administration working with both X12 and HL7 to develop the claims attachment specifications. We have had the Department of Defense working with both X12 and HL7 to help in their modeling effort.
If the federal government can continue to endorse this method of developing standards by participation, it will encourage others to participate as well. So encourage the private sector to participate by adopting these standards as part of the standards that you use in federal agencies, and participate in the development of these standards yourself.
The third thing is to provide funding to SDOs to offset the cost of the administrative and technology infrastructure required to maintain the model. As I indicated, the HL7 cannot continue to do this. HL7 I think is really the only SDO currently who has this harmonization process that is open, and allows contributions from outside of its organization. The cost of doing that is just prohibitive, so some assistance there would help.
I would have to agree with Woody. I would say do not legislate the adoption of a single business or information model. If you say one must use this one, even the HL7 RIM, as great as it is, if you say that's the one to use, then you essentially close the discussion and freeze it in time. The model has to evolve over time.
I do think there is value in having a single reference model that others models can then be cross-referenced to. We can identify the mapping from the nomenclature used in a model to the standard model. But to force everyone to use the "one" model, I think would be the wrong way to go. I do believe that it would be good to have a single reference model that everyone maps their models to.
Do establish guidelines that govern the development of the models that are developed by especially accredited standards setting bodies to insure that there is a public consensus process involved. Everyone must have an opportunity to have their expressions viewed, and contribute to the contents of the model.
My closing comments. HL7 continues to demonstrate that it is committed to progress toward the achievement of interoperability in health care information systems. It is developing its standards through an open consensus process. The HL7 RIM is gaining attention in international efforts, and in efforts of other standard setting bodies. HL7 has ongoing collaborations with X12, with CEN, with CORBAmed and other standard setting bodies.
The strength of the HL7 RIM is in its harmonization process, its linkage for defining vocabulary domains, and its use as a foundation for all HL7 messaging standards.
Any questions?
DR. COHN: I think we'll hold --
DR. YASNOFF: We only have a few minutes to the break. I have some specific questions about models. There was mention earlier in my last project, which deals with you might call it harmonization of vocabularies, although Leslie is not here to comment on that. Is there a need for a similar government sponsored project that involves extramural research to deal with this issue of harmonization of models? Is it a research question?
MR. SHAKIR: I take it that question was directed at me, but I'm hoping I'll get support from any of the other panelists.
DR. YASNOFF: Yes, it was.
MR. SHAKIR: I believe that the vocabulary harmonization similar to the information model harmonization again needs to be done by the experts in those areas. As Woody indicated, we have very little difficulty in getting the expertise gathered together, but the funding to support the administration is the area where we need help.
DR. YASNOFF: That's why I'm asking the question, because in UMLS project, the vast majority of that work has been in the private sector, but it has been funded and coordinated through the National Library of Medicine. So we have had informatics experts from all over working on these very, very difficult vocabulary coordination and mapping issues.
So essentially I'm wondering if -- and although it has been funded, I think they have spent about $20 million over a decade. It hasn't been a huge amount of money, but it has obviously produced some very nice work. So what I'm wondering is, this work is essentially being done on a volunteer basis, catch as catch can. Is there a need for a government program of extramural research to deal with these issues?
MR. RISHEL: Hi, I'm Wes Rishel. I'll be speaking later. I'd like to give an opinion with respect to that question. I don't think that modeling as an art or a science is in the same place that vocabulary was ten years ago. I think the work they are doing now is informed by the UMLS and wouldn't have been conceived without the basic research that was done.
But I believe that we are now at a stage where it is more practical applications as opposed to just fundamental science that needs to happen in order to reach a higher degree of standardization and a finer grain standard.
DR. BEELER: I was going to address it from a slightly different direction. In the UMLS you are dealing with thousands, if not millions of individual code entities that need to be linked or related to each other. In the information modeling field you are dealing with fractions of that, and therefore things that are probably less distinctly defined.
For example, the reference information model that HL7 has today includes on the order of 125 classes, and roughly three and a half times that many attributes -- four and a half times if you count associations. So we are talking about a beast with 1,500 pieces, as opposed to 150,000 or more in the coding.
Why is that different? First of all, it is within the realm of possibility to capture those mappings in a manual fashion and mentally, as opposed to automatically, which certainly was necessary in the instance of the UMLS. Secondly, as I indicated, the concepts being mapped are proportionately more abstract. That is to say, two coded elements either may be identical, or one may be a subset of the other. You can establish fairly firm relationships.
When you deal with two classes in an information model -- sorry, a single concept being represented and two information models, the distinction between whether entity in model A and entity in model B are the same is not as concrete, and frequently involves a verbal argument about other things within the model that aren't as tightly semantically bound as vocabularies are.
I am chagrined that I hadn't thought of the question, because it's an obvious analogy that I think we ought to also go back and ponder in our harmonization meetings. That is to say, to phrase it another way, if we were asked to specify a repository of model harmonizations, what would it look like? What would it have to do? What would it have to require?
There are in fact instances in the marketplace, there are three or four commercial products. Mayo in fact uses one of those two application data models together. By and large, they are quite good at capturing individual sets of data models. They can pull them from COBOL. They can pull them from object-oriented programming. But the challenge of doing the cost linking, the actual saying this entity over here is the same as that COBOL record over there is done by people, and done by hand.
So the tooling is something equivalent to the Metasaura(?) software, is actually commercially available, but no one has yet stepped up to the question of is this something we want to across standards. It's a good question. Maybe we're hesitating because of some sense of immaturity, as Wes suggested.
DR. DOLIN: Can I take a crack at answering that as well?
MR. BLAIR: Can I just mention that this is a very valid issue, and there will be opportunities to address this a little bit more. In May, we have two days scheduled to cover medical terminologies and the coordination of those terminologies in information models with respect to medical terminologies and vocabularies. So there will be additional opportunities.
DR. DOLIN: Bob Dolin. I just wanted to distinguish between what the UMLS is doing and what the RIM harmonization process is doing. The UMLS is mapping terminologies. They are not actually creating their own terminology. Versus the RIM harmonization process; they don't just map, they actually create their own model, which harmonizes all the other models.
In direct answer to your question, should the government step up to the plate and do this? I personally think that the process that HL7 has established has become pretty much of a well oiled machine. They have an excellent process in place for the harmonization. I guess I wouldn't see the government recreating a process. Rather, I would see the government supporting the work going on within HL7.
DR. COHN: Clem, one quick question, and then we'll take a break after that.
DR. MC DONALD: It's a short comment. I'm not sure what the question you were asking was about. General harmonization of the models across standards, I just want to point out that that may not be either required or wanted, because something they are very, very different, and they aren't about the same thing, versus the specific harmonization in HL7. I wasn't sure what you were referring to.
DR. YASNOFF: I'm trying to clarify. There were a couple of comments about the government supporting the work that is going on. One of the ways that could happen is with an extramural program like UMLS. So that's what I'm getting at with the question. Of course the other obvious follow-up is that once these models exist, where is the repository going to be? How is it going to be maintained, and so on?
DR. COHN: I want to ask you to hold that thought for when we start having open discussions. Certainly I think we are seeing that there are differences between the terminology issues and the information model issues, though they all relate. I think that after we have heard from Dr. Dolin and Wes Rishel, we will hopefully be able to have an open discussion about how all this plays out potentially, at least from the standards developers' view, and where the government may be able to help.
Now, Bob, how long is your presentation? I'm presuming it's 15-20 minutes long?
DR. DOLIN: Twenty to 25.
DR. COHN: Why don't we at this point just take about a 10 minute break then, since we are almost at break time. We'll reconvene in 10 minutes, and we'll start off with you.
[Brief recess.]
DR. COHN: Can I ask everyone to be seated for the second half of our panel presentation. I want to welcome those who are on the Internet to our meeting today. I know we were unable to get it on the Internet for the first while, so welcome. We're halfway through with the first set of panel presentations. We so far have heard from Woody Beeler from the Mayo Foundation and chair of HL7, and Abdul-Malik Shakir from the Huntington Group and on the executive committee of HL7.
With that, Bob Dolin from Kaiser Permanente, and also from HL7.
I'm Bob Dolin. I'm a physician at Kaiser Permanente, where I work in the department of internal medicine, and the National Clinical Information Systems. My responsibilities with Kaiser include to provide patient care, the National Medical Terminology Project, the National Clinical Intranet, HL7 and Kaiser Permanente XML activities, and the National Electronic Health Record.
The topic I was asked to address is XML technology in HL7's patient medical record information exchanges. I just want to point out the disclaimer on the slide is XML activities have not yet been subjected to HL7's formal ballot process. So I'm going to try to give you a state-of-the-art, current, up-to-date information on XML. So the XML is in various stages of draft proposal development in HL7.
You will see this same outline slide throughout the presentation, and in your packet relevant reference articles are listed on these slides. Also, some of the reference articles are also provided. They are on the table over there. We published three articles over the last year, which are relevant to the topic we have been asked to address.
So no talk on XML would be complete without trying to tell you what it is in the next three or four minutes. Basically, XML embeds tags in documents, and these tags tell a computer how to process the document. I wanted to distinguish between SGML, HTML, and XML, because this is a common source of confusion.
SGML is user-defined tags. The user can be a person, or it can be a national standards group. Those tags apply to a class of documents. So a user creates a set of tags. Then you can 10, 100, 1 million documents that all use those same tags.
HTML is a fixed set of tags. In this case, the user is the World Wide Web consortium. They came up with a specific, fixed set of tags. They used the rules of SGML to define those tags, and now you will see that all of the HTML documents on the World Wide Web use the HTML set of tags developed by the W3C.
XML, like SGML, is for user-defined tags that apply to a class of documents. It's a formal, simpler subset of SGML.
The next few slides provide some further clarification of the difference between HTML, SGML, and XML. HTML uses the rules of SGML to create a fixed set of tags. What you see here on the left is an HTML document. On the right you see how that document would be displayed in a typical Web browser.
Tags, such as the <b> here, and the closing </b> over here tell the Web browser to display the text in between those tags in bold. So the tags again, tell the computer that understands those tags, how to process the information.
I say that HTML is SGML, and I said that XML is a subset of SGML. So HTML is SGML, but it's not actually XML. One example is that for instance here at the end a paragraph, we don't see a closing tag, a closing p tag. That is legal in SGML. That's not legal in XML. So there are some subtle differences between SGML and XML.
In XML you can define your own tags. This is the same information from the previous report, but in this case these are now user-defined tags. In this case, the tag names here are meaningful to the user that created them. So you might say that these are more semantically meaningful tags, rather than the format-based tags that you will typically encounter with HTML. So here for name, rather than seeing this surrounded by a bold tag, you will actually see it surrounded by a tag called "Name."
With XML you can define your own tags, and you can define the legal arrangement of those tags within a document. The declaration of the tags and the legal arrangement of those tags within a document is placed into a separate document called a DTD, a document type declaration. So what you see in blue in the upper right here would be you consider it one physical file stored on your computer. This is a DTD. It's the document type declaration that specifies all the tags that are allowed in this radiology report, and any other radiology report based on this DTD.
So for instance, you will see here that the radiology report tag can contain a patient info tag, a clinical data tag, et cetera. The patient info tag can contain a name tag, a medical record number tag, a date of birth tag. These tags properly nest. In other words, the name tag can only occur between the opening and closing patient information tag. The name tag can't just appear anywhere within the document. So the DTD says these are the legal tags, and these are the legal arrangement of those tags within the document.
What does that do for you? As a result of that, XML generates computer-processable documents. An XML processor converts an XML document into a computer-processable object. Tags within an XML document proper nest, resulting in a hierarchical document structure.
Tags aren't allowed just anywhere within a document. A DTD represents a formal grammar that states exactly where tags can occur, and which tags nest under which other tags. In many ways this turns an XML document into a chunk of computer code, which can be validated before it is compiled. Formally stated, XML reduces a document or a message to a word in a known context-free grammar through a process of makeup.
As a result, a computer can validate that an XML document conforms to the declarations stated in the corresponding DTD. So if you send someone a document and they have the DTD, they can validate the document against that DTD. Also, in authoring a document, you can check to make sure it conforms to the DTD. So that's the technical introduction to XML.
A little of the history of how XML became introduced into HL7. Back in 1986, SGML was adopted as an ISO standard. In 1996, the original vision and charter for the deployment of SGML in health care was developed by John Mattison and John Spinosa. Later that year, HL7 presidents Ed Hammond and Woody Beeler strongly supported the inclusion of SGML and XML activities within HL7, and the HL7 SGML Special Interest Group was formed.
This group is currently co-chaired by John Mattison, Rachael Sokolowski, Paul Biron, and Liora Alschuler. The objectives of the group are to coordinate the development of a comprehensive document architecture for health care; educate the health care community in the capabilities and utility of SGML and XML; and investigate the use of SGML and XML as a messaging syntax.
In February 1998, XML was approved by the World Wide Web consortium, and at that time the HL7 SGML Special Interest Group was renamed the HL7 SGML/XML Special Interest Group.
I'm going to turn now to some of the XML health care applications. While medical publishing isn't per se an HL7 activity, I'm going to briefly touch on it, because it's going to become relevant again when we talk about clinical documents. A lot of what we are doing with clinical documents stems from the benefits of XML when used for medical publishing. So a couple of slides on medical publishing.
SGML has a long history of use in the publishing domain, including SGML-based publishing standards used by the DOD, SEC, and Library of Congress. XML will carry on and expand the tradition.
The "what" section here shows some examples of where XML is currently used in medical publishing and includes: textbooks, journal articles, clinical guidelines, and as an example, the AHCPR clinical practice guidelines on NLM's h-stat(?) Website are currently SGML encoded, and pharmacy and lab manuals.
The next section of why would you want to use XML for medical publishing. Bullet one is rapid widespread deployment. The point there is that XML is readily converted into HTML, and can be readily deployed over the Internet. The browsers that we have available now actually enable you to display XML documents directly with the use of a style sheet without the need for conversion into HTML.
Next, with XML you achieve consistency in content and presentation. This is because all of the documents in a class are based on the same DTD, so therefore they all could be validated to conform to that DTD. So they must have consistency in their content.
Consistency in presentation comes about because a single transformation engine applied to the DTD can then convert any XML document into HTML representation. So the conversion of every single document in that class into HTML guarantees the same look and feel for every document in that class that is based on that same DTD.
Enhanced search performance comes about because you enable field searching, similar to what you have available with Medline searching. You enable context-specific searching. So for instance, if I have a tag in my guideline that says this is the recommendation section, I can now qualify my search to search for aspirin, where it occurs in the recommendation section, rather than simply searching for aspirin as a free text throughout the entire document.
Finally, XML is an application-independent persistent format. Therefore, the same XML encoded data can be manipulated with many different applications and application versions.
This is one example of how we have used XML to publish our internal clinical practice guidelines. What we have done here is design a clinical practice guideline DTD, and from that DTD we create an authoring template. In this case, the tags on our DTD are derived from the double and core meta-data, and the medical core medical data. It turns out there is a nice description of this in JAMIA this month. Our clinical practice guidelines are largely derived from that work.
We then use a commercial off-the-shelf wordprocessing program to take advantage of the user-friendly data entry features and create a template, which is then converted into XML, and then transformed into HTML for deployment over the Web.
Next, I want to turn to XML and its role in messaging within HL7. To start off, I want to give my definitions of what I mean by data exchange and transfer syntax. Data exchange to me is the unambiguous standards-based transfer of data between applications. So for instance, a lab over here figures out what it is they want to say. They map it into a standard information model and a standard vocabulary, and then they send it across the wire using the transfer syntax.
The transfer syntax is the explicit expression of the sender's semantics in a format that can be understood by the receiver. So the lab figures out what it wants to say based on the information model in the vocabulary. Then it's got to put it into some type of syntax that it can actually send across the wire. That's the role of XML in HL7. It's the transfer syntax.
This slide shows the history of XML for HL7 messages. In 1993, the European Committee for Standardization, also known as CEN, issued a report called, "The Investigation of Syntaxes for Existing Interchange Formats to be Used in Health Care," where they studied ASN.1, ASTM, E1238, EDIFACT, EUCLIDES, and ODA. Based on example scenarios, general message requirements are determined, and then each syntax is examined to see which of the general requirements can be fulfilled.
The metrics that were studied in the CEN report include: supported information structures such as optionality, repetition and recursion; supported data types such as coded, binary, and character sets; encoding, including going into and out of the transfer syntax; evolution and backwards compatibility; conformance; and support and availability.
In 1997, we extended the CEN report using their same scenarios and evaluation criteria to include SGML. We found that SGML compares favorably with the other syntaxes studied by CEN. Now the metrics weren't weighted, so there was no way to declare a winner. The best we can say is that SGML compares favorably. No syntax explicitly represents all functional requirements that were identified.
In 1999, last month, Wes Rishel coordinated a 10-vendor HL7-XML interoperability demonstration. All the vendors that participated rated the demonstration a success, which just helps firmly entrench XML as a transfer syntax for HL7.
This illustration shows a standard encoded and XML-encoded HL7 Version 2.3 results message. In the upper right is the typical modern day HL7 message. That same message expressed in XML is shown down below. The most common response to this figure is on the apparent message link increase with XML.
There are many ways to map HL7 into XML syntax. Various metrics can be employed to help determine the optimal XML representation. Some metrics are fairly straightforward to quantify, such as message links, which others are more qualitative, such as ease of implementation and maintenance, and the value to making the message more human-readable.
There is a risk that the easily quantifiable measurements will assume significance out of proportion to the other metrics. All relevant metrics must be factored together in a determination of the optimal XML representation. The optimal XML message representation will be a balance of functional, technical, and practical requirements.
This slide summarizes the findings to date on using XML as a transfer syntax for HL7 messages. XML can serve as a transfer syntax for HL7 Version 2.3 and Version 3 messages. XML messages will be longer than today's HL7 messages. Within Version 2.3 there may be a 2:1 increase in size going from the usual encoding to an XML-based encoding. Because Version 3 adds additional message features not present in Version 2.3, the migration from 2.3 to 3, coupled with the introduction of XML syntax may result in a 10:1 or more size increase. This seems to be an issue, and it's going to be re-evaluated by HL7. There are a number of ways to make XML-encoded messages smaller.
The ability to express an HL7 rule in an XML DTD confers the ability to validate that rule with an XML processor. Not all HL7 requirements can be validated by an XML processor. The validation of these HL7 business rules who will rely on further message processing by another application.
That is illustrated in the bottom right, where you see on circle. This isn't the scale, although I think it is qualitatively somewhat the scale. One circle on the outside represents HL7 conformance. The inner circle represents those HL7 rules that can be validated by today's XML processors. The work going on in the W3C extending the syntax of XML will make that inner circle larger, occupying a larger percentage of the outer circle.
Mapping HL7 into XML uncovered areas of ambiguity with the HL7 standard, and again, the optimal message representation is going to be a balance of functional, technical, and practical requirements.
The status is that an XML-based syntax for Version 2.3 messages is being developed as an informative document. An HL7 informative document does not affect the standard, but is balloted. While Version 2.3 does have a default syntax, the HL7 standard is syntax-independent. The purpose of the informative document will be to describe the HL7 version of 2.3 XML representations in detail. The XML style being developed for Version 2.3 is similar to that being proposed for Version 3. Based on experience to date, HL7 plans on using XML as a transfer syntax for HL7 Version 3 messages.
Next, I'd like to turn to the role of XML for clinical documents within HL7. If you consider all the benefits of XML for medical publishing, along with the functional requirements required for unambiguous messaging, you are also describing some of the potential benefits of using XML for clinical documents within HL7.
In particular, XML is used in medical publishing to achieve rapid widespread deployment, consistency in content and presentation, enhanced search performance, and application independence. Unambiguous messaging requires that data exchange be based on shared information and vocabulary models. All of these are objectives for clinical documents.
Well, health care is document-centric. Considerable clinical content is contained in narrative notes, which are created on systems of widely varying characteristics. It is difficult to store and/or exchange documents with retention of computer-processable semantics over both time and distance.
Capturing some of the semantics of clinical narratives for computer processing is better than capturing none; capturing more of the semantics is better than capturing less; and if you know something and you don't record it, you've lost it. The HL7 Document Patient Record Architecture proposes a common data architecture that can accommodate a diverse set of records and requirements.
I think if I had to sum up the whole talk in one line, this would be it. XML provides a syntax for HL7 semantics. XML tags have no predefined semantic meaning. Interoperability requires a shared semantics. Document processing is determined by an application that understands the meaning of the tags.
HL7 patient record architecture XML tags will derive their meaning from the HL7 reference information mode, as do all HL7 Version 3 messages. A shared information model is central to the patient record architecture.
HL7 messages are also based on the RIM, and this will enable the interplay of PRA documents and HL7 messages. Such interplay may include deriving an order message from the Plan section of a document, importing a lab result into the lab result into the Results section of a document, and the ability to send documents as messages, and communicate with systems design for message storage, indexing, and retrieval.
HL7 PRA documents also provide for a standardized way of referencing external vocabularies.
Again, this slide is just meant to further clarify the distinction between the syntax and the semantics by asking what's in a name. Here you see two documents, one on the right, one on the left, both of which are XML encoded, but they use different tag names to mean the same thing. The point I'm trying to make is that if everyone uses XML to represent documents, but there is no central model upon which these tag names can be interpreted, then many of the benefits of XML will not be realized.
The HL7 patient record architecture is harmonized with the HL7 reference information model. This may be more detail than people are interested in at this point, but this shows exactly how, within a DTD, that we provide a direct mapping to the RIM. So for instance down here in the document you will see we have tag <DOB>. Between those tags you see is this number 19000513. What does that mean?
Well, we know that DOB represents the RIM attribute person-birth date-time. So now okay, great, we know the DOB represents the attribute birth date-time for the person object in the HL7 RIM. We also know that the HL7 data type for date of birth is an HL7 time stamp. Now we know that this is year, year, year, year, month, month, day, day. So now we know exactly what the information between these tags means.
We also know for the value of sex that male is drawn from an enumerated value that is provided by HL7. In HL7 table 0001. So not only do we know that the value is male, but we know that it was drawn from a closed list of enumerated values.
The HL7 patient record architecture also provides a common mechanism for referencing standard terminologies. I want to point out that HL7 doesn't support SNOMED. I'm using this as an example of referencing any external vocabulary. We have within the PRA documents -- it doesn't not support SNOMED. It doesn't require SNOMED.
We have a tag called healthcare.code, which is patterned after the HL7 coded element, where you can specify the identifier, which is the code, which is drawn in this case from a coding system SNOMED.3. So here you see the word "nodule." What this tells you is that nodule is representative of code M-03010 in SNOMED.3.
The HL7 document patient record architecture is an architecture. The PRA is envisioned as a hierarchically organized set of documents schema or DTDs that in aggregate, define the semantics and structural constraints necessary for the exchange of clinical documents. The proposal defines a multi-level document architecture where each level is derived from a more basic level, with level one being the most basic.
Higher levels enable the computer-processable expression of richer shared semantics. We anticipate domain-specific specializations branching out from each level such as an endocrinology DTD branching out from the generic PRA level two DTD, which is seen here.
The PRA levels can be thought of as levels of conformance. Regulatory agencies can require a particular PRA level for reporting. Institutions with different abilities to generate and process XML-encoded documents can claim conformance with a particular PRA level. This should enable more institutions to utilize PRA, while maximizing the amount of computer-processable and shared semantics embedded in an exchanged document.
Level one, also known as the "coded header" specifies encoding of the clinical document header, which contains information that uniquely identifies and classifies the document, attestation, event, patient, practitioner details, and common structural elements for a document body.
Level two, also known as "coded context" structures the document body into coded sections. The vision for level two is that it will provide the semantics to encode the context under which clinical events occur.
Level three, also known as "coded content" is envisioned to encode a document sufficient to meet the processing needs of a fully electronic health record.
I want to make a distinction between an exchange DTD and an authoring DTD. The PRA proposes and architecture for the exchange of clinical documents. An HL7 PRA document may be originally authored data, meaning that an institution adopts a PRA DTD as their internal DTD, or it may be a transformation from original data, meaning that an institution may have their own internal DTD, and map into the PRA for purposes of exchange.
In the latter case, the exchange document is not necessarily the same as the originally attested document. Given this distinction, and because many institutions have or are actively developing their own internal document representations, there is a need to map or transform from an institution's authoring DTD into a PRA exchange DTD.
While the discussion here focuses on mapping from one DTD to another, the issues are similar to those that arise in the more general sense of mapping from one information model to another. Some of these mapping issues are illustrated by the two documents shown here, and include differences in element sequence. So for instance you will see that on the left medical record number comes before date of birth, where on the right, date of birth comes before patient ID.
Required elements, which isn't illustrated here, data type formats. So for instance on the left you will see date of birth as May 13, 1990, and on the right you will see it as 19000513. Granularity and enumerated value lists, where on the left you will see between the sex open and closing tags of value N, and on the right you will see the value of "male."
Perhaps the most challenging mapping problem occurs when the source's information model of the real world differs from the information model underlying PRA. It may be that mapping to higher levels of PRA will depend on the extent to which the sender's information model can map to the RIM, or on the extent by which the author DTD can map to a PRA DTD, thus ultimately to the RIM.
This is illustrated somewhat in the figures here in a couple of places. One, you will see on the left, the tag for impressions, and on the right you have a tag where section title equals assessment. Is assessment the same as impressions? Well, I'll leave that as an exercise for the audience.
The other thing you will notice is that within those sections on the left, the healthcare.code tag is embedded within the text stream. So the word "nodule" is flanked by the healthcare.code tag, whereas on the right we have a tag called user text, which wraps the text of the user set, followed by the model of how the concept in that text interrelates, and we'll have a tag called concept. Concept 1 is nodule, concept 2 is malignancy, and there is a relationship between concept 1 and concept 2, meaning suggests.
Now if we have the model on the right, can we map that detailed representation of concepts and relationships into the model on the left? To me, there is an onus on the developers of PRA to examine all of these models and make sure that we have captured the semantics necessary to facilitate mapping, but that doesn't remove the potential for difficult in mapping between information models.
Next, I just want to give credit to the PRA editorial group. You see them here. Liora Alschuler chairs the group; Dean Bigdood; Paul Biron; Fred Behlen; Sandy Boyer, Michael Coleman; Don Connelly; myself; Joachim Dudeck; Dan Essin; Lloyd Harding; Tom Lincoln; John Mattison; Angelo Rossi Mori; Rachael Sokolowski; John Spinosa; and Jason Williams.
A couple of concluding slides. HL7 is defining standards for shared semantics of health care information. This information, be it documents or messages, is readily expressed and transferred in XML. XML is a sound technology, valuable for exchange of messages and documents. XML is application-independent, making it valuable for persistent storage of documents, enabling archived documents to be viewed and processed by a variety of software applications and software versions. XML documents are easily Web deployed.
The rapid industry growth of XML tools will facilitate HL7 implementations. The growth of interest in XML has helped focus attention on the need for shared semantics. XML can provide a standardized syntax for the expression of shared semantics. When these shared semantics are put into PRA DTDs, the process of validating a PRA document against its DTD presents an HL7 conformance metric.
Finally, I was asked to address the role that the government should play. Medical content is complex, and no organization has yet produced a complete or widely accepted model. The HL7 RIM and the HL7 Document Patient Record Architecture continue to evolve. Clinical scenarios and use cases, document analysis, review of other information models and DTDs, and an analysis of requirements set forth in clinical practice guidelines and regulatory requirements all need to be considered.
Timelines for national patient medical record information exchange standards should balance the need for implementation with the need for deepening our shared understanding of clinical information. This balance should insure that quality standards can continue to evolve, and not be hampered by early roll out of awkward standards.
The architectural approach put forth in the HL7 patient record architecture proposal is one way of achieving this balance. The National Committee for Vital and Health Statistics could be very helpful by identifying HL7 and the PRA as the organization and the process that will continue to develop these models.
Next, there are limitations to mapping between different information models. Perhaps the most challenging occurs when the source's model of the real world differs from the information model underlying PRA. If standard development organizations independently create DTDs, information exchange will be limited by the extent to which those DTDs conform to a shared model.
If all groups creating DTDs were encouraged to derive them from PRA, or map constructs directly to the RIM, or alternatively, to get themselves involved in the harmonization process with the RIM, so they don't actually have to just be taking what they RIM gives them at face value, but modeling their own specific nuances into the RIM harmonization process, then many barriers to effective information exchange will be minimized. This holds for groups within HL7, other standard development organizations, professional and regulatory groups, providers and vendors.
Finally, we have to figure out effective ways to accelerate standards activities. Many would-be participants, including vendors and users, consultants and academicians cannot participate due to lack of funds. Grants to standard development organizations such as HL7 and NIHI are one approach. Grants that foster further refinement of large scale validation of clinical data models is another approach.
Thank you for your attention.
DR. COHN: Okay, Bob, thank you very much. Wes Rishel. Why don't we take a question or two? Actually, Bob, I have a question or two for you, just to make sure that I understand sort of what you were saying.
First of all, is the patient record architecture a validated HL7 standard at this point?
DR. DOLIN: No, it's a proposal.
DR. COHN: The other question I had, had actually to do specifically with the nature of XML. This work group is looking specifically at issues around comparable patient medical record information. Now I want you to correct me if I'm wrong, but I'm just trying to summarize what I think I heard from you.
What I heard is that XML is a promising syntax, and it's major value appears to be its close relationship with Internet publishing and other Internet activities; primarily I would consider that publishing. I was unclear beyond the reference information model where it, in and of itself, helped us with issues of comparable patient medical record information. Is there a characteristic that was not immediately occurring to me?
DR. DOLIN: Well, I think one additional point I was trying to make is that when you have XML, and when you have an XML DTD, validation of a document against the DTD represents a conformance metric. To the extent that you can put HL7 business rules into a DTD, then just by the nature of using off-the-shelf XML tools, you are automatically validating a certain subset of HL7 business rules.
DR. COHN: Let me just make sure of that, because this is an area where I know a fair amount, and then there are areas where I miss some information. If you have an XML DTD, and you put in an area that says diagnosis, and you put in that field hair standing on end, or something or other, does XML, either tools or capability, have a way to say, gee, that's not a permitted term within that field?
DR. DOLIN: Well, yes and no. The reason I say yes and no is that XML DTDs do give you the ability to put in enumerated value lists. So on the example where you saw sex equals male, the value male was drawn from an enumerated value list. If you put some other value in there, the XML processor would give you a validation error.
On the other hand, if you are talking about putting in 150,000 SNOMED concepts into the DTD, I personally don't have the technical expertise to say should that be put into the DTD, or should that simply be handled elsewhere?
I guess the other issue that would come up there is that the DTDs are HL7, so HL7 can't put in 150,000 SNOMED terms into their DTDs, I don't believe, because of licensing. So yes, you can put a closed enumerated value into a DTD and have an XML processor validate it. Sometimes it makes sense. Sometimes I'm not convinced that's the best place or the optimal place to do the validation.
DR. COHN: So this will be my final question, since we're moving into the next presentation. So effectively, the processors of XML actually do allow you to enumerate a list, and it becomes a way to enforce a vocabulary standard within HL7?
DR. DOLIN: That's correct.
DR. COHN: Thank you. Clem?
DR. MC DONALD: You mention all the different ways that you could do XML, and it wouldn't necessarily be the same as everyone else's XML. I just wondered about two issues. There is a lot of agony over the elements versus attributes; that you can kind of put things in two different places. One, can you talk about that. Two, where is the current style, or how you're really doing it from the SIG.
DR. DOLIN: The element versus attribute debate has a long history of being more of a religious debate than a scientific debate. What we have really tried to do in HL7 is to turn it into a scientific debate. With current DTDs it turns out that there are different things -- now first, let me just say what the difference between an element and an attribute is.
An element is the things I showed in the brackets. So name, date of birth, those things are in brackets. Within the bracket you can also have -- you remember the tag for sex -- within that bracket it said value equals "male" before the bracket closed. That part was the attribute. The tag itself was the element.
It turns out that an XML processor can do different types of syntactic validation based on whether you express things as an element or an attribute. So my take had been initially let's look at HL7 business rules. Let's look at what types of syntactic validation we're trying to do, and let's let that lend guidance to how we want to do things.
We kind of went away from that a little bit as we bantered about in Version 3 XML representation in an effort to just have more of a uniform standard style. It turns out that there is good chance it's going to be a moot point within a year or so, because the work going on with the W3C with the schema working group looks like there's a good chance it's going to make the syntactic validation you can do with stuff in elements exactly the same as the types of syntactic validation you can do with attributes. So it becomes really a moot point. Then I think what we've been doing, just having a consistent style would make the most sense.
MR. BLAIR: Are we ready to proceed?
DR. MC DONALD: Yes, actually just a simple second part to that question, was where is the current style?
MR. RISHEL: When you say where --
DR. MC DONALD: Well, a document on some server.
MR. RISHEL: The specifications for the demonstration would be the most recent take. But we regard that as a work in progress. Even at 12:30 p.m. today there is a conference call where we are discussing that topic.
Shall I start?
DR. COHN: Please, Wes.
As someone who characterizes himself as a recovering propeller head, you can't imagine how much pain it causes me that I had trouble hooking up my computer to the projector, but one of the side effects is that I will be some chiropractic treatment here as I try to move my head back and forth between the screen and all of you. My apologies to those of you on the right side of the room, since I'm going to be working with my back to you most of the time.
One of the fundamental things that I will want to emphasize during this talk is that standards, like anything else, is an experience cycle. Judgment comes from experience. Experience comes from bad judgment. We have quite a history in HL7, as Woody has pointed out. I'm sort of racing, because I think we're working against the clock here. Is that correct?
In the past we have characterized certain things as being strengths of HL7. You could apply it to a broad set of functions. It's highly adaptable in terms of your ability to use it with different information system environments, and different variations in system capabilities. I think that's one of the main issues I want to come back to.
We would characterize this as vocabulary independent, meaning we didn't dare specify a vocabulary. Least common denominate technological base, a relatively simple syntax based on ASCII strengths.
As people have gone out to implement HL7 they have found the need to do bilateral agreements for certain reasons, which we tend to think of as deficits. Essentially what they have found is that the broad functional coverage is a problem. Since it's highly adaptable, you have to specify how to adapt it in the IS environments. If you have seen one, you've seen one. They are just quite different.
Among the different health care provider organizations, vocabulary independence means you have to specify a vocabulary. The least common denominator technological base means you have to accept the limitations of that least technology.
We saw that as recently as putting this demonstration together for HIMS(?), where the major new thing was a RIM-based XML set of transactions. Most of our debugging was on dealing with the least common technology; getting the systems to basically talk to each other. Far less than dealing with XML than we might have thought.
I think the previous speakers have addressed what is a PMRI. Clearly, the need for comparability has to do with extending both capabilities within a provider organization, and across organizations. I think that to a certain extent the government's role may be different in these two contexts.
Within an organization, as we say, the organizations are beginning to resemble Clem McDonald's old talk on problems where they are like oil drops. They come together and they go apart, and they come together again. So there is a tremendous information systems impact as organizations go forward in reverse mitosis.
The more that those interfaces among the systems and the organizations are standard, the more efficient the organizations are in the face of this change. So clearly, society has an interest in comparable standards within organizations.
Among organizations the ability to establish trading partner agreements in order to make a standard work is substantially reduced. Indeed it is notable that HIPAA effectively introduced a requirement for interfaces that do not have trading partner agreements. That has been a challenge both in the world of commerce-based transactions, or administrative transactions in X12, as well as in implementing clinical attachments under HIPAA.
In achieving comparability we believe that there are three levels that one needs to address. As we go forward a little bit, you are going to see that I have -- it has been said for some while that laptop computers and Kinko's redefined the last minute. I think I redefined it again, because in response to some of the other talks, I altered my talk this morning. So I want to get to a point pretty soon where you don't follow me in the handout. I'll know about that, because I'll hear the roar of the ocean in the background as you flip through and try to find a page. I will also post and send an updated copy of my presentation.
The fundamental basis for comparability, when you exchange information using a standard, is that the level that we have talked about largely today of vocabulary, the reference information model, and some thing that I will talk about, which is an effort called clinical templates, when you have got that straight, then there are various ways that you can employ that to improve the interoperability of systems.
Messages is one we are very familiar with, because we have been doing it for 13 years. The industry has been doing it longer than that, to the extent that X12 has been around, and ASTM lab standards.
Documents, as Bob Dolin just discussed at some length, are clear. Health care is document-centric, and frequently it's better to have a regular document such as an operation note from five years ago, than all of the hemoglobins in the last five years, because it provides more decision-basis content for the clinician in the process of giving care.
Rules -- the ability to have portable expressions of rules that could facilitate decision support through the Arden syntax depends on being able to describe the data that the rule is applied to, and that stems back to the information content.
MR. BLAIR: Wes, just one piece. This portion is an education session. I think some of the committee members may not know what you are referring to when you are referring to the Arden syntax. Could you just define that?
MR. RISHEL: There is a building, the Columbia site that is Arden House. I'm sure in many specialties there are Arden this's and Arden thats that started there. In health care informatics it is a standard for portable rules, meaning a way to express a rule such as a patient has been on a diuretic for some number of days, and we have made no potassium measurements. Do you want to do that, Mr. Intern, and so forth.
The committee formed quite some few years ago and developed a language that is similar to a programming language, but different in the specific needs here. They had somewhat limited success in terms of the adoption. One of the primary reasons has been that when you go through the portable rules that are at say the Columbia Presbyterian, and it gets to the part where you say the patient has been on a diuretic, you see some curly braces, or Alfred Hitchcock's if you use the metaphor, and there is this gobbledegook in there that represents a query against the specific physical database design at Columbia Presbyterian Medical Center.
The theory is that the syntax people have been able to isolate that which is non-standard, that is the data retrieval specifications, into what is inside the curly braces. Nonetheless, the notion of portability is greatly impaired by not being able to interpret that very critical section of the Arden language against your own system.
The Arden syntax and group actually associated itself with HL7 specifically. They had access to the notions of the RIM and so forth, to allow a transportable expression of what a statement like that means, as opposed to a specific implementation-based expression.
If you have the fundamental concept straight, and you know how you want to use it, then you can answer questions about what syntax and technology to use. Simon and I happened to be on the same flight last night, and we got to talking about this stuff. I think I probably characterized it as the propeller head stuff.
We observed that the secretary is probably not that interested in this, except as it has business impact on the rate at which standards can be adopted. In the conclusions in my talk I'm going to come back and address how this relatively downstream and somewhat arbitrary question of the overall standards model has practical impact.
The question is what happens when you are not sending completely comparable data, or your data is not completely comparable? Do you communicate less information? Do you communicate less precisely? Do you tolerate a percentage of error? Or do you have bilateral implementation ingredients, and after those agreements do you go back and tolerate a percentage of error or what?
I take the position that we strive to do the best available with what we have at any point in time. I wouldn't want this to be taken as an endorsement for sloppy systems, but clinicians are trained to treat the patient, not the test. To deal with data that is not consistent with the overall picture of the patient, and frequently some rough information is better than no information at all.
So I would like to characterize the role of the government as a series of steps to improve the quality and reduce the requirements for bilateral negotiations in exchanging clinical information, rather than an all or none description of the comparability of information interchange.
What does comparability cost? A bold statement. There is now and in the foreseeable future a cost barrier to the full exchange of comparable fine grained information. The barriers are not primarily attributable to the syntax or the technologies. They are primarily attributable to that top layer, understand the issues you will be addressing at later hearings about vocabularies, relationship to information models and so forth.
Secondarily, there is a cost of collecting that information in a way that it can be exchanged. I'll come back to address that one in the future.
HL7 is clearly working in the area of the information model. I'm going to speak more about clinical templates, and it has what I characterize as a semi-definitive approach to vocabulary. HL7 is clearly expanding the application of this conceptual infrastructure, as we talked about documents in the Arden syntax.
We are working to represent these things in a way that can be exchanged using the most appropriate technology, rather than identifying the technology with the standard. I think we have a rapid expansion of good technological support for information interchange. Everything from HTTP, which is the underlying protocol of the Web, to MIME, which is used in the Web and in electronic mail, to component technologies. All provide practice advantages for reducing the cost of implementing standards.
The goal of the standards organizations should be to take advantage of all of them, rather than become an advocate of one over the others when the real issue is the upper layers in this model.
In vocabulary HL7 has committed to a policy of using existing vocabularies as values for code of field in HL7 messages whenever such exist, and in fact is more interested in deciding what does a need of a vocabulary to be used than in redefining vocabularies. What is the match between a vocabulary and HL7's technical and information structure?
Once, it's just not HL7's business to define those codes. So this is why I characterize the HL7's approach as semi-definitive. We should be able to say definitively does a vocabulary qualify for use in HL7? And we should be able to support the use of qualifying vocabularies, but we should not be as HL7, directing the industry in which vocabulary to choose.
The further basis for that assumption is that the market model, that is to say the notion that industry provides vocabularies at a price that is able to support the substantial intellectual effort that is necessary to maintain a vocabulary is seen as one of the rationales for supporting multiple vocabularies.
Particularly I think in the area of pharmacy, it is easy to observe that the NDC codes are perfect for what they are used for in a governmental sense. They are not a good basis for information exchange among information systems. And there are several, although fewer, that have a number of Pharm.D.s on staff and try to keep up with the rate of new introduction of pharmaceuticals in the vocabulary.
HL7 recognizes that proprietary vocabulary use requires a license from a payer. This is going to be an area where the government may make a different set of assumptions than HL7 makes.
In HL7-speak messages are sets of segments, the current version. Two important segments are OBR and OBX. OBR is some kind of a group of observations, and OBX is an observation. In the OBX segment there is a code which says what is being observed, and a value that says here is what we observed. Then there is additional information such as the units where it is a numerical value and so forth.
Some codes work better than others for that. Some codes want to have a different value for different sets of units, and may not support all the units that a sender may want to use. Other codes express what is being sent independently of the units, and are therefore better suited to match the HL7 architecture.
The question has been how to put together the information model, the structure of segments in the case of Version 2.3, the codes which are very broad sets of concepts, and the domains, which are the subsets that are suitable to a certain kind of observation, and the codes that represent answers in a way that would allow us to be more specific, to make the information more comparable.
Without this, we find that some vendors or in-house shops simply don't know how to send information, and make up very creative solutions. And others have valid ways of sending information, but based on different aspects of code sets, they still don't operate, they still don't understand one another.
The notion that we are using in HL7 is that if you have segments or an information model and codes, that is to say a vocabulary that are subdivided into domains, and you specify constraints, constrain a domain to a certain set of values, constrain what part of the architecture you are using, you end up with an expression of very specific kinds of thoughts in information systems.
For example, a battery can be seen as a code that heads a set of other codes that represent the specific values that are being observed. In the case of blood pressure there are five or six different observations that go into a blood pressure reading. There is the obvious systolic and diastolic numbers. There is the kind of cuff that was used, the patient posture, the units, and so forth. A specific constraint would be to say you will send all of those five, and you will use this coding domain to specify the cost and so forth.
In the Version 3 we have the RIM, and there are basically 120 or so classes that represent broad, abstract notions in health care. Then we combine those classes to make messages or references in the Arden syntax, or something like that through specific technologies. But when you get to this level of a group of observations, just as in Version 2, we use the same classes over and over again.
But we haven't subdivided observations into laboratory observations and nursing observations. And we haven't further subdivided it into chemistry and hematology and then into sodium and potassium, and created this tremendously detailed number of classes in the model. Instead, we have chosen to use the same general purpose code value approach that we used in Version 2.
But if we had, it's likely -- and we were able to address the kind of things that were are popping up on a screen here -- it's likely that we would have thousands of classes, because that's the nature of the health care business. There are that many different kinds of ideas that are expressed.
The notion of clinical templates is the way to take the hundreds of classes, and the vocabularies that are appropriate, and come with the specific rules to deal with these thousands of different things that need to be expressed in a comparable way. So clinical templates are constraints on the classes. The point to be made is they can be applied both to existing HL7 Version 2.3 or to Version 3.
Clearly, what you can define with clinical templates gets to be very fine grained, and gets to the issue of comparable data that this committee is concerned about. How can we do that? One, we are currently in the process of defining how we're going to go about doing this. So this is a still a glean in our eye to a certain extent.
As you have heard already, HL7 has a tremendous orientation towards process that is both fair and workable, given that those are sometimes conflicting requirements. And we now know how these processes work. There needs to be a similar process for establishing templates. Probably the main characteristic of these templates, because they are so detailed, is that it cannot be presumed that the hundreds of people who attend HL7 meetings represent the appropriate body of expertise to achieve consensus on all of these templates.
In many cases we need to have an outreach program to reach professional societies, and things like that to get very specific templates related to diseases or body systems or things like that. Then use HL7 as the way to publicize the work of these specialty committees in a common way that is universally accessible.
I think most people are aware that many such professional societies have some kind of work going on right now to define their data. Whether it is thoracic surgeons or obstetricians, they, to a certain extent, are wandering methodologically between the notion that they will define the one information system that everyone will buy, and that way they will have common comparable data in their specialty to various kinds of data dictionary approaches and so forth.
To a certain extent, the needs of these societies might be met with these ad hoc approaches. Other times they are not even practical. But the need of the health care industry overall is only met if these specialized information structures are defined using a common methodology. That's what the HL7 clinical templates effort is about.
Creating repository A -- we do that stuff. What will happen if we do this, when we do this? Well, we will be able to have messages now that exchange lab data or diabetes interim reports, or ER trauma reports that can be communicated with much more fine grained detail, so that not only can a person read it and understand it, but another computer can read it and understand it. That's the point of achieving this fine grained comparability.
We'll apply that to messages, exchange of information computer-to-computer, to structuring documents in a way that Bob described earlier, and to being able to really dig in and describe the kind of things the Arden syntax needs to describe exactly what data goes into what rule.
As some of you are aware, HL7 has worked with X12 and HCFA to define a proposal for submitting claims attachments as part of the payer process. Now that is in fact a clinical document designed for a single purpose, which is to support payment, to justify a request for payment. But nonetheless, the need is to convey clinical information.
We are cognizant under the HIPAA to use existing standards. We based it entirely on Version 2.3, and a very cognizant of another HIPAA requirement which is no trading partner agreements. We established a very rich pattern of segments in HL7, and we relied on LOINC codes to describe what was being sent in that pattern of segments.
If you look at the documents that are available from HL7 you will see that this has been applied for everything from the justification for an ambulance run, which includes such clinical variables as how far did the ambulance drive, to detailed lab data, to op notes and discharge notes.
In those submissions that go to the payer, there is a quite a varying degree of granularity. Sometimes a text report is just that, a text report, without any of the benefit of what we might get structuring it in XML. Other times we get down to the last level of this prescription was prescribed for 30 tablets, no refills, three times a day, except on Sundays, where it is four times. And why is there that variability? Primarily because that's the variability in what we believe we can get from the source system.
We look at how to get the best data we can from the system to the payer, rather than what would be ideal, expense and other factors not considered? In fact, the payers are generally going to put this information in front of an adjudicator. They are not concerned about the fine grain. In future years they may well develop algorithms to support adjudication, but baby steps come first.
This approach, which is currently being reviewed by HCFA, make come out in a notice of proposed rulemaking this summer. At any rate, it has been balloted and published by HL7, in terms of the HL7 content for it. It is in fact a clinical template. It is in fact a set of specifications within a rigid structure of HL7, of specific subsets of the LOINC coding system, and the patterns that they occur in order to send clinical data. So even as we are trying to figure out how to do clinical templates, it looks like we did one.
Earlier I talked about two sets of interfaces where there was need for standards. One was within an organization, and one was without. Just a minute ago I talked about the fact that we decided what granularity to ask for in claims attachments based more on motions of what was available from the systems than the computer science or the informatics behind it. Why was that?
Well, the reason is because the user interface between the clinician and electronic medical records system is not a solved problem. What do I mean by that? I mean that in order to get the most comparable data, we need to capture information that is a part of the clinician's thought process. Not only what prescription was written, but why was it written? What problem was it for? Was it to combat the side effect of another prescription? And so forth.
The health care system is optimized around physicians' time, and we have been squeezing it more and more. It has never worked to ask physicians to take more time to enter information into the computer, because we need it downstream for whatever reason. Currently, the best of the information systems are finding ways to save physicians time, or at least be time neutral in exchange for getting this additional information.
The system itself to a certain extent is compensating physicians for entering more time. So this is the very leading edge of where the industry is. There is no one that can look out and say there is a robust market of electronic medical records systems that capture this fine grained information that we need in order to be able to send it through whatever standard there is.
Now why is that important to a standards body? It's important because it tells us how high we can afford to set the bar in writing our standards. In other words, this experience cycle that I started with, is not only the way you express that experience of trying to use a standard, is in the performance of the information systems that implement the standards.
What can the government do in terms of improving the efficiency and effectiveness of health care through the use of comparable patient medical record information? One, I think there are two legislative models that this committee may want to consider. One is HIPAA, which is directly involved in it, and there are notions in there of being based on existing standards, of penalties for failure to use the standards, and so forth.
But also I think that we can look at the automobile industry, and the process of at the same time reducing the pollution and increasing the gas mileage of automobiles. Those of us who are of age remember a time when Congress began to propose such things, and we heard a certain amount of whining from the auto industry that this was not possible, or it would make cars too expensive, or so forth.
The response was to create a series of goals over time that kept raising the bar. That, I believe, is a model that is applicable to health care information standards as well. Carry the model forward for HIPAA, that when you get into interorganizational transfers supported by this government supported standard if you will, that the measure of effectiveness is no trading partner agreements.
Don't let the perfect be the enemy of the good. In other words, early on emphasize selective achievements consistent with where information systems are today. We're very cognizant in HL7 that with Version 3 we are raising the bar for information system vendors. Since they are our primary voters, we have concern that we may never get a standard out if we raise the bar too far. If we don't raise the bar enough, then there is no reason to adopt Version 3.
The right model is to find that mix of enough improved functionality in the standard versus the cost and time in vendor organizations to improve their information systems. How do they do that? Well, they do it in two ways.
One, they do it in new designs. I venture that no one is starting a new design of a medical records system now that hasn't looked at the RIM, of the reference information model. Even though it's not final, even though it's not a design model for systems, being able to account for the classes that are in the RIM and ought to be represented in the RIM has got to be one of the design specs for electronic medical records systems today. Certainly, as I advise clients, I advise them to look at the RIM in that context.
Well, those things that are being designed today will be adopted in large numbers some years from now. How else do information system vendors adapt to standards? They adapt to it in major release cycles of their products. The typical vendor has a major release cycle of 18 months to two years. Therefore, we should expect that significantly raising the bar for an information vendor is something that industry can react to in two years or more, and cannot react to in less time.
So my point for the government is be selective in what we want in two years. At the same time, don't let the good be the enemy of the better. That is to say, continue to raise the bar in a series of progressive standards towards more finer grained information, towards being able to capture that at the source where it needs to be caught in order to provide it, and in time frames consistent with industry product cycles.
Some specific government actions. This notion of clinical templates is, as we have several times characterized, a one or two order of magnitude step up in terms of the volume of standards information that is being created. At the same it is what is necessary in order to be able to implement without trading partner agreements.
As we move forward, the areas where HL7 I think can use help is in operating the methodology, the costs involved in operating. And two, in establishing that outreach through the specific professional societies that is necessary in order to achieve the templates group by group.
Second, whereas HL7 is sort of the Switzerland of vocabularies, the government doesn't have a similar constraint. I would hope, speaking for myself, that the government would sponsor, negotiate public rates for a few specific vocabularies, and these particular recommendations here I support, and they are from other people in HL7 as well.
I think that concludes the presentation.
DR. COHN: Thank you, Wes. Actually, I want to thank the entire panel. It was a very interesting introduction to HL7, as well as bringing up a series of issues.
Now as it turns out, obviously, we're right at 12:00 p.m. right now; in fact it's 12:10 p.m., so I'm going to suggest that rather than discussion or questions at this point, that we adjourn for lunch. As it turns out, in the afternoon panel, one of our speakers was unable to come because of a family emergency. I'm going to suggest that potentially from 1:00-1:30 p.m. we begin to discuss some questions, probably have discussion.
I also don't know the abilities of the panel to stay for later on today, but I know my co-chair felt that based on some discussion occurring with the second panel, that there may be further occasion for some open discussion also. So we would encourage you to stay through the next panel after lunch if possible.
With that, why don't we adjourn until 1:00 p.m., and thank you very much.
[Whereupon, the meeting was recessed for lunch at 12:10 p.m., to reconvene at 1:00 p.m.]
DR. BEELER: Wes had a conference call. He will be breaking free from it. But I think we may, we should proceed. I think we might be able to fill in for him.
DR. COHN: Great. First of all, let me thank the panel for what I think has been a very educational session, and very helpful as the work group begins to ponder its responsibilities. Certainly I heard information being discussed at a number of different levels, all the way from the high level reference information model and perhaps beyond, down into the level of clinical templates and issues around vocabulary.
I wanted to start out actually with just a question for Abdul-Malik Shakir, and a few others may want to join in on this one, having to do with the highest level around reference information model and beyond. I think you had observed that were was an issue related to comparability of data having to do with multiple different information models that exist.
And whereas it is possible to harmonize models within the domain potentially, there are also problems with that. Then certainly one would observe that there are other standards development organizations and others who have other models. I guess the first question really is, is there a need for some sort of a super harmonization process that is actually really above HL7 at some sort of another level that would be prized to do some greater level harmonization?
MR. SHAKIR: It sounds like there are a number of questions in there.
DR. COHN: Perhaps.
MR. SHAKIR: The first thing, and let me see if I can break it down into its parts. The difficulty surrounding doing harmonization, how does one go about comparing the models and how do they differ, and is there a need to do such a thing above the level of HL7? I'll take those as two separate questions.
The harmonization requires that the participants exchange their views, and exchange them with an open mind. That we come together and try to get down to what is it you are trying to describe here? So that I may come and say that I want to describe characteristics of a patient. And in my mind I'm thinking that a patient is anyone who is receiving health care services. You may come to the table with a concept that well, gee, a patient is anyone who is enrolled in our program, whether they are receiving services or not.
So now we have to have a discussion, well, gee, I call that member. And we dialogue back and forth, and then we come to some agreement as to what term we're going to attach to this concept of an individual who is receiving health care services, and what label we are going to attach to the concept of an individual who is enrolled in a health plan.
So we first describe what it is we are talking about. First we identify that we are using the same terms, but different ways; describe the different concepts; and then agree on what label we want to apply. We may agree to call them both patients. We may agree to call them something else, but the thing is to come together with that dialogue.
That requires that we be in the same room. It requires that we have a language for articulating where our concepts are. So I think we have the framework in place for how to express the ideas. We have had some difficulty in bringing the people together.
Now as far as the need for a reference model beyond that of HL7, some sort of global reference model that all point to, I think more what we would need is some way of cross-walking from one model to another. HL7 has its information model, and it may have in it a class that it refers to as stakeholder. This is a person or an organization that is somehow involved in the health care arena.
Well, X12 also has a health care data model. They have a thing in it they call entity. Entity is a person or organization involved in health care. These two terms are essentially synonymous. They essentially have the same attributes, play the same roles in both models, but because of the sort of culture underpinnings in the two organizations, the word "entity" would never survive within the culture of HL7, just as the word "stakeholder" would never survive in the culture of X12. But we can, when we are talking to one another, make the necessary translation.
So I don't think there is a need for a super model, as much as there is a need for cross-walk between models.
MR. BLAIR: I'm am delighted with the testimony from everyone this morning. As we indicated, this was an educational session, and I think the panel members that are here probably recognize some of the faces on the committee as being HL7 members, and we're already familiar with things.
What I would like to do at this point, if I may, is really solicit some of the committee members are who are not HL7 members, and who are not as familiar with HL7, for them to ask questions of any concepts or issues with respect to message format standards or syntax that they might have.
MR. SHAKIR: While we pause and wait for answers, did any other panel members have a different answer than the one I provided for the first question?
DR. BEELER: I had a different direction that probably reached the same conclusion. And that was the observation that every model is designed to serve a purpose. In HL7's case the model is designed to define the content from which information structures are assembled. It is not designed for example, to be a database. It is not designed to be a patient record, although if it is done right, it contains all of the concepts that should be in a patient record, and all of the concepts that should in a clinical repository. It simply isn't designed for that purpose.
The question that I wrestled with in response to Simon's question is to what end would we put a next level up information model? I think there is probably a value in having a more abstract -- meaning fewer pieces -- model of health care to which all of us can map, so that we can at least understand where we are working, and what areas we are targeting.
This is in fact an activity that has been proposed now from several different directions all at once. The government CPR project has an interest in it. One of the CEN working groups has an interest in it. The National Health Service of Great Britain has recently issued a letter to a whole bunch of organizations suggesting such an activity. I think that sort of thing may come about, and certainly this committee would do well to remain at least cognizant of what's going on in that regard.
DR. COHN: Other comments?
COL. RAY: I think as we talk about moving up a level above HL7 in this organization process, I really want to move down to a level below that. This is the concept of how do you implement this? So in a GCPR the government is responsible for delivering to PRC, who will be our contractor, an information model that is implementable across three agencies.
For DOD for example, we have selected HL7 RIM as our information model, but at the same time we have the FAMD, our functional area model for data. How do we harmonize those in an implementable format? So it's not just setting standards. It's how do we take two models that we have and implement them together as a single model? I know that HL7 looks at a process. I'm looking at how do I really do it.
MR. RISHEL: I need a car and the army needs a car, and my wife needs a car, and they may not be the same car. My car has got to hold nine passengers, and mine has got to get the wind blowing in my hair. Models are like that. Even in a fairly tightly constrained environment such as building an information system without much worrying about the world beyond the moot, there are several models.
There is a model that is in essence an analysis model that is used to speak with the functional people. There are models that are derived from that that are used to speak to the computers. There is a lot that goes into that derivation.
The idea that the HL7 RIM could be delivered to a contractor and say build a system based on it is at best an invitation to a lot of ECOs. It is the right process, but we have to understand that what makes sense to the one model, doesn't make sense for the other.
So I think that your question was how to go about doing this. The answer is I think: (a) don't look anywhere for the one true model; (b) look for specific methods of deriving one model from the other, and accountably derived. That is, if you look at the literature of objective oriented systems development now, a lot of it is not so much about several individual models as it is being able to track back and forth between the models, and see how a change here impacts a change there.
I'm sorry that that's such an indirect answer, but I think that is a methodologically challenging question.
COL. RAY: I think what we are trying to do is harmonize across those two models, but I think of more concern is how do I manage that model for the future, changes that come? So if HL7 RIM changes next week, how do I implement that change? So are there tools out there -- and I think we talked about DiCOM(?) -- was that the two that we talked about Woody?
DR. BEELER: I mentioned that I know that at Viosoft(?) and Platinum(?) had products that did data model repositories. There are other vendors that I'm simply unaware of. As I say, the only thing that's an endorsement of is my lack of knowledge of the industry, because I don't know them more broadly.
MR. RISHEL: I would just add one point to my more learned colleagues. One of the characteristics of the HL7 approach is that we publish our meta-model. That is to say, you can to our message development framework and find out what do we mean by a class? What do we mean by an attribute? What do we mean by a message? And so forth. That is the key to tracking. If you understand the meta-concepts, you can develop a method to relate that.
So the question is do you have and can you get the meta-models for the things that you need to relate to it, and look above that? I would specifically recommend HL7 message development framework document, MDF, as our side of the key towards that translation capability.
DR. COHN: Other questions?
DR. FITZMAURICE: Let me start off with the big overview question. That is, what is the business case for modeling, and maybe for clinical vocabularies and for message exchange standards? Don't paper records work just fine? I don't hear doctors complain about patients dying because they couldn't read a medical record, because they couldn't get the right information. They say well, I'm trained to make a decision based on the information I currently have. Is there a case that where with more information, they could do a better job? Is it a hypothetical case? Is it a real case?
DR. BEELER: I think you asked two questions. You started out to say what is the business case for modeling. My answer to that is if you are undertaking any systems endeavor, be it building an application, be it building a standard, be it building a super system or systems to support public health on a broader scale, that system will be better, more durable, have fewer errors, and be more likely to persist if the intellectual analysis underlying a model precedes its design, rather than follows its design.
Halfway through the question I heard a different question, which is what is the business case for electronic patient records.
DR. FITZMAURICE: Well, I moved from the dollars and cents to what is the patient care and outcomes.
DR. BEELER: And I believe in very simple terms that it is two-fold. One is to increase the effectiveness of the information that is provided. Paper information as it stands can be of all shades of quality, but even if it is good it always suspect of being absent or being unfindable. That is to say, yes, it's well documented in the paper record, but I can't find the report that I wanted to use that justified whatever it was that I did last month.
I think one of the premises behind computer-based records is that you can have a better sense of their status in terms of completeness, and a better path through those data than you can necessarily do on paper. I would also assert that I believe that is still a premise. That is to say, there is still a lot of work in development of computer-based patient records to prove that that is in fact true with any given, and indeed with all patient record systems.
The second is the notion that we can provide better patient care if we can do it more efficiently in terms of human resources. I think the move of late that you see in many health care organizations to adopt computerized patient information is based simply on the belief that it will in fact over time, produce a more efficient practice. That is not proven. It has been documented rarely.
Third and finally, the notion of process improvement, which is as applicable to health care as anywhere else is substantially better supported by electronic information than it is by any other way. So the notion of being able to track methods of dealing with a particular disease or set of problems, and to understand how those work over a set of patients is something you probably can't do effectively on paper.
People have done it on paper. We have done it at organization, others have, but it's always hamstrung by insufficient access to the information that underlies it. So my three answers are one is you can probably provide better information at the decision point electronically than you can on paper. Secondly, I think you can improve the simple mechanics of health care. Thirdly, I'm certain that you can use it to assist in process improvement in health care.
DR. DOLIN: While I think it's true that a provider can read a paper note and can learn a lot of information about the patient and feel okay as far as patient care, there is no question that information needs of office providers are not being met. For the same reason that we need an information model and a terminology model to enable data exchange, we need those same models to enable interoperability of electronic health records with other applications.
For instance, if somebody wants to build a decision support application, and I have a clean, well described information model and terminology model for my electronic health record, there is a greater ability to plug those together. There is a greater ability for me to automatically trigger a Medline search from my electronic health record or trigger a decision support. So interoperability and providing greater answers to the questions that providers need in the context of care is enabled by the information model.
MR. SHAKIR: I think I'd like to take a third shot at that. The question, as I understand it, is what value does the modeling add? I believe that electronic medical records are enabling us to retrieve information better, but health care delivery is filled with communication across many people; one doctor to another doctor, a doctor to a patient, a doctor to the payer, et cetera. This information is exchanged among all these players.
If they are each using different semantics and different underlying vocabularies, that communication is made more difficult. There are many who, in taking their approach to creating an electronic medical record capability within their own organization are acquiring software products from a variety of vendors, and then attempting to have these applications talk to one another.
They are finding that it is often as much energy spent trying to get them to talk to one another as it was to assess which ones to buy. So the cost of creating the interoperability among the applications can be reduced if the applications were built from a common framework.
And then outside of an organization, an organization must speak with other organizations. So I have collected my set together, and I have spent three years getting them to talk to one another, and now all of the sudden I need to talk to the guy down the street. He has a whole different set, and we need to talk to one another.
So the exchange that crosses organizational boundaries becomes even more difficult, because I have no control over what decisions he makes as he tries to blend his applications together. So the modeling helps to reduce those differences so that the interoperability has less costs associated with it.
DR. FITZMAURICE: Let me jump to a question further down on my list. Is there a case for international coordination in modeling? That is, there may be a case for national coordination of modeling, because we don't want to duplicate efforts. Does it extend internationally? Is it the we want to sell in their markets, and as a consumer we want to have more competition in our markets so we get the best information systems and the best health care.
Or is it I may have a skiing accident in Switzerland, so we need to get my data there for this 1 in 1,000 chance? Is there a strong or a weak need for international coordination in modeling?
DR. BEELER: I think the core answer was really the first one, and that is to say the business of health care computer systems is certainly an international business. In fact, that question should probably be better posed to the vendor panel. But I believe that increasingly in all of our information markets the borders cease to mean much.
The commercial argument, as it were, for coordination internationally is probably stronger than the issues of patient movement across borders. I presume that diffusion might simply explain the movement of people, but if that's true there is a lot greater movement of people between two or three doctors at Mayo Clinic than there is between Mayo Clinic and one of its outlying regions, and much of that than out to Chicago. And the further out you get, the less likely it gets.
I was thinking of the flip answer which is I would guess that you probably won't still be skiing by the time that your computer record could be sent to Switzerland if you have a broken leg. That's one cynic's response.
MR. SHAKIR: I have a more selfish desire for why I would like it to be internationalized. My family is living in Ghana. The public health system in Ghana could really benefit from the studies that we do here in the states. So to the extent that I am able to create an information model that is consistent throughout the world, then the better we are to leverage the decisions and clinical outcome studies that we do here, in other places. I would especially like us to first start with Ghana, because that's where my family is.
DR. FITZMAURICE: That's a good answer. I was going to suggest also that the clinical trials for drugs is another reason. Why duplicate a study if it's been done well, and the data mean the same thing in another country as in this country. Why not use that as an argument for faster approval of drugs, or detection of side effects?
DR. COHN: I'm going to ask one final question and then I think we need to move to the next panel. This is just following-up on the questions that we had asked all of you. I think some of you have answered the question one way or another, but never with a great deal of specificity. In a number of our questions we asked this with issue of what role the federal government should play, if any, that would bear results in one to four years, versus longer term 5-10 years and beyond.
If you could just comment very briefly. Many of you made recommendations. It wasn't clear to me what, if any recommendations might bear early fruit versus be something in the long run.
DR. BEELER: I suggested in my written comments that there are a number of areas where the coordination and collaboration, particularly surrounding models will over time, suffer because of the simple logistics of keeping the processes going. So that on a mundane level, although fairly fundamental level, those processes could use work.
I think the notion of vocabularies -- and I recognize that you've got a meeting on that topic six weeks out, so I won't go too much further with that -- but there are some core questions relative to vocabularies and how they can be used. They directly affect interoperability. The interoperability of messages is dependent upon having valid vocabularies. That's another barrier in which there are undoubtedly roles to play.
Then the third, and I guess I'll it to Wes to talk about are the templates area. I would like to sort of endorse his notion that he introduced earlier, which is to establish goals, objectives, hurdles, steps to be taken is a good way to influence a marketplace, as opposed to driving it. Find an incentive for them to step up to the bar, and then you can move the bar up.
MR. RISHEL: I think that ditto Woody on dittoing me on that. With regards to your specific note about the four year time frame versus the greater than four year time frame, my belief is that in establishing goals within the four year time frame, the HIPAA philosophy based entirely on existing standards is important, because that's where the information system can adapt most rapidly to new requirements.
Secondly, I believe that the government has every right and reason to establish standards where it is a data aggregator or a payer or in some other way involved in the transactional flow. If those standards are done well, they will also benefit areas where it's not directly involved in the transactional flow.
In the longer-term I think we need to initiate efforts now for pay back largely then. This notion of an outreach program to the professional societies to establish their templates or data sets or whatever you want to call it. The specialty-specific definition of what is the data which we report and make decisions on is you pay your money now and you get your benefit later to a certain extent on somebody else's administration. But nonetheless, it is critical to achieving the comparability goal as best it can be achieved.
DR. DOLIN: I want to just try to make the distinction between what I consider deriving from an information model versus mapping to an information model as part of the point I want to make about the role that the government potentially can play.
If two different standards development organizations independently create their own information models, there is going to be a limit to the semantic interoperability. On the other hand, if one organization derives their information model as a starting set from what's provided, then the ability to share information goes up.
So I guess one role that I would see would be to encourage deriving information models, deriving DTDs from the HL7 information model and the PRA architecture being put forth by HL7.
The other issue which I'll agree is somewhat fuzzy in my mind as how best to proceed, but I think that we have to figure out how we can accelerate the standards development process. Some of the ideas that come to mind would be grants for HL7, grants for NIHI, and grants that help deepen our shared understanding of what clinical information really is, because I think as Wes and Woody have said, we do want over time, to raise that bar.
We can't raise the bar way up to the top yet, because we don't really have a detailed understanding and large scale validation of what that detailed clinical information is. We don't know how we can extract that type of information from clinical records. So we need to foster that kind of research to really understand what the clinical content is in clinical narratives before we can even set the bar.
MR. SHAKIR: I think we have presented to you a three layer cake, where there is a top layer of semantics, a middle layer of syntax, and lower level of the implementing technology.
MR. BLAIR: Which is the information model.
MR. SHAKIR: Well, the information model I think belongs in the semantic layer. The information model, the vocabulary, the clinical templates are areas where lots of collaboration is necessary. The syntax area requires less collaboration. I think it's fine for X12 to have its syntax or EDIFACT to have its syntax or HL7 to have theirs.
Then at the transport level, the use of XML or CORBA, those should become pretty transparent to whether you doing X12 or HL7 syntax. But the semantics is where we gain the value. That's where the interoperability occurs. The organizations who are developing standards have already demonstrated the will to work with each other. X12 and HL7 have collaborated on building that claims attachment specification. HL7 and DICOM have collaborated on building specifications. NCPDP has always been involved in matters in X12, and has expressed an interest in the HL7 data model.
So they have their willingness, but they all have that barrier of they share membership, and the membership can't go to all meetings. The organizations can't continue to fund the harmonization activities. So if the government can find ways to help encourage that collaboration among the organizations and continue the fire by underwriting the costs of some of the collaborative work that these organizations take on, I think that would be a way to work.
I think also to stay away from dictating any one of the syntaxes as the syntax. I think you need to let the market decide which syntax is the best, because as the technologies change, the appropriateness of the technologies change. With the advent of the Internet XML became more viable. Before the Internet XML would have been a little dot. So I would want you to stay away from dictating a particular syntax.
DR. COHN: Is this a real quick question?
DR. MC DONALD: Well, the answer is what determines the length, not the question.
DR. COHN: Last question.
DR. MC DONALD: This committee, we're sort of the more techie part of the whole NCVHS, but the NCVHS is largely concerned with data sets. A big chunk of the interest is in data sets, and a variety of kinds for quality assurance for this and that. And how does this relate to data sets? How would the HL7 mechanisms relate?
MR. RISHEL: When you say data sets, I think you are largely talking about functions that I lump together as aggregators; collectors of data for public health or policy purposes, evaluation, et cetera.
The biggest problem that aggregators face right now is variability in the source systems. Is there a system to collect the data at all, and if so, can it represent the data in a way that really permits aggregation? As in all kinds of research, we do awful things to find proxies for what we are trying to measure, because we can at least measure the proxy.
The ability to promulgate these templates or the data sites in a way that is over time -- I don't want to say forced or driven, but introduced into the source systems in order to generate comparable data provides the long-term solution for the data aggregators. But if someone has the data, you can send it.
There needs to be standards at all levels down to what phone number do you call if you are using a modem. Some of them are harder, and some of them are easier. The ones that have the most profound impact are the ones for the templates. I particularly believe that we are not making enough use of the public Internet. At the lower layers there is suitable security, particularly for aggregated data sets. All the capabilities are there, and we should support that. Those are solvable by a few programmers in a few months, rather than by the outreach program with professional societies, which is a much longer term project.
DR. COHN: We want to thank you all very much, and hope you'll stick around so you can provide some comments and also questions to upcoming panels.
MR. BLAIR: Woody and Abdul, Wes and Bob, would you please stay nearby, because the next panel will be some of the other SDOs, and there may be questions that come out of that from the committee and from the audience where we are trying to get an understanding for the interrelationship, coordination, or even possibly some conflicts. So would you please, if you can, stay with us at least for the next couple of hours?
Then I would like for us to convene right now our second panel of SDOs.
DR. BEELER: Three of us can. The fourth will remain for as long as he can, but he has a conflict.
MR. BLAIR: By the way, one of the other folks here came up to us just at the lunch break, and many of you have done an outstanding job of preparing written testimony. So if I could ask that in your presentations, that your presentations be about 20 minutes a piece, and that will leave time for follow-up questions.
Thanks.
X12N is the organization that develops electronic data interchange EDI standards for the health care industry, property, causality, life insurance, and the reinsurance industries. These standards facilitate internal organizational communication of business transactions, including the nine required transactions within the Health Insurance Portability Accountability Act of 1996, or known as HIPAA.
Recently, X12 and HL7 as we have heard earlier in the presentation by HL7, in a joint development effort completed the implementation guide for the 275 patient information transaction. This implementation guide will be referenced in a notice of proposed rulemaking in the near future as one of the nine required HIPAA transactions.
This transaction merges the strengths of both of these standards development organizations' syntaxes to support the exchange of patient information between payers and providers as a part of the health care billing process. Use of the X12 standards provides the same consistent electronic envelope for routing and delivery of these transactions used under HIPAA, which HL7 provides the syntax and the structure for the patient information.
The 275 patient information transaction set can carry other medical record information, including images, voice, video, or any other type of information that can be put into a digital format within the 275 binary segment.
With the Insurance Subcommittee we have long recognized the complexity of the data, and the transactions within the health care industry. To assist us in developing consistent EDI transactions, we have taken on the task with business and data modeling to assure the transactions we develop are consistent with each, as well as other business transactions and exchanges that occur within the health care industry.
Within the X12 subcommittee this function is facilitated by our business and information modeling task group or Task Group 3. This task group has produced three very important documents as part of the deliverables to facilitate exploration of data and business requirements of electronic data interchange and electronic commerce transactions.
As we move through the future, we are also taking these tools of business and data modeling and incorporating it into the development process we heard earlier this morning as HL7 moves into their standard. So is X12 making this business and data model an integral part of the development and maintenance of our standards and business practices.
The three documents that have produced is first of all under HIPAA there is a requirement that the task group has created a clear and unambiguous data dictionary for all of the HIPAA mandated transactions. This data dictionary includes industry standard naming conventions, data element definitions, and cross-references to the data elements to the transactions where they are utilized.
The second document is the data model itself that spans the X12 transaction similar to the HIPAA data dictionary. This allows cross-insurance industry standardization of the data definitions.
And the third piece is the business model that defines the usage of the transactions from a business usage standpoint, including the exchange of the patient medical record information. This is achieved by the document that basically displays the document's roles played within the industry, functional definitions, business narratives, and message standards and interactions.
All of these documents are available out on the Web at the X12 site, and I have included that Web address within my testimony. These are living documents, and will continue to change, as do the business and data needs within the industry. They will evolve and continue to be changed, especially as we bring in the business and data needs across all of the requirements of the health care industry.
We hope these documents will be of assistance to the secretary of Health and Human Services in the future as an aid in determining when it is time to select a new version of the standards to be implemented under HIPAA. Currently, under HIPAA we have three sets of data dictionaries and business models as we heard earlier in the presentations by HL7. Each of the standards development organizations, X12, HL7, and the National Council for Prescription Drug Programs all have business and data models.
As we proceed into the development of patient medical record, and other organizations play a role with this development, the need for coordination will grow. There is the need for a single business and data model that can be referenced. As we heard earlier, that vehicle that we are looking at within the standards development organizations is what is the reference model.
A few years ago there was movement that started in the coordination of this activity within the standards development organizations. I believe it was IEEE that actually started that activity where they brought together X12, HL7, and other standards organizations, but it never was completed.
We would like to see the SDOs working together as we have with the development of the transactions such as the 275 and the joint development efforts within X12 and NCPDP to restart and complete this project. It is very important that this reference model be built, so that we can communicate consistently across the spectrum of the standards that are to be mandated under the HIPAA.
I'd like to thank you for the opportunity to testify today, and I'm looking forward to answering any questions you may have.
MR. BLAIR: If I may do this, could we have the three presentations, and then have the questions consolidated at that time? Our second presenter, please.
A little introduction. I'm Harold Solbrig. I work for 3M, and I'm a senior product development specialist with 3M Health Care. I'm responsible primarily within 3M for systems architecture, product requirements, and figuring out how to implement them.
I represented 3M on a number of national and international standards committees, and I think of particular interest to this organization, within the object management groups, health care domain task force, which many know as CORBAmed.
I'm not a physician, and I don't play one on television. My background is computers, networks, and systems analysts. So I have tried to constrain by answers to areas that I know a little bit about, and so some of the answers I can be brief on. I just went down the questions and answered them in order as best I could.
The first question was what are the definitions and requirements for medical information? To which I deferred largely, and I said there are people here that are far more qualified than myself to understand the purposes and uses to which shared information put.
By the way, I found the term "patient medical record information" to be an awful lot of syllables to say, and PMRI, for some reason I can't ever associate with a topic. It's kind of like this big acronym that is supposed to be three and it has square letters. So I'm using the term "medical information" as a synonym for PMRI throughout the rest of the response.
So as far as the definitions, the one thing I do want to stress, and it's been stressed this morning, so just real briefly is that information is far more than transmitting bits and characters across a wire. Within a single enterprise it is quite possible that you can get away with putting relatively unspecified information into loosely labeled buckets, and having something worthwhile happen.
But this happens only because the people within the enterprise have an implicit understanding of what goes in where, what you say, when, and the meaning of it. As you try to share this information on a larger level, it just doesn't scale. As the requirements for information sharing grow, the rules have to be made more and more explicit.
What is the role of syntax in communicating comparable medical information? I pretty much agree with what was said this morning. Classical linguistics says that successful communication requires semantics, which is a common point of reference and agreed on set of terms to describe it. You have to have experienced or seen or other come up with the words for the same things.
Pragmatics, which is an understanding of the purpose and setting in which the communication is taking place, and this is a rather important one. Why is this communication occurring? What transpired previously? What implicit understandings do we have about it?
And finally, syntax, which is a set of rules for organizing the words and terms, and coding them in a way that they can be decoded by the receiver without loss of information. And much was stated this morning. Syntax is the least important part of this problem. In fact, there are a variety of syntaxes that exist to solve a variety of different problems.
ASN.1 is designed to deal with narrow band width communications. The telecom industry evolved that one. XML is designed for human readability and processing by Web-based applications. The object management group has an interoperability protocol suite, and the open group also has a protocol called ROWS(?) that are for interactive communications between distributed components.
It's my own opinion that the choice of syntax should be left to network architects and engineers. There isn't a right syntax. As stressed this morning, there is going to be a new syntax tomorrow. XML will evolve or whatever else is here will evolve to handle different problems.
So in direct answer to the question, I would like to suggest that first of all, syntax specifications aren't health care specific. While in the early days health care found itself in the situation of having to come up with some specifications, they are no longer necessary, and they are deferring to general specifications. So if there is any federal involvement at all, it needs to be approached from a very general level.
Also, I would like to suggest that the private sector is making excellent progress in syntax specification and use. Any government interaction at this level might just serve to muddle the pot.
As a side not, CORBAmed was listed as an example of a syntax. CORBA is a task force within the object management group. Its focus is on specifying component level interfaces. It's not the name for a syntax. Or if involved at all in syntax specification, it's extremely remotely.
Question 3, what is the role that models can play in defining, communicating, and insuring the comparability of medical information? The term "model" covers a lot of turf. We need to be cautious that if we are talking about models, that we're talking about the same thing. A document that I have found extremely useful is the ISO Standard 10746, the reference model for open distributed processing.
It partitions these things called models into five different views. Included in these views are the enterprise viewpoint, the model that is used to define purpose, the scope, and the policies for an enterprise or business. This model is quite independent of even data processing. Systems analysts frequently use these sorts of modeling tools to improve process within business. Only portions of what they discover need to be computerized.
The information viewpoint is the second viewpoint. This described that sort of information that is required by the various entities to carry out tasks to satisfy the business requirements.
The third viewpoint is the computational viewpoint. This viewpoint specifies the functionality of the system. It describes the tasks that are actually performed to create or use the information as described in the information viewpoint. In here I said the RM/ODP goes to engineering, technical, and viewpoints which I give a parenthetical no, but there was some question about -- I think Col. Ray specifically asked about how do we get the other direction.
The engineering viewpoint is where you take the information in the informational and computational viewpoints and map it into some sort of computer model. While there are no formal tools -- I think tools are evolving around it -- there is some certainly some formalized process involved in how one gets from information and computational viewpoints to the engineering viewpoint.
One of the things that they stress there and I think is very important is that you clearly separate the issues. For instance, the informational viewpoint may state that a person has a first name, last name, and middle initial. It is not until you get to the engineering viewpoint that you want to say well, the first name has a maximum of 30 characters. That's an artificial restriction, and you need to understand that that came from the process of computerization, not as a rule of the organization.
Today it's the information viewpoint which is most thoroughly covered. The HL7 RIM is the most visible in the United States. There are also some comprehensive models available in the United Kingdom, Australia, and elsewhere. One of the things I need to caution though is we need to make certain that we understand the enterprise viewpoint which underlies these information models before we embrace them.
I don't believe from my own experience for instance, that HL7 and the National Health Services in the UK have the same business model, or are attempting to solve exactly the same set of problems. I think some perceived collusion occurs because they do have different business models.
As far as the computational viewpoint goes, in the past the computational viewpoint tended to be embedded within applications. We want it on faith that a software vendor understood our problems, and had solved them correctly. As our Y2K issues demonstrate right now, in some cases they may have missed.
To date, the primary group that has been focused on formalizing the computational viewpoint is the ONG's health care domain task force, CORBAmed. CORBAmed's purpose is describing interface specifications for distributed components. If it is describing if I want to locate a patient, this is how I would invoke it programmatically, or this is what would have to be supplied, and what would have to happen. It's not a very good example, by the way.
It's their stated intent to defer the information specification to HL7, CEN, DICOM, and others, and this has turned out to be no small task. As I stated earlier, for instance, the National Health Services and HL7 models have some collisions. They don't always line up.
So one of the things that CORBAmed has embarked on and I think is somewhat misunderstood is they have said we need to come up with our own enterprise model as to what we're trying to accomplish with this computational model. We need to understand what the business of our participants and members is.
It is not intended to be an information model. It is not intended to compete with any of the existing models. Rather it is intended to be a road map and a business model that just describes how the business of the people involved in CORBAmed works.
What role should the federal government play in modeling? I would suggest in the short-term the federal government needs to fund an effort to specify the enterprise model for medical information from their perspective. I find it interesting you mention the need for a single business model. I would have to question whether there is such a thing. There are many different businesses involved in health care, and each business has its own perspective.
The models need to align obviously, but the idea of an overall unified model seems like a tall goal. In fact, that's what I'm suggesting. If we are looking for a nationwide enterprise as it were, even a loosely coupled one, we need to spell out what needs to be done, and what the rules are for the business.
It's not something that is going to be readily done by the private sector. At least for public corporations, they are focused on what's best for their business, which may not be what's best for national health care.
DR. FITZMAURICE: Can I interrupt for just a second?
[Administrative remarks.]
MR. SOLBRIG: Once the model is in place, once you understand what you are trying to do, then you can start to look at what, if any, information and computational models fit your business scope. In fact, when Clem asked a question today about data sets, one of Wes's quite correctly is that it depends upon what you want to use it for.
I think we need to step back and say what do we want to use this medical information for? What are the rules? What are we doing with it? Then we can find out how well the information fits.
Question 4, are there emerging areas, standards, or technologies that can contribute to the collection, storage, and communication of comparable medical information? Good question. Short answer, yes, but the reason for it is we need to step back for a minute and see what's really happening in that statement "collection, storage, and communication of comparable information."
In a sense, we are describing a distributed system on a national level. I would recommend that all of the tools and techniques that are used to implement distributed systems, and have been used successfully on a local level, are applicable here. Not only are they applicable, they are vitally necessary.
On a local level, you often have the advantage of a tightly knit corporation with well understood, and often well mandated goals. On a national level we are talking about competing non-profit and for-profit enterprises, approaching it from different perspectives and with different goals. It's a very complex thing.
So you need to focus specifically on a set of tools, standards, and technologies that are used to manage complexity. Amongst these tools -- I use "tool" loosely I guess -- but some of the approaches described in the reference model for open distributed processing and some documents that go along with that, as Wes mentioned this morning, distributed object and component technology, and information modeling techniques.
And also because Bob Mayes isn't here, I need to throw in a plug for the work of the NCI TSL8 organization. They are working on a meta-data repository as a common means of exchanging information about information amongst different organizations. The EPA is a participant in this, the Department of Census, Australian Health Care, et cetera. It is a very impressive effort about the repository of information about information.
It is my understand that Bob and others are working with the HL7 committee to get those things organized. One of the reasons I stress that is because the sharing of medical information goes well beyond the scope of medicine. The EPA for instance, may have a lot of very interesting uses for medical information, and the medical practices, Department of Census information is useful. There are a lot of boundaries that are fairly artificial.
So again, the federal government needs to recognize that this is a national project, and as such, the specifications need to develop on a national level. I would recommend some funding if you are coming up with a new system for distributed information, to determine exactly what you want to do.
Question 5, is there a need to coordinate or otherwise facilitate the development of medical information message format standards? As the question is worded, I would say no, as long as the emphasis is on the word "message." Certain at least not yet.
The first thing you need to do is clearly specify what you wish to accomplish. Once this is completed, you should look at how best to carry out the task. So once you have an enterprise specification, once you have a good information and computational model, then it is time to focus on the engineering portion of the specification. Included in that may be the decision to use messages; it may not. A lot of that depends upon what's going on in the business.
As I computer programmer, I don't know whether I get this cartoon right, but I always enjoyed it. A manager is announcing to a programming staff, "You guys get started coding, and I'll go out and find out what they want us to do." That's a real temptation for a programmer, because the technical stuff, by gum I understand, and I can start doing today. The business rules and what you actually are trying to accomplish with this takes a lot of work and a lot of asking.
So I would advise let's not define syntax, let's not settle on message requirements or start writing code, but let's work on a model and make sure we understand what we are trying to do with the system first.
Thank you.
I would like to talk a little bit today about what health care information is. I think we really need to ask that question to be able to understand what the patient medical record information consists of. Today, the patient medical record is mostly documents. It's paper-based documents.
Documents are a convenient conceptualization that we as humans have come up in order to carry and preserve information. Documents also organization information in ways that we can understand the information. And documents also have visual clues about information that also help us understand what type of information we might have.
The patient medical record is a collection of information that contains narrative text from providers, and it contains other types of information that might be in other formats, such as x-rays. The patient medical record information is document-centric today. If we are going to move to an electronic form, we should think about how we might be able to create electronic documents that map the paper ones that we have today.
Some of the issues that we have with the PMR are that we have all of these paper documents that somehow we need to get into an electronic form. There are no standard processes for collecting this information. There are a variety of different heterogeneous health care software applications that collect this information in some proprietary and some standard ways.
We have multiple formats. We have no standardization of the visual presentation of the documents that we have in the patient medical record. We're also trying to apply multiple technologies to the patient medical record. We're trying to use object oriented models. We have some word processors files that might be in electronic format, and we have databases which may be coded or not coded.
What are some of the information technology needs that the patient medical record has? Well, one is that we would like to have a set of regular and standardized types of documents that we can find in the patient medical record. We would like to be able to provide some kind of context for the narrative text that exists there, so that we know where the diagnosis might be in a document, or whether the symptoms list might be.
If we know the context of the information, we can ask questions of this information. We can say what allergies does this patient have? What the current medication was. What are the previous medications that this patient has been on?
Some other technological needs we have for the patient medical record are that we would like to pick a technology, or we would like to make sure that the technology that we are picking today, that the information included in this technology is likely to survive changes in the technology over time.
We have a technology system today that is built on updates and revisions, and this is very costly to people. Also, information does not necessarily survive these changes in the form that we can still access it.
We need timely access to the information in the patient medical record. We would like to have it at the point of care. We want the ability to locate relevant information. We don't want to locate all the information in the patient medical record. We want to locate specific information that we are searching for.
Ideally, we would like to be able to view this information that is in the patient medical record in different ways. We would like to have it on a piece of paper to take with us. We also might like to see it on a Web page.
XML is a way of expressing documents in electronic form. It may be a potential solution to the patient medical record. I'm going to repeat a little bit of what happened this morning, because I think that XML is a difficult technology to understand in some respects, and I think it's important to get some of the concepts and terminologies about XML down, so that we can have a discussion about it.
XML is Extensible Markup Language. It is an acronym. It's an activity of the W3C, which is the World Wide Web Consortium. It is promising to offer new and improved Web applications. I'm going to go so far as to say that HTML and Web pages were as significant to the adoption of the Internet as I think XML for patient medical record information will be in health care.
One other thing about XML that Bob brought up earlier today is that it's a subset of SGML, which will become a little bit important in my talk.
I think the most important thing about XML, however, is that it communicates information in way that both humans and computers can understand it. It's the only technology that I know of that I can read an XML document and I can understand what the information is, and a computer can process it in ways that it's able to process an object model or other types of representation of information.
XML allows the information to be re-purposed in different ways. You can display it as a Web page, or you can print it, or you can even translate it to audio, or from text to audio. The other thing about XML is that it allows for vendor-neutral interchange. It is independent of hardware and software platforms. If you think about Web pages and how they are able to be transferred all over the world, and understood on any type of computer system, the same is true for XML.
I'm going to make a statement that the XML documents that are authored today, will still be readable ten years from now. The reason I'm going to say that is because XML is a subset of SGML. SGML has been around since 1986. Any SGML document that was created in 1986 can still be read on a computer system today without any special software or any special processor. Again, this is the only technology that I know of that has survived evolution.
Well, let's go back to what is information, and what is the information in the patient medical record? Well, information is conveyed in two ways. We have the content of the information and the format. The format provides a visual presentation of the information.
Up here on this slide I have a prescription. The prescription may be a 4 x 5 inch piece of paper, and it has a certain format, but from across the room you can recognize that that's a prescription. You might not be able to tell what the prescription is for, what medication, but you can make a visual recognition that this is a prescription piece of paper.
The other part of the information is the content. This is the information you can't see from across the room. This is the patient name, the medication name, the date of the prescription, the provider, the form, that type of information.
I have now put up an XML example. As you can see, XML adds markup or adds tags to information. Here is an example of a prescription document. We have something called a start tag and an end tag. The very first thing is a prescription identifying document as a prescription.
I'm going to briefly go through a few XML concepts who have the same terminology and the same conceptualization of this technology. Elements are also called tags, and I won't get into the philosophical differences between the two here. The tags give boundaries to information. So that in this example, we have a medication name. We have some content. Tylenol is the content. We have an end tag for medication. We know where the information begins, and we know where it ends, and we know where the content is.
Typically, this marked up information that you see here, that name, does not appear in the published versions. So this information is for the human to read, or is also for the computer to process. But the most important part about tags is they provide context for information. We now know that Tylenol is a medication name.
Attributes are another piece of XML. Attributes provide further information. They modify the information in some way. They are immediately specified after the tag, and they are usually used to represent information that is processed by a computer. In the patient medical record we could think of attributes as being in the place where we might put coding such as ICD-9 or CPT. Here I have an attribute on the medication name, which is generic. Generic equals Acetaminophen, which is the generic name for Tylenol.
DTDs are document type definitions. I like to rearrange the words a little bit to understand what they are. DTDs define the type of document. So we might have very types of documents in the patient medical record. We might have a mammography report. We might have a portable chest x-ray. Those are all types of documents.
DTDs themselves define the structure of the document. They say what kind of tags can be in this electronic document and in what order, and how many times can this appear. They also contain the attributes.
This is a graphical representation of what DTD looks like. As you can see, this is for a prescription. It has the different pieces to it that says that this prescription report has a report date, some patient information, a prescription, some physician information, and a signature. Inside the patient information tag there are further defining pieces, such as the patient name, the address, the birth date, and sex. XML continues to build on these blocks of information or these concepts.
There is another standard called XSL which is Extensible Style Sheet Language. What this does is this takes that formatting piece that I was speaking of and applies visual presentation to the XML documents. So if we want to say that we always wanted to see the diagnosis tag represented in Times Roman 12 point bold, the style sheet is the place where we put that information.
We can also reorder the information, or omit information that we don't want in the original document. So these are varying ways that we can present the same information from a single source for different purposes.
XML on the Web looks exactly how it will as an HTML page, but as you can see, on the left-hand side of the screen there is further context for information. We have the patient identification number. We have the patient name. We can locate that information within this electronic document.
The same information in HTML provides no context for the information. We have a heading 1, which is patient information. We have a paragraph of Jane Doe. We have our medical record number. We have no context. We cannot find the information that we need to in HTML. Anyone who has done any surfing on the Web knows how frustrating HTML is when you are trying to find information.
In this example I just did a search on refill and prescription and I came up with 969 pages, one of which was the South Carolina General Assembly, and that's because there is no context in the information. Why that came up, I don't know.
So XML DTDs, the document type definitions, are very important for health care, because they will provide context for information. They will also provide a document information model for the different types of documents we might find in a patient medical record.
DTDs also allow for a high level agreement on structure. We can say that we have a mammography report, and it might have six sections, and they are all called XYZQP. With DTDs we can also standardize the style sheet. So we can standardize the presentation of the information.
However, I'm going to put out a premise which I believe is true. I have been working with XML and SGML in health care now for several years. A set of document types for health care documents and patient medical record don't exist. Nobody knows what that set is. Nobody knows what those documents look like. Nobody knows the structures of those documents.
It's not known whether these documents have anything in common. We don't know whether they have identifiable structures. We can pretty much probably guess that some regularity exists, and that we will find the types of documents, and we will be able to enumerate those types.
The other premise is that there is not one standard for describing the tags found on XML documents. I often get asked the question, where is the DTD that I can go to for an encounter registration? I have to say, let me know when you find it, because I haven't been able to find it yet.
I thought I would just kind of quickly give a summary of XML standards, at least from my perspective of where things are with XML in health care today. We have frameworks for information exchange. These are basically sender-receiver types of relationships, and they are also all about exchange. They are not necessarily about describing an electronic document. These include HL7, as you heard about this morning, X12, some other XML-EDI efforts that happening.
Then there are services for health care information. What services do is they provide further information other than send and receive. They have requests unfilter. You might ask for certain health care information. Each one of the framework and the services are both looking at XML as a syntax, and they are both looking at XML for representing information.
There are other research activities in XML that are occurring, and these are occurring in CEN and in ASTM. These go back to the question this morning about elements versus attributes. These are where some of these debates are happening.
But then we have this large set of paper-based forms and documents that we have not addressed, and how we will get these into an electronic format. Some of these forms might be the standard governmental forms such as the HCFA 1500 or some of the CDC surveillance forms.
We also have transcribed documentation. The ASTM E31.25 effort is working on the transcribed documentation, but I think some of that effort needs to incorporate some of the paper-based forms that we have today.
So what is needed for XML in health care and the patient medical record? Well, we need to have some type of standardization of the clinical document types expressed in XML DTDs. We also need to be sensitive to the fact that the W3C or the World Wide Web Consortium is the group that is responsible for the specification of XML, and that the DTD syntax is likely to change in the next year. So we need to be able to, whatever we produce today, be able to transfer to this new syntax.
We need to accelerate this process of the new DTD syntax, because without knowing where we are going with the description of an electronic document, we can't really take advantage of all the aspects. Some of that was touched on this morning. We were talking about putting rules into these XML documents. Right now as DTD stands, you cannot put rules on top of this information. With a new syntax for DTDs, it is likely that this will be possible.
We also need some type of standardization of government forms as I said, the HCFA 1500 or CDC surveillance forms in XML, so people can go and grab a DTD and create these XML documents, and know that they are using standard tag names, or know that they are using standard structures. That leads to a common set of XML tags for health care that relates to some vocabulary or some vocabulary that makes sense for XML tagging. We also need to develop XML style sheets that will give a consistent and standard presentation to the XML documents.
What role might the government play? Well, I have worked and had the benefit of having many colleagues who are here in this room that I have worked with over a period of time in different standards organizations. One thing that I found is that there is no organization that facilitates the communication among these different groups.
All of these groups are very interested in XML and how they use them for their own specific purposes, but the groups don't often talk together, and it takes a lot of work between individuals to make sure that the groups talk together. Specifically, in relation to XML activities, I think this would be helpful.
It also would be good to have type of oversight organization that was a collection or a repository of all the different XML activities that were happening, so all the different XML DTDs could be accessed from one place.
As I said before, the creation of DTDs for standard government forms; I believe this is needed. I believe resources to accelerate the ASTM E31.25 effort to reach a minimal set of document types as quickly as possible is one of the activities that could happen in the next year or two that would significantly contribute and help the patient medical record information.
Resources to accelerate the future DTD syntax that is happening within the W3C. And a facility for verifying that the documents you have in your patient medical record in an electronic form conform to some standard.
Thank you.
MR. BLAIR: Rachael, thank you, Harold and Gary. I would like to move right on to the questions. According to our schedule we now have about 35 minutes for questions. Simon, maybe you could help me. Let's give preference first to the committee members for questions, and then for the broader audience. Simon, is there anyone raising their hand on our committee?
DR. FITZMAURICE: I've got one. That is, when a document is in XML and you transmit it say to me, is there a way the computer can check the patient identification to see that it's a valid patient ID number, can check the date to make sure that it's year-month-day rather than day-month-year? Can it pick apart those elements and work it with to say yes, this is a valid date?
MS. SOKOLOWSKI: Yes and no. I hate to echo what was said earlier today. There are some rules you cannot implement in XML with the syntax that exists today. You can't, for instance, check the content Tylenol, in the example I gave, and verify that the generic name is really the generic name that goes with that. That's a rule that you would have to put on top of the information in the document that would say when you see this particular word, it needs to have this other word.
However, you can create date formats, and you can specify by which date format you are going to receive. There are a variety of different ways you could do that. So you could say I have year-year/month-month/day-day, or I have month-month/day-day/year-year-year-year.
DR. FITZMAURICE: Then when they send it though do you need to pull it out of the document, put it through another routine just to make sure that they really did conform to what you asked for?
MS. SOKOLOWSKI: Yes.
DR. FITZMAURICE: That's not part of XML?
MS. SOKOLOWSKI: No, not today, but that's why I think that accelerating the W3C activity for the future syntax of DTDs will take care of some of those problems that exist today.
DR. FITZMAURICE: It seems to be essential, because if a caregiver gets some information, they will want to know that it's accurate and valid, and there seems to be no validity test. If it looks nice and it's readable, but XML doesn't contain validity checking.
MS. SOKOLOWSKI: That's correct. I work with a variety of different clients, one of which is struggling with that problem right now. They have XML transactions, and they can't verify that the information is really the information that is required, because information is variable, depending upon what type of information you are accessing.
DR. FITZMAURICE: Now on the other hand, if somebody is in an HL7 Version 2.3 or 2.3.1, then can -- I guess maybe you have to have an engine at the end that receives it and does the same kind of checking. Maybe the same is true of HL7 transmission message standards, that it doesn't validate the format of what's in there, and say yes, this is a legitimate date, or am I wrong?
MS. SOKOLOWSKI: The HL7 has a date/time data type that will specify the syntax of a date and time. It is up to some type of processing to figure out whether you have actually put that information in that right format. It is totally possible to send the wrong information in the right place, but then you still need some kind of validation to occur on that information to make sure that it's correct.
MR. SOLBRIG: To a degree, what you are talking about is the richness of the type language. Not that I'm advocating ASN.1, but abstract syntax notion 1 probably is the richest type specification syntax generally known. It does have quite a bit of ability to state that explicitly. But still, when you are talking about accurate and valid, there is a point where you go well beyond type specification. I mean is the address valid for instance? You need an address database to check that. The boundary gets pretty fuzzy.
MR. BEATTY: One of the activities that is currently going on with X12 is we are going through a pilot project with our strategic implementation task group and working with XML in defining the X12 syntax as XML tags to carry through the structure and the knowledge base that we built within X12 forward in an XML world. Right now they are going through and actually building and going through a pilot project using those tags.
That can bring in the same level of syntax checking as Harold had talked about as far as some of the formatting validation. But when you start getting into some of the data levels, it is almost impossible to do that level of validation.
DR. MC DONALD: I have two questions, one tiny one and one big one. In the XML tag thing, is there a way to get a copy of that XML tag strategy? Because this whole business of a hide, the side tags and all, it would be nice if all the standards groups were sort of informed of the strategies the other was thinking about.
MR. BEATTY: I believe if you go to the X12 Web page on the Internet, which is similar to the same address that I had within my testimony, the strategic implementation task group does have a Web page that describes the activities that they are currently going through in the pilot project.
DR. MC DONALD: Does that need a password?
MR. BEATTY: No.
DR. MC DONALD: My other question, Rachael, you have described a DTD or a document for mammograms, and this kind of gets to sort of a deep philosophical question about what level of abstraction do you create these critters at. Now Y(?) mammogram versus high squeezed mammogram versus x-ray study versus diagnostic report, how do you pick? Or is there a strategy in the XML world of picking what the object is more or less in which things become instances versus which things are -- would you have a special report for potassium?
MS. SOKOLOWSKI: That really comes through something called document analysis. That's why you would have to take a look at what are the paper-based documents that we have in the patient medical record today, and what kind of commonality do we have across these. Some institutions might only have mammography reports, they might only have a radiology report type. We won't know the answer to that question until we are able to actually do some type of analysis of the types of documents that exist in the patient medical record.
MR. SOLBRIG: If I could address that also real quickly. It is interesting, because your question had little or nothing to do with XML. It had to do with sort of information is available, and how should we communicate it. I would like to encourage people to make sure they clearly distinguish the difference between what do we want to do? Is it important to know that distinction in our business versus can XML help us to do that? XML can help you to do whatever you decide to do.
DR. MC DONALD: I know that, but there are a different set of cultures in different groups. I just was trying to get a sense at what level of abstraction the culture lived.
MS. FRAWLEY: Just to follow-up on Clem's point, ASTM has a work group on medical record documents and formats. We have been feeding information to Rachael. What happened was AAMT, the American Association for Medical Transcription and AHI in May did a survey. What we did is we targeted organizations that transcribe medical record documents, and asked them to tell us what documents they were transcribing, and to send us copies of their formats.
Then at our fall ASTM meeting we actually went through the documents. I had 70 OR reports, and I couldn't even find, among 70 OR reports, commonality among data elements. There was a group that worked on histories and physicals, there was a group that worked on consultants' reports, a group that worked on discharge summaries, and then another what we called special procedures, which would be some of the radiology and laboratory reports.
These were provided to us by transcription vendors and actual institutions as indicative of what type of report you would find in their record. If we want to talk about moving towards computer-based patient record, when you don't even have any standardization, we couldn't even find an operative report agreement on what the common data elements were. We had operative reports that didn't even tell us who the anesthesiologist was. We knew maybe the name of the surgeon.
But simple things that you would expect to see, start time, end time, procedure, whether a specimen went to the lab, some description of the findings weren't even present. So some of the work we have been doing there has been feeding into Rachael's activities. It is very disconcerting to realize that medical records are as poor. We would like to think that they are better, but they're not. We're really starting off from a really poor place.
So our problem was trying to struggle with where do we start. So we went with what were the most commonly transcribed documents, and picked that as a way to go to kind of look at this and get our arms around it.
MR. BLAIR: Rachael, did you want to reply to the next question.
MS. SOKOLOWSKI: No, just thank you Kathleen.
MR. BLAIR: In other words, it echoes the challenge and the difficulty that you have in trying to derive standards.
Kathleen?
MS. FYFFE: We did not hear from the American Association for Medical Transcription. Will we get written testimony from them?
MR. BLAIR: Yes, Claudia Tessier was to testify today. There was a death in her family. She advises me that she has sent her testimony. I think we'll try to do the best we can. We will probably have another day covering message format standards. As we wind up getting issues out of today, we will probably focus in on those some more. Maybe that will be another opportunity for AAMT to testify.
MS. FYFFE: Kathleen Frawley, you might be able to comment on this. AAMT was listed as a standards developer. Have they developed their own standards?
MS. FRAWLEY: No. Claudia was probably going to be testifying in her capacity as chair of ASTM E31. Claudia is the executive director of AAMT. She does chair our committee E31 at ASTM. She has been leading a lot of the effort, particularly in documents types and formats that I was just describing. So I suspect that Claudia would have been here testifying on behalf of the ASTM.
MR. BLAIR: As a matter of fact what is it? ATSM E31.22?
MS. FRAWLEY: Yes.
MR. BLAIR: Simon?
DR. COHN: I'll move off of XML for just a second, and I just wanted to clarify a few comments from you Gary, and see if I can understand whether you are in agreement or disagreement with some of our previous speakers. I had asked the question right after lunch to Abdul-Malik Shakir, asking about the opportunities around whether there was some need to coordinate or consolidate overall models potentially at a higher level than the reference information model of HL7.
He indicated that that was not going to be useful, that instead the issue was mapping between models. And that probably is what ought to be done. Now in your testimony, you talked about the need for coordination and the need for a single business and data model that can reference, that appears to relate to the work that is ongoing between X12, HL7, and NCPDP. Can you clarify whether you are in agreement, disagreement?
MR. BEATTY: Actually, that is in reference to the reference model, and not the business and data models in that each of the organizations do have their own individual needs. As we heard this morning, the reason they are different is because they are coming from different perspectives.
So from an HL7 standpoint, they are looking at more of the internal organizational communication that needs to transpire between the very systems that need to be able to communicate within a health care setting.
In the X12 world we modeled based on the need to be able to communicate information interorganizationally, from one organization to another. There are differences between the data models. What we were doing originally in the IEEE activity was essentially creating the reference model that resolves the differences between the various data models so that we would know that an entity in X12 is something else in HL7, and the reference model kind of brings the two together, so that you know that you are talking about the same things. That their attributes are similar or the same, but they may be called two different things within two different business and data models.
So without creating one single business model, it allows the data models to still represent the domain-specific areas that the models represent, but still be able to bring all of the business directions and designs and attributes of those all in together into one place.
DR. COHN: Jeff, do you mind if I ask a follow-up question on that?
MR. BLAIR: Sure.
DR. COHN: Harold, please chime in, because you probably have some opinions about this also. If one were to recommend something like that, what would be the business case, and would it help? Is it just sort of a good idea? Would it matter nationally?
MR. BEATTY: It does matter, and I can use a case that we are going through right now as we implement electronic commerce within our own organization. We are a very large user of both HL7 and X12 standards. We need to be able to implement eligibility. The information comes to us, and from an electronic commerce standpoint, all in an HL7 format. We need to be able to communicate that out to the outside community, with whom we use an X12 transaction.
Currently, the verbiage and terminologies and so forth that comes to us from an HL7 standpoint is a little bit different than the X12. Common reference models would help us and be able to facilitate the communication from the intraorganizational communication that needs to transpire, to the interorganizational communication that needs to occur, and actually facilitating a swifter implementation of those technologies.
MR. BLAIR: I have a question that I'd like to address to Rachael. Could you help the committee understand a little bit better how -- you are co-chair within the HL7 SMGL/XML/PRA as well as ASTM. Could you clarify what the difference is and the role of the mission between those committees?
MS. SOKOLOWSKI: Sure. The HL7 SMGL/XML Special Interest Group has three current projects that it is undertaking. One is expressing the HL7 Version 2.3 syntax in XML. The other is mapping the reference information model or the Version 3 representation of HL7 in XML. And the third is the patient record architecture activity. The patient record architecture activity is based on how you exchange XML documents. What is the appropriate DTD for information exchange.
As Bob said this morning, there are two types of DTDs. There is the authoring DTD. That would be the DTD that a software application, what a medical record bender might have. And then there would be a standard exchange DTD that those vendors would map their local authoring DTD to the exchange DTD. Then information would be transferred from point to point using that exchange DTD.
The ASTM is I should say, a newly formed activity. It is very young. It was formed in November 1998. Its focus, as Kathleen was saying, is to look at transcribed documents and to describe the document description as it is on paper. So there are two different focuses. One of the HL7 focuses is message syntax; the other is to create a DTD for exchange. Then the ASTM is really looking at how can we describe these paper-based documents in electronic form.
The two efforts really do need to cooperate, because if you have DTDs that are local DTDs for a radiology report and you want to exchange it with somebody, then you would your standard radiology report DTD, and you would put it in the patient record architecture format, and you would send it off to some other trading partner.
MR. BLAIR: Woody, I think you have a comment, and maybe Bob might also have a comment?
DR. BEELER: I suspect there is yet unanalyzed overlap in some of what the ASTM group is doing in the templates work. Part of the challenge with that is that the templates activity has been evolving fairly rapidly of late. It has been an idea in people's minds for a while, but it has not been formalized where we could look at it and talk about it, which is simply a matter of time duration.
Whether that will be a dramatic overlap, a compatible over, how we will address it, I think is an open question. I would agree with the other characterizations, however, that Rachael made.
MR. BLAIR: Bob or anybody else either on HL7 or any other committee members that had any comments?
DR. FITZMAURICE: For Gary -- Gary talked about data dictionaries. You said we have three of them, X12, HL7, and NCPDP. There is also a data dictionary at the Department of Defense. Is there a case for having a single national data dictionary, or undertaking an effort to have a single national data dictionary that everybody can pull items off of, say this is what it means? And who should do it?
MR. BEATTY: There are three working documents out of Task Group 3, the first being the data dictionary, is more mandated out of the HIPAA legislation, one of the requirements. Not only were there standards for the transactions, but also the need for a clear and unambiguous data dictionary. That document that they produce is solely focused on that one activity.
The business and data modeling is more on a global standpoint from within our own standards development organization. As mentioned, there are others. I don't mean to all inclusive of the three SDOs. There could be others out there, as you mentioned. Does there need to be a single one? I don't think so. I think if there is a single reference model that cross-references all of these, that we can gain just as much strength out of that, because there is the domain specificity of each of those data and business models.
DR. FITZMAURICE: I have a question for Harold. Harold, what is object-oriented technology? Is it a competitor's XML?
MR. SOLBRIG: Object-oriented technology is a point of view of instead of looking at things as data elements, as looking at them as a series of processes to invoke. So instead of admitting a patient as filling out a message where you put the AD in the segment, and you put the patient name and the patient number, and you send the segment across, it is specified on a level of abstract where you say you invoke a routine.
I need to specify this. This is object-oriented programming. This is a small aspect of it. But it is where you invoke a process. You say, all right, to admit a patient you make the following call. So if you are programming in C++ you make a procedural call in C++, supply this information, and miracles will happen.
I guess the best way to exemplify the difference, and to also show where it doesn't contrast in any way, shape or form with XML is to take the notion of TCPIP stack. TCPIP -- well, I shouldn't say stack. TCPIP as it was specified, is a message syntax. It says that if you have the following bits in the proper order, and you send them across the wire, you can indeed connect to a file, or this string of bits will ping a site, and a site will respond if it exists.
What happened in the late eighties and early nineties is everybody said this is great, but I've got to program. How the dickens do I make this happen? Not everybody wanted to write the code that transformed between what they wanted to do and the message. So what happened is people began developing an abstraction layer on top of that.
I'm trying to think of some of the names. There was the TCP stack. There was certainly the Berkeley socket stack. There was the Netware stack. There was the Microsoft stack, and there were several others that were all different means of filling out the same underlying message. They quickly arrived at the notion that this didn't work, because were having to ship software that was written five different time, one for each TCP stack.
So we finally came up with a procedural definition that says, all right, to connect to a file, make this call or this file name. The object-oriented specification is an attempt to do this up front, instead of having it evolve nationally.
DR. FITZMAURICE: Do you have to agree on the elements within the object you are defining, both sender and receiver, in order for it to make sense, just like you would for XML or any other transmission?
MR. SOLBRIG: I'm glad you put it that way. Yes, you do to the extent that you do with XML, and no more. They are compatible technologies, and so to the extent that you choose to agree or not agree is the extent that you need to choose to agree or not agree with the object technology. An important distinction, however, is with object technology or the object/component approach, to throw some more buzz words into the soup, is you have to decide upon what you want to have happen.
That is one thing that has been evolving between the HL7 Version 2 and Version 3. HL7 Version 2 was just kind this notion -- and if I'm giving a bad picture, please throw something at me -- but you threw a message across the wall, and the receiver did with it whatever they thought was appropriate. An admit message came across the wall, and it could either mean that a patient has been admitted in my system, here is the information for it, or it could mean please admit this patient.
The model in object technology focuses on that piece. Instead of being information-centric, it says what are you trying to accomplish.
DR. FITZMAURICE: You mentioned that there was a similarity between the functions that XML and object-oriented served. I asked if the data elements are the same, then do you really get along well. Now let me ask, is there such coordination between object-oriented technology and XML that the data elements do really mean the same thing? Are you working on a common data dictionary, for example?
MR. SOLBRIG: XML, not that I'm aware of, because we're working on a more abstract level. We are working very closely with the HL7 RIM. And we want to make sure that the data elements, as defined in the RIM, line up with the data elements that are communicated through these procedural calls.
To the extent that the RIM matches to XML, that's one direction it will work. There is also a very obvious direct path, and that is that the OMG has several interoperability protocols right now -- IIOP, Internet, DCIOP for DCE. They are about to the point of arriving at an XIOP, which is a fairly direct finding between the specification and XML. There are too many paths.
DR. FITZMAURICE: So is object-oriented technology more related to modeling than it is to transmitting a message?
MR. SOLBRIG: Yes, I think that's a fair synopsis, although -- I mean object-oriented technology is one of those words that encompasses such a variety of meanings, that it's hard to say what it is anymore. But certainly the focus of CORBAmed is more on the computational model on what events need to occur, and what processes you need to invoke to make them happen.
It's basically if I've got a Basic Visual program and I want to admit a patient, what does the call look like to make it happen is their product.
MR. BLAIR: We have two other questions waiting in the wings, one from Woody and one from Wes.
DR. SUTHERLAND: Simply an observation. I think there is indeed a dichotomy between the position that Gary took and the one that we did. I don't know that it's by any means irreconcilable. I do know that it's one we have not discussed of late. In when Abdul-Malik Shakir left I sort of corralled him on the side and said, okay, what's your position on the notion of a common reference model?
As you may be aware, I chaired the Joint Working Group for a Common Data Model for the four years or so of its existence. Abdul-Malik was an active participant, and indeed held a subcommittee chair position within it. So we were more than familiar with the process and the intent.
I think the challenge is that we, as collaborating SDOs, must attempt to align our models as best we can. That's the first challenge. In fact, within the meeting last week where we doing RIM update, one of the things we received was a substantial update to the area surrounding insurance plans and so forth, informed very strongly by what the X12.N model was, and what the X12.N view was, with the goal of getting closer to a representation that would not map directly to theirs. I suspect there are areas of ours where we should try to help them incorporate it into their model.
The challenge of building a common reference model, however, that has the same level of aggregation, the same level of detail is that you spend a great deal of time and energy to develop an artifact in the proper sense of the word, something that is built, that is not used by anyone.
If it is not used directly by anyone, it always is suspect. I think as Gary indicated, and as we have, the core dependence on the models is something that we rely on. It means that in reality we will undoubtedly have to retain -- control is a nasty word, but it's probably the right word over the direction of the RIM.
We would like to, and indeed are very open to working with other SDOs. But there will come a day when there will be a point where the groups probably can't agree. At that point, the two models will differ. I don't know that having a common reference information model is worth the energy it takes to build it, as opposed to doing: (a) a strong job of collaborating between them; and (b) understanding what the mappings and differences are.
Maybe you could argue that the disclosure of those mappings and differences is a reference model. But when I hear that word, a common reference model, I hear of the thing with the same number, probably more classes, more attributes, a whole whale of a lot more associations, and maintained for simply the purpose of being there. I worry that we have got better ways to spend all of our modeling energies amongst all of the groups than to try to bring together a single reference information model.
MR. BLAIR: Wes, we have about five or six minutes. Depending on the length of your answer, we'll see if there is time for another question after Wes.
DR. SUTHERLAND: Can I make a comment back on the object technology question, because I think it is worth clarifying. The thrust of the W3C -- I'm Jeff Sutherland, and I'll be on the panel tomorrow. So I can say more tomorrow, but just a simple clarification.
The thrust of W3C is to enable a distributed object computing environment on the Web. XML is a fundamental standard for that enablement. There are already direct translations between JavaBeans and XML. JavaBean is a computational programming language environment. There is also a standard within the OMG for representing any object system in XML for transport between one object-oriented design tool and another. So there is really becoming a one-to-one isomorphism between the XML world, and what we have known as the object technology world, and they are interchangeable.
MR. BLAIR: Wes?
MR. RISHEL: I want to make a couple of definitions, and then respond to Harold "throw it over the wall" comment. Object-oriented text is a powerful idea that has come about in the last decade that as before we thought about data and we thought about algorithms, they were two separate worlds. It combined them in a very productive way.
Some of the benefits we have seen from that are improved programming. Object-oriented programming languages make programmers more productive, make the systems easier to maintain. Improved analysis, improved interface between domain experts and technologists, because object-oriented analysis as combined, has proved to be a powerful way to get the two talking to each other.
I marvel that the domain experts in HL7 come to one meeting and immediately believe they are experts in modeling. It should be two things; one, the power of object-oriented analysis, and two, the fact that they are or work around doctors.
The object-oriented programming model gave rise to a family of technologies that we often call software components. The idea behind software components is one that is common in the electronics industry. I don't make every possible resistor in the world. I make standard resistors, and you design your circuitry. Use standard resistors and everybody saves money.
So if I could somehow make software components that would plug into a lot of different operations, a lot of different locations, money would be saved. CORBA is an example of a component technology.
The object-oriented programming school developed properly, a very tight computational model. By that I mean they very closely specified what it meant when this object, which was a combination of data and programming, interactive with that one. HL7 has been loose, for reasons we have discussed, but it has never been absent the notion of the combination of data and function.
The admit message says do what is necessary when a patient is admitted, and here is the data to do it with. Now that's a lot looser than saying admitting a patient involves creating an encounter, doing a whole bunch of other -- creating a medical record or not, and all those sorts of things. But it nonetheless involves some combination of function and data.
It is noteworthy that the component technologies are having some of their strongest wins in systems integration by loosely coupled connections. For example, CORBA has what is called a messaging service. Now what does that mean? It means a way to do essentially what HL7 does, send a loose message from here to there, rather than a traditional object-oriented programming kind of interface.
IBM, Microsoft, and others are all demonstrating major systems integration wins through products that are based on components with all the benefits that comes with interplay, and an operational model that is loose, that is to say messaging.
So I don't believe that one can argue that a really tight computational manner is better or worse. But I do believe one can argue that where the goal is to take systems that were designed separated and built separately, and make them work, the messaging model is very important. Component technology is a good way to implement the messaging model.
MR. BLAIR: Thank you, Wes. I'm sorry, Harold, did you have a response?
MR. SOLBRIG: Yes, I'd like to respond real briefly first, to apologize to Wes if I in any way typified HL7 incorrectly. I understand that the messages had some actions in them. But also I think Wes's comment stresses one of the things that I think is important when analyzing any models. In fact, when Wes says that the component technologies have the strongest wins in loosely coupled connections, this is true if your business is loosely coupled connections. Indeed, the messaging model asynchronous delivery, if your business is communications between computer systems, it is an obvious solution.
HL7 in their mission statement states quite clearly, our business is communications between computer systems. The OMG has a slightly different approach, and actually is involved in a slightly different business. They are looking at, as Wes put it very well, distributed components, and how can we share not systems, but subparts of systems.
How can we partition this into something so that I can deliver a service, a patient identification service by itself that functions well in the total enterprise without having to build a system? I think in some ways to back up to the business models of the two organizations and look at the distinction between their purpose makes clear a lot of what seem to be direct conflicts previously.
MR. BLAIR: Let me call this panel to a close now. I would like to take a ten minute break to 3:15 p.m. That will get us started on time. Let me just mention that this next panel is going to be the vendors in the sense the vendors that wind up using the message format standards. So again, I would invite all of you to stay, as they wind up indicating the experiences that they have integrating the message format standards into their products and services.
So we are adjourned until 3:15 p.m.
[Brief recess.]
MR. BLAIR: Is our next panel assembled? Could I have you start from left to right, and introduce yourself. Again, to try to stay on schedule, if you could please target for 20 minutes for your presentation, we will go one right after another. We will accumulate the time for the questions. I think that that will work well.
Who is our first panelist?
I want to thank the panel for the invitation to speak today on the subject of message format standards on behalf of Hewlett-Packard and the Andover Working Group. Hewlett-Packard is a leading vendor of computer hardware and software systems, clinical measurement instrumentation and information systems, bioscience instrument system, and laboratory data and information management systems.
The Andover Working Group, consisting of over 300 member organizations, was founded by Hewlett-Packard in 1996, with the objective to accelerate and broadly deliver standards-based solutions for health care which feature plug and play interoperability across the continuum of care.
Hewlett-Packard and the Andover Working Group believe that heterogeneity is a fact of life in the health care information infrastructure today, and for the foreseeable future. Independent of whether heterogeneity is the result of "best of breed" architecture, a consolidation of formerly independent organizations, or of government mandates for electronic communication of health care information, interoperability of health care information in a heterogeneous environment is a top priority of health care information technology executives.
Health care message format standards, which mirror the loosely coupled organization model of much of the health information infrastructure represents an important paradigm in the communication of both administrative and patient medical record information in a heterogeneous environment.
The experience of the Andover Working Group is that precisely defined profiles for message format standards, coupled with component middleware supporting implementation of those standards offers the potential for significant acceleration of the adoption of message format standards.
Now to turn to the questions, and as Harold said, Not being a medical expert, I turned to some who are for some definitions. The first was definitions and requirements for patient medical record information. Attempts to establish an authoritative definition for the structure and content of the patient medical record are proving to be somewhat illusive, thereby complicating the issue of providing a precise definition of patient medical record information.
The Institute of Medicine provides the following definition of the patient record. "The patient record is the repository of information about a single patient. This information is generated by health care professionals as a direct result of interaction with the patient, or with individuals who have personal knowledge of the patient, or with both."
AHIMA gives an extensive definition in terms of type of information contained. For example, the contents contained in an identification sheet, problem list, medical record, history and physical, progress notes, physician's orders, imaging and x-ray reports, electrocardiograms, lab reports, immunization record, various types of correspondence, authorization forms, operative reports, potentially anesthesia reports, pathology reports, recovery room records, vital signs graphics sheets, and discharge summaries.
The IOM studies distinguish between a primary patient record and a secondary patient record. The primary patient record is used for the health care professionals, while providing patient care services to review patient data, or document their own observations, actions, or instructions.
The secondary patient record is derived from the primary record, and contains selected data elements to aid non-clinical users, i.e., persons not involved in patient care, in supporting, evaluating, or advancing patient care.
PMRI supports the work flow associated with the care of a single patient by supporting communication among health care professionals for purposes of planning and delivery of care, and providing legal record for verification of services and treatment. When aggregated, PMRI provides a basis for population-based research.
The multiple uses and users of PMRI imposes a requirement for comparable PMRI, which will be defined as semantically equivalent alternative representations. Information represented as an abstract data type can be mapped to and between alternative representations without semantic loss. For example, the notion of a temperature can be represented in either degrees Fahrenheit or degrees Celsius, and can be converted between these two with no semantic loss.
Reasons for choosing alternative representations might include efficiency, consistency, or convention. For example, the real time communication of patient monitoring information imposes different constraints on representation of a waveform than does the need to capture a snapshot of a particular segment of the waveform for inclusion in the patient record.
While standardization on a single uniform representation may be possible, it may not be practical, particularly when migration from contemporary systems is considered. The degree of semantic congruence required for comparable PMRI is dependent upon the specific intended use of the information. It is not possible to generalize regarding the allowed degree of mismatch without a specification of the intended use.
The second question was, what is the role of syntax in communicating comparable PMRI? The work of the IEEE P1157, CEN TC 251, and HL7 has established that it is possible to map a common information model to and between a variety of interchange formats without semantic loss. Conceptually, each interchange format can be described in terms of an abstract syntax, and concrete encoding rules.
The choice of a particular syntax is guided by trade offs in terms of expressiveness, efficiency, and extensibility. Expressiveness determines what concepts can be represented. Efficiency determines the consumption of computational resources in terms of processing and band width requirements. And accessibility defines the ability to represent new concepts in a transparent manner.
For a number of historical reasons, based upon the initial focus of the respective SDOs, a variety of syntaxes and encoding rules have evolved. HL7, X12, and other SDOs which initially focused on information which could be conveniently represented as text, developed approaches which led to positional ASCII encoding of information.
DICOM, which was faced with the representation of images and IEEE 1073, which focused on the real time interchange of parameter, waveform, and graphic information chose syntaxes and encoding rules appropriate to the efficient representation of multimedia data types.
Two methods have arisen for dealing with information described using different syntaxes and encoding rules. The first method involves encapsulation of one syntax/encoding in another. The second involves mapping between the different representations. Work on encapsulation has been undertaken by HL7 for incorporation of DICOM images and HL7 messages, and by X12 and HL7 for inclusion of HL7 content in X12 messages.
The Andover Working Group has done initial work on the mapping of information between IEEE 1073 and HL7. This work has been facilitated by the existence of an explicit information model, and rules for mapping of the information model by both IEEE 1073 and HL7. Preliminary work by HL7 on the use of XML as an interchange format shows significant promise as an indication of the ability of the private sector to make progress in this area.
What is the role that models can play in defining, communicating, and insuring comparability of PMRI? As noted earlier, an architectural model describing the mapping of a common information model to a variety of interchange formats has provided the basis for approaches to interoperability among SDOs for message format standards.
While message format standards represent an important approach to communication of comparable PMRI, there are other approaches to interoperability such as document management systems, visual integration, and distributed database approaches. Each of these will benefit from the development of a common information model.
The work of HL7 on the Version 3 reference information model is a significant example of the ability of private and government sectors to work together in the open standards process.
Are there emerging areas, standards, or technologies that can contribute to the collection, storage, and communication of comparable PMRI? One of the conclusions of the Andover Working Group is that the availability of middleware to support the implementation of standards is a key factor in accelerating the adoption of those standards. The work of the Andover Working Group, the MS-HUG ActiveX for Health Care Committee, the Common Context Working Group, and the CORBAmed in the development of component-based support for implementation of standards is an area showing much promise.
In recognition of the move to component-based middleware, HL7 has formed the Special Interest Group on Object Technology, which has focused on messaging standards, and the Visual Integration Special Interest Group, which has focused on context management.
As noted earlier, the use of SGML/XML for implementation of document architectures is a promising approach for communication of comparable PMRI. The HL7 SGML/XML special interest group is developing a framework of interoperable document type definitions, which is being coordinated with the HL7 reference information model development.
Is there a need to coordinate or otherwise facilitate the development of PMRI message format standards? The ANSI HISB, ISO TC 215, and the HIPAA initiatives collectively have provided an environment that promotes the coordination of the PMRI message standards.
In response to the questions regarding the role of the federal government regarding syntax models, emerging technologies, and coordination related to standards for communication of PMRI Hewlett-Packard believes that the federal government can have the greatest impact by:
If you will look at the handouts, the back part of my handout is kind of an outline of my answers to the questions. But I wanted to address some issues more broadly in the verbal presentation. So the slides are loosely connected to those topics. So it's a loosely connected interface.
I want to draw your attention to some paradigm shifts that, from my point of view as an information architect in OACIS, seem to be happening. Earlier standards were more tightly identified with their messaging syntax, and in the past few years there has been a definite shift towards an emphasis on information models. Instead of looking at just messages, we're looking at various exchange technologies.
In HL7 Version 3 we are specifying these as separate from the information models that defined the actual clinical content of the messages. So there is an abstract definition of the message in our Version 3 methodology called an HMDR hierarchial message description. That can be transmitted between systems in a variety of ways. We are looking for the first of these ways in Version 3 as using XML. We are also looking at component-based technologies for exchanging information such as CORBA and Active X DICOM.
There are also possibilities to use EDIFACT syntax. So we have made a very clean distinction between the syntax and the technology for getting information between systems or between components, and the actual definition of the content of that information.
Another shift that is happening is that until very recently, vocabulary and vocabulary content models have been considered as separate from information models. Again, we are starting to look at the fact that if I have an information that is named by a particular vocabulary term and a standard set of codes, that that context gives the vocabulary term a precise meaning. It also makes the information structure more interoperable. So this is another important shift.
We are also starting to look at, at least within OACIS and to some extent within HL7, at documents as collections of atomic, reusable information units. So the concept would be that if I have a fully specified document, that not only can every term in the document that is tagged be mapped back to the reference information model, but I can't have a machinery methodology for extracting this message level interoperable units out of the document and reusing them in any other form. Conversely, I should be able to form a document out of an arbitrary collection of atomic clinical information units.
In terms of the comparability discussion that is addressed in the questions, in terms of where we things from OACIS is that messaging and object interfaces have to have both a common information model and a common vocabulary model, and the standard vocabulary needs to be applied to the standard information model in the sense that was talked about this morning with the HL7 templates.
We are talking basically about object models rather ER models or older type models, because within an object model you get not only a collection of data elements, but you get the behavior of that group of data elements. So an object has both behavior and a collection of attributes.
It also has one other very critical point for characterization, which is that one can create different specializations of an object. So one can have a base class of a clinical information object of which lab-type observations are one specialization, and pharmacy administrations are another specialization.
So that in the object model viewpoint, you get to another clinical domain not necessarily by adding attributes, but by looking at your core classes of clinical information and adding specializations to them. So that's one really key evolutionary thing that is happening with the HL7 reference information model, and that we have a lot of experience with in our internal models in OACIS.
Another key is that the addition of new instances within a specialization is data-driven. For example, in the reference information model if I need to add a new lab test, I don't create new attributes for it. I just add another entry in the master file, the data dictionary that defines that specialization. So I can add things by adding codes referring to those things in my master file tables or my data dictionaries.
In terms of the OACIS point of view on PMRI, what it is, patient medical record information, it is basically any information needed by a clinician to care for a patient under his or her professional responsibility. In addition to the standard clinical and administrative areas, this includes enough financial, insurance, and related information so that a determination can be made as to what services or medications or procedures the clinician is able to order for that patient.
It excludes financial and administrative information that doesn't contribute to patient care. It also includes permissions based on credentials and licenses. So it is a little broader than basic clinical information, but it is not all the information needed for the various administrative and financial and payroll systems.
In terms of the comparability that is based on this kind of information or vocabulary models, from our point of view we are looking at it primarily from answering the question how much interoperability does it get us? The more fine grained structure that we can instantiate in the information model, and the more standard codes that we can use, the higher degrees of interoperability we can get.
The reason we want this comparability or interoperability is because it is not only a basis for a day-to-day clinical care of the patient, but when we have standard information in standard forms with standard vocabularies, we can create standard interfaces to all kinds of clinical decision support knowledge-based applications. We can do research and we can share information between many different systems.
So a couple of other basic characteristics of this point of view is that the model-based paradigms are extensible by via specialization. In that sense, they are not complete, because clinical knowledge, medical knowledge isn't complete. As we discover new forms of tests or measurements or observations, we will have new specializations to store that information.
As we further get better degrees of definition on diseases and problems in standard format, we will be able to support more fine grained clinical decision support and knowledge-based applications. So that is kind of the general point of view.
In terms of what OACIS thinks about syntax, it is kind of implicit in what I said before, but one comment in terms of this set of questions is that not everything mentioned here is a syntax. That was brought up before. But the OMG, CORBAmed, IDL is object-based. There are remote procedure call aspects to that, and so on.
So the basic point is that a syntax doesn't by itself, support information standards. The syntax has to be used in a particular way, in a particular form, with reference to a particular information model, and to particular vocabulary sets.
So again, I can have a document syntax that is perfectly expressible at a local site here as an op report or a clinic note. Here is its header, and here are the very sections in it. But if I don't have a standard way of referencing who the responsible clinician is, what the dates are, what the type of report is, what the standard headers are, if all that stuff doesn't refer back to some standard information model, that document is only standard between the senders and receivers at that site.
I can send it to some other site, and as a human being I may be able to read it, just as in the example of the pharmacy prescription. I could read it, and know that oh, well, this is the drug and this is the dosage and so on. But as a computer system, unless I know that this drug name is a particular coding system, and this SIG is expressed in a certain SIG-specific syntax and so on, I can't put it in a database and operation on it with any kind of decision support algorithms in an unambiguous fashion.
So from my point of view, the syntax doesn't get you interoperability. It's the use of the syntax with reference to a particular information model, and a particular set of codes in a vocabulary standard.
Going back to the original paradigm slide, what we want to do, and what HL7 is doing and OACIS supports is to have the idea of a technology-neutral definition of the information needed to be transmitted between two components or two systems. Then depending on whether I need to do it in an object paradigm or a component paradigm, or a loosely coupled system over the Internet paradigm, or a PCP within my site paradigm, I pick the appropriate syntax, and the appropriate implementation technology specification to do that. In my thinking and analysis about these things, I make a clear distinction between those two levels.
So basically, in terms of recommendations to this committee, if you have that kind of approach, you can let the market decide what syntaxes or what technologies are appropriate for now. If those technologies change in six months or a year or 18 months, then you just change the bottom layer of your implementation, where you translate the abstract message into a particular syntax. It is a fairly painless thing to do.
A similar point of view on technologies, especially in the hardware area, they are evolving so rapidly. Capacity doubles every 18 months is a mantra in Silicon Valley, and that includes new media, not just processing. So again, we want to concentrate on the information modeling and the vocabulary standards, rather than particular technologies. Components are hot right now. We think they will be hot for the foreseeable future. But something could come on in six months that blows them away completely. We don't know that.
Even in terms of image and binary storage, you want to book at standards that survive changes in technology. So for example, JPEG is an image definition standard that can be implemented in a whole bunch of different technologies. So again, technology neutral specifications. Then you pick the appropriate technology for the appropriate point that you are doing the implementation.
In general, in terms of what the federal government could do to help this stuff along, we would like to support the federal government investigating how it could help with the extension and evolution of the HL7 reference information model. We would like to encourage support in the development of vocabularies at what I'm calling the base level for a whole bunch of standard clinical things -- problems, sign/symptoms, drugs, labs, procedures, and so on.
The concept here is that we have a lot of vocabulary vendors who are doing very good stuff, but the licensing is complicated, especially if you are a systems integration vendor like OACIS, that has got 25 systems at a site and several thousand users, and you are interoperating with other sites. It is very difficult sometimes to negotiate licenses that are affordable and reasonable.
Again, with vocabulary, I want to make the distinction between kind of a base level code, in other words, I need a set of codes for problems, diagnoses, signs, and symptoms. I need to be able to send those in messages or between components, using other technologies without worrying about the cost of using those codes. Because that is what I need to transmit clinical information between systems and sites and components.
I don't necessarily have to deal with a particular vocabulary vendors information add-on that is supported by the basic codes. So if I have a pharmacy vocabulary vendor that has a nice set of generic codes, I want to figure out how that vendor's generic codes map to some other vendor's codes for generic drugs.
The classification hierarchies can be part of the standard or not. I don't need the classification hierarchies to transmit the basic clinical information. That can be part of a knowledge-based application that could be added on at one site or the other. So that's the kind of thing we are looking for.
We would also like to invite federal support for development of HL7 clinical templates, which was a point made earlier today. For each of these areas, I want to make the point that the can be extended kind of a clinical domain at a time. We don't have to go for the whole thing all at once. There can be a phased evolutionary point of view, where we pick the things that are most critical to us now, and we do those well, and later we add on the more abstract or unusual or less commonly used things.
Eventually I would like to see the federal government encourage standards for rules in data warehousing. There are also a couple of relevant TCs within HL7 doing that.
The last point on this slide is making the point -- to use the point redundantly -- that we don't necessarily have to wait for everything to start on this work. A couple of examples, CDC has an electronic lab reporting project where they have created an implementation guide that is quite interoperable for reporting of diseases that have public health and epidemiological implications, and lab tests that are important for that.
The HIPAA related work done with the claims attachments say between HL7 and X12.N is an example. There are things that the government SIG in HL7 is looking at that may prove to be further interesting and useful examples of things you can do right now.
The basic suggestion in another arena for the federal government is that every time you have a new project requiring clinical information, to do the specification in a technology-neutral model. To assign standard vocabularies, and then look at what implementation technology or messaging, or transmission layers you need for that. Again, that can be built on currently available stuff.
Each time you do a new information interface that is based on this technology, not only has the federal government saved money doing the project, but the information arrives not in a use only once fixed file format form, but already structured in terms of an information model that can be reused, not just for that project, but for other projects. So that helps build an overall structure within the federal need of this information for interoperability.
Each time we make an incremental step forward in this area, we are laying the basis for creating a level playing field for our clinical knowledge-based applications. Because those applications need standard information, with standard names as drawn from a wide variety of sources.
So the overall close is the model that I got from Wes, that he also reused, as is his privilege this morning. Don't let the perfect interfere with the good in making progress in this area.
So thank you.
DR. COHN: Thanks very much. Doug Pratt from SMS.
SMS, now in its 30th year is focused exclusively on serving the information technology needs of participants in the health care industry. On behalf of SMS and HL7, I want to thank you for the opportunity to testify before you today on the very important of standardization of message formats for patient medical records information.
During my testimony I will share with you SMS's commitment to industry standards, our view of patient medical record information, the role of data models in standardizing messages for comparable PMRI, an assessment of the health care industry's progress to date in developing these standards, with emphasis on HL7, some of the inhibitors to advancing industry standards development to achieving plug compatibility, and how the federal government can help the health care industry realize the enormous potential and cost savings of plug compatible interface standards for comparable PMRI.
SMS is firmly committed to supporting industry standard message formats and common vocabulary across its entire line of integrated solutions for the health care industry. We have actively participated in the development of these standards for over a decade, assuming a number of leadership roles during this time.
Our customers have realized significant benefits as a result. By providing a common starting point for negotiating interface specifications among the health care provider software vendors, messaging standards reduce the amount of time that it takes to deploy interfaces. This is positive for providers and vendors alike.
Standards also reduce the likelihood of misinterpretation of the meaning of various elements of comparable PMRI messages used for data exchange, especially when implementation guides are provided, so that all participants implement the standard message in the same way, with the same data content.
Computer-based patient medical record information, otherwise called CPR, is electronically maintained information about an individual's lifetime health status and health care. It replaces the paper medical record as the primary source of information for health care, meeting all clinical, legal, and administrative requirements. It necessarily encompasses all data related to the person's health care, including demographic, clinical, and financial information.
The data include text, numbers, sounds, images, signal tracings, and full motion video which are integrated so that any given view of health care data may incorporate one or more of these structural elements. It is not merely a recreation of the paper medical record. It enables health care providers to reengineer the health care delivery process, because it makes information readily available to the care provider when care decisions are being made, and as a by-product, provides a source to aggregate data for outcomes analysis. Clinical and financial decision-making is data driven, rather than empirically formed.
I'll let go of the sentiments of just about everyone I have heard testify today that the essential model is a vocabulary. It is this vocabulary that enables the diverse and fragmented elements of the health care delivery system to operate as a whole, coherently serving all stakeholders in facilitating effective and efficient health outcomes across the care continuum.
Information that is meaningful, interoperable, and sharable is the essential objective. This requires that the underlying vocabulary and the format in which it is communicated must be standard, and is key to achieving comparable PMRI.
Now the strategic goal of health information systems providers such as SMS is the computer-based patient record. Whatever the technical implementation, it must be a truly portable record that follows the patient, and that must assimilate medical logic modules that are models of best practice.
The CPR is made possible by improvements in underlying technology, particularly the growing reach and throughput of electronic networks. The primary barrier to achieving a viable CPR is the lack of universal standards that allow data integration across diverse and fragmented health provider organizations and health networks, and the application of standard medical logic modules. Progress is being made, but work remains to be completed.
Now let's examine the current state of HL7 messaging from our perspective, and where it is headed in the future. HL7 Version 2 is the most currently generally available version of this standard. SMS specified HL7 Version 2 for most its interfaces that exchange PMRI. There is no question that HL7 Version 2 has significantly improved systems integration over the past decade, prior to which there was no accepted industry standard.
Nevertheless, it is universally agreed that HL7 Version 2 falls short of achieving so-called plug and play compatibility, and there are a number of reasons for this. Among them are the lack of a common vocabulary pertaining to data elements who elements are derived from coding systems, the fact that a number of data elements are subject to broad interpretation, and an overuse of the optional attribute for HL7 data elements.
As a result, health care providers who purchase products that are designed to interface in accordance with the Version 2 specifications find that the products cannot work together without site-specific negotiations. This has made it impossible to construct and perform any kind of meaningful certification testing.
HL7 Version 3 promises to enable interfaces that come much closer to delivering this plug and play compatibility "out of the box." Whereas Version 2 provided a starting point for interface negotiations, Version 3 is expected to reduce negotiations to resolving minor site-specific requirements.
Version 3 messages will be derived from the formal, rigorous message models under development within the HL7 technical committees. These models greatly reduce the need to declare data elements optional, because messages are derived from the use cases. Together with the contributions of the HL7 Vocabulary Special Interest Group, Version 3 will directly address the three major deficiencies identified in my discussion of HL7 Version 2. However, much standards development work remains to be done before Version 3, as a full functional replacement for Version 2, can be balloted and interfaces written to it and put into production.
Progress is being made, but progress could be much greater if "funding," in whatever form, allowed a more intensive effort. The HL7 membership comprises some of the most talented developers in our respective companies. Efforts to accelerate standards development compete with product development. Travel expenses to a lesser, but still significant degree, limit the number of people that can attend working group meetings.
Another component of the industry's challenge today is that the revenues are declining due to Medicare, Medicaid, and managed care reduced reimbursements. At the same, regulatory initiatives such as medical necessity and HIPAA are driving the need for new capital and operating investments. Thus, revenues are declining and expenses are rising, putting more pressure on available capital and discretional spending. The industry is now facing more severe trade-offs between improving their care delivery capabilities, versus improvement their information infrastructure.
So how can the federal government help? First, we believe that the HIPAA legislation is a valuable initiative that will eventually help the industry reduce the overall cost of administering health care. However, the investment spike to achieve the projected savings is significant and daunting to many. The challenge is not in the logic or value of HIPAA, the challenge is how we can collectively afford to get there from here.
One mechanism that has worked in the past in American industry is the concept of targeted tax investment credits. If the government would like us to achieve the benefits associated with using standards and efficient electronic communications, then helping guide the industry's investments would stimulate progress in a meaningful direction.
We strongly believe that targeted tax incentives apply to meaningful investments on the part of all parties of health, including providers, payers, suppliers, and information systems and technology companies will accelerate our collective ability to realize the benefits described throughout my testimony.
Second, the federal government should help the health care informatic standards board, HISB, develop and execute a stronger charter that provides real leadership in health care informatics. This addresses a number of the questions that came up this morning with regard to collaboration between data models and respective organizations, and between SDOs. This would be an effective way to do that.
This group is chartered with coordinating activities of the various standards development organizations. This is a critical function that, in our judgment, needs stronger leadership.
Third, the federal government should designate an independent agency or agencies to design and execute conformance testing, should that become necessary. We feel that it is critical that this be done outside of the standards development organizations, which are dominated by competing vendors, in order to eliminate any possible conflict of interest. This also enables the standards development organizations to concentrate on what they do best, which is developing standards.
In summary, SMS and our customers understand the monumental benefits of the computer-based patient record and the critical role that messaging standards such as HL7 and ANSI X12 play in fully realizing these benefits. Towards that end, we have committed significant resources towards the development of these standards. While progress has been satisfactory, we believe that there is much room for improvement. We believe that the federal government can best help by providing much needed financial incentives to increase participation in the private sector.
Mr. Chairman and members of the committee, it has been an honor and a pleasure to deliver this testimony to you. I thank you for the opportunity.
DR. COHN: Thank you. Chuck Meyer.
I also represent McKesson/HBOC on the ANSI Healthcare Informatics Standards Board, and the US TAG to ISO TC215. Internally I function as a consultant to our various development organizations on manners pertaining to the identification and implementation of appropriate informatics standards within our product suite. I also work closely with our product management to further our goal of seamless systems integration.
McKesson/HBOC's information technology business provides a comprehensive set of cohesive systems and services for both the provider and payer environment of the health care enterprise. Provider and payer organizations seeking improvements in health care quality, delivery and cost have consistently chosen McKesson/HBOC product solutions and services.
As the preeminent vendor of health care systems solutions, McKesson/HBOC continues to be an active participant in the evolution of both administrative and clinical standards for health care systems. Taking a pragmatic view, McKesson/HBOC recognizes both the value-added of supporting industry standards, and the costs saved in developing and implementing standard solutions.
Although the vast majority of our products capture and maintain some level of patient information, several are specifically focused on the vast array of diverse information that forms the patient medical record. Of particular note is the Pathways Smart Medical Record, a comprehensive ambulatory patient record for clinical management of information access, patient documentation, work flow, and communication in the physician practice.
Pathways SMR provides an extremely rich data entry/data capture environment supporting point and click, keyboard, voice annotation, images/attached files, sketches, scanned files, and the importation of electronic transcription. The ability to capture virtually all patient medical record information is coupled with the wealth of product features to create an application designed specifically to provide a viable tool for electronic health records at the physician practice level, generally the least automated sector of the health care environment.
I have conferred with a number of colleagues, including Dr. Mark Taragin, product manager for Pathways SMR, and Dr. Dan Russler, vice president for clinical strategies in an effort to address those issues put forth in your invitation letter of March 17th. In our view, patient medical record information encompasses the entire content of today's ubiquitous patient chart in all its various permutations.
This includes literally all health care information from the patient's medical history and initial assessment, to the record of conversations with and/or about the patient, to the typically extensive documentation associated with an encounter, visit, or episode. It includes the full gambit of administrative, financial, and clinical data representing a patient.
The work group's use of the word "comparable" relevant to PMRI is interesting. As a vendor, we go to great lengths to establish working standards for our products that will facilitate interoperability. Sharing PMRI across the enterprise is a critical component of improved patient care and cost reduction. We are in reality, striving to reach these goals by comparing information.
Comparing patient data, comparing procedures and outcomes, comparing data in all its various combinations to support critical decisions about patient care, bring about improvement in health care administration, and drive advances in medical research. However, these lofty goals are attainable only when the data is truly comparable, apples to apples, and achieves a level of precision that promotes trust in the data being compared.
PMRI must be discrete data, that is, recorded at the element level. Only such elemental data lends itself to analysis and comparison. This is not to say that aggregate data doesn't have its place, however, the process of aggregation must start with elemental data, and must be closely controlled to retain the meaningfulness and usefulness of the aggregate. It goes without saying that decisions based on inaccurate or imprecise data may be skewing, glaringly wrong, or worse, life threatening.
To be truly comparable, such elemental data must be based on a standard terminology geared toward evidence-based medicine. This statement is easily defended based on our experience, however, it is utopian and clearly unattainable given the state of today's vocabulary. It is widely recognized that no single vocabulary exists today sufficient to the task of encoding the full spectrum of PMRI.
However, we are encouraged by and continue to closely monitor the initiative undertaken by the National Health Service in the United Kingdom to create a national health information infrastructure. HIPAA may provide the impetus to undertake a like initiative in the United States. The recommendation of the secretary based on information from the NCVHS will set the stage for continued work in the area of vocabularies, however, we now have a significant task ahead of us.
There are a large number of syntaxes available or evolving that will support the exchange of PMRI. Each must be considered within its inherent domain. Object-oriented technologies show much progress and promise in the client-server/desktop environment. However, it has little or no applicability to the large number of legacy systems still in use throughout the health care enterprise.
HL7 has developed a rich transaction set for communicating PMRI, but it is by design a transport mechanism, a carrier of information between applications. HL7 is widely deployed, and generally provides the format for PMRI employed in a variety of syntaxes, including object-oriented technology. Its data dictionary is often selected as the initial component upon which PMRI and clinical databases are constructed. It may be considered the glue that cements the process of PMRI exchange.
However, HL7 Version 2.x is more analogous to Post-It Notes than to epoxy. It provides an agenda for negotiation among applications wishing to exchange PMRI. Even so, it was well ahead of the competition and user demand dubbed HL7 a de facto standard long before it achieved accreditation.
The private sector, represented by the polyglot membership of HL7 is well along the road to removing the ambiguities, and improving the robustness of the standard. McKesson/HBOC, as with most organizations involved in HL7, is excited by the progress being made on Version 3. It represents a quantum leap toward plug and play PMRI exchange.
Being technology-driven, Version 3 has chosen Extensible Markup Language as its primary syntax. This evolving technology is significant in that it allows inclusion of certain meta-data in the context of the message content. The strength of this functionality was demonstrated in a private project at the recent HIMSS conference. The extensive lessons learned dialog arising from this project will go far toward bringing closure to the initial release of the next generation of PMRI standards.
As with most current technology, there is some concern over support for XML by legacy systems. Although the parsers for XML are generally available at little or no cost, they are dependent on Java to operate. Not directly supported by most legacy systems, the development and deployment of virtual Java machines has added this support to a number of legacy systems, and gone far to alleviate such concerns.
As we've heard, the bedrock of Version 3 is the reference information model, which has been in development, or more appropriately evolution for several years. By demonstrating the data content, grouping, and relationships within the health care environment, the RIM provides a graphic representation of the enterprise, and the basis for the development of messages supporting the exchange of PMRI.
McKesson/HBOC recognized the applicability of modeling the enterprise early on. It's health care enterprise model was one of several public and private sector models that formed the initial basis for the RIM. We continue to work on improving integrating and harmonizing both our own model and the RIM to further the implementation of Version 3.
I highly recommend a review of the HL7 message development framework, which is undergoing revision for 1999, for better understanding of how the modeling of data, process, and interaction drive the development of message format standards. The only impediment to extending the scope and applicability of the RIM is the continuing harmonization of the various models available today.
The government can support this process through participation. Making the DOD, VA, and public health models available, and promoting the harmonization of the RIM, the HIPAA data dictionary, and the ASC X12 data model can only improve through understanding of uniform data standards, message format and PMRI standards.
As I've noted, XML demonstrates great promise as a syntax of choice for the exchange of PMRI. HL7, via the SGML/XML Special Interest Group has taken the lead in the creation of a document-centered exchange standard. A document architecture is by far the most efficient method for specifying a comprehensive, extensible, and flexible set of document-type definition supporting shared processing requirements.
An architectural approach provides sufficient common structure and semantics for documents to be exchanged and processed without the need to recognize locally defined markups. HL7 has put forward the patient record architecture as a scalable document architecture that optimizes the interoperability between documents with diverse characteristics.
While providing a basis for the development of consistent DTDs through the industry, the PRA has also apparently engendered a competition to control or be the arbiter of the resulting DTDs. Such divisive activities are counterproductive, and might easily become disruptive.
This arena represents an area prime for coordination. Given the interaction of SDOs necessary to facilitate the deployment of consistent DTDs, it would seem logical for the ANSI HISB to take the lead in mediating a successful closure. This working group, and by extension, the NCVHS, can provide leadership through support of a document architecture following due diligence to identify the appropriate candidate.
Another critical area begging coordination, yet much less clear in the process is the issue of vocabulary terminology and code sets. We applaud the efforts of Drs. Chute and Cohn to bring order from chaos in this volatile, and in all candor, politically charged arena. However, as evidenced by the recent ANSI HISB meeting devoted almost exclusively to this agenda, there has been little progress and a decided lack of commitment among those agencies reported to be viable vocabulary developers.
It appears that we are in the early stages of an entrepreneurial drive to create the penultimate vocabulary. Each in their own way wants to own the market, yet we have seen a cry from the industry, the users of these various coding efforts, to focus on the benefits to be gained in patient care and health care administration versus control of commercialization of vocabularies or code sets.
HIPAA provides the precedent for identifying standard code sets, regulating their availability, and mandating low cost distribution and implementation. However, there is no clear de facto standard code set or vocabulary specific to PMRI. Does it fall to the government to pick one? I'm not the industry can provide that answer, but it certainly is deserving of more research.
If the National Health Service of the United Kingdom can settle on a single comprehensive vocabulary for their national health initiative, perhaps there is hope. It does fall to the government to conduct such research, and ultimately recommend a process for closure, if not the outright declaration of a standard vocabulary to which all disciplines should contribute and adhere.
I appreciate the time allocated by the working group to consider our opinions. McKesson/HBOC remains optimistic of the outcome of these efforts, and will continue to promote the implementation of standards supporting improved patient care and health care administration.
Thank you.
DR. COHN: Thank you very much, and I appreciate your candor. Questions from the working group?
MR. BLAIR: Questions addressed to Jack Harrington. The integral working group endeavored to build on the achievements of HL7 in terms of communicating clinical messages. It took a number of steps to improve the interoperability. I think it would be helpful for the committee to understand what specific things the Andover Working Group did to improve interoperability.
MR. HARRINGTON: In a sense what we did is we prototyped Version 3.0. We applied it to Version 2.3. We basically got a group of leading vendors and users together, and looked at the process model of how you could do a multi-vendor profile. HL7 has a number of standards that are not particular to HL7. It has a number of optional elements, and a number of user defined elements.
By getting to a precise definition where optionality was totally eliminated, by having a contract in terms of the source and the receiver of the message, so that you could do verification and validation that the contract was being adhered to, by specifying the error recovery and other things that are necessary when errors do occur in transmission we were able to demonstrate that with an addition to middleware that would support the messaging paradigm, we could significantly reduce the burden, and we could in fact achieve what is commonly called plug and play.
To wit, we were able to bring together eight vendors. In less than two days we had them all running together on PCs, unit work stations using ActiveX, using COBRA, using a variety of technologies. And actually to the surprise of most people that were there, it was quite an amazing -- I think Harold, you were one of the ones that commented on it -- it was the fastest integration they had seen.
It is possible. Again, the process model we used was very much based on the HL7 Version 3.0 message development framework as it stood at that time. It gave us a great deal of confidence in going forward that HL7 Version 3.0 in fact can come much closer to potentially achieve the plug and play we are looking for.
MR. BLAIR: Could I follow that up if I may? Mark, you have been very much involved with HL7 in many different areas. Do you pretty much echo Jack's observation that this might have been a prototype of many aspects of Version 3? And that this bodes well? That Version 3, especially the RIM would be able to help us generate standards faster?
MR. SHAFARMAN: My basic answer is yes. The question of generating standards faster is a paradoxical one. In other words, to do more interoperable standards requires more attention to detail. So when you have interoperable standards, then hooking systems together via a variety of methods is much quicker. But the actual development of those standards may take a little more time. So that's the only distinction.
I would like to point out also that we had a second validation of the Version 3 methodology recently at HIMSS where we actually were using the more current version of the method development framework, and we were doing experiments with XML as the basic messaging syntax. We showed interoperability between Version 2.3 and Version 3 messages, and also interoperability between HL7 PRA documents and messages as well.
So there is a bunch of exciting precedents and paradigms that were demonstrated there. So, yes, I think it's the considered opinion of all those that are involved in the process that it is close enough so we can taste it. It is happening.
DR. MC DONALD: Just a comment, and maybe some of you may not know. Jack Harrington was very involved with object modeling and the all the rest before many of us even understood anything about it. I would like to say some of us were born, but that's not true for me. And he has had a big influence. It's a nice example of sort of cross-transformation from one standards group to another, and the best harmonization, because it kind of melded in some very good sense. I think it was more than the Andover Work Group, but you had a big influence for a long time.
MR. HARRINGTON: Actually, to follow-up, Jeff, just to be clear, the production of the standard probably as Mark has pointed out, if you are going to be very precise, it will take a bit longer. But that is really only a part of the lifecycle of diffusion of a standard into the industry.
You have the developer, who has to implement the standard, and this is where middleware and HL7++ if you will environment that you can just work in, and simply implement without having to go into all of the detail of the standards. The ability of a profile which is unambiguous, so I don't have to dig through everything, and then go out and define a number of things. There is that aspect.
There is another aspect with regard to being able to locate a set of vendors who have committed to a set of interoperable profiles, we dubbed the term "yellow pages." Within the HL7 group we have the conformance SIG for the registration of profiles by vendors, hopefully creating a marketplace.
What we hope to see is a number of vendors signing up to support various profiles, and use as procuring to these. It's really the market that will end up driving the good from the bad from the ugly in terms of what the various profiles are. The ability to do a registration of a precise contract which is enforceable is a key point.
Then finally we built into the middleware the operational support for deployment of the standard. So there are a number of pieces of the value chain that need to be taken care of, the production of the standard being one of them. But if you truly want a diffused standard, you have to look at the rest of them.
Fortunately, as I think Wes Rishel pointed out, middleware is becoming available. Message-oriented middleware from the OMG, from various vendors such as Microsoft, IBM, and others is becoming available to support that infrastructural element very quickly.
MR. PRATT: If I could add on to Jack's comments about the middleware. Together with one of Jack's co-workers, Jack Trainor, I co-chair the Special Interest Group on Object Brokering Technology, which is about to request a name change to component-based messaging.
What we do in that group is really to specify at a component level, the interfaces for such middleware such that the middleware could be constructed by any number of vendors that are in that business; components that adhere to one standard. Such as an application can invoke segmental wear to exchange messages, and to encode and parse messages regardless of the format, whether they are XML or HL7 Version 2 format.
But again, it's one more level of interoperability that we are attacking, not so much at the network level, but at the level between the application and the middleware itself.
DR. FITZMAURICE: I have a question for Doug Pratt. In your testimony you mentioned that there should be an agency independent of the standards developing organizations to design and execute conformance testing. By that do you mean conformance testing for message standards to make sure that the syntax is accurately achieved? Do you mean with XML, that what you get is in the right spot on the visual document as what the person who sent it, said it would be? I'm not sure what you mean by conformance testing.
And do you think there is enough maturity in the marketplace in the use of standards to achieve that? Or are things fairly loosely fit together, so it's hard to achieve conformance when the standard developing organization itself doesn't specify so completely the linkages?
MR. PRATT: Going back -- I guess I've been a member of HL7 since about 1989, and probably for about eight of those years there has been a number of efforts to try to achieve conformance criteria with Version 2 towards the goal of achieving conformance testing such that a vendor could say that I support HL7 Version 2 ADT transactions, and have it mean something more than that they do conform to the standard.
But as we have heard many times today, that when you have seen one HL7 interface, you've seen one. There are just so many areas that are subject to misinterpretation in Version 2, and so many fields that are optional, that that just wasn't a viable option.
Now with the advent of HL7 Version 3, based on the data models, and the extensive work that has gone on over the past five or so years, that becomes much more of a possibility. So I guess what I'm suggesting is that should we come to the point when, as a hypothetical, let's say that HIPAA would require that a vendor's interface must pass a certification test for HL7 Version 3 in a given use case, that this shouldn't be chartered by the development organizations themselves, because it's mostly dominated by us as vendors, and frankly, we would rather invest our time in developing the standards and enhancing them.
I was at a meeting with a number of folks in this room about CORBA, and this was sometime within the past year at the NIST, National Institute for Standards and Testing. They, it seems, would fit that bill perfectly. They do partner with private industry to take on conformance testing and that sort. So if this should become a reality, I think that should happen in that guise.
DR. FITZMAURICE: Could I ask Chuck Meyer a question, Jeff?
MR. BLAIR: Okay.
DR. FITZMAURICE: Chuck, in your testimony you talked about the need to be an arbiter of the resulting DTDs so that if there is a common national reference set of DTDs that everybody can draw upon in the public domain, as opposed to being licensed by somebody and getting a profit from it.
Secondly, you talked about this working group and NCVHS can provide leadership by supporting a document architecture after we go through the due diligence process to identify the appropriate candidate. By document architecture do you mean a specific form of XML? Or are you referring also to a national set of DTDs that everybody could use?
MR. MEYER: Well, part one. What I was actually referring to in the presentation was the apparent move by certain organizations to become the arbiter of standard DTDs. Candidly, we are concerned about the apparent cross-purposes of the ASTM effort to define DTDs external to HL7's patient record architecture, versus the ongoing effort within XML and SGML. Quite candidly, I'm even more confused now, because I wasn't aware that Rachael was on both of those groups. So that was my concern, who is going to be the arbiter.
That segues directly into this discussion about the architecture. We, and that is in concurrence with HL7, have absolutely no problem with any organization, be it an SDO or not, developing and promoting a standard DTD, as long as it is within the context of the patient record architecture, and takes into account the consistency with the RIM. That is where the issue arises.
Now if someone else wants to promote a light, flexible, or more robust architecture, then let's bring it forward, and that's where the due diligence comes in. But right at the moment we have an august panel that has come together to form this PRA out of what was originally the CCAL(?), to say this is what the content is, this is how you should develop your DTDs. Keep these things in consideration. As long as we develop it within that context, or some like architecture, then we will have viable DTDs.
DR. FITZMAURICE: So what you're saying essentially is that you believe that HL7's reference information model is good enough to be a national standard architecture, and that people should build DTDs around it, so that it fits with it? And you don't see something that is really in second place at this point?
MR. MEYER: Again, let's get back. It's the patient record architecture that I was referring to. The reference information model I think candidly does represent currently the paragon of modeling of the health care enterprise. I'm co-chair of Task Group 3 of X12.N, and so I'm very, very much attuned with what is happening with X12.N, and candidly we are somewhat parochial.
I don't say that to be derogatory. We are just very much focused on electronic commerce, and moving that forward, and understanding what we had to do for HIPAA. The reference information model under HL7 has extended to become conceptually a graphic visualization of the health care enterprise.
It was mentioned earlier that at the RIM harmonization meeting last week, some elements were brought forward specific to benefit ineligibility. There was an immediate hand up to say well, isn't this the purview of X12? We had to once again make the point that what we're modeling here is not a database. It's not an application. It's not any of those. It is the reference information model.
It's the concept in place in the health care enterprise that shows the relationship and the interaction of information. Nothing says that every attribute in the RIM has to end up in a message somewhere. If in point of fact -- logically, if we can embed and HL7 message in an X12 format to do a claims attachment, then why can't we communicate eligibility information if necessary, with an X12 message embedded in an HL7 envelope? Who cares who the developer of the format is per se, when what we are looking at in the RIM is conceptually we know that eligibility information played a large role in who a patient is, and what services he is provided.
DR. MC DONALD: I'd like to get back to the conformance question, because as someone in a hospital who has probably dealt with about 25 interfaces, I can tell you all the HL7 off conformance isn't due to the variability. They never read the book. They didn't even come close.
In that context, do you think it's not possible -- I'm asking of both Chuck and Doug -- not possible to do a smallish conformance testing at the current level, the current generation? I actually thought that there was something coming. I thought I heard some rumors that HGO(?) was going to donate a conformance --
MR. PRATT: I think that all depends on what you mean by smallish.
DR. MC DONALD: You wouldn't shoot people for having missed a dotted I, but at least you get the fields in the right order, and you can check to see that the data types are somewhat in range, and some of the things that are definitely specified in HL7. I can tell you stories that would make you fall off the table. These little companies come in and they even know -- we had to teach them.
It seems to me it would be really helpful if it wasn't the perfect lock step, it would go a long way compared to where we are.
MR. MEYER: We, Clem, as you know, represent a microcosm of the health care environment. We have systems that run the gambit from single physician practice, all the way up to the Mayo Clinic, and everything in between. So we deal internally with much the same issues that the industry is dealing with in a form of compliance and conformance on our interfaces.
Candidly, it's really embarrassing as a vendor when we walk into a place, less so when we just acquired the other company, to be told that why can't you talk to yourself? Well, we recognize that as an issue, and we have a very structured environment internally that is designed specifically to address the integration and interaction of our own products.
To further that, we have in fact developed a tool which allows us to do conformance and compliance testing against our own products interoperable with each other. Now as you mentioned, it wasn't really rumored, because we actually demonstrated that product at HL7 Canada in October of last year to several members of HL7, as well as we had Woody up there, and I think you were there as well. Oh, you weren't there.
We say this is what we've done. We think it has possibilities. We are not looking necessarily to market it. We are looking more for if someone might want to consider championing that. It was just kind of an initial dialog about where we might go with that.
We have continued to improve and enhance that tool. It is basically a database based on the HL7 specification against which you post your product specification, see how you match up, and then run your specs against the other product's specs, and see how they match up. So it's a gap analysis tool. It weighs you against the standards, and it also weighs you against the other interfaces you might be wishing to interact with.
I'm sure we're not the only vendor that has undertaken that. It only makes sense if you have a wealth of products, that you can in fact say, yes, we talk to each other, and here is how we validate that.
MR. PRATT: Clem, I think it would be very helpful if HL7 had something that defined what that smallish is. What are the minimum criteria if you were to claim conformance? I haven't seen that yet. That is really what is missing.
DR. COHN: Bob Dolin, I see you had your hand up.
DR. DOLIN: I wanted, if I could, to comment a little bit further on Dr. Fitzmaurice's question, and also make a couple of comments on Charles Meyer's testimonial, if that's all right.
First, there is a comment in here that although the parsers for XML are generally available at low or no cost, they are dependent on Java to operate, which is incorrect. A parser can be written in any programming language, and I just wanted to clarify that for the record.
Next, on the next page there is statement, "while providing a basis for the development of consistent DTDs throughout the industry, the PRA has also apparently engendered a competition to control or be the arbiter of the resulting DTDs." I was hoping to just give my opinion on this as one of the members.
I think something that Wes Rishel said this morning was that when people go out there and start building their information models, he encourages them to look at the RIM. My own take is that if two different people build information models independently, there is going to be less ability for semantic interoperability than if one person derives their information from the other.
So my own personal feeling is I don't want to control DTDs. I have never heard that mentioned as part of the PRA. I do feel that encouraging people who are developing their DTDs to look at the RIM, look at PRA, and strive for consistency with these models, will achieve greater semantic interoperability.
MR. MEYER: And that was the intent of my comment, Bob.
DR. DOLIN: Right.
MR. MEYER: It was simply to say that I see the possibility of some divergent activity developing, and I want to make sure that everybody understands that there is a framework to accommodate that, and we should all work together on that.
DR. DOLIN: I agree.
DR. COHN: I actually wanted to ask a question, and I realize we have spent much of today getting into very heavy technical issues. I think the work group has developed a much broader understanding of all of this. I was impressed that this session, probably more than any other, began to get close to these issues on business cases. I know some of the members find that at the end of the day, sort of a key issue in all of this.
Now I am reminded that part of the charter of HIPAA has to do with encouraging improving the efficiency and effectiveness of the health care system. Just listening to the recommendations that you are all making, and I'm just sort of wondering from my own mind, certainly standards having to do with patient medical record information is key, and I'm hearing some recommendations having to do with easier, or at least some sort of sense of access to vocabulary.
I'm hearing about conformance testing. I'm hearing about the HL7 RIM. I'm actually wondering if that alone will move us towards really this vision of the future of improved effectiveness and efficiency, or whether from all your views is there more that needs to happen? I know Doug, you began to put one view of gee, there needs to be something to move the industry forward. Perhaps others of you may have comments? Mark?
MR. SHAFARMAN: Yes, one is the issue that standards are an infrastructure thing. That's always less visible than the latest eye candy on your desktop. So infrastructure kind of things require otherwise competing entities to get together and say, we're going to agree not to compete in this one area, so that we can create a level playing field for competition. So it's a paradox.
In industry every company wants to be the biggest, the best, the fastest growing and own everything. That's the ultimate corporate goal. On the other hand, we are creating an infrastructure here that I think allows individual entities to compete, but also allows competition in the different kinds of applications that can work together.
So OACIS is primarily a clinical data repository. We're moving into the clinical documentation and order support area. But as a data repository vendor, a patient record vendor, if you will, we need to gather information from all kinds of different sources, and so by the very nature of our core business, we need to support standards much more than say a large integrated vendor that provides everything to everybody, or a specific niche vendor that just says if I can just do this one interface. I can make a lot of money doing a lot of different interfaces.
So not to denigrate the worthy competitors to my left and my right by any of these statements, but there is a place for infrastructure. Infrastructure is typically seeded or supported by the society as a whole, rather than by individual elements. So that's just a generic, philosophic comment.
In terms of improving efficiency, you can see lots of places where standards can, at different levels, improve efficiency. I mean the prototype studies that CDC itself has done on the ELR reporting of lab results that point to communicable disease. When they have the ELR interface in place, they get those results faster and more accurately.
If I have an integrated patient record application and I can get the basic form of my data standardized enough so that I can apply many different knowledge applications to it, I can do all kinds of clinical decision support that I can't otherwise do.
So in terms of OACIS's current products, we are working in a non-standard vocabulary way with one of the pharmacy knowledge-base vendors. That allows us to do drug interactions, return those to the clinical during the order session. So it's more efficient and more timely. It would be nicer for us if we had a standard vocabulary interface for that kind of knowledge, because then we could make more of it available at the point of care.
DR. COHN: Any other comments on that one?
MR. MEYER: I was just going to say whether a niche vendor or integrated systems vendor, there is a strong business case for developing interfaces and supporting them, because of the simple fact that regardless of where you go, you are rarely, if ever, going to replace every system in that hospital.
Nor are you going to encounter a provider or facility that is still totally unautomated. So you have to be able, to be a viable candidate, to move in and accommodate those systems in which they have already made an investment. Be it an EKG or radiology or a lab or whatever it is, in order to get your system in there, you've got to interface to them.
Even more so because they may be likely to buy Mark's clinical repository system, and by golly, we want to be the other side of that. So we're going to interface. That's how it works.
MR. PRATT: I would echo every comment that Chuck just made. I think it's interesting that when we all got together three times a year, and work in HL7 working groups, and even in between, we have been working with these guys for years, and they are just like my co-workers, and I think it's just a very great environment.
To that I would like to add some of the additional benefits of the standards, and specifically with the computer-based patient record, certainly in terms of telemedicine, when you have to reach remote populations, it certainly achieves economies, especially when all of the elements of the patient record are available. So that's an area that we see a lot of growth, and a lot of potential for cost savings for the government and others.
DR. BEELER: I wanted to observe a couple of things. First of all, if you go back to 1996, when this legislation was drafted, and look at where the standards community was then, and where the perception of the standards community, and even though the standards community of itself was then, and where we are today, there has been a lot of change.
At that time, I think there was the perception that there were dozens of ways to go, and no one knew which direction to go. There was a perception that X12.N and HL7 were about to go at each other's throat, and one of them would be left tattered on the floor.
I believe in 1999, that was when I looked at my watch last, that that picture has very much changed. I think the collaboration as evidenced over the last year, but it has been building longer than that with X12.N is strong. I think the relevance of HL7, which was frankly less clear in 1996 than it is today, is a major change.
The panel that you assembled was admittedly focused on HL7, but again, the vendor panel wasn't to my knowledge, and you heard the importance of it. So some of the question comes to not what can we do to bring standards together, but what can we do to make standards an easier process within business?
I hadn't really thought about it until Mark made the comment, which is that yes, there is a good business case for it. Certainly there is a good business case for it on the health care provider side. Yet it is not always obvious to people. It is frequently the thing that is hardest to sell. When times get tight, it is not so easy to convince people that we have got a core investment in standards, whether "we" is one of the vendor corporations or we are the providers.
I don't know what sorts of incentives are appropriate, not being on the business side of things, but that is a line of thought. To see if there is a way to incent standards participation amongst both vendors and providers, could I think, be very beneficial, particularly on the provider side.
We started out as a group of providers, and we still have a strong group of providers, but I don't think that growth has matched the growth of vendors. Not that we are losing votes. Not that in fact there are contentious votes. But we would like to maintain the balance, or even increase the balance a bit going forward in time.
So I think what you are hearing is that there is a community that is working better together, but it could use more volunteers. The way to do that is to convince the organizations for which they work that volunteering and participating in the process is the right thing to do.
PARTICIPANT: Just real quickly, to address your question also. I think standards are a means and not an end. We need to keep that in mind. If you would think about some of the standards that have come into place today, it would be very odd to promote car safety by funding research in air bags. It was promoted by simply saying cars will be safe, by gum, you guys figure it out.
I mean there was additional assistance, but I think it's important that you need to understand what your goals, and motivate those goals, standards being a means to get there.
DR. GREBERMAN: Mr. Pratt, I'm glad you brought up the issue of conformance testing. We have been involved with that in the DICOM area for a number of years. One way we have done it was in order to demonstrate that DICOM, at the Radiological Society of North America meeting, you had to go through a testing process to show that you could actually do it.
I was curious. I'd like to get some of the feedback from other members of the panel, and perhaps you if you would like to expound a little more on it, on practical ways of really doing this. You mentioned NIST, the Joint Commission as examples, but clearly I think this is a real issue that might be -- it's something I'd like the committee to discuss a little bit later. Perhaps you might have some practical ways of doing this.
MR. PRATT: Since I opened that can of worms, let me take a first crack at it. I think an organization like NIST would be perfect. First of all, we have to start with HL7 Version 3. I think we can specify, as Clem suggested, some minimum standards for Version 2 and document them, and they would have to be balloted by the membership, Version 2, in my opinion.
But in terms of Version 3, if that's really where we are going, and I think it's where we should be going, I think we do have a conformance SIG, and Jack, I think you are a part of that. Is that true?
MR. HARRINGTON: Co-chair.
MR. PRATT: So I think maybe it's best if I defer some of my response to Jack, but the point I wanted to make was that we would like to see it done outside of the vendor arena. It shouldn't be if SMS is on the board of HL7, SMS dictating what the testing criteria should be, or volunteering to run the test for some other perhaps niche vendor. I'm not saying that there would be any problems with that, but just to remove any kind of issue right from the start. I think it would gain much more acceptance in the vendor community.
MR. HARRINGTON: I think as was mentioned with the Andover Working Group, to the extent that you've got an explicit profile with no optional elements, with defined roles for sender or receiver, which is essentially saying you have mimicked what you are going to get to in 3.0 by doing a multilateral agreement in 2.0, which can be done.
You can do conformance testing. You have an unambiguous specification. You have a set of precondition/postcondition predicates that are going to be satisfied, and you could test it on the wire. You could build a tool such a HBOC or perhaps a vendor would care to develop such a tool. That would be something that would be very nice to have.
I formerly chaired a group at NIST on conformance testing. NIST is a good organization to do that type of thing. You can do the type of thing that was suggested by Mel, simple interoperability testing. One of the things you can do is get it into a very complex scenario with abstract test suites and other types of things that can end up being quite costly, and really not prove an awful lot more than you would by some simple interoperability testing.
So there are some pretty well understood paradigms for doing that, that we could be able to make some headway. We could actually get a lot of experience in what we're going to do for conformance testing in 3.0.
MR. SHAFARMAN: Just to make one other comment on that. In Version 3 will have explicit methodology for conformance profiles, but as Jack has pointed out, AWG has already created some. The CDC's ELR project has created implementation guidelines for their messages that are tight enough to run a conformance test against. The claims attachments SIG in HL7, their methodology for the HIPAA claims attachment is also in the form of an implementation guide that again, is tightly enough specified so that one could run real verifiable conformance tests against that, if one had the tooling, or were to write the tooling.
So it is possible to do a lot of that in the Version 2 world. What is lacking is tooling and a formal methodology. Maybe the conformance SIG can develop some of that.
MR. HARRINGTON: Well, actually, we were looking to vendors to help us. One of the things we are doing that conformance figures, we're looking to set up a registry of all profiles. You just mentioned a number of them. When we do have well defined profiles, we want to start putting them out there. And again, hopefully create this marketplace. What will ultimately drive us to conformance testable is when there is a purchase rec that says you must conform to this. All the sudden the industry will start to converge on very, very, those that the writers must want to see implemented.
MR. MEYER: Unfortunately, we are dealing in an arena here that is kind of analogous to a high school dance. We've got all of the girls on one side, all of the guys on the other side. The band is playing, and nobody is in the middle of the floor.
The reason I bring that up is because HL7 Canada attempted to take a very straightforward, simplistic approach of saying we recognize the need for our providers and our vendors to identify their compliance levels. How do they play in HL7. So they basically created an HTML page that listed all of the data elements, et cetera, and said, please check off the data elements you support in your interface and what format you use, year-month-day, month-day-year, whatever.
The problem we ran into was that candidly, the vendors were hesitant to expose themselves, including HBOC candidly, to the possibility of making a mistake on that page, or misquoting something, or saying that you thought you did, but you really didn't do. It opens too many cans.
So I guess I'm bringing this up to promote what Doug says. There needs to be an external agency in some form. But it's going to be driven by the first vendor that steps up and says, see, I'm compliant, what about the rest of you? Because he can use that as a tool against us, or to his benefit, maybe I should say. That is going to in essence, drive the business case for more and more to become certified in their own products.
MR. BEATTY: With the issue of compliance with standardization, and the exchange of transactions between organizations, the Association for Health Care Transactions or AHCT is setting up a facility to perform compliance testing of the HIPAA related transactions. If the HL7 transactions are as fixes as the implementation guide outlines.
That those can also run through that same compliance verification process and provide the opportunity for all stakeholders to bounce basically transactions against that service, and come back with a compliance report, whether they are compliant, and if they are not, where they are short on their compliance with the HIPAA transactions. So the industry is stepping forward with compliance verification when it comes to the HIPAA transactions.
MR. MEYER: I suspect though, Gary, that that's a fairly tight domain there that is involved. Plus, the accreditation is important, but it carries the weight primarily of simply a market tool that says AHCT has accredited my transaction set, and so I'm good. I'm golden.
MR. BEATTY: AHCT is taking on multiple facets of this. One is the accreditation of organization for being a clearinghouse, and accrediting them as being compliant with all of the criteria that AHCT has put forth. That's one aspect.
The other aspect is the actual compliance verification piece, which is separate from the verification piece. That is a true service that they are looking to offer to the industry to provide a compliance verification and potentially a mechanism where if there are disputes between two parties in exchanging the transactions, and compliance with implementation comes into question, that they can use this neutral third party testing ground to see what is the problem between the interactions.
MR. MEYER: I guess the other issue that I would raise as a vendor is that I would be much more comfortable with a definition of conformance from the standard developers, as opposed to a definition of conformance from an agency that works specifically with another standard. A learning curve within AHCT/ENCT(?) for HL7 would be significant compared to what we would see coming out of the conformance SIG or some agency promoted by the conformance SIG. So that would be a concern as well.
DR. COHN: We're now at 4:55 p.m. Are there any last comments by the committee? I think we'll try to avoid getting into a bunch more questions if we can.
DR. FITZMAURICE: Just one small question. We have a lot of information about models and standards that will benefit these large computer-based patient record vendors and large institutions. What is out there for the sole practitioner or the small group practitioner in terms of standards for communicating information across town, or from Podunk to Podunk University? Is that just an area of the market that hasn't been developed yet, and is not profitable enough to focus on it? Or will there be just plenty of spillover from these standards efforts that we don't have to worry about them?
MR. PRATT: I think we will see more and more of that, especially I made a remark before about telemedicine, that the sole practitioner out in the middle of Podunk, whatever state that is in, would have the ability to pull up on his PC perhaps x-ray images from a patient's record that were taken two or three years ago.
The whole concept of telemedicine can only be advanced through the electronic patient record, and the ability to communicate that, and to assimilate a lot of the remote components of that record electronically.
MR. MEYER: I think we need to recognize, Michael, that first of all there are very few systems that stand alone anymore. As an example, take the Smart Medical Record System. Although we can operate unto itself, it is designed to interact with practice management systems. It's the documentation arm, the patient record information arm of the practice management system.
It does not though, unfortunately in its own mode, generate information to some other enterprise. If the physician in question was operating within some integrated delivery network, then we, Smart Medical Record, would rely on the practice management system to communicate information that we had given it into the enterprise. So you have to look at the interactions of systems.
Please, I would contend that there are few, if any physicians anymore that do not have some type of network affiliation. Maybe I'm being naive in that statement, but I can think of few that are not in some way taking advantage of the resources on the Internet to do research, keep up with their literature, whatever they are doing, that don't have the basic concepts of communicating information in some form.
MR. SHAFARMAN: I would like to add that the Internet is the natural channel or doorway to that kind of stuff. OACIS has Web-enabled the clinical display part of our products. So if you are a practitioner who has patients at an OACIS installation, you can track them from your bedroom, if that's where your phone is.
Also interesting enough, one of the security things that HL7 has done in other areas is we have created as an informative document, a way to send HL7 messages securely over the Internet. I think it's invalid now, but it was done also in conjunction with the Internet commerce group, so it's got a formal RFC number.
So any system that knows how to read HL7 messages and in the Version 3 world that understands the data and vocabulary models, will be able to send and receive any of those messages over the Internet. That would allow individual providers to do things like send orders to other providers for other services, and view results remotely.
MR. MEYER: Mark is correct, that document was released March 19th, and the valid period closes April 18th I believe.
DR. FITZMAURICE: Two things. One is that the Version 3, that's it going to be great, but you also said that almost every doctor is linked up with the Internet somehow. All it takes is a couple of -- if I'm inferring this -- a couple of XML DTDs and they can transfer --
MR. SHAFARMAN: No, I didn't say that. If you are sending high structured, granular model-based and vocabulary standard based information in messages across the Internet, however you do that, the system at the other end, whether it's in the doctor's home or the doctor's office, or the patient's home has got to have enough smarts to decode and translate those things.
You might have a post-processing thing where you would take an XML PRA document and render all the granular coded electronic information into visible text. That might be a possible application you could write. But just sending something with XML syntax doesn't guarantee anything.
DR. FITZMAURICE: Does it have to be smarter than a fax machine?
MR. SHAFARMAN: Yes, orders of magnitude.
DR. COHN: We need to wind down here. Clem had a quick statement.
DR. MC DONALD: Two comments about the small practitioner. I think that the idea is that there are two markets and that these groups that do standards doing it just for the big guys is not recognized in reality. The reality is that the little guys who don't have computers can't do much.
My brother was the last practitioner in central Wisconsin solo. He went to the university last year. So it's gone now in central Wisconsin anyway. He may come back, but that's another story.
I think that historically the lab vendors have been sending HL7 matching to little guys. There are a bunch of little practice management systems that have been taking it for years. It's just little amounts. They don't have any kind of support.
DR. COHN: Jeff wanted to close the meeting. I personally want to thank you all for wonderful presentations. It was very educational.
Jeff?
MR. BLAIR: I just wanted to say thank you to all of the folks that have testified today, and the committee members, and the other attendees. This was the first day of specific hearings the CPR work group has for this year. We had a general one to try to give some direction. So we obviously targeted today on message format standards, and tried to educate ourselves on the committee, and in many different ways.
For all those of you who have testified today to help us to reach a better understanding, I want to thank you.
DR. COHN: So we will adjourn. Thank you all. We will reconvene tomorrow at nine o'clock.
[Whereupon, the meeting was recessed at 5:00 p.m., to reconvene the following day, Tuesday, March 20, 1999, at 9:00 a.m.]