[This Transcript is Unedited]
Hubert H. Humphrey Building
Washington, D.C.
Tuesday, October 9, 2001
SUBJECT: PMRI Message Format Standards
DR. COHN: The Vital and Health Statistics Committee is the main public advisory body to HHS on national health information policy. I am Simon Cohen, Chairman of the Subcommittee and the National Director for Health Information Policy for Kaiser Permanente. I want to welcome the fellow subcommittee members, HH staff and others here in person. I also want to thank those of you who are here to testify, recognizing that the heightened security at airports and across the country, this has obviously not been the easiest meeting to attend, and certainly as more of you will notice, we started a little late, recognizing that it was not the easiest building to get into either. So we want to thank you for your presence and participation this morning.
The focus of the hearings over the next two days is to identify next steps for the committee related to patient medical information standards. I want to thank Jeff Blair, our Vice Chair in charge of PMRI, and Mike Fitzmaurice from AHRQ for putting these hearings together. We thank you under these circumstances.
Let's now have introductions around the table and then around the room. For those on the National Committee, I would ask as part of your introduction if you would note if there is anything that you need to recuse yourself about, and that will do the introduction.
DR. ZUBELDIA: I'm Kepa Zubeldia with Gary Corporation and a member of the committee and the subcommittee. I'm also a member of X12.
DR. YASNOFF: Bill Yasnoff from the Centers for Disease Control and Prevention, staff to the committee.
MR. MEYER: Chuck Meyer, McKesson Information Solutions, part of the first panel.
MR. ADDY: Brett Addy with Superior Consultant Company, Senior Technical Advisor.
MR. GARTON: Aaron Garton, Cerner Corporation.
MR. DICKINSON: Gary Dickinson, Per-Se Technologies.
DR. FITZMAURICE: Michael Fitzmaurice, Senior Science Advisor for Information Technology to the Agency for Health Care Research and Quality, liaison to the National Committee and staff to the Subcommittee on Standards and Security.
MR. BLAIR: Jeff Blair, Medical Records Institute, Vice Chair of the Subcommittee on Standards and Security.
MS. ADLER: Jackie Adler from NCHS.
MR. MC CALLUM: I'm Malcolm McCallum from Medcom Soft.
MR. SOMA: Tom Soma from Medical Record Solutions.
DR. AITA: Same Aita from Medcom Soft.
MR. GUINAN: Jack Guinan, ProxyMed.
MS. JACKSON: Debbie Jackson, National Center on Health Statistics, Committee Staff.
MS. WILLIAMSON: Michelle Williamson, CDC and CHS.
MS. KENNEDY: Rosemary Kennedy from Siemens Medical Solutions.
MS. UNDERWOOD: Carolyn Underwood, Siemens Medical Solutions.
MS. BOIL: Daphne Boil, Department of Defense Tricare Management Activities.
MR. READY: Dan Ready with the American Health Information Management Association.
DR. COHN: I'll be turning the podium over to Jeff and have him make some beginning comments, but I did want to note that we actually do have a quorum of the subcommittee. Kathleen Fyffe has resigned from the subcommittee and actually will be leaving the subcommittee later on this month for other work and other future activities, but obviously we have really appreciated her involvement and participation in the subcommittee over the last number of years. With that Jeff, would you like to introduce the sessions for the day.
MR. BLAIR: Yes. To put this in perspective, so for anyone who may not have been following the activities of the Subcommittee on Standards and Security during this last year or so, the subcommittee, in addition to the other responsibilities that we have related to the administrative simplification provisions of HIPAA, we also have responsibility for, as the law indicates, studying issues related to the adoption of patient medical record information and the electronic exchange of that information, and providing a report to the Secretary by August 17th of last year.
That report had 10 recommendations. It was submitted by, you can find it on the NCVHS web site, ncvhs.hhs.gov, and within that report is a framework of how we would proceed as a subcommittee during these next several years, as well as a number of other recommendations to HHS. We are essentially in this meeting following up on the second recommendation within those 10 recommendations, and that second recommendation is a self-imposed target date on ourselves, that by February of this next year, we hope to be able to make recommendations on PMRI message format standards.
In order to do that, the process we have gone through is we focused on first of all message format standards, because we figured that might be a little bit more easy to address and get consensus on than code sets or other areas of PMRI standards. And in March of this last year we invited many of the SDOs in to review a questionnaire that we were going to submit to them for information feedback on PMRI message format standards.
That questionnaire was then updated based on their comments, distributed to them in April. We got responses back from the message format SDOs during June and July. We had a report to us in April that kind of summarized the findings from many of those message format PMRI SDOs. And this is October and in October we are seeking insights from the vendors and users of the SDOs, and that what, you know, you are here for.
And so during today and tomorrow morning we are looking for responses to the very brief set of questions that Michael sent out to each of you, and I would say at this point that I would wind up simply saying we are looking forward to what you have to say, and there will be plenty of time, by the way, during each of these panel sessions for us to ask you questions after your testimony. So please keep your testimony within the allotted time that Michael indicated to you, and then we will have time for questions.
DR. FITZMAURICE: Jeff, before you continue I wonder if I might interject that this is going out nationwide over the web. That's why the microphones, it is not only to get a transcript, but also, through the courtesy of the Veterans Affairs, it is going out nationwide, and if they are listening, to our servicemen all over the world.
DR. COHN: And with respect to the comment that Michael just made, it is very helpful if you speak directly into the microphone so that the people on the Internet can hear. And Gary Dickinson, would you like to be our first testifier?
MR. DICKINSON: Thank you Jeff. I'm trying to get the presentation to work here.
MR. BLAIR: We can switch sequences if that would be easier for you.
MR. DICKINSON: I think I'm just about there, thank you.
MR. BLAIR: Okay.
MR. DICKINSON: We are focused on the NCVHS objective to study the issues related to the adoption of uniform data standards for patient medical record information and the electronic exchange of that information. We have identified a series of essential criteria that we think are key to the selection of standards, and some of these are called out of course in the HIPAA legislation directly.
The first is that the standards be ANSI accredited or from an ANSI accredited standards development organization. The main objectives there are obviously openness, that it is open to all participants, that it is inclusive and not exclusive, that there is no undue financial burden to participation, that the process and the membership is balanced, including producers, consumers, government, academia and others, that it follows an open consensus process, and that the ballot has a method by which negative comments can be resolved.
Further that in terms of the criteria that the standard not be technology dependent, that there be completeness of coverage within the standard, that there be validation in proof and practice for the standard in its implementation, and that there be evidence of market acceptance of that standard.
As we look at the existing standards that are suggested, the first, and this is not in the order listed but I will put them in my own order here, the first is HL7, Version 2.x Data Interchange. We believe that this meets the ANCI SDO requirement, that there is obviously widespread industry acceptance of this standard, the deficiencies remain with regard to enabling a robust electronic health record, and we will get into some detail on that as my presentation continues. If you look at section 1.8 of HL7 Standard Version 2.4, you will discover that HL7 itself has recognized the various, a series of deficiencies regarding the current scope of the standard.
Moving on to ASTM XML Specification, clearly it is also an ANSI accredited SDO, but it lacks validation at this point, and industry acceptance from our perspective.
The third standard suggested is the DICOM Version 3 Imaging Standard. This is a consortia. It is not an ANSI SDO. It is unbalanced from our perspective in that it is dominated by producers, and it is not fully open or consensus based, although it does have wide industry acceptance within the imaging market.
The NCPDP SCRIPT Version 4.0 suggested standard is obviously ANSI accredited SDO and therefore it has consensus and balance, but we are not sure about industry acceptance of that particular standard at this point.
The fourth or fifth standard is the IEEE Medical Device Communications standard. IEEE is ANSI accredited, an ANSI accredited SDO. This particular standard, however, lacks validation and industry acceptance from our perspective.
Continuing on to the OMG CORBAmed standard, this is a consortia. There is a substantial financial barrier to participation in this group. The specifications are technology dependent, and as far as we can tell at this point, there is minimal industry acceptance of the OMG CORBAmed standard.
Looking at Per-Se in terms of its particular approach to the market, we have a software family which comprises three basic product areas. The first is Patient1, which is a full clinical system supporting inpatient, ambulatory, emergency, short stay, long-term care and home care. It includes an electronic health record, and we'll get into additional characteristics of that product as the presentation continues.
We have a new product called Business1, which is a patient accounting, billing and claims system. And our third product line if Resource1, which relates to patient scheduling and staff scheduling. I'm going to try to get this presentation to work here, hang on a second. Okay, success at last.
DR. COHN: By the way, Michael, is our guideline 10 minutes or 15 minutes.
DR. FITZMAURICE: Our guideline is 10 minutes, but I think Gary has had some difficulties, so I'll extend it a couple of minutes.
MR. DICKINSON: Okay, continuing on looking at Per-Se's product line, we line this up in what we call a HIPAA chain of trust, where we have the Patient1 products at the clinical front end or point of service, point of care. Information flows from there to the financial system, in this case Per-Se's Business1 product, and continues on to our clearing house, which is our E-Health service division, and then on to the health plan or payer. So we cover three of those four major components in the chain of trust, from the clinical front end to the ultimate point of claim submission.
If we look at the six standards suggested, in terms of how they fit against our products, we discover that HL7 Version 2.x is actually the one that is most applicable and has the benefit of major market demand. The ASTM and OMG standards are also applicable, but we don't foresee that there is much market demand for those standards at this point in time, and therefore we have not responded with implementations in our products. In terms of our products, the domain is not applicable as we look at DICOM, the NCPDP standard, and the IEEE Medical Device standard.
Here is a graphic where I attempt to show the difficulties we have interfacing with external or foreign applications. Obviously when we do that we have, there are two applications involved, our application and another application. We start off with HL7 and we use that as a baseline for our implementation of an interface, so that covers in our graphic here maybe 25 percent of our typical requirement for interfacing.
Typically we can cover another 10 to 25 percent by extending HL7 and using Z extensions, and then typically we end up with a large disjointed domain where we have no good way to communicate information or function, because the architectures for the systems are basically that incompatible. So in other words, if you have, the greater the heterogeneity, the greater the disparity between information processed, and therefore the lower the common denominator between the interfaced applications.
In terms of HL7 of course, the things that are in scope for Version 2.x are those directly enabled by the HL7 Version 2.x specification, and thus we have what we would call an HL7 Version 2.x common denominator, which consists of trigger events, message segments, data attributes, data types, and also the Version 2 vocabulary. Beyond that scope of course to implement requires the Z extensions to HL7 which are Z-triggers, Z-segments, Z-attributes and Z-vocabulary if you will.
In terms of coupling applications in our Patient1 products family, obviously if the application is written by us, it becomes part of our homogeneous architecture and it becomes fully integrated into our EHR by design. It is tightly coupled with that architecture. We do not use HL7 messaging for that purpose.
As we interface with foreign applications with heterogeneous architectures, we implement a loosely coupled paradigm typically with HL7, and based on the common denominator, the HL7 Version 2.x common denominator, we then extend it with Z extensions as appropriate to get additional functionality. To achieve full EHR integration and tight coupling with this foreign application, many impediments are involved and may be difficult to overcome, and typically this involves disparities in architectures or lack of will, budget or resources to implement those extensions.
As we look at the particular questions that are being asked by this committee, we have attempted to gauge the HL7 coverage against our Patient1 product, and the experience we have had implementing interfaces to that product and enabling a tightly coupled relationship with those interfaces and a tightly coupled EHR solution as a results. So we are presenting our assessment in the context of design objectives for our product, also trust objectives for our product, and based on our experience in implementing interfaces using HL7.
The illustration I have on the screen right now shows essentially a progress bar if you will. The blue section shows the coverage that is scope of HL7 Version 2.x, and the white space shows the section that is beyond scope and which must be implemented using the Z extensions to HL7.
And as I continue on now, the various, starting on slide 16, the various design objectives that we have established for our product are described and a progress bar is placed to the right of those. So if we look at what we feel to be the design requirements for medical/legal health record, we believe HL7 is at about a 40 percent coverage position right now in terms of Version 2.x. In terms of the care continuum, in this case being inpatient, ambulatory, emergency, short stay, long-term care, home care, we believe also that HL7 is right at about a 40 percent coverage at this point.
If we look at the timeline continuum, which includes the prospective view of things that are to be done, the current view, which are things that are currently in progress, and the retrospective view, we believe that HL7 covers the retrospective at about 60 percent, concurrent is about 40 percent, and prospective at about 20 percent.
Continuing on, if we look at our health record continuum, starting with the individual health record, we believe that HL7 is about 50 percent there. In terms of the organizational business or operations record, we think HL7 is maybe 40 percent there. In terms of the practitioner service record, we think again that HL7 is about 40 percent, HL7 Version 2.x has about 40 percent coverage in that regard. If we look at the creation of a multimedia record with HL7, we believe that HL7 is at about a 40 percent coverage at this point.
If we continue on looking at work flow management in terms of health care delivery, we have a series of objectives that we have established. HL7 comes to a 40 percent level in the area of integrated scheduling and performance and completion of health service events, but remains 20 percent or less in most of the other areas identified, including assigned responsibility, allocation and staging, routing and deployment, alerts, prompts and reminders, problem list, clinical pathways, careplans, and costs and resource projections and actual measurement.
In terms of functional or business integration, we believe that HL7 is presently at about a 60 percent coverage in terms of inter-disciplinary integration among practitioners and across departments, services and specialities. It is at about a 40 percent level of coverage in terms of intra-organizational coverage across the IDN, across sites, facilities, and business units. In terms of measuring the continuity and completeness of the health care delivery process and the health record, we are about 40 percent in terms of delivery process and about 60 percent in terms of the health record.
In terms of clinical decision support with real-time, concurrent and retrospective, we believe that HL7 has about a 40 percent coverage at the present time in terms of our experience interfacing foreign applications with our product. In terms of clinical knowledge bases, we believe that HL7 has negligible support at this time for those requirements, which include directories of facilities resources and services, guidelines for diagnostic, treatments and medications, standards of care, and medical literature.
I have a couple of requirements here that are not applicable to HL7, one of which relates to availability. The second relates to scalability, but continuing on then to localization, I have identified five areas where HL7, or two areas where HL7 has 20 percent coverage, in the area of master files and data definition identifiers, and we believe that HL7 support for localization of vocabulary, work flow and clinical decision support is negligible in that context.
If we are talking about synchrony of databases, HL7 has a negligible support for that. If we are talking about synchrony of clocks and time across the enterprise, we believe that HL7 again has negligible support for that at this point. Continuing on with version control, HL7 has maybe 20 percent coverage in the area of vocabulary and messaging standard version control, but at the application level the support is negligible.
So again I'm reading through these, Jeff just for your edification, I'm reading through the various objectives, and on the right I have my progress bars that show the level of coverage that we believe exists today with HL7 Version 2.x all the way through Version 2.4.
I'm moving on now to trust objectives, which include developing a uniform privacy and security infrastructure as required for uniform implementation of HIPAA across the enterprise, and we believe that HL7 is at about 20 percent coverage level there. In terms of accountability and traceability, we believe that HL7 maybe has 40 percent coverage in the area of accountable parties, which includes organizations, business units and individuals, maybe 10 percent coverage in terms of accountable agents, which are software and device accountability. In terms of accountable actions, we believe that HL7 has about 40 percent coverage in the areas of provision, performance, completion of health care services, and in terms of origination, retention, use, disclosure of protected health information.
Access control, HL7 is negligible in that regard. There are basically no provisions in the current standard for how you would manage access control across your enterprise. There is no messaging set, there's nothing. Authentication, entity authentication is about a 10 percent coverage. Data authentication and message authentication are about 20 percent coverage in terms of the current HL7 Version 2 specifications.
If we look at defining discrete privacy and security policy domains within the organization, within the enterprise, which may have certain limitations within the organization by facility or by business unit, obviously HL7 does not have the messaging structure in place to manage those domains or to define those domains. So that again is a negligible point of coverage.
If we look at developing a single point of administration and configuration across the enterprise, in terms of master entity registries, in terms of security classifications for data groups, data sets, functions and resources, as well as security clearances, again HL7's coverage in Version 2.4 is negligible.
In terms of objectives related to audit trails and audit inspection, HL7 does reasonably well. It is a 40 percent in the areas of devising audit trails or developing audit trails for health care delivery and work flow events, and maybe 20 percent in the area of record chain of trust events and record integrity and continuity. Those are both 20 percent coverage. In terms of access events and security incident and systems management events, we believe that the coverage is negligible in Version 2.4.
Our trust objectives continue with data integrity, actually that first bar should be down one line, relating to uniform data definition, we believe that HL7 has about a 20 percent coverage in the area of uniform data definition, vocabulary, which includes data groups such as data sets, attributes such as data elements, data typing, code sets and classification schemes, that's about a 20 percent coverage.
In terms of the JCAHO definition of data integrity, which is accuracy, consistency and completeness, we believe that HL7 has a negligible contribution or negligible coverage right now in terms of being able to measure accuracy, consistency, completeness of data across from its point origination to its ultimate point of use. The last criteria under data integrity is the persistence, permanence and indelibility criteria, which is for the HIPAA definition, and we believe that HL7 may have 20 percent coverage of that at this time.
In terms of our health record "chain of trust," from point of origination to point of access or use, we believe that HL7 has about a 20 percent coverage of the requirements in that area.
Looking at "chain of trust" audit events, to further enumerate that, we believe that HL7 has 40 percent coverage in the area of record origination and amendment and also verification, but has nothing to offer in the areas of audit events for access and use, for data translation, for disclosure, transmittal and receipt of records, for record de-identification, aliasing and re-identification, for record archival, and for physical record check-in and check-out. So the 40 percent scoped against the two criteria and everything else is negligible in terms of the "chain of trust" audit events.
I'm just now to wrap up, there are some references that will help guide your further work in this area. One is recently published, the ISO 18307 specification, which is "Healthcare Informatics-Key Characteristics for Interoperability and Compatibility in Messaging and Communications Standards," and I believe if you take that document and review it carefully, you will discover that my estimation of HL7 being in the 25 to 30 percent coverage for all the requirements is probably high when you compare it with this particular document.
There is a good document produced by ASTM in 1966, called "Standard Guide for the Properties of Electronic Health Records and Record Systems." Again that is a good document to compare against current HL7 functionality. And then if you really want to go to the source for HL7, refer to Version 2.4, Section 1.8, which describes in fairly great detail the many deficiencies that remain in HL7 Version 2, and probably will continue with Version 3 as far as we can tell at this point. Thank you.
MR. BLAIR: Gary, thank you very much for your testimony. I would find it helpful by the way, on the rest of those folks who testify to us, that if you do refer to HL7 Version 2.x, could you just let us know which of the seven message format transactions you are referring to, so that we have a feeling for which ones in specific your comments really reflect. Our next testifier is from Cerner.
MR. GARTON: Yes, Aaron Garton from Cerner Corporation.
MR. BLAIR: Thank you for being here and we look forward to your testimony.
MR. GARTON: I'll provide my oral comments and I've also submitted an electronic version of our comments. First Cerner Corporation would like to thank all members of the Subcommittee on Standards and Security for giving us the opportunity to present the following information to you. We hope that our comments allow the subcommittee to move forward with the standards process.
DR. COHN: Aaron, could you get a little closer to the microphone?
MR. GARTON: A little closer, there we go. Cerner Corporation designs definitive solution to accomplish one mission, to connect the appropriate person, knowledge and resources at the appropriate time and location, to achieve the optimal health outcome. In general, Cerner Corporation is in favor of any technology that will reduce IT costs. We are not convinced that the idea of tightly regulated transactions and message formats without data content definitions will reduce the costs for our clients.
Specifically, when the transactions for message formats do not require corresponding data content definitions, the benefits of standardization cannot be achieved. We believe that data content standards are needed before standard message formats can be developed and implemented efficiently in the marketplace.
We offer the following general observations regarding the current available standards. There are many standards owned by multiple organizations and listed or sourced in different locations and ways. Each of these standards is balloted, accepted and updated on a different cycle, many as often as yearly. The standards themselves are controlled by different organizations with different memberships and publication processes. Maintaining currency in each different standard is very difficult and expensive.
In an effort to provide a standard environment for implementation, we recommend that any regulations that reference standards must be version number specific. Regulators must also resist the temptation to use the most current version of each standard if the benefits of standardization are to be achieved.
The current discussion regarding the regulation of clinical data standards must be considered as it relates to the existing investments of health care organizations. Cerner Corporation, along with our clients, have created over 3,500 interfaces that must be maintained and supported at any point in time.
Regulations have helped with message and transaction formats, but the lack of specific data content references or standards as part of these regulations has caused the additional confusion, delay and costs. One of examples is the confusion created by the delay in finalizing the National Person ID as part of the current HIPAA regulations.
The current push by the Department of Health and Human Services to create regulations which force standards into an open market with a relatively short period of time, 24 months implementation timeframe, will most certainly increase the costs and time commitment for all organizations diverting the limited pool of resources from the more important mission of improving the process and quality of the health care system itself. This begs the question, which is more important, reducing medical errors or standardizing clinical data transactions as part of HIPAA?
Cerner Corporation is driven primarily by market demands. The HL7 Version 2.x, specifically Version 2.1, is our primary standard model. It is the most requested standard from Cerner Corporation's current clients. Again this standard is highly market driven. It is important to note that no current site is pushing Cerner Corporation to Version 2.4 standard.
The major weakness of HL7 Version 3.0 is that it has not been proven by the market, and thus not ready to be considered as a major national regulatory requirement. Balloting by HL7 for Version 3.0 was completed the end of September and has not yet passed.
Again we are currently market driven by the standardization process. We have only had one request for the IEEE standard for Medical Device Communication, and no request to date for COBRAmed or ASTM specifications.
In summary, Cerner Corporation would like to see standards for data definitions and content, via controlled medical vocabulary prior to any regulation regarding the format for clinical data messages. A consistent controlled medical vocabulary would not only benefit the message format standards, but is key to the portability of medical records by our mobile population, and more importantly, is the key for comparable data outcomes that is required to improve the quality of care provided. Unfortunately there are no current well-accepted standards for a comprehensive controlled medical vocabulary.
In closing, Cerner Corporation does support the need for message format standards, but message format standards implemented without content standards force the time and cost of support to be high. Cerner Corporation would like to recommend that the Department of Health and Human Services consider investing in the creation of an affordable controlled medical vocabulary in addition to these message format standards. Thank you for your time.
MR. BLAIR: Thank you Aaron. And our next testifier is?
MR. ADDY: Brett Addy from Superior Consultant Company.
MR. BLAIR: Brett, please try to identify if you can, if you are going to reference HL7, please reference the specific transactions within the seven HL7 transactions that were listed in the questionnaire that you are referring to, which ones.
MR. ADDY: Superior is over 1,000 professionals, consultants, and we are providing expertise to over 1,900 clients. My background personally has been product development and also with interface engines interconnecting and integrating all these systems together in large facilities.
Which protocol for PRMI? Well it depends. If you are addressing just the medical record and not other data issues, then it is HL7, the reason being is that HL7 Version 2.x has become the de facto standard for electronic data exchange between systems providing patient care for both intr and inter-facilities, and I'm talking about ADPAs, orders results, charge information, et cetera.
Why? Well pre HL7 integration there was no standards, interfaces were point to point, there were vendor proprietary fixed length, fixed field flat record messages that weren't easy to extend, add new data. If you did, it required customization. There were support and maintenance issues. A lot of times to get the information out of the systems you ended up coming up with very customized access. When new versions of software were released, there was no guarantee that you would come up with for a solution would be viable in the future. It also required extensive knowledge of each system by the integration staff in the facility.
The benefits of HL7, it is industry standards widely acceptable and implemented. It's vendor supported. It is also customizable with new segments and fields. The dynamic length in both segments and fields allow new large information to be passed. It is forward compatible, and it is the most mature of all the standards.
It has been our experience that most of the implementations out there are Version 2.2. Now there's no business incentives to migrate to later releases, even though you have had 2.3, 2.31, and 2.4 come along. Later versions have added segments and fields to address data not identified in earlier versions. However, facilities addressed the undefined data with customized segments and fields, but since the interfaces are currently up and running, there's no incentive to go mess with them. It is the old if it's not broke, don't fix it. Also Y2K did not force HL7 version changes. Since HL7 was fully compatible with Y2K issues, it was not impacted overall. It was the vendor systems that had to be addressed and retesting in that area.
Issues. The location of some data is open for interpretation as we have matured products, offerings in the health care industry, such as enterprise wide group systems like an enterprise wise patient tracking number, internal note tracking numbers for passing back and doing orders, from a lab system back to the main order entry system and back and forth. Those were not laid out in the beginning. There's lack of standardization of field values for facilities and groups. It is not fully integrated into some products, thereby adding problems into the messages themselves. For example in free text data entry fields, some systems will still allow the entry of HL7 delimiters in those fields that are not filtered out, therefore causing problems in the system. It is still an evolving spec for speciality issues that are going beyond what was basically laid out in Versions 2.1 and 2.2.
Time to implement. It is a function of vendor systems, vendor specifications, transaction type and knowledge base at the facility and from the vendors that are working with the facility to get the systems implemented. Simple interfaces can take 120 to 200 man hours to implement and test on an interface engine, more if there's other systems that must be modified. More complex interfaces are 500 plus, depending on the complexity of what is going on in the interaction, the handshaking going back and forth between the systems.
Cost to implement. It varies on the number of systems, interfaces and the customization that is involved. One of the big issues is lack of skilled integration staff at facilities. Even the most prestigious facilities use consultants to implement their major projects, and facilities use their own staff more for maintenance and support and adding in small projects. Interface engines centralize the knowledge which helps small integration staff at many of the facilities, but there is a high entry cost into the interface engine arena.
Later versions of HL7. They will add new segments and field to mainly address the specialty issues that weren't originally dealt with in 2.1 and 2.2. And for an example I threw up in patient information now they added breed and species fields, but that was only for the benefit of veterinarians.
HL7 and XML. We believe that XML has a future in health care information. A simple XML implementation of HL7 would allow position independent data within messages, but the issues is is there enough business incentive to move quickly to this. Probably not.
If you were to pick some other new standard to go with, the recoding effort, and a rough estimate that we put together, was a charge of $250,000.00 per medical facility for the interface engine alone. We took a rough estimate of 6,000 facilities. You come up with an area of $1.5 billion dollars, and this does not include practices, payers, vendors or supply chains, and the cost rises exponentially when these systems are considered.
Other cost consideration. There's a training and learning curve cost. The first interfaces that went in using 2.1 and 2.2, between different vendors, the interface engine vendors and the facility staffs took a lot of project management, a lot of back and forth discussions to get a lot of these systems in and working in the first place. We are past that point in many areas, but if you were to go to another standard, we would probably have to go back to that learning and training curve again.
MR. BLAIR: Just so I understand. When you say go to another standard, are you saying another version of HL7 or are you saying another standard other than HL7?
MR. ADDY: Another standard other than HL7. If you were to go to another standard, you would mandate integration and retest of every function of every system in the facility, plus inter-facility messages also. If you were tied to HIPAA, the two year implementation window with current skilled resources may not be realistic, with the number of experienced qualified integration staff that is out there in the market. And one of the biggest issues that will happen, that we saw with Y2K, will be procrastination by the facilities which will make this an even bigger issue, because they will wait until the last minute and resources will be at a premium.
Our recommendation to control cost is to keep the current 2.x standards and build upon them. Add transactions, segments and fields that address issues not currently handled. Define standard field values and vocabulary for systems and facilities, and add a voluntary migration path to an HL7 Version of 2.x XML schema. The current draft of HL7 Version 2.x schema does not address all the issues and has some holes in it as it currently exists. Thank you.
MR. BLAIR: Thank you. Our next testifier please.
MR. MEYER: Last but not least Jeff. Mr. Chairman, members of the subcommittee, I am Chuck Meyer Informatics Standards Liaison for McKesson Information Solutions. We greatly appreciate this opportunity to address the subcommittee regarding PMRI message format standards. McKesson has long been a supporter of comprehensive health care informatics standards and believes that the ultimate adoption of standards specific to the capture, exchange, and maintenance of patient medical record information will go far toward improving the quality and safety of patient care.
I have restricted my comments at this point to the list of standards presented, and by the way Jeff, when I refer to HL7 2.x, I am referring to the entire suite of message formats, because candidly they do not do well standing alone. You must have ADT to enable the order process and they are in fact building blocks. If you could implement a single one, it would probably be the patient administration message set, and that is in fact the most widely set of transactions when HL7 implemented. All of the others would tend to build off of those or have some ancillary function with them.
The list of standards included with the invitation to address the subcommittee is comprehensive; however, with the except of HL7, none address the full spectrum of message exchange relevant to PMRI.
While the IEEE standard is unparalleled in its ability to communicate patient telemetry data, its purview is limited to those scenarios requiring automated patient monitoring. This standard does not, nor was it ever intended to, address the exchange of information necessary for patient administration and scheduling, order entry and management, observation reporting in the general sense, or medical records management. The IEEE standard fills a unique niche in the conglomerate of information that forms the patient medical record.
The CORBAmed standard from OMG is without a doubt the leader in component-based health care messaging. However, by its very definition it is limited to client/server applications and, once again, does not support the full and essential exchange of information necessary to qualify as a PMRI messaging standard. Further, OMG is not an ANSI accredited standards development organization. Beyond facilitating portal operations, CORBAmed has achieved little penetration as a messaging standard in the health care environment.
The DICOM standard is used widely for the exchange of radiological images, but it is a very complex standard and restricted in scope to the exchange of such images. We have seen little or no penetration of the general health care market by DICOM nor would we expect any enhancements to the standard to rectify that situation.
It is interesting to note that ASTM is only represented by two "enabling" standards, which in reality do not serve to enable a higher standard of interoperability. These draft standards, now in ballot for final approval, are incomplete clones of the HL7 Clinical Document Architecture. They profess to be CDA compliant, which seems synonymous with a proprietary approach to structured documents based on CDA. We question why an ASTM working group is trying to replicate an ANSI accredited standard without the infrastructure necessary to support its implementation. In the overall scheme of things, ASTM E31 standards have not received wide spread industry support. We do not expect these documents to fare any better.
Finally we consider the NCPDP SCRIPT standard for a prescriber-pharmacist interface. This standard, although well conceived, designed and documented, is constrained by its definition and domain. NCPDP represents the standard in use for all retail pharmacy transactions in the United States. We believe this standard will be adopted for that domain as well. However, it is obviously not a workable solutions for the full gambit of medication information exchange necessary for support of the patient record. HL7 has a robust medication information messaging structure supporting all facets of such information exchange. NCPDP and HL7 are currently negotiating a cooperative messaging development agreement, initially focused on vocabularies.
This brings us to HL7, the only viable messaging standard relevant to the exchange of patient medical records information. McKesson has long relied on HL7 as our integration tool of choice. It is broadly implemented within our extensive library of health information technology applications. This is mirrored by the general industry acceptance of HL7 as the standard of choice for clinical content. Beyond the domain of the provider-payer, HL7 is far and away the industry leader in health information exchange with implementations reaching well beyond the traditional acute care arena.
We need only look at the current organizational structure of HL7 to recognize its wide acceptance, both nationally and internationally. HL7 now has 18 international affiliates and is being used in such diverse applications as home health, public health reporting of proscribed laboratory results, and the CDC immunization registries project. At last week's HL7 meeting it was noted that the New Zealand Health Services' Ambulatory Care Service is based entirely on HL7 messaging.
As a vendor of health information technology McKesson Information Solutions is largely market drive. The high demand for HL7 expressed by our customers over the last decade has led to our extensive involvement in the development and use of the HL7 messaging standard. We have implemented literally thousands of HL7 Version 2.x interfaces and contend that it is the de facto standard for the exchange of patient medical record information. Based on the number of non-McKesson ancillary systems we have completed HL7 interfaces for, it's apparent that the rest of the industry supports that position.
Given its current wide spread use, the designation of HL7 Version 2.x as the national PMRI messaging standard would not, in our opinion, prove to be too much of a burden to the health care industry. However, we do not believe that such a decision would ultimately benefit the quality and safety of patient care.
In its current iteration HL7 Version 2.x represents a specification that still requires significant negotiation to resolve its ambiguities. Many vendors, including McKesson, have a long history of conducting such negotiations and have developed mechanisms to speed the process. Nonetheless it is a time consuming and expensive exercise. Even though HL7 has committed to continue to develop Version 2.x standards as long as the industry demands it, there is little to console the Version 2 veteran given the issue of backwards compatibility. It should also be recognized that to a large extent the insistence of continued V2.x enhancements is driven by the International Affiliates.
It is interesting that you have chosen the designation Verson 2.x, given that the current ANSI accredited version is Version 2.4. Hopefully this is directly related to the large number of earlier versions of the standard still in use. It was apparent by the selection of the standard transactions and code sets that it was not the intent of administrative simplification to turn the industry on its ear. This would certainly accommodate the installed industry base. It may also recognize that there may well be later Version 2 iterations that should be considered when designating a national standard. I applaud such forward thinking.
However, we contend that it is not forward thinking enough. McKesson has made significant commitments of time and personnel to further the HL7 Version 3 effort. We believe that Version 3 represents a quantum leap in integration technology. Based on a common reference information model, well-defined methodology, and a comprehensive tool set, Version 3 should not be considered as just the next version of HL7. It is the next generation of health care messaging standards, easily extensible to cover all facets of health care data interchange requirements.
Rather than tie the industry to a given version of a standard, we believe that the process should support the designation of an SDO, in this case HL7, as the producer of the national standard and allow the adoption of any ANSI accredited version of that standard. Such an approach would further validate the dual track approach supported by HL7 and foster systems enhancements to support the next generation of the standard.
Our experience with the process of adopting standards for administrative simplification has produced some trepidation. We share a concern with the industry that a methodology must be adopted that improves the timeliness of this process. We do not believe that the recommendation of a standard should result in the mandated adoption of one that is at that point obsolete.
McKesson has already made commitments to incorporate the V3 process into its product development cycle. While awaiting accredited messaging standards, we have instituted a process of basing data exchange and integration on the reference information model and quasi-proprietary refined message information models, quasi-proprietary due to the fact that our R-MIMs or reference message information model, refined message information models, may differ slightly from the one actually balloted by HL7. Wherever possible we use proposed components and stand ready to convert to the accredited messages once available.
In summary, McKesson believes that HL7 represents the only viable PMRI message format standard from among those presented to the panel. McKesson's selection of HL7 was driven largely by market pressures to adopt it as the de factor health care messaging standard. I have chosen not to address any implementation issues as the questions seemed more applicable to the user versus the developer. Further, our prices are the subject of contract negotiation and may vary in any given circumstance.
Although widely implemented, HL7 Version 2.x has certain limitations related to ambiguous field definition and inflexible message structure. These are addressed in Version 3. McKesson is committed to providing support for Version 3 in our products. In this effort we have integrated the Version 3 process in our product development methodology.
Let's not make the mistake of stipulating a version of a standard that is obsolete by the time it is adopted and implemented. And finally, McKesson is not aware of any other standard that meets the criteria for the exchange of patient medical records information.
Thank you again for your time and attention.
DR. COHN: We want to thank the panel members and we'll begin questions in just a second. We wanted to give Dr. McDonald who has now arrived the opportunity to introduce himself, as well as indicate whether he needs to recuse himself regarding any of the issues coming before the subcommittee today.
DR. MC DONALD: I'm Clement McDonald from the Regenstrief Institute, Indiana University. I'm an activist in HL7, as are other people on the committee, and I think I am fairly objective, but you can yell at me if I am not.
MR. BLAIR: Actually Simon, I had failed to indicate that I am a member of HL7, I'm a member of ASTM. I'm not an activist per se in either one, so I don't feel like I need to recuse myself from any comments or judgments with respect to both of those.
DR. ZUBELDIA: Yes, this is Kepa and I also am a member of NCPDP and ASTM.
DR. COHN: And I guess I should finish up by saying I'm not a member of any of those organization, but I am a member of the ANSI Health Care Informatic Standards Board, which works collaboratively with any of the SDOs.
PARTICIPANT: - identify our memberships as well, Jeff?
MR. BLAIR: No, no. Just the four.
DR. MC DONALD: I'm a member of, let me tell you I'm also a member of ASTM and I am on the mailing list of all ASTM - in the NCPDP.
MR. BLAIR: And I'm a member of ANSI ye as well.
DR. COHN: We are just indicating our affiliations. I think we should open up for questions and comments.
MR. BLAIR: We have about, Michael, do we have about 20 minutes, it that right, for questions?
DR. FITZMAURICE: Yes, 21 minutes for questions.
MR. BLAIR: Alright. Simon, let me turn it over to you. You can point up, acknowledging people.
DR. COHN: Well Dr. McDonald already had his hand up, so we'll let him start with the questions.
DR. MC DONALD: I would like to ask, get a sense from each of the testifiers the size of the company and the health care industry that they are working with. We heard some of it, but I don't remember hearing McKesson's size. If we could just march through it.
MR. MEYER: You mean other than thousands of interfaces, Clem?
DR. MC DONALD: Well is it you know, 30 bucks a month, you know, how many hospitals, you know, some sense of the scope.
MR. MEYER: I have no way of writing a number figure to that question. I mean we are the preeminent health care information technology vendor in the country. We do over 3 billion dollars a year in business. We have outsourcing arms as well as product development and our products run the full gamut from a single physician's office to the Mayo Clinic. I have no way of giving you a dollar figure relative to that.
DR. MC DONALD: That's sort of a sense here, and you mentioned some numbers.
MR. ADDY: Yes again we are about 1,000 professionals, consulting every aspect of health care. We currently have contracts with about 1,900 different facilities. Personally I have been involved with many of the large facilities in doing integration, even in the DC area and all over the country.
MR. GARTON: Aaron Garton, Cerner Corporation. We have over 3,000 employees. We have over 3,500 actual interfaces that would include both our classic and millennium products. I have no way of giving you financial numbers on those individual interfaces, but hundreds of clients worldwide.
MR. DICKINSON: Per-Se has close to 6,000 employees, primarily US based, some international. We have three divisions, a software division, we have an E Health Division which is a clearinghouse function, and we have physician services, which is our largest division, which does physician and practice management physician billing services. I don't know that I can break all this down.
DR. MC DONALD: Well I just was trying to get a sense. These are not little players, these are big, big players.
DR. COHN: Yes. Let me ask a more substantive question of the panel. I mean, more substance. Oh no, I think it is useful to know. Sorry Dr. McDonald. I think one of the questions, as I was listening to the panelists, was really the question that the subcommittee needs to address, and I've just sort of moaned about well what is our question, and I hear all of you talking about various versions of HL7 2., for the purposes of this discussion 2.x, which is really four or five different versions over the last 10 years of HL7. And I'm really wondering, and I appreciate all your comments about this, about whether or not the real issue for the subcommittee is agreeing that some version of HL7 2.x should become a national standard. It appears to go only a de factor standard if you consider the four versions of national standard, or is really the issue for the country and the health care industry to assure some sort of successful transition to Version 3.0.
What do you see as the issue here? Do you think the industry is going to be happy to stay with 2.0 into the far future, or is that other issue really a valid issue. And Gary maybe you could start off. I mean observing, you thought that any of the versions of HL7 2.x didn't quite meet what you considered to be all of your needs.
MR. DICKINSON: Well that's correct, and again we are looking at it from the standpoint of how do we implement a robust electronic health record, with communication, with various foreign applications, using HL7, and it turns out that we have to extend it heavily or we just don't do it. Many times customers don't want to make the investment to do those extensions on a site by site case by case basis, so we end up using common denominator, which is pretty much HL7 version, pick your version, 2.2 shall we say, and that's what we go with. And so that gives us a common denominator which is very constrained and does not give us all of the messaging or communication interchange requirements that we need, that we feel we need, to implement a robust electronic health record.
So in that case we think that there, that even though the existing standard has good structures and good capabilities as far as it goes, it is far from complete. As we look at Version 3, we don't see, we beg to differ with our industry colleagues here, we don't see the great leap forward in Version 3 that others might, because we see essentially a retooling of HL7 Version 2 now coming forth in Version 3 with some new nice things, but again not covering the new domain or the extra domain that we think is necessary to implement a robust electronic health record.
MR. BLAIR: That extra domain is?
MR. DICKINSON: I'll start with security and privacy. If you don't have a security and privacy structure infrastructure in place for your organization, that includes accountability, includes authentication, includes auditability, all those things, you don't have a robust electronic health record. You have fragments of this and that, but you don't have what I would consider or what I would call a robust electronic health record solution.
MR. BLAIR: Do you, may I ask a follow up question?
DR. COHN: Sure, well we were going to ask everybody to respond to this one, but if you have a specific issue on this point.
MR. BLAIR: Yes, because I want to just sort of sharpen the distinction here, since there seems to be a disagreement here. Okay so you feel as if that is the main area where HL 3 does not promise to meet your needs as a vendor. Do you share the feeling that seems to be generally prevalent that HL 3 will improve interoperability and get the industry closer to plug and play?
MR. DICKINSON: Well in the sense that there is a modeled foundation for Version 3 that was not in place in Version 2. Version 2 was much more of an ad hoc added to the end kind of a development process. That is a benefit certainly. But the things that we need for interoperability and the full range of interoperability are wrapped up in what Version 3 has devised as interaction models and application roles, and at this point in time those are so, that effort is so diverse and fuzzy, that it is not clear that the interoperability as claimed or suggested will ever come forth. And therefore I don't think we will get the coverage we need and we certainly won't get the interoperability characteristics that we might have been expecting given the way this was sold.
MR. COHN: Any other testifiers?
MR. GARTON: DR. Cohn, I would answer your question from the standpoint of our customers, and I believe our customers' viewpoint is and would be there is a cost associated to upgrading from Version 2.1, whatever it may be, to Version 2. whatever, and it appears that our customers associate that cost to the benefit, they weigh the benefit of replacing that interface with actually replacing the product, and I would say our current customer base is moving more towards a single repository approach and replacement of that product versus replacement of the interface.
MR. BLAIR: Does that imply, when you say a single product approach, a tightly integrated approach which may not necessarily require another version of HL7, or are you saying that next product uses a different version of HL7?
MR. GARTON: I would say that next product does not use a different version of HL7, that next product simply sits on top of their current data base or repository. There is no interface.
DR. COHN: Brett?
MR. ADDY: I kind of echo the same things that have been saying, that the issue in the facilities is the return on investment to rebuild their interfaces, what advantage do they get from them. At this point there's not a whole lot. If you were going to migrate to a brand new standard or to 3.0, then it needs to be a migration path that can be done on an as needed basis.
The other issue is that if you are going to do that, you need to make sure that the 3.0 is fully specified, fully matured so that it is a one-time cost and not the migration that happened with the original HL7. For example, again as I pointed out in my presentation, there was a big huge learning curve and maintenance because of things were not clearly specified, open for interpretation, open for location, and so what happened was there was large amounts of man hours set just in meetings trying to negotiate where things were going to exist and the message formats and everything.
Like I said, we have swallowed that, we've gotten past that. The later versions have addressed those issues. So if you are going to make that move, it has got to be tightened down solid. The other approach would then extend the 2.x as it is now and try to tighten it down for its specifications.
MR. MEYER: I certainly cannot disagree with my colleagues with regard to reticence of the customer base to want to change their interfaces. I mean there is no question they are doing what they needed them to do, and as the gentleman from Cerner pointed out, often the issue of the interface only comes into play when you are addressing the replacement of some form of ancillary system, or even your major HIS.
However, we believe that this activity currently underway, all that HIPAA 2 or whatever we want to refer to it as, does in fact provide the impetus to move the industry toward a more robust and open standard. Given the history of HIPAA, the X12 transaction set at the point in time it was adopted had not been accepted nor proven nor even widely implemented in the industry, and yet the industry came together and said this is the standard we want because it is more comprehensive, it will do a better job, and there were extensive costs involved in that, no question about it.
So it is our intent that given the window that we see with these other things, and I think as I related it to the relatively glacial process of the bureaucracy in implementing these things, that in point of fact a five-year window for mandate of clinical standards is not unrealistic, and at that point Version 3 is certainly a viable candidate and should not be excluded.
MR. BLAIR: Thank you. Is there anyone else that is on the subcommittee that has a question?
DR. ZUBELDIA: Thank you Jeff. I think is fascinating to see four vendors, all four of you agree on one thing and that is HL7. But beyond that, Per-Se is vying for 2.4, Cerner for 2.1, Superior for 2.2, and McKesson for Version 3. It is great that we have, we are contemplating here a standard to allow the communication of medical records, but if the vendors don't want to communicate with each other, it won't work. So it is just a comment.
Now the question here comes at what point should we stop in the recommendation for adoption of a standard. We could stop at saying the standard should be HL7, and that's it, stop there. Or we could say the standard should be HL7 Version 2.x or Version 2.5, or whatever version 2. something or Version 3, or go one step deeper than that and say these messages with this specific implementation guides is what should be elected. And the purpose of this is to allow interoperability. If we have a standard that is not interoperability, you will have a standard that has to be negotiated for each pair of interfaces, and every time there has to be negotiation and new development of the standard in order to make two pieces of software talk to each other, I don't think we have achieved much.
But I think I would like to hear your feedback as to where do we stop. Should we go all the way down to implementation guide, or should we stop at a higher level?
MR. MEYER: I think that I made our position quite clear, that we believe that it should be the designation at the SDO level, because we see HL7 as continuing to pursue a duel track scenario, and continuing to evolve in enhanced Version 2.x while it moves forward with the accreditation of Version 3 simultaneously. And it is not that as vendors we don't communicate. Fully half of our interaction with laboratory systems is with Cerner, and those are 2.1 and 2.2 interfaces.
What you have to do as a vendor, and we have undertaken it, is to develop a process that supports the full range of interface implementations available, and that may be accomplished either through an interface engine, much as Superior is proposing, or through a comprehensive software suite that actually is a back end to your application set that does all of this composition and transferring communications, which we also have available.
MR. ADDY: Point of clarification is that we are not advocating Version 2.2. It was our observation that's where the industry is kind of sitting at for the most part at this point in time. And it is kind of interesting the fact that you have gone on with Version 2.3, 2.31, and 2.4, and yet the number of implementations using those standard do not match the number that are sitting out there currently running at 2.2.
And again, the issue of any of these standards in making the work, what is going to happen is you are going to get, what we are seeing is more and more different types of data being passed around the facilities. There is no way of foreseeing what is going to be new out there. So this issue of trying to get new forms of data, there's always going to be integration people negotiating, trying to work out the details of getting these new data types in and formats. The issue comes to coming up with good techniques and procedures to negotiate and to get this done as quickly as you possible can. And a good standard that has locked down as much of the definitions as possible will allow us to move forward with that.
DR. ZUBELDIA: Does that mean you recommend that we stop at the implementation guide level?
DR. ADDY: Most of what we have, I've heard the comments using a common vocabulary, coming up with standard definitions, it is not in the implementation, it is coming up with standard definition for the different fields and the data content therefore, even the simplest of things, because what is happening, years ago when we first started integrating systems, it was just within a single facility. And there we were having problems of translating different types of fields between those systems within the one facility.
Now you have compounded the issue because now you have many health care groups that are now trying to talk amongst themselves and that compounds even on top of that. You know you start talking about specific issues like order pneumonics, order definitions, each site comes up with its own customized test suites, pilots, whatever you want to call them, and again so because these are all different between the different facilities. In a medical group maybe sharing one lab system for example, there is a tremendous amount of work to get this all integrated so that they can share the one system.
MR. BLAIR: When you are winding up saying common definitions, are you thinking in the back of your mind the common definitions that might be provided by the HL7 reference information model or by Loink and Snowmed or both, what are you thinking of.
MR. ADDY: Both, just coming up and nailing it down tightly in both those areas, so that there is a common definition, and if you can get, you'll never get where there is 100 percent, but you can get, you may be able to get a large weight there and that would simplify a lot of the effort that goes on.
MR. BLAIR: So you feel like that would be a good way for users and vendors to transition between different versions of HL7?
MR. ADDY: Yes, that's one of the biggest areas that, of the work that I have dealt with, that I've seen, is working in those specific areas. Once we got past, like I said, the initial learning curve of 2.1 and 2.2, and trying to handle internal tracking numbers from one system having to be passed back to another system, so that we could get the enterprise tracking numbers, that kind of handshaking down, then things got a whole easier to interconnect the systems together.
MR. GARTON: The cynical version is we are not advocating 2.1 again. That's where we believe the market is currently and vendors do talk, they communicate. That again is market driven. The cynical version though, even though I have said we have 3,500 interfaces, we don't believe that interfacing systems is actually the way to go, and I know I say that tongue in cheek, but we believe to improve health care, to improve the quality of care, the ability to run rules, the ability to use a database to its fullest extent, requires a single repository.
DR. FITZMAURICE: You mean a single vendor or no?
MR. GARTON: No. We mean a single database that gets information from a variety of sources, locations, and by that I mean radiology, lab, patient care, home health, all those different sources of patient information, and we believe that that is the most effective way to again improve health care.
DR. COHN: Let me follow up on that one, because I think most of us support the - it doesn't begin to meet for interfaces.
MR. GARTON: Again, I definitely understand what you are saying, and again we have 3,500 interfaces, and we do talk to other vendors, but I feel compelled that your, I'm answering the question from a Cerner perspective.
DR. ZUBELDIA: I'm asking the question again, how deep should we go. We know that talking about until 7 and say what needs to be standard is a single repository.
MR. GARTON: We believe moving to HL7 Version 3.0 would cause additional cost to the market that is not needed by Cerner Corporation, again I want to preface that, that I am speaking for Cerner. We believe that pushing the market to HL7 Version 3.0 would cause an increased demand and cost to our current client base.
MR. BLAIR: If I can pressure you a little more, you say that's what we shouldn't do. What should we do?
MR. GARTON: My comments earlier are that in order to interface effectively, efficiently, we need current content, we need content standards to know exactly what we are receiving is the same across multiple systems.
MR. BLAIR: Is that parallel to the comment that we need common data definitions?
MR. GARTON: Yes.
DR. MC DONALD: But let me clarify. I think this is really vocabulary everyone is talking about, not data base definitions, I mean although they all play in. But you mentioned order sets, you know the codes you list you have in the various fields. Is that correct or not, I want to just clarify for the, I'm seeing nods, but I don't hear anybody saying anything.
DR. ZUBELDIA: Aaron, are you saying that we should stop there and say there should be standard vocabulary and stop there, and then let the industry do whatever they want for the interchange standards?
MR. GARTON: I'm saying you should consider very strongly the standards that are released and the time that they are released. Coming out with new standards even every 12 months is a considerable cost to the market. Does that answer your question?
DR. ZUBELDIA: No, no it doesn't.
DR. COHN: Do you want to try it again or should we let it go to Gary.
DR. ZUBELDIA: Let's go to Gary.
DR. COHN: Gary, comment?
MR. DICKINSON: Yes. I guess in terms of your question Kepa, I would say the Version 2.x family of standards, in that they are backward and forward compatible for Version 2.1 forward. Now this is important to note, because Version 3 obviously moves us away from that compatibility and Version 3 moves us away from it in a dramatic fashion in the sense that Version 3.0 and Version 3.1 are not guaranteed to be backward compatible or forward compatible with one another, because changes to the underlying model will change the way the messages are structured, and therefore we no longer have a forward compatibility scheme in HL7 once we go to Version 3.
So I would suggest that if, and that is one of the reasons that we can talk in terms of is it Version 2.1, 2.2, 2., all you have done with those is we have added more stuff at the end or we have added new segments, so that in fact you can still run, on a 2.4 system it can still communicate at a basic level with a 2.1 system, and that is because we have maintained this compatibility seen throughout.
Now I should point out that interfacing does not yield integration and certainly does not yield interoperability, so let's be careful when we talk about interfacing. We are talking about interfacing within a common denominator, which is obviously, which in most cases is much less than what you would need to achieve human operability between applications. And that's what I tried to point out in my presentation is there's a big gap there, and it remains and will remain for the foreseeable future.
DR. MC DONALD: Just a comment then, then a question to the panelists. I'm an active user of HL7. Our hospital we could not have built our medical records without somewhat 30 some odd interfaces, and just an observation over time. It is often stated that the problem has been that HL7 is ambiguous, and I won't deny there is ambiguity in life everywhere, but what we found was that the early vendors submitting HL7 would come on with two vertical bars and anything else in between it and it was really what I have seen change dramatically in the last five years is the vendors know what HL7 is and they represent it correctly.
So we can put an interface in, in terms of the interface, in a week or two, and the only hardware because of vocabulary. So I mean I support lining up what do they mean by this word in their English word when they speak of vocabulary in there versus what we mean by it. And it has really gotten fun, I mean in terms of the ease of snapping them in for the different clinical feeds, it is pleasing. And they often will give you a suite of them. You can choose 2.1, 2.2 or you can have some with more, you know, with data graphics or without. It is kind of nice.
MR. BLAIR: I hope this is a quick question at the end.
DR. MC DONALD: Oh the question, I'm sorry, I almost forgot until you mentioned the word question. The question I have for the panelists is really I want to reemphasize, there was only one of the panelists mention anything about ambulatory care or none, well you didn't specify the domains in which you are working. So could you comment on experience in terms of outpatient, office care, home health care with HL7, or is HL7 exclusively in the hospital.
MR. MEYER: From a McKesson perspective in Information Solutions, we have widely implemented HL7 in what might be construed as some unique environments. For example, we support the communications of the care plans between acute care to home care facilities using HL7 messages. We have a current process underway in our Home Health Division to communicate between our home health product as it relates to the patient and the supplier of durable medical equipment. As a result of the visit we can now communicate directly with those suppliers and that triggers into their central supply organization, which in turn drives invoicing and delivery of equipment and all that kind of stuff.
As I pointed out, as a result of some information at the HL7 meeting, for example, that the entire ambulatory care services group within the New Zealand Health Services Organization is based on HL7 messaging. I think we need to be clear here too that the focus of this particular panel, as important as these other points are, there's no question that we need to define vocabulary and data content standards and everything else, the focus of this particular panel at this point in time is messaging standards, because if we go beyond that, then we need to expand the scope of this discussion to specifically, HL7 position strategically on electronic health records and those type of issues, which may not be appropriate for this venue.
MR. BLAIR: Clem, are you finished?
DR. MC DONALD: I haven't finished my question. I don't know if the testifiers are finished with the answers.
MR. ADDY: Superior has experienced, the majority of the systems are at the health care facilities, hospitals, but we do practitioner offices, we have brought HL7 out to that level, and many other aspects. A lot of facilities, we have done external reference labs and interconnecting large groups and systems together, so in the facility but also practice offices, external labs and things like that.
MR. GARTON: Home health, physicians offices, ambulatory care, acute care.
MR. DICKINSON: We pretty well cover the gamut as well. Home care is probably the one area we haven't done any HL7 messaging in to my knowledge.
MR. BLAIR: Bill, would you like to go next? My question is real short and I'll wait until the end.
DR. YASNOFF: Yes, I would like to ask a question about business incentives. There hasn't been any mandate to adopt HL7 as yet, yet it sounds like, well we know that HL7 is extensively used throughout the industry, but yet it sounds like there's a significant lack of business incentives to move along the HL7 continuum or to change from where things are. So can the panelists comment briefly from their perspective as to what the business incentives were that drove the market to where it is now, which is at 2.1, 2.2, wherever it is, and why those same business incentives are not driving people to move forward to Version 3 or further along on the HL7 continuum.
MR. DICKINSON: Well you kind of dive in wherever you are. When a new system is acquired you look at whatever the current version of HL7 is and typically adopt that. You may adopt something earlier than that if that happens to be convenient for you, but you typically, that's the incentive.
Now once you have sunk that investment, you have very little incentive from that point forward to go to the next version of HL7, unless it has something, you know, so compelling for that particular interface instance, that you just have to have it.
DR. YASNOFF: So what you are saying is that when you are ready to build the interface, you say okay, well, I'm going to adopt whatever standard is out here. Obviously I would like to, if I'm going to build an interface, I'll use a standard. Once it is built, I don't want to touch it.
MR. DICKINSON: Essentially once you've got it working you want to leave it alone.
MR. MEYER: Actually there are two sides to that equation. We have found that where we have wanted to promote another version of the standard, that we run into the problem that is inherent in any interface, in that it is a bilateral function. We cannot unilaterally change the interface, and even though we may come along and promote that as a part of our next release and of value to the customer, there is another player. So it is really a love triangle that often goes awry here, and there's nothing we can do about it.
That is not to say that there is not a lot of importance given to the point that Gary made, that we've done that, we're moving on to something else. Where we see an installation that has multiple versions of the standard implemented, it is because they started out with an ADT interface and then they moved up and they added a radiology system and that jumped to 2.2 or 2.3, and then they put in another ECG or EKG, and the capabilities in the later versions were driving those niche products to support a higher standard, and we would interface to those.
But as is stated by my colleagues, the vast majority of interfaces currently employed are still in the 2.1, 2.2 range.
MR. ADDY: Yes, the main incentive for going to HL7 in the beginning was, as I said in my earlier presentation, was that the support maintenance costs, the knowledge base that was necessary to do proprietary point to points was just killing the industry, so the add of HL7 addressed those issues and brought them to something that was manageable. But again one you get into an interface up and running, there's no incentive to mess with it whatsoever, and especially when you look at the ADT point of view, because you are not talking to one Euria system to one system, you are talking to 20 or 30 different systems out there. So if you go changing that, look at the cause and effect ripples, the reintegration testing, everything that must go on, there is no incentive to bite that bullet.
The other issue is even if other vendors go to 2.4, if everybody else doesn't jump, then what you are going to do is because of the backwards compatibility, additional information that is in there is just going to get dropped. So again, unless you've got some really big value for moving up, it is not going to happen.
MR. MEYER: Or a mandate (laughter).
MR. GARTON: Yes again, what is the goal for updating interface. If there is not a significant goal, it is not worth the organization's time or money.
DR. COHN: Is it ready for, Michael? Why don't you ask your question, then Michael.
MR. BLAIR: This is just a real quick question. Chuck, your recommendation was that the committee consider a duel approach. Would you elaborate what you are thinking of when you say a duel approach in terms of our recommendations?
MR. MEYER: My actual recommendation in response to Kepa's question was that the designation of a standard be limited to the SDO level, not to a specific version or implementation of that. Now I know that goes contrary to a certain extent to what the Secretary believes is the directive, i.e. to very tightly focus. The rationale behind that was is that allowing or identifying an SDO, and let's say that it is HL7, allows us to continue those interfaces that are already implemented under HL7, particular those which were at the time ANSI accredited, may or may not be, but also allows us to move forward with new functionality, new products, that drive on the next generation of the standard.
So by designating the standards development organization versus the specific version of a standard, gives the industry much more flexibility to move forward.
DR. COHN: Michael?
DR. FITZMAURICE: Yes, I want to kind of summarize or recap what I have heard, and then think about the future. Kepa - saying I hear HL7, I think Simon say I hear a lot of different versions. So I take away from this that HL7 is probably the most advanced and most used for general purpose. Secondly I hear that we need a common medical vocabulary or at least a data dictionary to which we can all refer when we move data from one system to another, that that is a particular problem.
I'm thinking also well how then would we transfer images, or is that just another speciality to be added on to some master standards list such as HL7. How do we write prescriptions from the physician's desk to the pharmacy, whether it is a hospital pharmacy or a retail pharmacy, when we have NCPDP SCRIPT standard or maybe an SDO will invent a different one, perhaps with an HL7.
Basically how do we record and how do we transmit the electronic health record might be a larger question on this. I want to push it into the future by saying as we move from EDI to something else, such as sending information through the web, then it becomes less important to have slashes. It may be important to replace the slashes with XML tags or some other technology. But you can't get away from the vocabulary, you can't get away from the content.
So I'm thinking and I'm asking if you agree, that it would be helpful to have a push toward existing standards, a push towards a common medical vocabulary or a data dictionary, and a push not be bound by existing technology, but to look forward to higher level versions, such as Version 3, to pave the way for future ways of transmitting this information. Is that a realistic picture and a realistic set of take home points, or would you add to it. Let me start with Gary.
MR. DICKINSON: Well my concern about control of medical vocabulary occurring in standards, the standards as far as data interchange is concerned are occurring at the back end. So it is kind of like the tail wags the dog or tries to wag the dog in this case, where you are trying to define your standards at the back end and in fact all you clinical practice is happening at the front end. At the front end, if those standards are not visible at the front end, then it becomes a real major issue to be translating between this and that and you lose all kinds of fidelity in the process of that translation.
So while I think it is commendable that we are looking in that direction, I think it really has to be an issue of how do we practice medicine and in fact at the front end, at the clinical front end, and how do we insure that those vocabularies, however good they may be, are in fact used at that front end so we don't have to go through this frightening translation process at the back end where we lose fidelity and where we lose authentication, we lose, we put ourselves in a position to make the information capture reputable if we haven't kept the original, even though we may have translated it to something else, if we haven't kept the original so it is reproducible in the original form as the information finds its way from one system to another, then the author of that information can repudiate it as soon as it shows up in another system in a different form, even though it may have gone through a very clean translation.
So I think we have some major issues there that are not fully appreciated as we have this discussion.
DR. FITZMAURICE: Essentially you want it so that a doctor can say that only is what was recorded not what I said, it is not what I meant.
MR. DICKINSON: Exactly.
DR. COHN: Aaron?
MR. GARTON: I agree with your summary points. I don't have anything else to add.
DR. COHN: Brett?
MR. ADDY: I agree with the summary points. I guess what I am suggesting is that what we move forward in the future -
(End of side B of tape 1)
- and I tried to put together the best estimate of what the cost would be if you step in today and say we are going to do everything new right now. There's a tremendous overhead cost and hit to health care at this point in time, and given the hangover that we had from Y2K, are we willing to swallow that all over again.
DR. FITZMAURICE: I don't sense that the committee wants to do everything new. Chuck?
MR. MEYER: Michael I want to thank you for that excellent summation of the Version 3 scope and charter statement, because that is exactly where we've been driving in HL7 with Version 3. We surely recognize the importance of standard data types and in vocabularies, and are seeking methodologies for implementing that within the context of a diversity of implementation technology specification. So we have tried to stay as independent and clean as possible in Version 3.
There is no question that Gary has a very valid response. What you do in back end with the standards has to be compatible with the way medicine is actually being practiced, and I think we have tried to accommodate that. Because of all the standard development organizations, and I'm sure, I put my HL7 hat on for a minute, we have probably the most diverse membership, including a large number of clinicians representing practices and facilities. And they are so much focused on patient care and the impact of common vocabulary that sometimes it becomes our major topic.
DR. COHN: Back to you Jeff.
DR. MC DONALD: Well I wanted a clarification of Mike's - in that you said you were going to summarize and then in the summary you asked questions, which is not usually part of a summary, and then you said the standards in one phrase and then you said we will do this. So I'm not sure what the this is that you were really proposing, unless it is what Chuck just said. They were all talking, I didn't hear any of the testifiers talk about anything but HL7, and you said the standards, so I'm not sure what you were referring to.
DR. FITZMAURICE: That was my point is that there were other functions than just what we heard covered in HL7 today, transferring images, writing prescriptions outside of the hospital setting, and I didn't hear a comparison between the HL7 and the other standards in terms of getting the job done. What I was driving at was what should NCVHS do. Should NCVHS pick a standard, say choose your version, but be aware of new technology, should it do something more specific. Is it helpful to be very tight in our recommendation to the Secretary, so that if something actually concrete happens, or should we be fairly loose so that we don't disrupt the industry and cause them to freeze at a point in time when technology is flying down the road.
I don't know the answer to that, so I gave a summary but I also gave questions. I said I'm uncertain about these areas. We need more information. And we are going to get more information in the testimony so maybe that would also be a lead to the future testifiers.
DR. COHN: I want to thank these panelists. It was a wonderful panel. It is now 10:50, we'll break for 15 minutes and reconvene the second panel.
(Break)
MR. GUINAN: Jack Guinan and I'm representing ProxyMed, Incorporated.
MS. KENNEDY: I'm Rosemary Kennedy and I'm representing Siemens Medical Solutions.
DR. AITA: I'm Sami Aita representing Medcom Soft, Incorporated.
MR. BLAIR: Do any of you have a preference as to which of you would like to go first?
MR. GUINAN: Well I guess we'll start down at this end and I'll go first. Jack Guinan. Thank you for having me. I am Executive Vice President of the Prescription Services business unit of ProxyMed, Incorporated. I've served as an executive at ProxyMed for the past eight years and have been involved in the health care EDI industry for approximately 10 years. I am an active member in NCPDP. As such I will be addressing you all today on the use of the NCPDP Script standard as it relates to PMRI.
ProxyMed is one of the nation's largest health care EDI companies. We focus on providing EDI services to the physician community, the ambulatory physician community mostly. Our service encompasses all business and clinical transaction sets. We are currently the second largest medical claims clearinghouse and will process close to 100 million HCFA 1500 transactions in the next 12 months, primarlily HCFA 1500 claims.
Our medical claims business is over 10 years old. We are the largest provider of laboratory result distribution devices and services. We currently serve over 550 laboratories, providing connectivity services and devices, mostly the teleprinters that you see prevalent in the physician offices for getting the results to the physicians. These devices are in approximately 150,000 physician offices.
Pertaining more specifically to my testimony this morning, ProxyMed operates the oldest and largest physician to pharmacy network, that we call PreScribe.net. PreScribe.net has been providing EDI services to physicians and pharmacies for over seven years, currently has over 5,00 registered physicians, and has processed more than 10 million EDI e-prescription transactions.
In addition to operating an EDI network, ProxyMed also provides software applications to physicians and web based application services to facilitate e-prescribing and connectivity to pharmacies. We currently have over 1,600 physicians using one or more of our e-prescribing systems and are actively sending prescriptions as EDI transactions to pharmacies.
As a provider of a broad set of EDI transaction services, it is vital that we understand the implications of HIPAA across all of our transaction sets as soon as possible. So one of my points this morning is that we have a good understanding of how HIPAA affects our medical claims business, but are lacking guidance at all really as to how this will apply to our lab and pharmacy EDI businesses. We know that we will spend a large amount of money and resources in complying with this over the next few years, but it is very important that we can establish one set of operating policies and procedures as an EDI service provider across our company, that can be applied to all of our transaction sets. Having different regulations across the transaction sets will result in a much higher implementation ongoing cost for companies like ProxyMed.
In addition, being specifically covered as a provider for some of our transaction sets under the regulations or being considered a business associate for other transactions will result in a lot of confusion in our own company as well as with our business partners, and certainly will cost us much more money in implementing and in our ongoing compliance efforts with the regulations.
To us the different treatment will not make logical sense as the basic content of the transactions are equivalent in terms of need for privacy, confidentiality, and security. To this end I am recommending today that the physician to pharmacy e-prescribing transaction set become specifically addressed, covered by the HIPAA or any other regulations that you set forth, and that the NCPDP Script standard, as I'll discuss, should be adopted as the official transaction standard for this narrow transaction set.
The NCPDP Script standard has been in use and was adopted by ProxyMed as our primary transaction standard for PreScribe.net even before the final ratification of the standard by NCPDP. We were actively involved in initial formation. There was a bit of positioning between two different organizations, ASAP ad well as NCPDP. There was the med free standard being discussed at the time that Script was being formed. We were proponents of the Script standard and that did become then the accepted standard from NCPDP.
We participated actively in the NCPDP Script work groups from the beginning and we continue to play an active role, and we are satisfied that the NCPDP Script standard, now this goes to I would say Versions 1.5 and later to answer in advance on the questions I heard in the previous conversation. There are a few other versions, we are already up to Version 4.2. That's up for vote to be ratified, but we've implemented from 1.0 up through 1.5. We are satisfied that the current, the 1.5, meets our requirements and that the organization and the process that it has will be able to meet our needs going forward.
The modifications to the Script standard being currently discussed for ratification of Version 4.2 will not be costly for ProxyMed to implement and we do have plans to be a proponent of pushing forward with Version 4.2 and those in the future.
Operating in our capacity as a network service provider, ProxyMed has used the Script standard to implement physician to pharmacy connectivity for a broad and diverse set of trading partners. They include seven physician office software vendors, three EDI networks, two major retain pharmacy chains, the three largest pharmacy software vendors, one of the nation's largest Pharmacy Benefit Managers, and a large Health System with their own in-house electronic medical records system.
These organizations represent the vast majority of companies that are participating today in physician to pharmacy connectivity on an EDI basis. The interfaces I just mention use a variety of the versions, from Script standards from 1.0 through 1.5. The most prevalent version as I just said is the Version 1.5. I do believe that it would benefit the industry, now particularly I am speaking of the pharmacy industry here as it relates to physician to pharmacy connectivity, that we do push for a more current version of the standards be mandated, for example or higher.
This would force the companies that are already participating to do the housekeeping necessary on their systems to become compliant. At the moment although we have implemented a large number of these interfaces and they are all working well, we are starting to see interoperability issues as the number of companies grow that are using this type of interface. It is not as much a matter of the actual format of the message as it is that these companies have implemented the interfaces over a range of time, going back from seven years ago to now. There has been no financial incentives for these companies to update the interfaces so they have not. Companies that implemented Version 1.0 are still on 1.0.
But to really advance this valuable service of getting physicians connected to pharmacies, it would be a big help for a little push from the government to, I would say mandate the use of a more current standard. This will not be that costly to move between the various versions of NCPDP Script as they have been laid out. So we are proponents of moving ahead with a more current standard.
To address the pricing issue that was requested, I can tell you that ProxyMed has developed standard pricing for assisting organizations in developing a Script standard. They range in the approximately $25,000 for a standard interface to Prescribe.net. So for a physician office software company or another EDI network that would like us to develop an interface using the Script standard to our network, the approximately cost is around $25,000 for a standard interface. Then we charge ongoing fees to these vendors on a negotiated basis.
We have developed and distributed various developer tool kits based on the Script standard. These include advance implementation guides, software programming objects, in some cases complete communications applications. With the Script standard and these tools, we have had various organizations implement the Script standard in as little as 60 days. No special skill sets required. NCPDP we feel has done a good job in sticking with the rest of the standards and work very closely as we heard before with HL7 and the other groups.
And it has become much more common for ProxyMed to implement the network interfaces using XML as implementation of the Script EDI standard. We have implemented the Script standard using XML with two training partners. We have built XML based tools as part of the tool kits I just mentioned, and as a general rule, we do prefer and hold out as our method of choice for new partners to use XML as a representation for the Script standard. There's been lively conversations at NCPDP regarding this. There's been no decision reached. ProxyMed as an organization is very comfortable with using XML as a representation of the standard.
The areas of the Script standard that require I would say assistance by the national government are about the vocabulary that other folks have talked about. I'll call them code sets for the purpose of my discussion. There is a complete lack of national standards for unique identifiers at the heart of Script. These include unique IDs for physicians, physician office locations, patients and drugs. The routing of Script messages, physician to pharmacy messages, is based on IDs for physicians and their physician offices, yet there is no unique ID for either of these entities. This results in a proliferation of proprietary ID schemes and interoperability issues.
The physician ID issue extends to ProxyMed's other EDI transaction sets, including especially lab related transactions, getting the result reports from the labs back to the ambulatory physician setting. At the heart of an EDI business a clearinghouse is routing, and without unique IDs and the ability to match an ID to a destination source, this becomes very difficult.
The lack of a standard patient identifier results in substantial problems in transferring medical record information. There is the obvious problem of knowing which patient's records should be updated with the transmitted transaction data. Mistakes made in merging patient data from transactions can have severe consequences to the patient if the data from a transaction are applied to the wrong patient's record. This really is the single largest problem in providing good data to some of the folks that testified a little earlier today.
If a retail pharmacy wants to send a medication history or if a pharmacy benefit manager wants to send a patient's medication history to an electronic medical record system, there is not a good identifier for the patient to know that it belongs to that patient, there is not a good identifier to know that it is being sent to the correct physician's office to be routed.
This is probably the biggest impediment that we have in implementing this type of transaction today. Although there is a widely used identifier for the purchasing and inventorying of drugs in the pharmacy industry, the NDC code, this code is unique at a different level than that used to prescribe drugs by physicians. For a pharmacy to inventory and dispense a certain drug, they identify it at a manufacturer, product and purchased package size level. Physicians on the other hand are not concerned with manufacturer or purchased package size, but rather just with the product designation.
There could be hundreds of NDC codes which represent a particular generic drug that is manufactured by multiple companies, and a pharmacy system might have any number of these codes in its database. A physician however will just have one record for that product. If NDC is used the code, the chance that the physician system will pick an NDC code that is in the pharmacy system sometimes is not that likely, and the chance that it is the same NDC is highly unlikely. This results in sometimes the improper designation of a drug in the record.
The lack of proper identifiers has resulted mostly in a lack of functionality in the physician and pharmacy systems, primarily on the physician side. We have had to dummy down the applications that we provide to the physician offices, as well as when we work with software vendors to implement these types of connections, we usually have to pass along the message that unfortunately you can't provide advance drug interaction checking on messages that come from retail pharmacies, because we can't provide enough data in the message that will allow you to perform this function.
So the level of systems in physician offices today I would say are not that smart. This is one of the impediments for physicians to adopt these systems. Physicians don't want to use them unless they have the higher functionality. We need to really advance the content of the messages that are going between physicians and pharmacies if we want physicians to adopt these systems. And there is a lot of value in them adopting these systems. That has been proven.
Another area of the Script standard that could be improved is that there is too much latitude in the use of optional data elements. This is always a big discussion at the work group meetings, although the general rationale behind each and every one of the decisions to make the data element optional is logical and on its own probably the correct decision. The result is the possibility of interoperability issues. These happen every day in the business. We suggest that the any mandated standard tighten up the use of optional and mandatory fields.
In summary, the transactions associated with physician to pharmacy transmission of medical record information should be directly addressed by HIPAA, this organization, any other regulations, and companies providing network services related to these transactions should be able to treat them the same as other covered financial and administrative transactions already regulated by HIPAA. The NCPDP Script standard is a well-established standard that fits the needs of all the participants from our viewpoint, in the exchange of information and the NCPDP organization has policies and processes in place to insure this continues.
However, the single largest problem, as I just mentioned, in implementing this standard comes from the lack of nationally recognized unique IDs for physicians, patients and drugs. Thank you.
MR. BLAIR: Rosemary Kennedy.
MS. KENNEDY: Mr. Chairman and members of the committee, I am Rosemary Kennedy, a registered nurse at Siemens, with a Masters in Business Administration. My experience spans clinical practice in various settings, health care administration, and information technology. I have been actively involved in the vocabulary front, integrating nursing terminology and vocabulary into more global effort around terminology to reach conversion.
The Medical Group of Siemens is the most diversified supplier of medical electronics-based products and information.
DR. COHN: Rosemary, could you get a little closer to the microphone?
MS. KENNEDY: The Medical Group of Siemens is the most diversified supplier of medical electronics-based products and information technology systems to the health care industry. The clinical specialties served by Siemens include diagnostic imaging, oncology care, critical care, respiratory care, audiology, Picture Archiving and Communication Systems, and health care information systems. Worldwide the Medical Group has $5 billion in revenues, with almost 1.5 billion of that in the United States, making it the most important country for Siemens Medical.
On behalf of Seimens, I want to thank you for this opportunity to testify before you today on the very important subject of patient medical record information messaging standards. During my testimony I will share with you three things. Seimens' commitment to industry standard message format, some of our experience with the standards under evaluation, and I'll identify what standards I will be talking to, and our recommendations for improving existing standards and their use and the role that the government can play in helping us move forward as a nation.
Siemens is firmly committed to the development of industry standard message formats and vocabulary, and to incorporating them into its entire line of integrated solutions to the health care industry. We play proactive roles in various - committees and standard setting organizations. We did originally as SMS, which some of you may know us as, and now with the addition of Siemen that has tripled the involvement we have on the national front and international front in setting standards.
HL7 and DICOM organizations are the leading standard setting bodies in health care information systems. HL7 and DICOM are clearly the dominant standards for the exchange, management and integration of structured clinical data with images across all health care settings. Therefore the rest of my talk and testimony will be addressing HL7 and DICOM.
The HL7 and DICOM message format standards listed by the National Committee for Vital and Health Statistics do address our highest priorities for exchanging patient medical record information electronically. But to be comprehensive, they must be supplemented with person identification, security and vocabulary standards. HL7 Version 2., encompassing Versions 2.2 through 2.4, is used by Siemens for the bulk of our structured clinical data exchange. DICOM Version 3 is used by Siemens for multimedia interfaces. HL7 and DICOM are the only logical choices for clinical interfacing.
For HL7, several characteristics are important. HL7 is the message format of choice in the United States and many other countries. HL7 has become the widely adopted standard for the exchange of clinical data, and is an approved American National Standards Institute standard. HL7 has proven it is flexible enough to accommodate the data diversity that exist in the health care community going across all case settings. Many government organizations are moving towards embracing HL7, including the Centers for Disease Control and the Centers for Medicare and Medicaid Services. Currently HL7 has 14 international affiliates and is submitting HL7 2.4 to ISO for approval.
For DICOM, most of the points made for HL7 also apply. The DICOM standard has been adopted by virtually all suppliers of imaging products. The standard has evolved to provide a comprehensive set of services to fully support the work flow in radiology. It is international in scope, involving more than 50 industry vendors, and it has a strong market visibility.
From a Siemens perspective, we have been using HL7 for many years, during which it has evolved substantially. We have been using HL7 for communication within our applications as well as the - Siemens systems and other systems going across various health care setting. Our customers have implemented thousands of interfaces using the HL7 standard supported in our integration engine. It is almost impossible now that we are combined with Siemens to give you a specific number on the interfaces as our customers use the engine to interface with their systems as well as with other systems.
Without some standard to fall back on, the cost of developing these interfaces would have been considerably higher. We have done no controlled studies to quantify these cost savings as I know you were interested in getting that information, but without a standard each interface would be considered unique, with each requiring significant analysis and implementation costs. The bulk of the effort goes into defining the data content and the requisite mappings to other systems' data requirements. The bulk of the costs are incurred developing interfaces that map to and from non-standard vocabularies.
With DICOM over the years, greater stringency and conformance requirements built into the standard have streamlined the implementations somewhat. Complexities still arise when dealing with old machines and old DICOM versions, which is the same with HL7.
It is universally agreed that HL7 2 falls short of achieving so-called "plug and play." There are a number of reasons for this, some of which you heard from the first panel. The lack of a common vocabulary pertaining to data elements defined within medical and non-medical coding systems is a huge problem. The fact that elements of the standard are subject to broad and non-standard usage that often conflicts with the data element's name. An overuse of the optional attribute for HL7 data elements, and relatively little conformance testing of message format standards, although some of those issues are being addressed with Version 2.4, and will be addressed further.
Health care providers who purchase products designed to interface in accordance with HL7, Version 2.x find that the products cannot work together with site specific negotiations, which increase the implementation time and the cost. DICOM is confronted with similar problems but to a lesser degree since the introduced the concept of conformance to overcome of the different interpretations, which has helped somewhat.
Both HL7 and DICOM are working towards improving interoperability. The relatively new joint group HL7/DICOM Working Group 20 has set as its as its main goal the harmonization of the two standards, thus bringing information and imaging systems closer together, which is a goal we all have.
HL7 Version 3 promises to enable interfaces that come much closer to delivering "plug and Play" compatibility "out of the box." Version 3 messages are being derived from formal, rigorous message models under development within the HL7 technical committees. These models greatly reduce the need to declare optional data elements because they capitalize on the significant effort expended to fully understand and describe the health care process through object-oriented design. We are looking HL7 domain model, looking at it in terms of data base structures, applications and terminology, so we can ultimately move to that goal. Together with the contributions of the HL7 Vocabulary Technical Committee, Version 3 will begin to directly address the three major deficiencies identified in my discussion of Version 2.
In general the HL7 and DICOM standards should have the highest priority. There is little time and money to deal with other standards from a practical pragmatic perspective. Our industry needs to concentrate on migrating from HL7 Version 2 to the new HL7 Version 3, which in itself will require a significant effort and there are some cost barriers to that. In addition the critical domain must follow the financial X12 lead and establish clear and specific message guidelines for data definition -.
The Federal government can have a significant impact in standardization by taking several actions. There are quite a few that we have outlined in the paper and I'll bring forward to the table here for discussion. Limit significantly the number of standards organizations that operate in the health care space. Encourage HL7 and DICOM to continue working more closely together. Provide leadership by adopting one or more non-overlapping clinical vocabulary standards. Provide leadership in the development of reference terminologies at the integration point. Place the adopted standard in the public domain, going through a standards development organization process.
In summary, we believe that the Federal government can best help by providing much-needed financial incentives to increase participation by the private sector in the development and implementation of appropriate standards, by participating itself in these standard setting efforts, and by using these standards within the government, and by endorsing medical terminology standards once they are proven and integrated into a consistent and systemic terminology model, and to take an active role in that effort and to use those terminologies within their systems as well.
Changes will not occur unless there are clear financial and regulatory incentives to invest in change. HIPAA and some other future legislation and regulation must ultimately require that standards, once defined and adopted, are fully integrated into the health care system if we are going to improve the overall health of populations.
Mr. Chairman and members of the committee, it has been an honor and a pleasure to deliver this testimony to you. Thank you very much for your time.
DR. COHN: Thank you Rosemary. Our next testifier?
DR. AITA: Honorable Chair and distinguished members of the committee, I would like to thank you for having me here to testify on behalf of Medcom Soft, a relatively newcomer that does not have to deal too much with installed base, but it is a company that originated in Canada and now is operating in the United States and Australia.
Medcom Soft has recently introduced a totally new generation of electronic patients record systems and is pioneering the use of intelligent data entry systems and the internet to improve the collection and dissemination of health care information, to simplify work flows, improve the delivery and quality of patient care, and decrease costs throughout the health care industry. The Medcom Soft platform was developed to facilitate the business transaction and the exchange of information between all entities involved in the health care industry, which includes providers, suppliers, insurers, payers and regulators, and of course, patients. Medcom Soft systems support the capture, aggregation and secure communication of structured and codified electronic patient records.
Medcom Soft recognizes the imperative of the PMRI initiative to determine comprehensive standards. We have taken steps through the implementation of our system to analyze industry-recognized standrds for clinical data capture, drug and lab codes, as well as data transmission and message formats. The task of researching and implementing compatible standards requires enormous resources from any business, and as CEO of Medcom Soft, and as a licensed physician, I am grateful to participate in helping NCVHS take the lead on this issue. The health care industry is seeking guidance, and these discussions are a very important component.
In order to capture the clinical data Medcom Soft adopted the highly structured Medcin Nomenclature. We believe it facilitates the appropriate degree of granular detail required for medical documentation standards in a codified format at the point of care. For data transmission and messaging Medcom Soft adopted and implemented within its data engine the ANSI X12 for claims data transmissions, and HL7 standard for other patient related medical transactions.
I appreciate the opportunity to provide comments, and present to you Medcom Soft's experience in implementing some of the standards being considered today.
I will speak first about HL7. Medcom Soft data engine supports HL7 standards Version 2.1 and 2.3 with all transaction sets. We are currently in the process of implementing HL7 Version 3.
HL7's earlier versions used informal and ad hoc development methods and lacked "plug and play" functionality. During the development of Version 3.0 these were replaced with more formal development methods used in object oriented analysis and design techniques. The use of the Message Development Format and the Reference Information Model provides an advanced and comprehensive Object Oriented information model for clinical health care. The increased specificity of the RIM in Version 3.0 will enable greater interoperability between health care information systems.
However, even with the support of XML in HL7 Version 3.0 the problem of semantics in health care is not resolved without significant effort. XML is rapidly becoming the data portability standard enabling the exchange of information between many systems. In my opinion it will require several years of hard work to build a semantic foundation for health care interoperability which positions HL 7 Version 3.0 to take advantage of XML.
The HL 7 messaging format has become the industry's de factor standard for communicating patient related clinical information. By electing to use the HL7 format, the Medcom Soft system can communicate with the majority of third party vendors with systems similar to ours, as well as other health care participants. The initial implementation was completed within 12 months. The support for higher versions of the standard, as they became available, was completed in two weeks.
We anticipate the implementation of Version 3 will require a minimum of 18 months due to the newly introduced record structure and the use of XML. Medcom Soft decided to implement Version 3 because it matches our system's future architecture and flexibility.
The costs incurred during the development of the standard breakdown to 20 person days for education, three person years for the interface engine, 10 person days per year for the custom coding, 20 person days per message set, and 10 person days per year for maintenance.
We view as advantages of HL7 the simple protocol to implement and understand, the complete set of messages for application integration, and the wide industry support of messages.
However we recognize certain weaknesses of the HL7 standard. The organization does not provide a mechanism for testing. This creates the need to have an actual vendor on the receiving end of the message to check the validity of the transmission. In order to complete any pretesting, the vendor is forced to simulate a second system, which would be sending and receiving message to and from the data engine. The openness of user defined segments can lead to much vendor customization. This openness prohibits the integration of systems in a timely and low-cost manner.
Lack of implementation guides leaves too much room for vendors to develop their own implementation guides that may contradict or avoid requirements that are very specifically defined in the standard. Our experience is that when integrating applications to HL7 interfaces, the two systems never communicate perfectly without some customization.
The more information that is exchanged between systems, the higher the likelihood that the interfaces will not work properly. As these HL7 interfaces increase in their sophistication, the requirement for customization also increases, slowing down implementation times and increasing integration costs. The lack of a certification body that provides conformance testing to the standard. Compliance must cover communication processes as well as data types. There is a lack of standard codes to insure the format and content of the transmitted message is comparable and consistent when shared among different systems. While many industry codes have been established within HL7, there is still room to add more. The more data values that are standardized, the more easily data can be exchanged by systems.
Our recommendation are that the committee should support the appointment of an organization that will facilitate the testing and provide the proper mechanics for vendor compliance and certification. There should be a very specific but standard implementation guide that is employed by all vendors for each kind of PMRI message. The organization should provide a means for testing the implementation of each transaction set that the standard supports. And example of this would be a web site for vendors to send messages to and receive validation of the message format.
Create the mechanics for certification. Certification should be issued to the vendors based on the level of conformance to assure that a standard has been implemented according to its implementation guidelines, and that it performs its functions as needed.
Create one standard format that includes both health care terminology standards and message format standards. Standardizing the content of the message facilities interoperability between systems. Message formats should establish minimum and maximum data elements to promote better integration. With this benchmark in place and accessible to vendors, interface development will have a common reference point for all vendors.
In conclusion, Medcom Soft recommends that HL7 remains the preferred messaging standard. We believe that significant improvements can be made including the addition of medical terminology and will encourage its universal acceptance by vendors. However, because HL7 does not include a broadly accepted scripting standard, the use of an additional standard such as NCPDP messaging standard becomes necessary.
And therefore, the standard that NCPDP is most famous for is Telecommunication Standard Version 5 Release 1, which has already been named in HIPAA's final rule. This standard deals primarily with direct electronic submission and adjudication of transactions in an online, real-time environment and has huge implications for pharmacies. However, the NCPDPD Script standard, which was developed for the purpose of transmitting prescription information electronically between prescribers and pharmacists, seems the most relevant NCPDP standard for the purposes of Medcom Soft. It adheres to UN/EDIFACT syntax and utilizes standard EDIFACT and ASC X12 data tables where possible.
Currently the standard addresses the electronic transmission of new prescriptions, prescription refill requests, prescription fill status notifications, and cancellation notification. Future enhancements, as listed the NCPDP, may include patient status requests, lab values, diagnosis, disease management protocols, patient drug therapy profiles, DUR alerts, prescription transfers, and formulary recommendations.
The NCPDP version 5.0 standard is very comprehensive and included many extensions covering information such as controlled substances, eligibility, and drug utilization. Previous experience with the conversion of claims adjudication software to incorporate NCPDP 5.0 standard format versus NCPDP 3A standard format required 3,857 hours of development time at an internal cost of $212,570. These did not include all the new NCPDP 5.0 formats, but just those related to claims processing.
It is very apparent under this effort that, for example, NCPDP 5.0 had many data items which duplicate those data items found in the HL7 standard format, particularly as it relates to patient information. These duplicate items are slightly different in each standard. At this time NCPDP 5.0 comprised several hundred data items of that fashion.
The committee should seek to reduce duplication among standards. An effort should be made to eliminate duplication in NCPDP of any HL7 standard, but still provide NCPDP as an extension to already existing HL7 data standards.
In the end I would like to stress again the need of creating a medical vocabulary standard that could help providers at the point of care adopt electronic medical records and will pave the way for better transmission of data between the different players in the health care.
On behalf of Medcom Soft and Medical Record Solutions, we thank you for the opportunity to work with you on this much needed and important initiative.
DR. COHN: I want to thank the panelists for that wonderful testimony. Questions from the committee? Kepa?
DR. ZUBELDIA: I have a question for Bill, Jack and Sami. You are talking about a recipe to - and I think that Jack you mentioned that the NCPDP Script should be, is one of the administrative transactions rather than a clinical transaction. I would like to hear feedback specifically on that. Should it be considered part of PMRI or should it be an administrative transaction?
MR. GUINAN: Well the problem we are facing as the business of being a clearinghouse that handles both financial and clinical transactions is that if they are handled differently in the sense of what we have to do to comply with the regulations, we'll have to have basically two different companies inside of our organization, two sets of costs. So I don't know if they should be termed as administrative transactions.
My point is that we should not be classified as a business associate for some, as a covered provider for others, and that the amount of security, the policies we have to have in place, should be the same. So I don't know if necessarily they have to be termed as clinical or financial, but rather the policies imposed on us and our compliance effort should be the same across the two of them, however that gets worked out. I know it will be a challenge. Does that answer your question?
DR. AITA: I believe they could be included as part of the clinical set, not only as the management set, but part of the clinical set, because of some of the extensions and the way they handle the prescriptions. It could be essential for the exchange of that information.
DR. ZUBELDIA: Let me clarify my question a little bit better. - sections have very specific implementation guides. The - sections have excruciatingly detailed implementation guides. The SEBP implementation guide is very detailed and we're looking from the testimony today that maybe the clinical section should not have that kind of detailed implementation guides. Where does the Script fit? Does the Script fit into a very detailed implementation guide type of transaction, much like the NCPDP - or does it fit more into a loose type of transaction more like the clinical type?
MR. GUINAN: I think then that it should be covered more like the administrative transactions, that we should try to nail done as many of the different aspects of the standard as possible and it should not be considered a loose clinical transaction. The largest problem we are having in implementing the standard today is the wiggle room in the standard, and even with the small number of organizations participating, we are starting to see interoperability issues, especially between pharmacy benefit managers and retail pharmacies that have different business goals in implementing the standard and they are pushing this apart. So the more stringent the implementation guide I think the better that it will be applied to the health care industry and we get more value out of the transaction.
DR. COHN: Any more questions? Clem?
DR. MC DONALD: The question of the implementation, I don't think it is fair to characterize the clinical ones as necessarily loose and sloppy or something like that, and the other ones are more defined. I think the challenge is, in the clinical areas, is that you have areas that on the starting end that cannot be confined as well as if it is just a machine to machine. You are talking a physician, and I think you mentioned some of the biggest problems you are having trying to represent a prescription as an NDC number. It won't work. I mean I could tell you that a year ago, any physician can tell you that. And so that is another vocabulary problem.
We don't really have, I mean HL7 I think is working on one and FDA may actually come up with what might be described at the clinical level granularity, so people would really know what we are talking about. But the more broadly we cover these things, even when you get into more different business cases, the tougher it gets, and being very strict off means they both break, and it is hard sometimes to figure out how to do it so that they both will work for you.
So I just wanted to make that point without characterizing it quite that way. Everyone would like it as specific as possible, but what is feasible in the real life.
DR. COHN: Any questions?
DR. MC DONALD: Well actually I had a question about, I was wondering how medicom is going to deal with a lab standard, well actually two questions about the lab standards. You mentioned you are doing lab transactions.
MR. GUINAN: That's correct.
DR. MC DONALD: Are you using NCPDP for that?
MR. GUINAN: No we are not. We are primarily using various versions of HL7 2.x.
DR. MC DONALD: And then you mentioned that NCPDP is going to, may be a proposed lab standard. I didn't understand that.
DR. AITA: No, they have a lab standard, we are using for the lab standard HL7 for the lab for the time being.
MR. COHN: Michael?
DR. FITZMAURICE: I want to also compliment the testifiers, not only the first panel but this panel, on the very high level of their testimony, very good quality. And the push to learn more about the standards problem, Jack Guinan described the drug coding problem, the classification for NDCs, but I'm not sure what the solution is. You didn't propose a solution to that one. Is it having a better classification system built on top of the NDC codes? Is it having a different coding system? Any suggestion?
MR. GUINAN: From a practical standpoint, it would probably be a solution layered on top of the NDC code set. I think that the cost would be enormous if we were to depart and start over, you know, to over here from the NDC code. So to try to devise a scheme that is at a different granular level than the NDC, you know, 11 code, and then probably, as was suggested, maybe use the HL7 standards body to carry forth some of this vocabulary issue. NCPDP has done a good job of adopting the other X17 code sets, and so I don't think there should be two separate efforts though. If HL7 embarks on a vocabulary issue and NCPDP embarks on this narrow one about the, just the drug code set, well again we'll probably end up with two. So whichever one of the two organizations is responsible, probably should just be one, and then the other adopt that code.
DR. FITZMAURICE: I wanted to follow up on another question, excuse me, go ahead doctor.
DR. AITA: I think it is a bit broader when you look at the granularity of the code to adopt, specifically when we want to do a specific action, like drug interaction. We view drug interaction in the industry as drug to drug, but actually it extends to drug to condition, drug to applications, drug to pregnancy, and all of a sudden you start needing clinical information that is structured to perform that task. So any standards which you would have that hook with these extensions that are coming from a pure clinical condition that has to provide the data to do the transaction.
DR. FITZMAURICE: Are you saying not only tie it to maybe its chemical composition, but tie it to the functionality of it, that is group all beta blockers together?
DR. AITA: Absolutely. And that's why we, we have done a very interesting model in the past year. We mapped the FDB database to the Medcin database, and therefore we can now have a total inter-organization between the two in doing drug interaction to conditions, lactation and pregnancies, without being confined to the structure of FDB, using all the extension of Medcin that classifies the drugs as you said, in some logical clinical way.
DR. FITZMAURICE: The follow up question I wanted to ask Jack Guinan was you mentioned that there is too much latitude in the use of optional data elements. I know that NCPDP is working on trying to get rid of or eliminate the optional elements and have just the situational or the necessary, the non-optional elements. Is that coming along? Would that take care of this problem, or would it not?
MR. GUINAN: I think yes, it is coming along, but some of the more lively discussions in the work group meetings revolve around this issue. So I think a little push from the outside, whether it be from this organization, usually from the National Government, helps move things along. So without a business reason to resolve this inside the organization, I think it will take some outside force to move it along a little bit quicker. I don't see it being resolved in the next, you know, year or so.
DR. FITZMAURICE: Even if they then run into problems with the HIPAA transactions and codes and the privacy rule? That's not enough of a spur to get them to resolve it do you think?
MR. GUINAN: Well I think, well we are waiting for some more guidance (laughter) actually on how that applies to the transactions.
DR. FITZMAURICE: A point well taken. Can I ask one more question? I want to ask it of Rosemary. You mention in your testimony about evaluating more current versions of the standards you are using. That was our question. You said that Version 3 messages are being derived from formal rigorous message models under HL7, and that there are advantages to those models. If you were to go to implement a Version 3 model, would you be more inclined to do it with an existing installation that you have, or would it be more likely to be a brand new installation where you can start closer to scratch, or am I being too naive in that there is no starting from scratch anywhere, somebody already has something embedded.
MS. KENNEDY: I think it may be both, because there's, and you would be naive to be starting from scratch, because most facilities have something up and running and they are interfacing lab data and other information at a minimum. And so I think given the number of organizations that do have interfaces up and running, we need to take the approach of working with existing organizations and trying to integrate that model in, and it is going to take significant effort, if you look at the RIM, in terms of the changes that may need to occur at the database level or the application level and the messaging level.
But I think we need to look at facilities that have interfaces up and running already. It would be great to start from the bottom up with a brand new system and facility that may not have any interfaces up and running.
DR. FITZMAURICE: Does that imply that there may be a business need then for another interface. You have, let's say, an HL7 interface and then you have a Version 3 interface put on that that would convert things let's say to XML. Does that sound like the automatic, more automatic way of doing it, or is it scrap the existing interface and go just from the output of some other vendor system into Version 3?
MS. KENNEDY: It seems as if we could have a layer above that would be migration. To scrap the existing and just do more or less a conversion overnight initially I think would be potentially difficult, although maybe it could be done incrementally, incorporating certain components of HL7 3.
DR. MC DONALD: May I comment on that? There's two things, is that XML comes out of Version 3, so you don't have to do another step to get XML. But I think most people are assuming, the messages that are just now being balloted for Version 3, they really are quite, they correspond pretty well with the current Version 2 messages, even though there is not any obligatory backward compatibility, and most people are assuming that interface engines will make those transitions.
MS. KENNEDY: One of the challenges is the business case, and I know that was brought up earlier this morning, that as a vendor we are typically challenged trying to create the business case for our end users in the facilities that we go into, that unless there is a system or a vendor that drives some of it, there's no intrinsic benefit or business value they see moving towards a newer version.
We have begun to educate them on 3 and the advantages of HL7 Version 3, but we think in light of declining revenues and reimbursements, that we are going to be really challenged with that in the future, and that maybe if the government takes a leadership role in kind of driving and moving that forward, then until we do that we are really going to be challenged with capturing information, the point of care and communicating that information, both within facilities and across the nation, in order to identify outcomes. And that is the biggest business driver we bring to facilities in light of patient safety to get them to move forward with those kinds of models, but it is always a challenge.
DR. COHN: Jeff?
MR. BLAIR: I have one question for Sami, and then also one for Rosemary Kennedy. DR. Aita, you indicated that Medcom Software is already making the investment to develop your systems using Version 3, even though Version 3 is at an early stage where the balloting is just proceeding, and you encouraged us to consider the funding for implementation guides, which was one of the recommendations you probably, I don't know whether you saw that in our document from a year ago.
What was not clear to me when you were making that recommendation to us was whether you were saying we should recommend that HHS fund the implementation guides for Version 3 or for Version 2.x or for both. Could you clarify that for us please?
DR. AITA: It is a difficult question to answer because I heard the industry and the reaction of the industry this morning. We at Medcom Soft, we had to adopt the versions that are the widely used. We implemented the versions that are widely used because after all we have to interface with some institutions that don't have any other capacity than that. Any institution that has a prior version, an older version, is going to have limited, the amount of data that it could exchange, because what Version 3.0 is going to provide us is that extension to the possibilities.
So we will have to be somehow backwards compatible to a certain extent, so we have to support previous versions. But we definitely would like to see a major push for the Version 3.0 because there is a lot of advantage of adopting the Version 3.0.
MR. BLAIR: I'm still, help me again. Are you recommending that our recommendations, to support implementation guides to Version 3 or Version 2 or both?
DR. AITA: Version 3. Our recommendation is really to support the implementation of Version 3.
MR. BLAIR: Okay, thank you. Rosemary Kennedy. Let me see if I heard correctly on your recommendations to see if they converge closely with the summary that Dr. Michael Fitzmaurice gave us at the end of the first panel. If I heard you correctly you were winding up saying there were three major areas that we should focus on in terms of improvements in PMRI standards.
You mentioned the data security area, which Gary Dickinson had referenced in the previous panel. You mentioned greater interoperability and you mentioned better data definitions and terminologies. Is that correct?
MS. KENNEDY: Yes.
MR. BLAIR: Those were the three?
MS. KENNEDY: Those were the three areas, yes, that is correct.
MR. BLAIR: Okay, then may I ask, to just check back with Michael. Michael were those the three that you had summarized as well, or did I not hear that correctly or not remember it correctly?
DR. FITZMAURICE: I didn't get down into the level of data security, but I did hear the vocabularies, and all of this contributes toward interoperability. So I may not have stated it as eloquently as you did and as Rosemary did in her testimony.
DR. BLAIR: I was trying to find if we had conversions. I think we do.
MS. KENNEDY: I think we do Jeff. I think you may have taken one, there were four, and I think you have combined two of them into one, but we are covering all those areas, security, messaging, and the terminology and the standardized codes around that.
MR. BLAIR: Okay, then let me just ask you one other piece here, and I'm kind of going to make an observation in terms of what I think I am hearing, and please tell me whether you think this is on target based on what SMS feels and Medcom Software feels and ProxyMed feels, or whether this is off target.
I think I am hearing everybody indicating that HL7, and I'm getting to HL7 in particular, HL7 Version 2.x is the de facto standard, and furthermore, that any variation from HL7 Version 2.x has to be justified by business case issues, and right now until Version 3 is further along, the business case issues are not a driving factor quite at this time, and that you also wind up having interoperability issues where you can't do that alone without other business partners willing to also work on a new version.
So that you seem to be saying that you are hoping that any recommendations that we make recognize that HL7 Version 2.x is the de facto standard and that we don't do anything to threaten that in terms of the investment that vendors have made and users have made. However, if I am hearing correctly from Dr. Aita and from you Rosemary and from Chuck Meyer, that in addition, Chuck referred to it as his two-track or dual strategy, that in addition to recognizing Version 2.x as the de facto standard, that we might also consider some incentives to either accelerate or strengthen the development of Version 3.
Please tell me whether I am hearing all of your testimony and your thoughts correctly?
DR. AITA: Yes, absolutely correct, because I want to stress on one point. The quantum leap that we are all seeing, the electronics patient record, is really when we are going to start seeing on the market an adoption of a medical vocabulary. The problem of non-adoption of electronic medical records up to today was the fact that all existing medical records produced text at the end which could not be easily aggregated, could not be analyzed, and could not really leave to the use of the computer.
So once we are going to see in the market in the next few years, now with the arrival of the new system that will have codified and structured clinical data, we will see a quantum leap in the adoption, and the adoption of these vocabulary will put us - as the demand more for the Version 3. Today Version 2, we don't believe that Version 2 will serve the purpose of extending the functionality there is in the market today through Version 2 to a very rich set of contents that future electronic medical records would want to see exchanged between the participants.
MS. KENNEDY: I would agree, and there are two other points that I would like to bring to the panel for consideration. As we see in various and customers implement the computerized patient record, I think it started out merely as a way to gather data, just data elements to put in a record from a documentation perspective, and we are seeing two driving forces that may be a variable to move people more towards Version 3 and to have them move forward.
One is the fact that they want to use this information to improve the process of how care is delivered. And from there we are seeing a drive towards terminology and a drive towards looking at their data and how the data goes through the continuum and to try to standardize that and find the best messaging communication vehicle for that data, because it is going to drive the process of care.
We are starting to see too another factor, is the fact that they want to look at the outcomes of that care and compare the outcomes, so they need the data to do that comparison, both within their systems and to report at the state and the national level. So there again we are seeing another re-evaluation of the data that is collected, how it is communicated in that pipeline going across from one application to the other.
And if you look at it from a business perspective, there are some driving forces there around safety and outcomes and trying to improve the process of care delivery. So I just wanted to bring that to the panel as a factor not to lose sight of as we move forward in terms of what we are trying to do with our ultimate goals and objectives.
MR. BLAIR: So from the SMS perspective those are business driving forces that make Version 3 attractive to you?
MS. KENNEDY: Yes, and current versions and Version 3 as well, yes, that we can move forward and take advantage and help us achieve our ultimate goals and outcomes here.
DR. COHN: Questions?
DR. FITZMAURICE: I have a question on a slightly different topic. Are these follow up questions on this morning or other topics?
DR. COHN: That's other topics. Make it quick.
DR. FITZMAURICE: Dr. Aita, when you talked about Medcom Soft adopted a highly structure Medcin nomenclature. There is also a Snowmed nomenclature out there and there may be some others. I hear from the testifiers, virtually every testifier, we need a common medical vocabulary, a common medical terminology. It has to be clinically oriented. And I know that the Chair of the Subcommittee on Standards and Security, Simon Cohn, has had in mind that this is going to be a major push in the year 2002, if I'm not jumping ahead of his gun. Can you tell me in about three sentences, not too long sentences, why you chose Medcin over something like Snowmed?
DR. AITA: Very interesting question because there is fundamental difference between the entire strategy behind Medcin and Snowmed. First of all the presentation of the point of care, the way that the data is presented, the way that a physician can assimilate the data and capture clinical information. The Snowmed engine lacks the links between the data element, the links that will work the way the physician can operate, and today Medcin is the only nomenclature that will allow to transform the practice of medicine from an art to an absolute science. I don't know of any data element or nomenclature today that will allow that. And that is allowed through the 72 links that are between the data element, that will allow us not only to capture but the quick viewing of the data and structured the way a physician works, and that is the most important, for me as a physician, is the point of care action of that nomenclature.
DR. FITZMAURICE: Thank you for that opinion.
DR. ZUBELDIA: I have a question, different topic. Dr. Aita has made a statement that nobody else has commented on, and I think it may be somewhat of a contradiction. You are asking for conformance testing and some reference that - interoperability against, and everybody else has been talking instead about how to facilitate the customization of the interface through the interface engine or by using the same standard with interoperability. And it looks like if we are go to the conformance testing route that could stifle the flexibility that we would gain by using these standards.
DR. AITA: Well it depends what is the end result that we are looking at. Are we looking at a broader end result where the data is going to be exchanged across facilities regardless of the business relation between these facilities, or are we looking to really facilitate the process of customization between two entities. Medcom Soft is looking more from a broader view, is that we want regulation to make sure that a message standard or standard that is adopted could be read by everybody. We do not believe in interface engines, even though we have to put interface engines, because interface engine means that you really have to translate one to another, as opposed to having the same data field in the same structure. The more we structure that at the front, the less we need interfaces and customization at the end.
MR. GUINAN: I would add the National Association of Chain Drugstores, with the new initiative called Short Script, has proposed a similar idea in a certification body. One of the functions of Sure Script, as put out in the initial plan, is to act as a certification body for the implementation of whatever standard the industry decides on, maybe the same one that you all decide on. So we also agree with that approach, that it would help folks like ourselves in our business to comply and actually have a lower cost in compliance if there was some sort of accreditation body out there that would be able to monitor, and ongoing compliance, not just the initial implementation, but ongoing compliance as we change our systems and software. So we are proponents of that idea as well.
DR. MC DONALD: On that point, we had decided as a committee I think that we should try to push for conformance testings of these standards, and I don't think that they are contradictory, those two things. I mean you still have some tweaking at the end, but some of the stuff is so far away from any normal human's reading of the standards, that any kind of a testing would certainly be of value to users I think, that they would have some idea this at least was in range. It depends on how far down you go down the trail.
DR. ZUBELDIA: I had said I'm very, very big proponent of performance testing and compliance (laughter), but I'm concerned that it could stifle the implementation of HL7.
DR. MC DONALD: As someone who uses it as a user, I would sure prefer that there was some kind of conformance testing. There still will be issues because of the content flexibility when we don't have standardized codes. What I wanted to ask again for this group, the other group was, to what degree are these standards that you are talking about being used, and I think I know the answers to some of the questions, do you use them in institutional hospital care versus office practice, home health care, ambulatory settings, your experience.
DR. AITA: We cannot talk from very long experience because as I said we newly introduced this box in the last few months, but we have found there is equal interest from institutions, we are implementing the system in Hopkins, as opposed to a single doctor office, because really the clinical part of a patient's record is exactly the same, the provider works on it the same, and we are finding that the interfaces are different that are required in different setting, but the core of the patient's medical record is still the same.
MS. KENNEDY: I would agree. We have experience in the emergency, critical care, medical surgical unit and ambulatory clinic and home health areas and physician offices, so it is very broad with fairly large numbers behind each one of those categories.
MR. GUINAN: ProxyMed participates solely in the ambulatory physician marketplace. That is the goal of our business to connect the physician office marketplace with its business partners. So that's our experience.
MR. BLAIR: I believe that you made a recommendation that NCVHS consider recommending to HHS that there be "an organization" established or created for the conformance testing. Can you elaborate as to what you have in mind, and are you thinking of that being a government entity, a professional association, a private sector organization, a consortium, what were you thinking of?
DR. AITA: Well in the recommendation if we are looking at, our thinking was if there an organization is going to do the testing for HL7 standards, it should be within the HL7 organization or a section that is going to be organized and funded to do that job. I mean nobody would be better than people who are behind that standard to do that job. And the same would go for any standard that is applied in NCPDP or the others. But yes we believe that it should be somehow regulated, government regulated, but you need the organization itself to be the one who will take the mandates off of implementing the rules.
MR. BLAIR: May I ask another question here? To what degree, have you had a chance to be here all morning where you have heard the other testimony from the earlier panel?
DR. AITA: Yes I did.
MR. BLAIR: Great. As you may have observed, many of the representatives from the earlier panel were from major vendors who have large installations in acute care institutions as well as ambulatory facilities, but their heritage for the most part has been coming from an acute care background, and they have many installations of HL7 on Version 2.1 and 2.2. You are a new vendor, and it appears as if your principal focus has been on ambulatory care and using the Internet with XML. Is that correct?
DR. AITA: That is correct.
MR. BLAIR: Okay. I would appreciate your perspective on how the same HL standards, like for example the message format standards for patient care, the message standard, well which specific HL7 messages do you look to from that list of seven, and how well do you feel that meets your needs from an ambulatory perspective and from an Internet perspective. Do you feel that that's different than from an acute care perspective?
DR. AITA: I don't believe there is really a different between ambulatory and acute care. We are going to find that as we evolve there will be, we will start seeing a separation between the pure practice, the practice management to the electronic patient record segment of it, the clinical segment. The message set of order entry, whether you are in an ambulatory care and you did it with an outside lab or within the hospital to the lab of the hospital, it is still an order entry message set that is going to be the same.
I think we will find that, and I heard this morning HBOC and Cerner and one was pushing for HL7 and the other one for medical vocabulary, so I guess we have an understanding in the industry that something has to be done in the same direction, but Medcom Soft believes that there is absolutely no difference when it comes to electronic patient records between any sets of institutions, because ultimately a proper electronic medical record has to go through institutions to give the continuity of care.
So we should look at the medical record separated first and how it integrates with the rest of the institution in their business process, but we should not drive the format of the electronic medical records to the business process of the institution already in existence today. We have to think of that medical record as a separate entity, to find how that entity is going to operate between the institutions, how the messages are going to be exchanged. But more than just exchanging the messages where, we are the most interested in is to see and work towards proper aggregation of the data coming from one system to another, because if we are going to do a proper disease management, the data that we collect in institution B should integrate with the data collected in institution A instantly to allow the provider to view that data and act on the patient in a fashion whereby the data is shown as an integrated fashion.
And I want to give you just one example if you give me one minute. If we look about health care, health care really is nothing else but a spreadsheet, and electronic medical records are nothing else but a spreadsheet. On one side we have data elements and one the other side we have time, and we give value of each one of these data elements in time. So when we look at an electronic medical record in the future, we have to look at it as a spreadsheet and everybody should be entering data in these cells of that spreadsheet.
So it irrelevant what system or what vendor system is there as long as we can come to the understanding that the end data should be fitting in that cell of the spreadsheet where it points to a data element that is codified and it points to time and it points to a patient. We have built a system today that show all the data and spreadsheet, manage the data, disease management in spreadsheet, aggregate the data in spreadsheet, and there is really a total view of the electronic medical record when you see it there because you can graph any data element and aggregate any of the data elements together.
MR. COHN: Should we close?
MR. BLAIR: Are we running out of time?
MR. COHN: Yes.
MS. KENNEDY: May I comment.
MR. COHN: One final comment and then we will adjourn.
MS. KENNEDY: I would just like to add the comment that if we are looking in terms of the data and the volume of data that is collected, we could have a great infrastructure for messaging in terms of sending the data from one system to the other. A large volume of that data that is collected, it is collected by nurses, and we have very little commonality around the terminology that is used for the information that is collected.
So I just want to bring that to the table as a variable that we need to take into consideration, because we need to collect it once, capture it once, we need to have a common reference terminology around it, if we are going to invest in the business of doing the standardization and putting an infrastructure in place.
DR. COHN: I want to thank you for a very interesting panel. We are running now about 25 minutes late. We will reconvene at 1:30 p.m.
(Lunch)
DR. COHN: Will the panel introduce themselves please? There is two of you here in person with use and I believe another two that are on the line. So we'll have the two here first introduce yourselves if you would.
DR. BERMAN: My name is Cliff Berman with Allscripts Healthcare Solutions, Inc.
PARTICIPANT: Hello?
MR. BLAIR: We can hear you. Can you hear us?
PARTICIPANT: Just barely.
MR. BLAIR: Who is it that we are speaking to now?
DR. HUFF: This is Stan Huff.
MR. BLAIR: Stan, we are just going through introductions of our panel.
DR. HUFF: You were here for a second and then I lost you.
MR. BLAIR: How about if we speak into the microphones, does that help you.
DR. HUFF: Yes, some.
MR. BLAIR: Okay, let's just be careful to speak as close as possible into the microphones. And Stan, we are about to go through the introductions. We have two people here and Marc Overhage and then yourself, okay.
DR. HUFF: Great.
MR. BLAIR: Okay, go ahead.
MR. WAGNER: My name is Steve Wagner. I'm with the Department of Veterans Affairs, Veterans Health Administration.
DR. BERMAN: It is Cliff Berman with Allscripts Healthcare Solutions, Inc.
MR. BLAIR: Marc?
DR. OVERHAGE: Marc Overhage with the Indiana University School of Medicine and the Regenstrief Institute.
MR. BLAIR: Stan?
DR. HUFF: This is Stan Huff with Intermountain Health Care and the University of Utah Department of Medical Informatics.
MR. BLAIR: Okay, I think that it is proper for people on the Internet to know Stan, one of the things that we have all done when we have introduced ourselves on the committee in particular is identify any other close associations, so I think you should mention your role and position on HL7.
DR. HUFF: Okay. I am the current Chair of the Board of HL7. I am also a Co-Chair of the Loink Terminology Committee, specifically for the clinical Loink aspects.
MR. BLAIR: And for Marc and Stan's benefit, the committee members that are present right now are Clem McDonald, Simon Cohn, Kepa Zubeldia, and Jeff Blair. Shall we go ahead and have our first testimony.
DR. COHN: Which of the two of you here in person would like to start with the testimony?
DR. BERMAN: I'd be happy to start.
DR. COHN: I think we will hold those on the phone until last.
DR. BERMAN: Good afternoon Mr. Chairman and members of the subcommittee. My name is Cliff Berman and I am appearing today on behalf of Allscripts Healthcare Solutions, Inc. I am Senior Vice President and General Counsel of Allscripts.
Allscripts recommends that electronically transmitted prescriptions and related computer-to-computer communications between physicians and pharmacies be included within the electronic health care transactions covered under the Health Insurance Portability and Accountability Act of 1996. Allscripts further recommends that the Script Standard format created and maintained by the National Council for Prescription Drug Programs, NCPDP, be adopted as the message format for these computer-to-computer communications.
Allscripts is the leading provider of wireless point-of-care solutions for physicians. Over 5,000 physicians use our wireless applications to perform a variety of tasks, including e-prescribing, lab orders, dictation and charge capture. Our e-prescribing application has been used to write millions of prescriptions. Our latest software, called Rx+, performs drug utilization review against other drugs prescribed for the patient to identify any drug interactions, therapeutic duplication or drug disease contra-indications.
It also alerts the physician to possible problems with drug allergy and drug dosing. The Rx+ software also indicates whether the chosen drug is included on any formulary that may be administered by the patient's prescription drug benefit plan and if not, identifies formulary alternatives for the physician's consideration. Finally, and perhaps most importantly, the Rx+ software creates an electronic prescription that is legible.
Once the prescription is created, the Rx+ software allows three options: the physician can print a hard copy of the prescription for the patient to take to the pharmacy, the physician can electronically fax the prescription from the physician's computer to the pharmacy's fax machine, or the physician can electronically transmit the prescription from the physician's computer directly into the pharmacy's computer via Script Standard.
While all three formats are superior to handwritten prescriptions, the computer-to-computer format holds the most promise in the fight to decrease medication errors, since it eliminates the need for pharmacy staff to retype the prescription into the pharmacy's computer. The computer-to-fax and electronic paper prescription formats still dominate, because of the slow adoption of Script Standard technology by the pharmacy community. Some of the mail service pharmacies and the largest pharmacy chains have implemented or begun implementation of Script Standard, but most pharmacies have not.
We are hopeful that adoption of e-prescribing technology will be accelerated by the inclusion of electronically transmitted prescriptions and related computer-to-computer communications between physicians and pharmacists as transactions covered by HIPAA and the adoption of Script Standard as the standard message format for those transactions.
Allscripts is a member of the National Council for Prescription Drug Programs and we are active on its work groups. Allscripts implemented NCPDP's Script Standard in late 1998 at an approximate cost of $25,000. The time to implement was approximately two months. Script Standard transactions are routed to the pharmacy through a switch. Some pharmacies maintain their own switch and others contract for that service. It takes about six weeks of testing time for each connection we make to a new switch.
There are really no alternatives to Script Standard in this arena. While HL7 has a message standard that supports inpatient drug orders, only Script Standard applies to the unique requirements of outpatient prescription transactions. The transmissions that Script Standard supports include new prescriptions from the prescriber to the pharmacy, requests for refills or prescription changes from the pharmacy to the prescriber, and response to those requests from the prescriber back to the pharmacy. Although issues exist around reaching agreement on common code sets, identifiers and data elements, we are satisfied with the Script Standard message format itself.
We utilize Script Standard Version 1.5, which is the version in use by the few pharmacies that have implemented electronic prescribing software. We will implement Version 4.0 when there are pharmacies that have implemented it. Given the relative frequency with which new versions of these standards are released, we would recommend some flexibility in adopting a specific version so that the rules do not mandate obsolete versions. New releases tend not to be major overhauls, but rather add data elements based on suggestions by users. Perhaps the standard chosen should be the version then in current use and all subsequent releases.
All scripts would be happy to work with the subcommittee to address these details as it formulates its recommendation to the Department of Health and Human Services. Thank you for your consideration of our comments and I would be happy to answer any questions the subcommittee might have.
DR. COHN. Thanks very much. Next, Steve Wagner.
MR. WAGNER: Mr. Chairman and the committee members, I would like to thank many for extending an invitation to the VA to testify at today's hearing on the use of message format standards related to PMRI.
The Veterans Health Administration, or VHA as we are often times referred to, is a major user of message format standards for the exchange of patient medical record information. VHA first implemented a message format standard in the early 1990s, namely the HL7 2.1 standard, and also began participating in standards development organizations at the same time. Today VHA is a participant in virtually all the standards development organizations related to the list of standards for which NCVHS is requesting testimony. VHA has implemented or had experience with almost all of the standards except the IEEE medical device standards.
One of the first questions you asked of those testifying was do the PMRI message format standards on the attached list address your highest priorities for exchanging PMRI electronically. The one high priority area that is not really addressed by the standards on the list that you provided is the area of vocabularies and code sets. The vocabularies and code sets used to exchange information are an integral part of the message format standards, and the assumption is, that we have, is that vocabularies and code sets will be addressed perhaps by a separate hearing. Leg me address each of the other groups more specifically.
ASTM. VHA participated in and was an actual co-chair of the ASTM E31.25 Subcommittee. The DTDs that this subcommittee developed are based on the HL7 Clinical Document Architecture and implement the Level 1 Header of the HL7 CDA standard. The DTDs are intended to provide detailed health care information that would normally be associated with Level 3 of the HL7 CDA. VHA has implemented the Draft Specification for Health Care XML DTDs as a demonstration project.
No unexpectedly, we encountered a number of issues in implementing the draft specification. We believe that all the issues are due to the fact that there is a natural disconnect at this time between the currently defined Level 1 Header of the HL7 CDA and a Level 3 implementation and that is because the Level 2 CDA is not yet fully defined. We believe once Level 2 of the HL7 CDA is fully defined and the ASTM XML DTDs are revised to accommodate changes that this will introduce, that the ASTM XML DTDs will be very useful standards for the exchange of health care information.
The VHA has participated only peripherally in the ASTM 31.27 Subcommittee that you have on your list and not sufficiently to be able to comment on the Draft Specification for the Health Care Document Formats.
Reflated to DICOM, VHA has implemented the DICOM 3.1 standard. We found it a relatively easy standard to implement. We had implemented an earlier version of this standard so our implementation was an upgrade as opposed to a brand new implementation there. We also found the standard relatively easy to use, however, VHA issued a set of our own specific requirements in addition to the standard that further limited the optionality allowed by the standard itself, and that probably assisted us. The standard has met our needs quite well. We have no major weaknesses to report. We believe a new section of the standard, called Structured Reporting, will be very useful for exchanging imaging reports and we are beginning to evaluate implementation of that section.
Related to HL7. As I indicated previously, VHA is a long-time user of HL7 standards starting with Version 2.1. We have continued to expand our use of different sections of the HL7 standard to the point where we now have implemented and/or evaluated virtually all of the HL7 standards on the list provided by NCVHS. The 2.x versions of HL7 have continued to improve with each new release, and VHA has found even the earlier versions met many of our needs. However, they required extra work to implement due to the amount of optionality that existed in the standards. Optionality has been reduced with each subsequent version, but there is still too much even in the latest 2.x version of the standard.
Version 3 of the HL7 standard is expected to significantly reduce the problem of optionality, but we feel it is still too early in the development of Version 3 to draw a real conclusion. The only part of the Version 3 standard VHA has implemented is as a demonstration project, and that is based on the HL7 Clinical Document Architecture. The main comment that we can make related to just the messaging portion of the HL7 Version 3 standard is that it does hold the promise of being a significant improvement over the Version 2.x standards.
Our evaluation of the HL7 Clinical Document Architecture Framework standard is that it currently meets only a limited amount of VHA's needs due to the fact that only Level 1 of the standard has actually been implemented. We believe that most of VHA's needs can be met once the Level 2 of the CDA is actually fully defined, and we believe that this standard has great potential for enhancing the exchange of clinical information.
Related to IEEE, the VHA has not yet evaluated or implemented the IEEE standards for medical devices and therefore we are unable to comment on these standards at this time.
Related to NCPDP, VHA has not yet implemented or evaluated Version 4.2, which is the, specifically the prescriber-pharmacist part of the NCPDP standard. We have currently implemented Version 3.2 of the NCPDP standard, specifically the part related to claims submissions, and it is definitely meeting our needs. We have also evaluated Version 5.1, which is the version required by the HIPAA regulation, relative to claims submissions and have found it acceptable for our needs as well.
And related to OMG standards that you had listed, as a part of a project called the Government Computer-based Patient Record, VHA has evaluated and implemented the OMG Person Identification Service or PIDS specification and the OMG Clinical Observation Access Service or COAS specification. These implementations consisted of minimum functionality as opposed to the most robust implementation of these standards. VHA did not have prior experience with any of these standards and therefore a lot of training was actually required for us. The implementation of both of these standards, including all of the training, took approximately 18 months. The standards were reasonably easy to use once they were implemented.
The final question you had was areas not met by the current PMRI standards. There are a couple that we have identified that are possibilities. There is a need for a scanned document type standard, one that includes file format and annotation kinds of capabilities. Some existing document formats include TIFF, and PDF, and you can include DICOM there. The DICOM standard could be extended to actually fill this need by enhancing it to handle document images specifically, since DICOM already has annotation capabilities built into it.
There is also a need for an EKG standard, and we believe DICOM is in fact working on this, although we are uncertain as to the current status on that. And that concludes my comments.
MR. BLAIR: Your last comment was an AG standard did you say?
MR. WAGNER: EKG.
MR. BLAIR: Oh EKG, thank you. Marc?
DR. OVERHAGE: Thank you. I am sorry I am not able to appear in person, and I appreciate the committee allowing me to participate by telephone. My name is Marc Overhage and I am an Associate Professor of Medicine at the Indiana University School of Medicine and an Investigator at the Regenstrief Institute for Health Care. I'm going to comment today on our experience using the HL7 method standard over the last 13 years at Wishard Memorial Hospital, and the last six years implementing a city-wide electronic medical record.
Researchers from the Regenstrief Institute organized the ASTM 1238 Standards Committee that was the basis for HL7 standards in the late 1980s and we have been intimately involved in using an evolving HL7 since then. Just to be sure, can you hear me alright?
MR. BLAIR: Yes Marc, we hear you very well.
DR. OVERHAGE: Good. We called the city-wide project the Indianapolis Network for Patient Care, or INPC. The INPC currently connects 11 hospitals from five competing health systems, a large primary care practice, a homeless care network, and the county and state health departments. These 11 hospitals provide over 95 percent of all the inpatient and emergency department care in the Indianapolis metropolitan statistical area, as well as a significant fraction of the outpatient laboratory and radiologic services.
We receive laboratory result data and most of the encounter data in HL7 format directly from the hospital's operational systems. In addition we receive a large variety of data from specific hospitals, including pulmonary function test results, electrocardiographic reports and tracings, radiologic reports, echocardiogram reports, emergency department triage records, physician notes, vital signs from bedside devices, and approximately a dozen others.
Other date such as the emergency department logs, that we do not receive as HL7 are converted to HL7 and processed for storage using the same systems as are used for data that arrives natively in HL7 format. We currently process approximately one quarter a million HL7 messages daily, and have processed over 100 million in total.
As you can imagine, we must accept a variety of variations on the HL7 standard, with the vast majority of the messages conforming to Version 2.2, but we find some Version 2.1 and 2.3 in use as well. The addition of richer data types, such as the XPN or extended person name, in more recent versions has extended the functionality of the standard.
We also use the DICOM standard to receive and process radiographic, conventional radiographs, CT, MRI and Ultrasound imagines and soon echocardiographic and gastroenterologic images as well. The software link these images to the reports describing them, and they can be retrieved and manipulated using a web-based image viewer built into the electronic medical record.
We took advantage of the "plug and play" capability provided by HL7 to provide an electronic laboratory reporting function for public health. The electronic lab reporting system capitalizes on the existing HL7 message processor or the INPC that reads each message, parses out as separate components, and then determines whether result reported might contain evidence of a reportable condition. If the result might carry evidence of a reportable condition, the software places a copy of the HL7 message into another message cube that a reportable condition processor services.
This processor assumes that the messages are well formed and that the result codes will be represented by Loink codes. The software uses the CSTE CDC or commonly called wire tables, that define reportable conditions based on Loink codes of test that indicate the presence of a condition. We have been identifying and storing reportable conditions in real time for over three years using this approach. These data are available to the county and state health departments for use in case finding and surveillance.
Ongoing evaluation studies indicate that we identify cases sooner and more completely than traditional reporting methods. We believe this system demonstrates important components of the NEDSS or National Electronic Diseases Surveillance System project underway at the CDC.
The HL7 and DICOM standards have worked well as a foundation for building a community-wide electronic medical record. We chose HL7 for the INPC project for several reasons. First and most compelling, nearly all clinical computer systems in use can send data as HL7 messages. It is the most widely supported message standard for the exchange of clinical information between computer systems. In 1998 a survey of hospital CIOs, 80 percent reported that they used HL7 at that time and 13 percent more are expected to do so in the near future.
Second, we can easily map the message content of the HL7 messages into the INPC as information models. The fields contained in the HL7 messages all have clear semantic homes in the INPC's databases. This degree of compatibility arose partly because the information model on the HL7 message standard have evolved in parallel.
Third, we can use a single set of monitoring and control functions for management of all of the data flows. And finally, and very importantly, performance is acceptable. With today's computing hardware systems can process the large volume for the HL7 message that can be expected to be created in a large integrated delivery system, or as the INPC demonstrates, over an entire community.
The messages created by clinical computer systems do not all conform to the HL7 standard completely. We have managed this variability by inserting message preprocessing software into the stream that modifies the message to better conform to the HL7 standard. The most common variance encountered is that the data are not placed into the proper HL7 fields.
For example, units, normal ranges, and results will often each be sent as a separate HL7 OBX segment, or alternatively the OBX 3 field, which is designed to carry the actual results, will have not only the result, but the normal range, units and interpretive comment and information about where the test was performed. These problems seem to be worse when other systems pass the data through. Fairly well formed messages sent from a reference laboratory, stored in a laboratory information system and forwarded to a clinical data repository such as the INPC, may become less well structured in the process.
In recent years we have observed, however, that the HL7 messages created by the clinical computer systems are beginning to conform more closely to the standard and requiring less preprocessing effort. A typical new interface for us now requires only about one man day of effort. Further efforts to educate software developers and vendors on the proper way to implement the standard will accelerate this process. The HL7 Version 3 reference information model or RIM will help to insure that developers create HL7 messages that conform to the standard, by providing clear descriptions and precise definitions.
In summary, we have been able to create a community-wide electronic medical record system using HL7 as the primary message standard. HL7 has proven to be a workable choice for information exchange in its very heterogeneous environment, and along with DICOM and the Internet standard such as JPEG, MPEG, and TCPIP, provides for all our current and immediately anticipated needs.
We do expect to evolve to HL7 Version 3.0 as the developers of commercial clinical information systems are able to develop and deploy that capability. But there is no reason to wait until Version 3 is widely available to start taking advantage of the strong functionality provided by the current versions.
Thank you for this opportunity to share our experiences. I hope you find it somewhat useful.
MR. BLAIR: Stan, can you hear us?
DR. HUFF: Yes. Are you ready for me?
MR. BLAIR: Yes, we are ready for you Stan.
DR. HUFF: Thank you again for this invitation to participate in this testimony. Let me introduce myself again. I work for Intermountain Health Care, which is a not-for-profit health care provider, centered in Salt Lake City, Utah and sort along the - front. We have 22 hospitals and a number of urgent care clinics and emergency rooms, along with 400 employee positions and also a health care, basically an insurance or health plans division.
I'm also a Professor of Medical Informatics at the University of Utah, and my job at Intermountain Health Care is managing, in fact, the interface team and also our data dictionary or coded terminology team. We have currently 12 people employed full time in creating and maintaining interfaces, and we have eight people full time maintaining coded terminology that is used in our electronic medical record.
Just to give an overall, I think it is important maybe to give an overall perspective first. The two standards that are under consideration that we are primarily using are HL7 and DICOM. HL7 is used extensively to interconnect our outpatient systems, our inpatient systems, to accept data from stand alone emergency room systems, pathology systems, external transcription systems, and also to communicate from IC to the Utah State Health Department for sharing of immunization data on children.
We are processing close to a million transactions per day of HL7 formatted data. In our environment we have roughly 20 different kinds of HL7 messages that we are using that, when I say kinds that is talking about medication orders versus medication administration, source of records, medication allergies, laboratory orders, microbiology orders and results, et cetera, and so we have roughly 20 different kinds of HL7 interfaces that we implemented, and we have over 200 running incidences of HL7 interfaces connecting our various hospitals, facilities, laboratories, et cetera.
So with that general background, let's start and just describe independently the questions that were specifically asked in the invitation. The one standard that I would mention is the C-CAL standard, and that may have been discussed before by the committee, but C-CAL is actually a way of sharing information that is different than the standard messaging standards, but we found an important role for that in terms of integrating for instance our state immunization database into applications and sharing of that data within Intermountain Health Care. So I think that would be another standard that should receive some consideration.
IHC does not currently use any of the ASTM or IEEE standards that are listed, nor NCPDP Script. As mentioned, what happens right now, similar to Mr. Berman's testimony, we are primarily faxing prescriptions from our systems to outpatient pharmacies, and we haven't used any of the OMG or CORPAmet standards that are under consideration.
Our current versions of HL7, we have in service interfaces that vary from Version 2.2 to Version 2.3.1. We are currently testing and installing versions of 2.4, and that is really, in most cases that's a simple upgrade, so even though those are new versions, 90 percent of what we are doing is consistent between Version 2.3.1 and Version 2.4., and those have been easy transitions because of the backwards compatibility requirements of the HL7 standard.
Why do we use HL7. It is primarily because it is the standard that's available from vendors. It has almost become a screening test of vendors. If, you know, you ask about HL7 interfaces and they say what is HL7, it is a bad sign, because basically all of the key vendors support HL7 and it is supported in commercial interface engines, it is supported with interface development kits, there are tutorials and training materials readily available. There are people who are skilled and can act as consultants, and program managers to install HL7 interfaces. And of course, not showing any bias at all, there is a stable open consensus standards group that can maintain and enhance the standard and is responsive to new needs as time goes on. So that is why we are supporting and using the HL7 standards.
You know I think in terms of implementing the standard, some of the biggest positives are just it is easy to understand and it is sort of intuitive to people who work with clinical data, and it allows for the integration of standard terminologies, Loink and/or Snowmed or other standardized drug terminologies, as an integral part of the standard, and allows appropriate references of those external vocabularies.
As I'll point out and second some of the other things that have been said, the standard, the single biggest problem is the fact that there is no standard terminology for many of the things that we are trying to send, and I think that echos what Steve Wagner said. That is the single most important thing that is needed.
How long does it take to implement. Depending on the particular interface, it could be something that could take as short as a week to implement or as long as six months. The things that are closer to the six month timeframe for implementing are complicated things like microbiology culture results, which are not standardized within the laboratory information systems. And so it takes a long time to match up data models and to match up terminology and to match up the process and knowing how to update things appropriately as cultures move from preliminary to final and that sort of stuff.
And so working through those issues are the things that cause interfaces to take six months to do. The simple interfaces are typical admit, discharge, transfer, demographic kinds of interfaces that we can set up very quickly because they are much more standardized and have been in use for a longer period of time.
The cost of implementing depends again on the sophistication and the particular company, so in purchasing interfaces from vendors the costs are varied from as low as a couple of thousand dollars for an interface, up to $20,000 to $25,000 for an interface. And the cost again it just varies mostly based on the number of kinds of transactions that are going to be supported in the interface. In any of the interfaces the greatest amount of work is doing vocabulary mapping between the sending system and the receiving system, again pointing to the need for standardized terminology as one of the key things that are needed.
The interfaces, once they are implemented, are very easy to use and easy to maintain. Again a lot of that is because of the support in standardized commercial tool sets and interface engines to make that important.
What are the major weaknesses and limitations. Again the biggest problem is a lack of a standard terminology, and that leads to the second problem, which is it is difficult to do conformance testing because people are using different terminologies and without a standard terminology we can't do standard kinds of conformance testing for the interfaces. Loink is serving a very strong role in laboratory data. We are beginning to use clinical Loink for some of the typical kinds of clinical measurements. There really is no national standard currently for signs, symptoms, clinical diagnoses, a lot of the other things that we are trying to move in a clinical environment, and so that I think is probably the single most important need.
What could we do to improve that. I think it would be very easy to make implementation guides that would specify, that would remove a lot of either the vagueness and also specify the terminology that should be used in particular of messages. And, you know, I think those implementation guides would be easy to develop for the highest return kinds of transactions.
So I think it would, there's already work in progress for instance to specify implementation guides for microbiology culture results. With pharmacy and medication transactions, what is primarily needed is a specification of what standard terminology would be used in those transactions, because the foreman and the rest of the routes of administration of other date is pretty well specified in the standards.
So I think the one thing that would really help would be in fact to make some implementation guides that covered the high volume, greatest return kinds of transaction sets, and that is an entirely doable sort of thing.
We have been looking at Version 3 of HL7 in terms of, right now what we have done is early prototyping using the Version 3 data type standard. We have not tried to implement a prototype for Version 3 messages. We anticipate moving to the Version 3 standard, but it is not in our production systems today. And I would echo the comments of Marc in saying that there is a lot to be gained by going and standardizing on Version 2 of HL7, because I mean, we've got again a million transactions a day of 2.4 non-compatible data in our system, and we ought to start taking advantage of that today and Version 3 will, at an appropriate time, will become a more, will be a next generation, but it would be premature I think to go to Version 3 right now.
So that is the summary of our use of HL7. Our use of DICOM, DICOM is in many ways less visible in our institution, and that's not because it is necessarily less valuable, but in fact the standard sort of comes bundled with the PAC system that we use and also is part of the instruments and devices that are used to collect the digital images, and so whereas those interfaces essentially get implemented by people who are installing either the PAC system or new instruments and our IR staff doesn't really see those interfaces.
The interfaces, in terms of DICOM, our use of DICOM is limited to the use of that standard for radiology images. We don't use it for light microscopy so we are not using the visible light supplement of DICOM and we are not using the structured reporting capabilities of DICOM. In the case of structured reporting, it is heavily overlapping with HL7 and as an institution we don't really feel that we want to support two different ways to send clinical data between systems. So in our institution basically all of the clinical data is going in HL 7 and it is only the image data itself that is being sent in DICOM.
So again, the implementation of DICOM is roughly gauged by the task of vocabulary mapping and aligning information models and terminology across the interfaces. Typically that requires three months or so of work. Again it is rather hard to know exactly how much the interfaces cost, because it comes bundled as part of the system, but near as we can tell, the cost of implementing DICOM interfaces throughout our enterprise is somewhere between $75,000 and $125,000, which is sort of the initial purchase price, and then of course there would be ongoing maintenance fees and other things associated with that.
The DICOM interfaces have been very stable, have been very good interfaces, and we haven't had any problems with that. My major concern with DICOM is that DICOM actually standardizes less than what I thought it did. When you get into the internal aspects of it, it really is sending, it is sort of a standard wraparound proprietary image representations. So it is a different thing for instance than the Internet standards that allow a truly application and vendor independent rendering of an image. And so I think some next generation may try and resolve some of those issues, and I think it is worth investigation for image transmission in the future whether in fact some of the more industry broadly Internet based technologies as opposed to specifically medical technologies for imaging might gain more market share and more acceptance.
So I think again the biggest improvement for the DICOM standard would be in standardizing terminology. DICOM uses parts of Snowmed, the subset of Snowmed, to represent body locations and some other things like the kind of dyes and radioisotopes that are used in the procedures, that sort of thing, but it is not standardized on all of the diagnosis names or other clinical day to day that would be associated with the xrays. And so again the need for standardized terminologies is probably the single best enhancement that we could ask for in terms of DICOM.
Now we haven't investigated any future versions, and so we are basically using the current version of DICOM.
Just to reiterate again that I think the C-CAL standard is one that we found utility for, and it increases operability of applications even though it is not a traditional messaging standard. So I think that is a standard that would be worth looking at and potentially adding to the list of standards to support the patient medical record. Thank you.
DR. COHN: Thank you Stan. Before we take questions, I was asked if Stan and Marc, could you send your copies of your presentations to Mike Fitzmaurice?
DR. FITZMAURICE: I have Stan's. He sent it to me. I have it on a disk in my pocket. I just pulled it out about 30 minutes ago. Okay fine, so Marc can you take care of that also?
DR. OVERHAGE: It's on the way.
DR. COHN: Okay, thanks so much. Questions?
DR. FITZMAURICE: Can I ask a clarifying question of Stan?
DR. HUFF: Sure.
DR. FITZMAURICE: You said the DICOM standard is really a standard wraparound a something, and I -
DR. HUFF: Well, yes, it is a wraparound sort of the proprietary good oriented representation that is supported by the proprietary vendors. So in the inside basically it comes down to it, and then, you know, the vendors have each, they view it as part of their proprietary advantage to know whether you are doing 16 bit images and how many bits are gray scale and a whole bunch of other things, and that internal representation has actually not been standardized.
What happens is DICOM branches down to a particular point and then it basically says here I'm going to start using, you know, the actual data content is now this particular bit representation that is used by GE and this is, and somebody else will say and this is the one that is coming from Siemens and this one. So it really encapsulates, you know, the bit level representation that the image is not standardized. It is standardized within a given vendor, but it is not standardized across vendors.
DR. FITZMAURICE: Does that mean that when you go from one vendor to another, you have to do some interfacing, some transformation, in order to go from say 16 bit to 8 bit?
DR. HUFF: Right. You need to, yes, and I mean it is not clear that a transformation is 100 percent possible because the differences at the bit level, there is a potential for information loss or that, you know, one representation is actually stronger than the other representation.
DR. FITZMAURICE: Okay, thank you Stan.
DR. ZUBELDIA: Can I clarify that? So essentially you would need a different proprietary viewer to view the messages that are coming from that specific xray machine.
DR. FITZMAURICE: That's worse than I thought.
PARTICIPANT: Is that a true statement or is that a question?
DR. ZUBELDIA: Stan, could you confirm that?
PARTICIPANT: The question is would you require a different proprietary view in effect.
DR. HUFF: What happens is you, you know, when you purchase DICOM software, what they do is they say, you know, we support DICOM and then the next layer down in their support says which particular binary formats their viewer or their interfaces support. So what happens is the people have generic DICOM viewers, but the second part of the specification is to say which particular flavors of the DICOM protocol that viewer will support.
MR. BLAIR: Stan, if you can hear me, if not Clem will translate for you. But even if you have a proprietary viewer, how does this affect the ability to send a DICOM standardized message with an image over the Internet maybe to a web server, how does it affect that?
DR. HUFF: Most, I mean in our implementation the DICOM images aren't sent over, well, they are sent via the Internet, but what happens in our case is that the PAX vendors now basically have web servers that transform the DICOM image into JPEG or TIF or one of the other formats and that is the actual format that is on the wire from the image web server to the clinical work station or the, you know, where a physician or clinician can view the image.
MR. BLAIR: So it would have to be sent completely separately from an HL7 message, whether it is in 2.4 with XML or the upcoming Version 3 with XML. A DICOM image would be completely incompatible, is that correct?
DR. HUFF: Well we are talking about two different things. I mean HL7 today, I mean it has the capability to send images, but nobody is sending images in HL7, and I wouldn't propose HL7 for that use. The distinction I was making is the fact that people take DICOM images and they put them into a DICOM archive. When you want to render that image for viewing on the web, then it gets transformed from its DICOM form into one of the Internet standard image transmission forms, and that is what you actually see on the wire between an image server and the work station where the person is, actually the person's PC where they actually see the image.
MR. BLAIR: Well does this force you to have a completely separate image server from a server that is handling HL7 messages?
DR. HUFF: That's how it is in our institution. We have an entirely separate, we have an entirely separate server that is serving images up as opposed to the servers that are serving up clinical data, you know, from our electronic, from the more textual or numeric based coded base part of our electronic medical record.
DR. ZUBELDIA: Stan, this is Kepa. Help me understand this a little bit better. You mentioned that DICOM would be for image data but not for the structured reporting, at least you don't use it for structured reporting. In any structure, even things like the patient's name and so on could be sent with an HL7, and then have the image encoded either in the proprietary format or in JPEG or TIF as a binary object in HL7 and that environment would not be used other than just to store the data in the high resolution DICOM data server. Would that be a correct assessment?
DR. HUFF: I couldn't hear everything that you said, I'm sorry.
DR. ZUBELDIA: I'm coming to a speaker. It seems to me like the use of the DICOM server is to store high quality, high resolution with the gray scale, with some structured data along with the image, but for transmission you could as well just send either the proprietary data format or a JPEG or TIF encapsulated inside an HL7 structure instead of sending it as a DICOM with a little bit of content inside an HL7. So it seems to me like DICOM may not be all that important for transmission of data as much as it is for storage of those files in the DICOM - server. Is that correct?
DR. HUFF: Yes. Where DICOM, I think you described it accurate. We use DICOM as the format between the imaging device itself and its archive, and you are right, that allows us to keep and contain a high fidelity image, you know, according to what ever level of sophistication is available to the device. But then once we are now making that image available to the general network, and really as you think about making it a part of your electronic medical record, it would suit our purposes much better if there were a very general purpose rendering of that rather than the DICOM rendering of that image when you serve it up for clinicians to review and to integrate with web browsers and other kinds of web technology that allow integrated access to the data in the electronic medical record.
DR. OVERAGE: This is Marc. If I could add to that just a bit. I guess I view DICOM to some extent as being like HL7 in the sense that that's what vendors who create products that store images tend to have available and use. Therefore from a very pragmatic standpoint it is a very important standard because it is the only way you are going to get, in the near term anyway or the intermediate term probably, images out of the systems. It would be nice if, as Stan pointed out, the content of the images themselves were further standardized. But at least you can get at them and begin to manipulate them in a fairly - the common thread that lets you get at a large variety of clinical imaging systems without developing unique ways to get at it each time.
DR. COHN: Are there DICOM questions? I'm on a sudden different topic. Okay. Stan, this is a question for you. Can you hear me or do I need to come to your -
DR. HUFF: Yes, I can hear you.
DR. COHN: And I like to ask any of the others to also comment. During the day there have been a number of testifiers, including yourself, who have commented about overlaps between standards and others have used the term some duplication of, and it seems like the others have described these standards fee medical informatics and clinical data is getting pretty crowded. I guess the question is we know that historically there have been a number of efforts that some of us have been involved in to try to reduce redundancy and inconsistency between the various standards groups and their areas.
At this point in time, recognizing that we are a couple of years into this now, do you have any thoughts, and I would ask you, Marc, Steve and others of things that the Federal government or the NCVHS might do to help with this issue. Certainly we are seeing this in a number of venues, and I would actually probably the Script standard as another area where there might be some, at least inadvertent, overlap between the standards organizations. Can you comment?
DR. HUFF: Yes. Well a couple of things. I think there are natural ongoing collaborations. For instance, just in the last couple of weeks discussions have been initiated between NCPDP and their working group, Working Group 11, which creates, maintains the Script standard, asking the questions, you know, what is the same and different between those standards, and in fact the first work item from that collaboration is to say can we correlate the terminology for describing forms and routes of administration and other things. And then look at in fact making the information content the same between the Script standard and HL7.
As pointed out, the Script standard is sort of ideally suited for what it was created for which is transmission between a provider and a community or outpatient pharmacy. HL7 in fact has all of the same data fields to do the same thing, but it additionally has been created so that it can support more complicated orders than are supported by the Script standard. So you can support in HL7, you can support, you know, mixed split dosing insulin, orders in a coded way. You can support coded information if you are making recipes or drugs, et cetera.
And so I got probably into too much detail, but there are ongoing discussions between NCPDP and HL7, actually more than discussions. There is work going on to try and coordinate the information content. That is happening in other areas. DICOM actually meets, it is a joint special interest group where DICOM members and HL7 members meet to discuss imaging, images as it relates to DICOM and imaging as it relates to DICOM's integration with newer versions of HL7.
You know, I think a lot of it is happening naturally, and that is because, you know, for the most part the people who are participating are volunteers and they are like me and other people, they are just working for health care, either providers or vendors, and want to improve the quality of their products or improve the quality of patient care, and so there are not enough resources to go around. So people would rather work together and have a single thing. But there are areas of duplication and that causes friction at times.
I'm not sure what I would ask the government to do to try and help with that. I think maybe the most important thing would be to choose and adopt good standards and provide incentives for people to use the standards, and I think that will cause more interest and more movement towards consistency just by the fact that it is more officially adopted as a governmental standard. I would appreciate other people's, I would like to hear other people's thoughts on that too though.
DR. COHN: Yes. If there were a simple solution to this one, we would have figured it out long ago, any member around this room. Marc, do you have a comment before I move to people here.
DR. OVERHAGE: Only that I think that it is a fairly natural process. What seems to me happens is that a hole, a weak area in existing standards are identified by a group who have an immediate need to fill that hole, and then they start to fill that hole and they expand into the surrounding areas, and that is where the crowding perhaps, that term was used, occurs, and that is, as Stan said, a very natural thing. And I think the positive element here is that there is a good history of collaboration and evolution and incorporation so that we don't end up with conflicting standards for very long if they can be evolved together for good reasons.
DR. COHN: Steve, do you have a comment?
MR. WAGNER: Yes. The VA, being part of the government, sees one effort going on right now that could help very much in this area, and that is related to the NCHISB effort for a meta data registry or a USIC as it is being called, as a method to actually identify at least the duplication and overlap that is occurring and how significant it is, how wide spread it is, et cetera, by registering these message standard formats in the metal data registry so you can do easy comparisons and actually see where the problems lie and then use that as a way of identifying the high priorities at least, and beginning to have the SDOs themselves get together and address those.
DR. BERMAN: On behalf of Allscripts we certainly support common means of identifying drugs, patients, providers, disease states, across these various message formats. So I am in concert with everything that the speaker on the phone said.
DR. COHN: I guess I will just finish up with this comment before we go on to the next question, but just observing that there actually is a DSMO process that is in place for changes to currently existing standards. I think it is a little less clear about how it applies to new standards, and certainly the question also is whether or not all the right people are there to reach agreement as you move into some of these new areas, and certainly NCPDP is there, X12, HL7. DICOM however isn't there, et cetera. And the question gets to be like making sure that all the right players have signed off on something before it moves in and becomes a standard. Mike, did you have a question?
DR. FITZMAURICE: Yes I have a question for Clifford Berman. In your testimony you say we are satisfied with the Script standard message format except for some issues. And you identify them as common code sets, identifiers, and data elements. Could you briefly describe some of the issues around the common code sets, identifiers, and data elements as they pertain to the Script standard?
DR. BERMAN: Again, it is basically what I just said and that is common identifiers, ways in which to respond or refer to physicians, patients, drugs. But the message format we believe of Script standard is broad enough to encompass various options that are out there in terms of the length of the fields and the rest of it. But we would like there to be some agreement in the industry as to what those identifiers are.
DR. FITZMAURICE: Is a social security number good enough for individuals?
DR. BERMAN: That is one identifier.
DR. FITZMAURICE: Is that the most commonly used or is something else used more commonly?
DR. BERMAN: I'm not familiar with another identifier. I guess Medicaid numbers, I don't know if those are social security numbers also, I don't know.
DR. ZUBELDIA: (Comments off mic) If I can add to that, the - identifier question. That is a big problem.
DR. HUFF: I can't hear that discussion.
DR. ZUBELDIA: (Comments off mic) - identifiers because typically the pharmacy identifier issued by the prescription benefit - if not the social security number. They typically issue - identifiers that does not match with the - benefits. So the prescription cannot be easily matched with the hospital stay or the outpatient services rendered, and that has created all kinds of issues and that is one of the current discussions among the - members and - where the pharmacies are saying - is the ID number and the - are saying we also want to see the - of the patient so we can identify who this is, because - cannot be matched with the clinical stay. So that is a problem.
DR. YASNOFF: Bill Yasnoff. I have a question for Marc. Are you still there? You mentioned that you can detect reportable conditions earlier using you system. Can you quantify that in terms of how much earlier?
DR. OVERHAGE: Well we have two different lines of evidence there. One is we have an interesting natural experiment, I did not - start of infection, a Shigella outbreak in Indianapolis last year, which provided an interesting national experiment because we know the dates that the reports reached the health department through the traditional reporting process and through the electronic process. And if you look at the first month of the outbreak, it was an average of six and a half days sooner that reports were available to the health department through electronic laboratory reporting than through traditional methods.
The second bit of evidence that we have is in the process of doing a validation study where we are comparing data that the health department has versus what the hospital folks they reported versus what the electronic lab reporting finds. Overall, across all conditions, for a one month period, January of 2001, and this number is a little bit preliminary yet, it looks like it is about seven days earlier across the board.
So for some conditions that is not an important amount of time. For others they could be critical.
DR. FITZMAURICE: Marc, let me follow up with you testimony. You said a lot of good things about HL7. What difficulties do you have with HL7.
DR. OVERHAGE: I think the real difficulties as I mentioned really are the fact that the interpretation of the standard is not uniform, and that creates the majority of the work involved in using it. And in particular the fact that people may choose to either encode multiple components of the information into a single field or to use completely independent OBX segments to send the data, that really makes it difficult sometimes to sort out. You can overcome a lot of the other funny things that you see.
And then of course codes. I thought we were focusing primarily on the messages, as Stan said, the codes really are one of the major issues, and doing our city-wide projects would have been much easier if we hadn't had to deal with mapping all of the vocabularies, the terminologies of these different health care entities to a common one, life would have been much easier. Many of us will spend a substantial fraction of our last year or so pouring over those kinds of mappings, and that is a huge effort and a huge issue. In other words the method standard is very adequate, but the fact that the codes are different makes life very hard.
DR. FITZMAURICE: Thank you Marc. Jeff?
MR. BLAIR: Stan, can you hear me?
DR. HUFF: Yes.
MR. BLAIR: Okay. Maybe Stan and Marc and Clifford, you could help me with this a little bit. You know clearly the prescriptions from, or medication orders from a physician to a retail pharmacy has pretty much the same information as it might have, or you know, there's an overlap in terms of much of the data element content, whether it is to an in-house pharmacy with an acute care institution or to a retail pharmacy. However, there is clearly a lot of differences in the general types of orders.
I was under the impression and maybe I am completely wrong, I was under the impression that when a prescription is sent to a retail pharmacy, NCPDP was used. When it was sent to an acute care institution pharmacy, in-house pharmacy, then HL7 was used. Is there examples of where HL7 is used to send messages to a retail pharmacy?
DR. OVERHAGE: This is Marc. I think, as Stan said, I think we are not currently electronically sending data to any retail pharmacies that are not affiliated with the hospitals directly, and we actually do, interesting that for the fax thing, use HL7 to send a message from the clinical system that generates the prescription to a system that generates the fax to the pharmacy, and that message is in HL7 format.
DR. HUFF: I would agree. Again in our institution we are not using a coded, you know, electronic format to transmit orders or prescription from our physicians to the outpatient pharmacies. Those are happening basically as faxes, and the data is handled internally in HL7 messages in the same manner that Marc has described. So you know, I mean there are, we do use HL7 to our outpatient laboratories, excuse me not outpatient laboratories, our outpatient pharmacies, but those are pharmacies that are actually, outpatient pharmacies that are still - use these facilities, they are not community pharmacies.
So the message structure is correct, but we are not currently using HL7 or NCP, you know, or the Script standard to send that data to outpatient, you know, community based pharmacies.
MR. BLAIR: Dr. Berman, could you help us?
DR. BERMAN: Yes. In terms of, you know, Allscripts and the rest of what I call the outpatient providers, it is Script standard exclusively. You know, that is not to say the HL7 couldn't be developed to work in that market, particularly the prescription ordering aspect of it, but Script standard already has the fine transaction types, the message types for refill requests and responses to those change requests for generics, for therapeutic alternatives, the elite types of transactions that happen in the outpatient side frequently, so just already in place, and it has already been adopted by those pharmacies that have.
And virtually every pharmacy has Script standard for adjudication, so there's certainly some benefit to utilizing the Script standard for all of the pharmaceutical transactions, whether they be adjudication as they are now, or whether they be Script standard, and something in the future called pre-adjudication, where a prescriber will pre-adjudicate a claim to see it unwinds, to see if the drug is covered by the benefit plan et cetera. So a lot of reasons to support Script standard in that realm.
DR. COHN: Sorry Steve, did you have a comment?
MR. WAGNER: I did want to add one more thing to it, an example from the VA basically. We have created consolidated mail-out pharmacies which essentially performs a lot of the same functions that a retail kind of pharmacy would perform for our patients. And they handle basically all refills of prescriptions for all of our patients at this point in time, which has been very cost beneficial. And those transactions from our medical facilities to the consolidated mail-out pharmacy and back are in HL7 format.
DR. MC DONALD: (Comments off mic) I kind of got a question. The general issue, and we almost - kind of work in standards and really don't care about brand names that much, - just have one unified whatever - is you can always grab a hold of - and say this is why it should be this way. And so, and I'm not just agreeing with what you said, but you could say well because a pharmacist, convenient for the pharmacist, they should do this, but the physicians who are writing into their hospital into the pharmacist, I mean, somewhere when you've got these triangles somebody gets screwed or has a harder time of it.
So I think what, the NCPDP we work with them, and it is really a good group, and the hope is that you can get them overlaid enough that it really wouldn't matter, you know, the content and the structure be similar enough that - one way or the other way and everything still works. The challenge is, and this is not anything against any of the standards groups, it is that when you have different groups of people looking at different rooms, they come up with different ideas, and it is like kangaroos in Australia and, you know, reindeer up in Alaska or whatever, they just come out different. And they all can't meet together. So that sort of, it is really a political thing till we get to the point where we could get those kangaroos to mate with the alligators or something. You know, we would end up with just one nice uniform.
But I think NCPDP has been trying to work that way, so I think we ought to hope for is we get these things that the patterns were not the same, that one used this kind of thing and one that kind of thing in terms of the mechanism below, that is just computer work, and you could end up with making life easy for any parts of the triangle.
DR. BERMAN: Right, and as I said, we are totally supportive of that. I don't think anyone wouldn't be.
DR. ZUBELDIA: I have a repeat of a question, but I will use - for anybody else. That is where do the testifiers think we should stop the recommendations. Should we stop at HL7 or stop at a specific version of HL7, or go down to an implementation guide. From what I have heard, both Marc and Stan, I think they are both looking to have specific implementation guides maybe for the messages that have a shorter term investment over the - that we discussed before in the subcommittee. I would like to hear from all four testifiers, what is your recommendation?
MR. BLAIR: Well with Kepa's question, could you specify when you answer his question whether you are thinking of Version 2 or Version 3 when you are talking about what level you go down to?
DR. BERMAN: Cliff Berman for Allscripts, Allscripts standard, and I mentioned this briefly during my testimony, the concern with obsolete versions, but actually it goes both ways. You heard from Steve that VHA is at the 3.2 standard on the telecommunications side for adjudication, when the HIPAA standard is 5.1. We also support 3.2 in our adjudication end of our business, and in fact we are not aware of any pair that supports 5.1, and so basically it is universal that 3.2, you have the standards as 5.1, so that is going to force everyone to upgrade.
DR. ZUBELDIA: You've got me confused here. If in the Script you work on 1.5?
DR. BERMAN: Yes, I understand. There's Script standard and there's an adjudication side. So I'm sort of making the point it can be set too high. In the case of the existing telecommunication and adjudication, it is at 5.1 and administered at 3.2, forcing everybody up. The other concern is if it were set too low. So if you were to set it at a version, you know, 1.5 and mandate only 1.5 and there are versions above that, that is a problem. So if Script standard, here's a history of their changes, they've had a 1.2, 1.3, 1.4, 1.5, 2.0, 3.0, 3.1 and 4.0. So if you peg 4.0, which is what I believe was on the table, that will quickly be obsolete. I don't know how quick your mechanism is to change that.
On the other hand, we also heard that the industry is at 1.5. So by setting 4.0 you would force everybody up to that standard who haven't decided on their own, from a business case perspective, that it was worthwhile for them to upgrade to that. So that is why we are suggesting that you take the approach of the model of the version that is currently being used in the industry, which in this case is 1.5, and all subsequent versions. On the adjudication side that has already been done, but that would have been choose 3.2 and all future versions.
So we think you should go with what, where the industry is and leave some leeway for further versions.
DR. ZUBELDIA: And develop a standard implementation guide or just standard?
DR. BERMAN: Well you mentioned the versions. Implementation guide, are you talking about administrative versus clinical, that question before?
DR. ZUBELDIA: I'm talking about reducing the optionality to having practically a zero optionality. Should the standard be something that has really no optionality or maximum flexibility?
DR. BERMAN: I guess that, that was the question of administrative versus clinical. Obviously we believe that a prescription and all the communications between a physician and a pharmacist are clinically based. They are not about adjudication and payment, they are clinically based. On the other hand, based on the definition that you provided, and I'm not very familiar with the administrative definition to the extent that that is a more rigorously defined definition, we think that's consistent with the Script standard in our prescription setting.
So I don't want to say that's not a clinical transaction in the common vernacular, it is, but it sounds like by HIPAA speak, an administrative transaction might be more of what a prescription is, and in that regard, we are in line with what Jack says from ProxyMed.
MR. WAGNER: Well the VA perspective I would probably have to ask a couple of questions back. There are two significant things buried in here. One Jeff asked which version of the standard would we recommend, and my question back would be what is the timeframe we are talking about.
MR. BLAIR: Let me refocus. Kepa's question was on levels, and he was winding up saying should our recommendation be at the level of identifying an SDO organization per se independent of versions, or does it go down to recommending a version within and specific message format transactions, or should it go down to a third level, down to the area of also specifying an implementation guide to support those. And my only comment was that if you are going to recommend going down to the third most detailed level, please indicate which version you are talking about when you do that. Kepa, is that consistent with it you?
MR. WAGNER: That still wouldn't answer my question. If I want to go down to the implementation guide level, I still need to know what timeframe we are talking about actually doing an implementation here. If you are talking three to four years out, I might say Version 3 of HL7, and if we are talking within the next 18 months I would probably say 2.x. The second point I would make is it also depends on whether or not you are talking about a series of standards that are backward compatible or a change to a standard that is not.
So if we are talking a series of standards that are backward compatible, then you can say a Version 2.2 or later version and that would be fine, and I would drill that down to have implementation guides for each of those versions that you would then follow. If on the other hand you are talking about a standard like Version 3, which is not backwards compatible with the rest, then you better be specific as to Version 3 and I'm not sure you are going to specify "and later" versions at this point in time. It depends on whether or not HL7 is willing to make the at least commitment to try and make subsequent ones backwards compatible.
DR. ZUBELDIA: Marc?
DR. OVERHAGE: To answer the most recent version of the question if I can, I think that, I would think that we would want to direct ourselves towards standards developing organizations rather than specific standards, because the standards evolve for good reasons and not in a vacuum, and that one has to evolve with them. I could imagine specifying a minimum version number for the purposes of HIPAA that one wants to tolerate if you will, given that you can't do them all. So there may be a minimum version number that would be acceptable.
And I think that the SDOs in general have recognized the areas where there are opportunities for interpretation in the standards and are moving in the direction of narrowing those boundaries themselves as the standards evolve. And to some extent you could say whatever you want, you could say okay, there's going to be an implementation guide and there's going to be Version 2.2 of HL7, and the realities are that is going to take some time for the market to catch up with.
It is not easy for those vendors to change how those messages are structured and delivered. And so the timeframe question gets tangled up a bit with the desired timeframe and what you specify. And so I tend to be a bit of a realist and think that we need to work with that, what's out there and available and we could begin to build on, rather than stuff in some nirvanas that we may never get to.
MR. COHN: Stan, do you have a comment?
DR. HUFF: Yes. I think that we need to specify a specific version of the standard and implementation guides. I think that is the only way that you will get to a level of interoperability that will be truly beneficial. So, you know, I'm pro in fact specifying things down to the level of implementation guides on a specific version of the standard.
I think echoing what others have said, what I see a need for in addition to that is to specify a process whereby this evolves, and whether that you are saying, you know, identifying in addition a particular organization and saying, you know, some future version that we are evolved from Version 2.2 to 2.4 at some point in time or how that happens. But you see the thing that, I really think what we need to describe a process for is saying whether you are going from Version 2.2 to 2.4 or you are going from Version 2.4 to Version 3 of HL7, what you want to do is have an orderly process defined for doing that.
And so the kinds of things I am thinking about are even though we, at a particular point in time, we are specifying exact detail in an implementation guide about how we do the pharmacy order or a lab result, I think right even as that is happening, there needs to be a set of people both in the government as well in the standards organization as well as in enterprises that are in fact doing real implementations of Version 3 and that's a recognized part of what is going on.
So that, you know, if there is Version 3 and some other standard that looks like it could be better or, I mean, we have to be doing experiments with the new versions, and that should be a recognized part of the process, so that we don't come to the point where we're adopting new standards that have not had implementations and really basically adopting them blind based on good design but no practical experience in the field.
So I mean I think we need to have a methodology that says this is the standard and for everybody in the United States that the way you expect the data to be sent, and with the exception that five percent of these people are actually going to accept it in this new form, and that those prototype systems or those, you know, the people who want to work on advancing the standard, that's a recognized part of the methodology and supported, so that, you know, people don't find themselves having to adopt standards that haven't been field tested, and that the people who are doing the field testing don't find themselves in non-compliance because they are trying to move forward with the new verion of the standard.
I think that the worse thing that can happen is if we fix on a level of the standard that doesn't allow us to do field test of Version 3 and in fact maybe broad implementations within given enterprises of Version 3, so that the bugs can be worked out of that and in fact we learn the practical issues that we need to in perfecting that standard.
DR. BERMAN: I guess the question is, you know, does that presuppose that the newest version is always the version that should be the one chosen, and of course there is always a newer version after that. So if the decision is made that it is 4.0, there will soon be a 4.1, so what mechanism does the rule have to address that and to be timely.
DR. COHN: (Comments off mic) That certainly gets me to the question of the process of the acceptance of the standard. Stan, and like I said, and probably Clem, I need a little bit of guidance in terms of my own thinking about all of this stuff, and I will apologize that I need to show some of my ignorance over a basic level about HL7, but I've been listening to the testimony and obviously been thinking about this now for a number of months, about whether one size fits all for all os this, and - I think a first cut when we said gee, some things should be - considered by HL7 as maybe - in some way being acknowledged or otherwise by the Secretary, and other stuff probably isn't quite ready.
So maybe there is a question, at least I have in my own mind, and I guess I am thinking to many health care entities, where - in the environment, users, probably some interfaces that they have which I would say very quietly probably aren't even HL7 compliant and others that are using versions 2.1 and others that are 2.2 and others are 2.3 and some of these are using - segments to sort of put things together.
And at the end of the day the question I sort of scratch my head about is yes we can do implementation guides, we can either require or not require compliance, but I'm sort of struggling with the business case of making all of that happen.
Then the other question is however that there may be some, and I'm going to say may be, in HL7 standards that we are describing that aren't just primarily between my local nursing station and my admitting department or other lines, that maybe transcend organizational boundaries in some way, well gee, somebody else cares - like this outside entity that cares, and we see an example of that when, with the Script, whether it is an HL7 or an NCPDP. You have a provider that is different than a pharmacy, if this stuff is going across sort of via interstate commerce or intrastate commerce, where everybody suddenly cares a lot about implementation guides and - being very specific and exact.
Now I guess the question is that if you are going to look at the HL7 standards that we are talking about, are some - organizational that there isn't much of a business case here, and others maybe more likely that they may occur across entities that we might use as a way to judge. Clem, I'll ask you the question first, since you are - on this.
DR. MC DONALD: I think that the HL7, although there's different chapters with different content, they all use the same data types, they all use the same syntax, they all use, I mean there is a lot reuse throughout it, so that dividing them up by chapters is probably not real helpful. I think if, I have assumed all along that we would not achieve standardization in the clinical world at the same level of discipline or severity that we tried to in the business world with nine transactions, because it is more complicated, because it creates backlash, because of all those kind of things.
And that what I would suggest we would want to think about doing is recommending saying at least this and this is the ideal and give things to target for, and then the recommendation would be that the agencies, the Federal and the state agencies would take advantage of that in the various ways they work with users. And so either by requiring in the environments, which then sort of stimulates the industry by saying when you send us messages about X you should send them in this format at this level of standard, that is the way we do it more gently, by pull and by push, and you don't have to worry as much about the hard edges.
DR. HUFF: I would agree with that, and this is Stan. I think, in my previous testimony I basically made the same argument, that the place where this makes the most sense and the place that there is the greatest business case is in fact when you send data outside of your own enterprise. So that is when you are sending it to a public health department or when you are participating in a clinical trial, when you want to send clinical data as part of claims attachments, if you want to send data to HCFA for Medicare case review, that is where there is a huge benefit and business case for doing the standards, and that's where we ought to start first.
I mean you take the HCFA Medicare case review, all you are doing now is essentially zeroxing or photocopying, you know, the patient's record, and sending it to somebody who then has to review it, and you are talking about spending, you know, the copying cost plus the person cost to have a personally manually read, if it is legible, the paper copy of that record.
If these standards were properly constructed, we have the data that HCFA wants to see in an electronic coded form within our system, and we could send it electronically for ten cents a record or something. I mean two to four orders of magnitude less expensive to communicate that data. And that is where we should focus.
I think the second situation that shouldn't be overlooked though is that in the business case that comes from these standards, it accrues to the providers. If IHC is buying new systems and we knew that the new systems were compliant to the standard, it decreases our cost to purchase, install, and implement the standard. So we can move faster to get the data in an electronic form and to create a more integrated electronic medical record because of the standards as well.
And so that is a business benefit that accrues to providers and purchasers of software that, you know, might not be manifested in the same way that say the data exchange to public heath departments and to others would say. But yes, let's start with the places where there's a clear business case, and I think there is a very clear business case where the exchange with almost all government institutions, public health departments, clinical trials data to the FDA, claims attachments, you know, as part of reimbursement, and then the data that goes to HCFA for Medicare case review, those ought to be things that there is a clear business case and clear savings to everybody.
MR. COHN: Clem I think is going to answer a question and then Jeff.
DR. MC DONALD: Yes, just to elaborate a little bit on it. Again if we think of this as saying that we are going to set up and ideal but not a - ideal, I mean I may say 2.4 in a year and we would have a review process as always, and with as good an implementation guide as we can do, and/or conformance specifications. And then we would say this is a target, this is what people should be aiming for, but no one is going to go to jail or be punished, penalized.
But now what happens is if the VA is contracting out for laboratory tests, they say you've got to send us in this one. The prisoner systems, I mean the Federal prisons, there's lots of areas where if the Federal government was encouraged to aim for that target, the industry would thin to it. And then in addition, if that's up to sort of the standard, you might well find a large HMO saying well we want to get it sent according to this, you know, this is exactly by the book how we want it, just by the Federal standards.
So I think you would find a natural but not too fast, whatever would really work for the industry, acceleration by that kind of a strategy.
DR. COHN: Well Clem, let me ask just one follow up question and then Jeff has a question also. A question about the claims attachment which I know you are pretty familiar with in terms of the implementation guide, and I sort of know there is an implementation guide for that. The question was, which I don't know the answer to, is how specific is the, since this - example for an HL7 transaction, or HL7 data, how specific is the data described in the implementation guide around the HL7 piece of all of this?
DR. MC DONALD: Well that is a long subject. It is very, very specific in a sense, but then in a sense you say this is the, it's a highly defined typically business case about endless attachments, and there's 55 attachments documents and you can go through the 55 attachments documents and look at 200 variables and it boils down to 18 or 20 and then the dialogue discussion about, that is the value of that process, which then can involve all of the standard groups. But that's still, I think that currently is in the NPRM think stage or maybe stage.
DR. HUFF: But overall the answer to your question is that it is a very specific implementation guide.
DR. COHN: So we can mark that one off of this.
DR. ZUBELDIA: But it is not one very specific implementation guide. It is a very specific implementation guide with multiple HL7 look ups for multiple applications on that one guide. So it goes down much better than the current X12 implementation guides into specific applications of the implementation guide.
MR. BLAIR: Marc and Stan. This morning we had testimony from a number of folks and there was at least some degree of convergence on some of the thoughts and directions that the NCVHS might take in terms of its recommendations, and I would like to see if I articulate this in a little bit broader manner to include the thoughts that both of you just expressed and Bill Yasnoff also has articulated to us. And let me see if this begins to encompass things that you either agree or don't agree on for direction for NCVHS.
And I'm going to start with Chuck Meyer's comment, Chuck Meyer from McKesson. He was referencing the fact that we should consider a dual strategy, and this expanded a little bit, but the essence of the dual strategy was recognition of those message format standards, and of course HL7 has many of them, that are virtually de factor standards in terms of their market acceptance, where many vendors and users have made a lot of investment and there is not a business case right now for changing, and for the NCVHS recommendations to recognize these things in a manner that none of these organizations are compelled to change in those areas.
Now he also had another part of that strategy, which was to recognize that there's areas for increased interoperability, for the use of clinically specific terminologies and data definitions, whereby it's a lot of the things that HL7 has identified for Version 3 that it would like to move to, and take advantage of the PMRI recommendations numbers three and four, which were addressed at accelerating the development of standards and having government support and assistance for making those standards easier to implement, mainly that in addition to the first piece, which is recognizing as de facto standards the existing ones, that in terms of for example Version 3, that to assist that we might be looking at Federal funding, as in recommendation four, or Version 3 implementation guides, conformance testing, government licensure of clinically specific terminologies that would, you know, help lock that in, maybe related back to the reference information model it also begins to help, and support for that.
And Bill, I think if I were to tie it in with some of your comments in terms of CDC needs, you just were referencing that one of the business cases or incentives to support this would be certain needs that public health and CDC has for more clinically specific information, information more quickly, that some of those, whether that's NEDs or immunization records or other public health things, that that might flow into the areas where there's government incentives that would strengthen and make Version 3 quicker.
Now that I've gone through this speech, specifically Stan and Marc, do you feel comfortable with this, or does this or not?
DR. HUFF: No, I'm comfortable with that. I mean I think I would say specifically, you know, in recognizing de facto standards that the ones that are under consideration, you know, I think the things that are there that are in use are HL 7, Script, and DICOM, and those are the ones that I think you would want to recognize. And I think that is a good strategy, I mean recognize those things and I think as part of that again I would just say that some of the benefit of that is going to come in making implementation guides on that.
And at the same time, you know, the second prong of that, moving forward with support that would realize the benefits of Version 3 earlier, is likewise a good strategy. You know I think if we are going to learn a lot we need to get some input - and that's a reasonable strategy to accept what we can and start funding to accelerate some of the things that we know that we are going to need in the future.
MR. BLAIR: Marc, Steve and Bill, do you have comments on that?
DR. OVERHAGE: The only thing I might add to Stan's comments are that as we move in those directions though, it is not just changing the messages and so on that we are talking about as we talk about vocabularies and terminologies. It is much deeper than that because, for example, the microbiology system that is used to interpret the response of the various antibiotics of a particular organism, how that data is stored and structured in those systems will be fundamentally impacted, and that is going to be a slower cycle. So I think we've got to recognize that those changes we are talking about, in order to get data out of those systems in say Snowmed as an example, means it is going to be encoded that way to begin with, and that is not going to be a quick change, because that is changing how people's work flow and the guts of some of these systems. So I think that will be a slower process, valuable but slower.
DR. BLAIR: Steve or Bill?
MR. WAGNER: I would agree with both Marc and Stan's comments. I don't really have anything more to add t that.
DR. BLAIR: Bill, are you comfortable with the way I characterized?
DR. YASNOFF: Yes. I would like to suggest a potential framework to help us think about this. It is clear that we are struggling with if the question in front of us is what single standard, what single message format standard do we recommend for adoption, we are struggling with that question. And so what I would suggest is that perhaps that is not the question we ought to be asking ourselves. And perhaps we do need to take into consideration what several of the testifiers have said, which I agree with, which is that standards is a process and so we can't do the analogy of saying all the electricity is going to be 115 volts and we are finished. That is not going to happen.
It is tempting in message format standards to think we can do that, but in vocabulary we absolutely could not do that because the vocabulary itself changes as our knowledge changes. So vocabulary is not static. So in view of that, maybe we should take a framework that has been used for other technology related standards, which is to essentially have three standards. There's the, maybe one or more of the old standards. In other words things that if you have them, they are acceptable, you can still use them, but you shouldn't implement them for anything new.
Then there is the current standard which you are expected to have, which is fully supported and so on. And then there is the future standard, which is what everyone is working toward. There might be incentives for it and so on. And that there is a gradual migration so that the old standards have a deadline, a certain number of years they fall off and are no longer supported. The current standard becomes the old one, the new one becomes the current one, and there is another new one. And those periods of time can be adjusted appropriately depending on the standard and how fast it needs to change.
So for example in the message format standards area, we might recommend that HL7 Versions 2.2, 2.3, and 2.4 are the, or maybe we should say 2.2 is the old standard. If you have 2.2 or 2.1 you should keep it, don't throw it away, it should be supported, you should be able to send data back and forth with that, but don't implement anything new. If you are implementing something new, maybe the current standard should be HL7 2.4. But that the place where we are going clearly is HL7 Version 3, and there should be incentives to move people to HL7 Version 3, and by the way, those of you who are using 2.2 and 2.1 have to recognize that X number of years from now, that is no longer going to be supported. You are going to need to move along the continuum.
And this is a model I think that maybe can be effective and give people predictability and help move things along, because if we don't set up a system where people, we can move along, we are just going to be back here debating the same issues again and again and again as we keep changing the standard, and I don't think that what we want to do.
MR. BLAIR: I would like to have Clem's opinion on this multi-phase strategy.
DR. MC DONALD: Well it has sort of got motherhood in some ways. I can't disagree with Bill. But I worry that that is very much like the style of the first nine standards and I worry that it will impede progress because it will be a backlash in by saying to people this is what you've got to do and this is what you are going to have to do, it is a different way than saying, I would rather set out saying currently we say 2.4 is sort of the ideal and there's new things coming, and we don't say you must to anyone, not any American and at the low level of the industry.
We would rather say the government will provide, will be encouraged to use it and to encourage its use in their kind of communication. I'm not sure what the detail of that is, but some way where you are sort of, it doesn't look at scary to the industry. I'm just afraid that if it comes out looking like sort of a doctrinaire, you're going to hit - that we would have backlash. But I like it. It is just a matter of whether we -
MR. BLAIR: We are presenting it in a, maybe thinking it through.
DR. MC DONALD: Well see the other one it says you are going to have penalties, you are going to be punished, you've got to do it by this date and all this other stuff. That I don't think, you may have a tough time selling that. Whereas if we said this is the ideal and there's going to be a lot of government encouragement to the agencies to find ways to incent this. However we state it, I think that might work better.
MR. WAGNER: Just a comment from the VA. I have to lock what Bill was saying because it mirrors a process that we use for what we call enterprise architecture in the VA, and we believe that your architecture has to be evergreened, it has to continue to grow, and so within that architecture we have retiring standards, current standards, and emerging standards, and you try to have a floating window of time across those standards when you will try to retire certain ones by, adopt new ones, and investigate new future standards. It works fairly well.
DR. ZUBELDIA: The - standards have something that they call marked for deletion and they have some things that are still in the standards book, they are marked for deletion, you better not implement it (laughter). I think we also need to consider along with this evergreen approach, but also what is going to be the use of the standards and for whom, and whether it is enforceable or not. If there is going to be standards defined for interchange of data between outside entities and the health care institution, such as reporting to Medicare, reporting to public health and so on, that is a level that can be readily easily verified and enforced. Standards for use by a life health care institution for use internally, life health care institution, is probably outside of the scope that can be enforced in any meaningful way. So I think that is another consideration.
DR. MC DONALD: And again, if we kind of defined what's sort of good, I think what you would find is an organization taking advantage of that leverage when they are contracting or whatever, so you'd come up with some good things.
DR. YASNOFF: I would be interested in comments from Marc and Stan while we have them on the line, about this framework.
DR. HUFF: I agree with both comments. I mean I certainly agree with the evergreen concept or the concept that Bill put forward of basically saying this is the standard that is now obsolete, this is our current target, and this is our future target, and have windows of time that are set on those. And I guess I, I wasn't even thinking about the things that Clem brought up. You know my view is again that we should offer incentives to move to those targets, not penalties and not trying to throw people in jail. So I really like the idea. That is the sort of good idea that I've been searching for and couldn't think of in terms of how we define this thing as a process, as an ongoing process that gets adjusted over time, as opposed to something that gets cached in concrete and becomes a ball and chain around our leg that keeps us from moving forward to better ideas and better versions.
So I really like the idea of having sort of what, our current target, a future target, and maybe a recognition of where we were or where we have been, and incentivizing people to move to those. Again I think it could be things where you say, you know, you can either photocopy this stuff to us or we'll pay you a dollar or 10 dollars or five dollars a case to send it to us electronically in this format. And I think you would have tremendous movement based on those kinds of, you know, bees to honey incentives as opposed to penalties and threats of fines and incarceration if people didn't move.
But I really like the idea of the past, current, future, the evergreen philosophy, I think that is great.
DR. OVERHAGE: The other advantage I see to that approach is that it gives the vendors a direction to say we know that if we implement Version 2.4 somebody wants it, and there's some additional value to it. There's a business case for the vendor, so hopefully if they have the future or the current standard implemented, they may compete better in vendor selection, and offer that advantage.
And the other way I that I think besides the monetary things that Stan suggested, that we incense people by making it easy to go that route, by having the implementation guides and those things, making it easier for people to go that route. And that is another powerful incentive. Everybody likes to take the easy way out, and if we can show them a path that is not as difficult to follow, they are going to follow it I think, unless there is some strong reason not to.
DR. COHN: I want to thank the panelists for their assistance with this particular work. I think it is time to take a break. We will take a 15 minute break.
(Break)
DR. COHN: Go ahead please.
MR. BLAIR: Well first of all, who do we have here? Is Michael here?
DR. FITZMAURICE: I'm here in front of you.
MR. BLAIR: And Bill? He went upstairs. Kepa, are you with us?
DR. ZUBELDIA: I'm here.
MR. BLAIR: Okay, it is the fantastic Musketeers here. Well let me just ask you first, and maybe I'll just go around to each of us in terms of what you, my thought is in terms of do you see a convergence on recommendations, and you may wind up saying there is one or two or three areas of convergence, and Kepa, can I ask you for your thoughts as to where we might be finding consensus on recommendations, no, we will have some more testimony tomorrow morning, right.
DR. FITZMAURICE: Yes. Well we have two scheduled and there's another one. Steve Horey is coming in from it is either the University of Pittsburgh or the University of Penn, to testify on DICOM.
MR. BLAIR: Okay. Kepa, what are your thoughts about areas of commonality or convergence on a set of recommendations that we might be able to reach here.
DR. ZUBELDIA: It looks like everybody agrees on HL7, that we reach the agreement. Everybody agrees that there has to be some sort of standard for nomenclature, common data dictionary or something like that. Also there seems to be a need at least for some of the transactions to have an implementation guide that is very well defined. Not everybody agreed on that though. Some people would rather have an open-ended adoption of a standard, even going to just say open-ended adoption of an SDO rather than an implementation guide. But I think that at least for some of the messages, an implementation guide would be a way to go. And I think that is an essential set of agreements that most people agreed to.
MR. BLAIR: Simon?
DR. COHN: Most everyone agreed with the evergreen concept that I think Steve Wagner described, and it might be actually interesting if we went back and asked them that were arguing about the difference between more open-ended or tighter implementation guides and layered this on top of it, whether or not people would be so, whether the issue of more open-ended standards would be such an issue at that point.
DR. ZUBELDIA: I think you've got a good point there. I think most people when they were thinking about open-ended standards were thinking about one size fits all, and there is a very tight implementation guide for some messages, and then an open-ended evergreen approach for everything, and a completely open-ended for other messages that are not standard. I think that would be more in line with what they are talking about. I'm not sure that they are all talking about the same thing when they say open-ended.
DR. FITZMAURICE: I think I heard support for HL7, strong support for HL7. I heard support for DICOM. I didn't hear very many negative comments about DICOM. I heard good things about Script and didn't hear any bad things about Script. So I guess I would put those up there for consideration. I didn't hear that the other standards were used very much, and indeed the Script standard may be used by I don't know, 500 physicians in the country. I didn't get a good handle on the volume of use for the Script standard.
And also I heard that there could be overlap between Script and DICOM. They could probably get along pretty well, and that they are talking about how to get along even better.
DR. COHN: That's in HL7.
DR. FITZMAURICE: Beg your pardon Simon?
DR. COHN: That's in HL7 I think.
DR. FITZMAURICE: I'm sorry, Script and HL7, you are right. In the break I heard more support for Bill's concept that Steve labeled the evergreen process, identify here is the current standard, here's the old one, it still has value for many people, and here's the new one that is coming along. So that is more directly what I heard. Indirectly I heard a continual need for vocabulary, terminology, codes, and I think that that has to be sorted and settled up probably somewhere beyond this. That gets very complicated, and the interaction between codes and vocabularies and just what is needed for drugs versus what is needed for recording clinical notes is something more complicated than I think we might be able to come up with recommendations even to the Secretary in a letter.
I think Simon has mentioned he would like to have a year to study that, 2002, and maybe we can talk more about that in future directions tomorrow or in December.
MR. BLAIR: I think we have plenty of good things to say to the Secretary. I don't know that we have a statement that comes out saying this should be a HIPAA standard, because even it you choose HL7, which one would you choose? So that needs more discussion among us, so we are thinking, but we are getting very close to being able to say to the Secretary here is what we heard and here's some things we think you ought to do, ought to consider doing.
MR. COHN: I think I was going to add a little bit, that I think I was also hearing that people were generally against strong regulatory dictums, the more I think people described as trying to create incentives, benefits to moving forward, rather than somehow requiring that people have to do X, Y, or Z. Though that I think varies a little bit about on whether it is all an internal organizational standard or whether it is something that is involved more with the exchanging of information. And we heard a number of examples of Clem's attachments, sending things to the government, I can't read my other handwriting as usual, clinical trial data, et cetera, where there's probably a good rationale for there to be tighter use of the then prevailing standard and the data requirements related to it.
DR. FITZMAURICE: Simon, would you agree that several people said that the role of the government is to lead and to support. I didn't hear them say strongly enforce.
DR. COHN: Exactly.
MR. BLAIR: If I may, I think I have heard three major areas that maybe we need to come to consensus among ourselves on from your comments. One is which of the message format standards are on the tables. Number two is what should be the language we should use to recognize each level of the evergreen stair step. And number three, what would be our next steps with respect to terminologies, data definitions and all.
And on those first of the three areas, if this is correct, there seemed to be easy acceptance that HL7 is on the table. There also seemed to be general acceptance that NCPDP Script standards between physicians and retail pharmacies is on the table, and that DICOM is on the table. And the ones that, I seem to hear that probably OMG's CORBAmed is not on the table. The other piece that seemed to be an open issue is we didn't hear a lot about IEEE's standards for medical devices, and my thought is I'm not sure that that should be off the table. We just didn't hear a lot about it. What are your thoughts on IEEE or CORBAmed?
DR. YASNOFF: This is Bill Yasnoff. On IEEE, I think this relates to Kepa's comment about whether we are talking about standards within an institution or standards for exchanging data with the outside world. I don't think too many people are using the IEEE standard to exchange information with the outside world. That's just not what it is for. It is for devices within an institution. I mean I'm not familiar with the details of the standard, but I would guess that there is a distance limitation on how far you can send the information on an IEEE bus, that probably is consistent with instrumentation. So I think that's why we are not hearing about, because it is just not an issue in terms of inter-institutional communication.
MR. BLAIR: Okay, but nevertheless it is one of the first points of data capture of clinically specific information and especially in intensive care units. Should we not say anything about it in terms of our recommendation?
DR. COHN: Well I think without some testimony that it is being used or desired, it is hard to make a statement, and I think if we want to move forward on it we need to elicit some testimony from people who are users.
MR. BLAIR: Get additional testimony.
PARTICIPANT: Yes, these vendors are not the ones that care about that standard. We need to get the, I mean we need to have somebody from IEEE come and talk to us about it, and people who are manufacturing instruments that use that standard, to talk to us about it and then we can decide what to do. So I'm not willing to say whether we should do something with it or not, but I certainly wouldn't be in favor of doing something now. We just don't have the information.
MR. BLAIR: Okay. Now we did have an individual from IEEE testify to us, and Michael I think that you contacted that individual to try to get the names of users, and that you didn't get any. Is that right?
DR. FITZMAURICE: I wasn't very successful at getting names of users of that standard. It is a question of which standard it is or if it is embedded in one particular company's product, and that company's product talks to another one of its own products, and that is what is sold to a hospital, particularly for intensive care units for example. Then the users, it may just be transparent to the users. They may not be trying to link one company's product with another company's product at this point. I think the standards are still early.
MR. BLAIR: Well do we settle on Simon's suggestion then that until we are able to get additional testimony relative to IEEE medical device standards, that that is not on our table until we can get that additional testimony?
DR. YASNOFF: Yes, but also I would suggest that maybe that is not, should not be one of our highest priorities, because it doesn't represent a burning problem for people that we have heard from.
MR. BLAIR: Okay. Now -
DR. ZUBELDIA: I have a question maybe at a different level, and maybe we need to get guidance from the Department on this. What are the covered entities under HIPAA or PMRI? Are they - providers and clean houses (laughter) covered entities, or are the vendors covered by this, because the vendors are critical in all this process. And I think we need to get some guidance on that and see where we go, what approach should be take, because I think it is important to know that.
MR. BLAIR: How do we get -
MR. COHEN: Well Kepa, I don't think you can reinterpret the law. On the other hand, there is really no law about this particular aspect. This is a set of recommendations that is being made that will go where they are, go where they go. The only thing in this whole list here that really looks like a HIPAA sort of one recommendation is maybe a Script standard, maybe. But I'm not sure we need, we think about these things quite the same way, in the sense that we are not, I don't think the issue of covered entities is a germane one really.
DR. ZUBELDIA: So it would be more a recommendation for a future law on something like this or just for action by the department?
MR. BLAIR: Providers are already covered entities and all of the PMRI standards would be used by providers.
PARTICIPANT: I think this point, that the HIPAA law does have criteria in there whereby the Secretary can adopt other standards as HIPAA standards, and it would probably be premature for us to reach a conclusion that those criteria have been reached or not reached, that we might consider just making recommendations to the Secretary for something to be considered for the HIPAA standardization process. And that these are the good things that we found about these particular standards.
DR. ZUBELDIA: Would it be more a recommendation to the Secretary that the department or that the government entities or just the VHA, health take certain actions rather than a mandate under HIPAA standards?
DR. FITZMAURICE: I don't think we are bound to be so narrow in the scope of what we would recommend that might be messages to standard developing organizations or other vendors or other users, end users of the standards. But that is for the committee to decide. I'm just trying to think of the broad brush.
DR. COHN: Well I think I was just going to agree with Mike on this one. I'm just not sure that maybe we should probably look at the recommendations. It is once again like the HIPAA recommendations. You remember HIPAA said you will do X by X date. Here we have, you know, old standards, continuing standards, new standards, - implementation guides, we are trying to encourage implementation in the industry, it has a very different feel, and I don't even know really how it fits into the covered entity context.
DR. ZUBELDIA: Well and that is why I was asking the question, because I don't think it fits into the covered entity context at all. That's why I would like to get maybe clarification. Maybe we don't need clarification. Just say this is not within the scope of the covered entities under HIPAA, this is something that would apply to the entire industry.
DR. FITZMAURICE: I think you are right, but under the charge to NCVHS, we are acting under the charge from Congress to NCVHS and the acceptance of the Secretary's office of our recommendations. And so it may be better not to raise that as an issue is that we think these people shouldn't have to abide by it, those people should. I wouldn't you know. Some of those things are up to the Secretary and they may be up to Congress to decide.
MR. BLAIR: I think we should go by exactly what our mandate was under the administrative simplification provisions of HIPAA, which we have been doing so far. They are looking for, you know, it called for us to make recommendations on uniformed standards for patient medical record information and, you know, all of the words there, and when we did a year ago, we've got broad HHS support for all 10, and that includes recommendation two which says that we would be making recommendations on specific PMRI standards as well as three and four, which are incentives to promote new standards.
So I think that we, you know, we are on target within the law and the other piece is that PMRI standards in particular are used within provider settings and, you know, so I feel like the fact that they might be used outside of provider settings is another issue that I don't think we need to address. Yes, no?
DR. COHN: Before I forget things, on a slightly different topic, I did want to, this brings to issue that one of the things I came away with around the Script recommendations is that I would want to have other standard organization sign off or at least agreement on that standard before we started supporting it. I mean - something in here about that, it is a good idea, it needs to happen, but it seems like that's an overlapping with at least one other standard that I can think of, where we want to have sort of bilateral agreement.
DR. YASNOFF: While you are talking about Script, we also heard testimony that codes are a real problem in Script, and we have heard, this is consistent with testimony we have heard before, that the whole area of drug codes is a big problem and needs to be worked on. So this is just further reinforcement of that, and I would think that before we want to go ahead and recommend that standard to the Secretary, that we would want to include in that recommendation at the very least some process for establishing more effective coding systems to be used within it for drugs and categories of drugs and so on.
MR. BLAIR: Well isn't that true for HL7 as well?
DR. YASNOFF: Yes, I mean we have heard that testimony consistently that we don't have a good system for drug coding, but all I am trying to point out is that today we heard that again specifically for the Script standard, and so I would be a little bit uncomfortable saying okay, well it is in widespread use and let's recommend it, without at least pointing out that it will be strengthened by having a better coding system, as we have pointed out in our recommendations before.
MR. BLAIR: Okay. Let me just capture that. For NCPDP any recommendation with respect to that needs to be accompanied by a statement about the need for more clinically specific drug terminologies to be used as part of that. That is apparently also true for HL7, but I'm not sure that that idea captures what Simon was saying, I think Simon was saying something a little different.
DR. ZUBELDIA: Well the problem with Script is so severe that the, as far as I can remember, the current implementation of Script doesn't use a code for the drug prescribed, which is described in its text. It is not codified.
DR. YASNOFF: That's a serious problem I would say.
DR. COHN: Kepa has described as what?
DR. ZUBELDIA: As text.
DR. YASNOFF: That's a serious problem.
DR. COHN: Or that is a really good solution.
DR. YASNOFF: No, I think it is a serious problem.
Wasn't one of our recommendations, one of our 10 recommendations?
MR. BLAIR: Absolutely.
MR. COHN: I think it is actually happening.
DR. YASNOFF: Jeff could probably tell us which number it was.
MR. BLAIR: Yes, exactly (laughter). It was recommendation 3.e.
PARTICIPANT: And nobody is going to argue with him.
MR. COHEN: Well then I think the only question is does one hold off recommending something like this, - drug terminology.
DR. YASNOFF: No, we're not saying that. But we shouldn't recommend it. I'm just saying if we do recommend it, we need to point out that it needs to be supported by this other thing we have recommended, and that there is a relationship between the two and that its usefulness is going to be diminished by the fact that these codes don't exist.
MR. BLAIR: Simon, I sort of felt like we didn't quite capture a concern you had about NCPDP in terms of organizational usage. Did you want to verify who is using it, was that it?
DR. COHN: I think Mike you have something there.
DR. FITZMAURICE: Other SDOs should concur with the recommendation favoring Script. I was reflecting what you were saying, to give us a greater deal of comfort that we are doing the right thing, that other SDOs ought to agree or give us additional information.
DR. COHN: Yes. I think it actually had to do with the fact that with some of these, where we have this issue of overlap and redundancies, and even though this one isn't exactly an overlap, it gets right close to an interface between other standards.
DR. FITZMAURICE: I think you are right. Anytime you have a particular standard for a given function and you have something that covers a range of functions maybe including that one, that we should help coordinate rather than start a fire. I think that was the sense of what you were saying.
MR. BLAIR: Do we have anything else with respect to which PMRI message format transaction standards are on our table, or have we covered.
DR. ZUBELDIA: I think there was also a common theme that at least the people who spoke about it agreed on, and that was the need for testing and some sort of compliance verification of interoperability.
MR. BLAIR: In a sense that almost gets into I think our next topic, which is the next issue, which is how should we express the levels of the evergreen stair step, you know, in which cases do we wind up making recommendations for HHS funding for implementation guides and conformance testing at all, or certain ones. I think the first step we have to think through would be for each of those message format standards that we have agreed to so far that are on the table, we've agreed to HL7, DICOM, we are considering -
DR. COHN: - made a comment about DICOM, I suspect that DICOM is a very good standard. I did not hear enough testimony today by any user to however I think validate that. I know that for example the RNA, many of the large radiologic, companies that make radiology equipment, are major users of DICOM, and I would observe that we didn't have testimony from any of those groups that either spoke of the goodness, badness or otherwise around DICOM, and I would hope that maybe in December that we might be able to elicit some of the actual users. I mean we heard where HL7 users had had experience with DICOM, but I think that was about as close as we got.
DR. YASNOFF: I think that's right. We haven't heard from those people either, but of course the people that we are going to get to testify are all the people who got together and created DICOM, so, but we still should hear what they have to say about it. Just because they created it, they still may not be satisfied with it.
DR. COHN: Well that's right. And I guess I would feel that it might be appropriate to hear from radiologists since they are avid users of DICOM standard before I said yes it is a good standard for radiology.
DR. ZUBELDIA: But I'm not sure whether DICOM fits into the same category as the IEEE standard, because from what I have heard today, they use DICOM between the xray equipment and the storage of xrays -
DR. YASNOFF: No, it is not the same as the IEEE standard, because the IEEE standard is for connecting pieces of equipment within an institution. DICOM is the standard by which you store an image. So if a patient moves from institution A to B, then you are going to send the image from A to B, and so whether it is DICOM or not really does make a big difference. I think it is quite different.
DR. ZUBELDIA: From what I have heard today, if a patient moves from institution A to B and institution B uses a different vendor and they can't read that proprietary format, the way you move the image is with a JPEG or a TIF. It is not a DICOM image anymore, because those are proprietary formats. So I'm not sure whether DICOM fits within an institution and then when you go from one institution to another, you have to use a common format.
DR. YASNOFF: Well we don't need to resolve this. Why don't we just get testimony from the people.
DR. ZUBELDIA: Yes, find out more.
DR. YASNOFF: But the intent of DICOM is to be able to move images from institution to institution.
MR. BLAIR: Are we at the point that we sort of know what things we agree on and what things are ambiguous in terms of which of the message format standards are on the table? HL7 is on the table, DICOM we would like to get some more information about, NCPDP we would like to get more information about, and also IEEE and CORBAmed is off the table. Is that correct? Okay.
DR. YASNOFF: What more information do we need about NCPDP?
MR. BLAIR: I think Simon was suggesting that we hear a little bit more from other SDOs.
DR. YASNOFF: No, Simon is shaking his head.
DR. COHN: No actually what I meant was I think there was a suggestion, which I sort of agreed with, was before whatever it is becomes a standard, it needs to go through the DSMOs or it needs to go through some process where they are actually signing off on whatever it is, the version that we would be talking about, and I think that -
MR. BLAIR: Version?
DR. COHN: Yes, I mean whatever it is needs to be sort of agreed to.
DR. ZUBELDIA: I think that is a big issue, because the NCPDP implementation that exists today for Script are either 1.1 or 1.5, and the current version which is 4.0 is actually an - syntax, it is not even an NCPDP syntax, it is a - so that is another situation where going to a newest version may not be all that appropriate.
MR. BLAIR: Are we ready to hit issue number two? Okay. Issue number two was a framework suggested by Bill, which I think you referred to as the evergreen concept, and I think everybody appeared to have resonated towards that as a useful idea, where we could, because it had the virtue of being non-threatening and non-coercive to those folks that already have made investments on current HL7 versions, while providing incentives for the development and implementation of future HL7 versions.
There was, at least in my mind here, I think we could maybe take advantage of some of our time together here in terms of either discussing this and seeing if we could put a little bit more flesh on the bones with respect to what wordings we put around the three different levels that you articulated. Bill, would you like to start off?
DR. YASNOFF: You mean you want me to name the three levels?
MR. BLAIR: Yes, go ahead and repeat your concept and then maybe we could each react to that and refine it.
DR. FITZMAURICE: Maybe just in terms of the HL7 standard.
MR. BLAIR: Yes, just in terms of HL7 and how we might approach it.
DR. YASNOFF: To be specific in terms of HL7, I think, I'll just say, you know, start with something, that HL7 Versions 2.1 and 2.2 ought to be supported, they are still out there, that 2.4 is the current version and I'm not sure where to put 2.3, and that Version 3 is clearly the emerging standard. So if you want to call it the still supported standard and the current standard and the emerging standard, if you want to use that terminology, then 2.1 and 2.2 I would say are the still supported standards, 2.4 is the current standard, and Version 3 is the emerging standard, and I don't know where to put 2.3, whether to put it with 2.4 or back the other way.
And then you need to define what we mean in terms of how those things are treated. So for example, by still supported, does that mean you can send them outside your institution and people should still be willing to accept them, does it mean you can send them outside your institution and people will accept them but they won't be happy. Does that mean that you have to use, is it the current standard that you have to use for example to report to CMS or to report to CDC. And what about the emerging standard, what is that used for.
So I think there is a need for some further consideration of what these things mean, and then also to be much more specific about what the incentives are. So for example, if you use the still supported standards, do you get nothing, if you use the current standard you get a transaction fee, and if you use the emerging standard you get a much higher transaction fee or something like that. I don't know if that makes any sense.
MR. BLAIR: Could I suggest something slightly different, instead of fees. Accepting the three categories that you have defined, where Version 2.4 would be considered the new standard, that we begin to apply some incentives to encourage people for new installs, not to migrate, but for new installs. If they are going to have a new install, lets encourage them install, to choose 2.4, and one of the ways that we could do that is, well there's two ways, or three ways.
One of them is to encourage it for implementation within the Federal government departments and agencies. Another is maybe that is where we could have some funding for a single implementation guide and/or a conformance test. What is your thoughts of applying those incentives at the 2.4 level?
DR. YASNOFF: I think there are three different issues there. One is which version of the standard should be at what level, that's one issue. The second issue is what should the incentives be. And the third issue is where should have conformance testing. And then how should conformance testing be related to the incentives if at all. Let me just comment on one of those.
I think that we need to have conformance testing for all of them, because without conformance testing -
MR. BLAIR: All of the -
DR. YASNOFF: All Version 2.4, for all the versions, because otherwise -
MR. BLAIR: You mean that we've got to go back to Versions 2.2 and 2.1 and create conformance tests for those?
DR. YASNOFF: Why not? If you don't have a conformance test, how do you know that anyone's HL7 transaction is really correct or not?
MR. BLAIR: Well the thing is that I felt that the incentives would be to make it more attractive for people to move to the newer versions. If we wind up going back to strengthening those that are installed, it is almost a dis-incentive for them to move forward.
DR. YASNOFF: So what you are suggesting is one of the incentives to move forward would be that there is conformance testing. I'm not disagreeing with that. I think I'm trying to understand.
DR. ZUBELDIA: That's a very strong incentive. And there is no conformance testing for other versions, only on the new ones, and people should not be implementing the other versions anyway anymore. And if it is running, don't touch it, you don't care about conformance testing.
MR. BLAIR: It is already installed, it's running.
DR. ZUBELDIA: But if you are going to do something new, then you use the new one because it has conformance testing among other things.
DR. COHN: My vision asked Mike to stop playing with his computer because it is driving me a little nuts.
MR. BLAIR: That's why I'm looking at you, I'm looking away from it.
DR. ZUBELDIA: There could be conformance testing for the new one, incoming standard also.
DR. YASNOFF: Yes, and there should be conformance testing for the emerging standard.
DR. ZUBELDIA: The current and the emerging.
DR. YASNOFF: But Jeff, were you suggesting that 2.4 should be the emerging standard that we recommend?
MR. BLAIR: Well actually I had come into the discussion with the idea that it was going to be Version 3 that we would apply our incentives to, but the way you just defined it, I was piggybacking on your thoughts, as I do from time to time (laughter), and I was thinking well if 2.4 is where we want to encourage people to go for the next year or two or three, then what incentives would be appropriate for 2.4. Clearly there's other standards that we might apply, 2.3, because it is still in many cases under development, and we may want the same ones for Version 3, but maybe even stronger. Anyway, just for discussion purposes I was trying to see where we would make our distinctions.
DR. YASNOFF: Well I think incentives for 2.4 are fine, but I think, I would think even at this time we would want to designate Version 3 as the emerging standard, and so then provide incentives for 2.4 as the current standard, in other words, you have some incentive for implementing things as at least the current standard. Right now is it actually possible to install anything with HL7 Version 3 today? It is not even possible is it?
MR. BLAIR: No, it is going through its first ballot. The expectation is it will go through two or three ballots before they really consider it implementable. However, I do think that they are figuring on the demonstration projects to be about four or five months away, and that probably by the second half of next year, it will be considered implementable.
DR. COHN: I think I would change new to emerging. I don't think it is new.
DR. YASNOFF: Well I used the word emerging, but I think in that case I might actually amend my own idea and suggest there need to be four categories, because I think there needs to be three categories of actual implementable standards that you are dealing with, and you know, I would be interested in other people's reaction to this. In other words, to me you have the new standard, the current standard, and the old supported standard.
So the way in which I envision this and the way I've seen it work with other standards is if you have something that is running the old supported standard, don't throw it away, but realize that its life is limited and you are going to have to replace it. If you are buying something new, that should use not the current standard, it should use the new standard, but if it uses the current standard it is okay.
So and then this kind of fourth category would be the emerging standard, which you can't even implement now, and that would be subject to, you know, we could provide incentives for demonstration projects and so on for emerging, you know, emerging type of standards. But I'm not sure we even want to recommend adoption of a standard that is not implementable.
MR. BLAIR: You said there's four, I kept hearing three.
DR. YASNOFF: No, there is the old supported, the current, the new -
MR. BLAIR: - 2.2 and 2.3.
DR. YASNOFF: I don't know, is it?
MR. BLAIR: I think so, those are one, yes, I think so.
DR. YASNOFF: Those are the current ones?
MR. BLAIR: Yes, let me just capture. The old is 2.1, the current is 2.2 and 2.3, the new is 2.4, and the emerging is 3.0.
MS. BURKE-BEBEE: Can I throw something out here. Looking at the role that we are using standard and trying to develop this fourth category of emerging, which I agree with, would we want to define standard as those that have been voted upon and concluded as being standard by the SDO. Another thought too that we have been talking around is the incentive. It sounds like possibly the incentive could be timeframe with the testing as being just an attractive component to the incentive. But I heard in the testimony that there was not that much difficulty in going from a 2.1 to a 2.2, to a 2.3 type of thing, so I don't see that as being a barrier if we would put a timeframe on it, so that the incentive would actually be a timeframe and we would make that timeframe attractive by having the testing as a component of that.
MR. BLAIR: I think you are correct Suzie. I think that maybe what we are trying to figure out is which incentives would be appropriate for the new and which incentives would be appropriate for the emerging, is that correct, did I hear everybody shake their head?
DR. YASNOFF: Yes, that is the issues that we are on. And actually I am encouraged with these four categories that fit nicely with the actual situation. I think that it describes what is going on reasonably well, which I think is an advantage, rather than having us twist the situation to fit some categories.
DR. ZUBELDIA: So in those four categories you would have compliance or testing for the new and the emerging, and you would not have it for the current or the ongoing.
DR. YASNOFF: That's one way of doing it, and then you would have the additional incentive presumably that the new standard would be required for use in the government, and so that the government would be, any systems the government was using would be using the new standard.
DR. ZUBELDIA: New acquisitions by the government.
DR. YASNOFF: New acquisitions and every effort would be made to push towards the new standard within the government.
MR. BLAIR: Okay, so that is three incentives for the new, implementation guides, conformance testing, and government usage. Is that correct?
DR. YASNOFF: Right. And then for the emerging one you could add the incentive that demonstration projects would be funded.
MR. BLAIR: And for the emerging one it is those three plus demonstration projects.
DR. ZUBELDIA: No for the emerging one the government would not make acquisitions unless it is a demonstration project.
DR. YASNOFF: Right. You can't acquire, by definition we have said you cannot acquire a system with that, so that incentive would not be applicable.
MR. BLAIR: Is there any other incentives for the emerging that would help?
DR. ZUBELDIA: Is there some sort of disincentive for the old standards, so it can get retired?
MR. BLAIR: Ooh, that is what I think they wanted us to stay away from.
DR. ZUBELDIA: I know, but what moves people to move on rather than stick with the old.
DR. YASNOFF: I think if you want to stay with disincentives, I mean one way to have a disincentive is if someone sends you an old thing and you charge them for it, to translate it, but since people want us to stay away from disincentives, the way to deal with that is to pay something for the current one.
MR. BLAIR: Well let me as you this. Within CDC, the NEDSS system, which HL7 standards will NEDSS be using?
DR. YASNOFF: Whichever ones NCVHS says we should use (laughter).
MR. BLAIR: Alright. Then my next thought is, let me try to take this down a special path if I may, okay, I'll try to be careful. There are several things that are important with NEDSS. Clinical specificity is important, timeliness is important, access to information from a broad range is all important. And by the way, NEDSS stands for National Electronic Disease Surveillance System for those of you who are not familiar with what we are talking about, and there's also, CDC is also working on immunization standards with HL7.
DR. YASNOFF: Immunization registries, right.
MR. BLAIR: Immunization registries. So my thought, but especially with respect to NEDSS, and Michael, are you there, Michael and Simon are conferring. Michael, could I drag you into this?
DR. ZUBELDIA: He is conferring with Simon on his laptop. What we did 10 minutes ago, he needs to catch up.
MR. BLAIR: I think that, tell me when you are ready Michael, that I could ask you a question.
DR. FITZMAURICE: Fire away Jeff.
MR. BLAIR: Okay, the question I am trying to really get to is both CDC and AHRQ have need for information with greater clinical specificity then exist today, and in a more timely manner. NEDSS from CDC, but Michael, you have also outlined that AHRQ has the National Guideline Clearinghouse and tracking for outcomes and patient safety and all. My thought is that those tend to be where Version 3 is needed. So what additional incentives, other than the ones we have identified for the new level, 2.4, are appropriate as incentives for Version 3.0?
DR. FITZMAURICE: Well we usually fund researchers and then researchers go out and buy data. So convincing researchers they should pay more for data because it is Version 3 standards rather than Version 2. something standards would provide such an incentive. However, researchers might want to crunch more numbers than pay people to put in the right standards.
I think by showing the benefits of the standards, for getting larger databases, for working with standards groups for specific data needs that we have, such as for medical error reporting, those are likely to be new data sets, perhaps even new codes for classifying medical errors, that building goes into the emerging and the new standards can go a long way toward reducing the cost of complying with patient incident reporting. And it will spill over into the other research databases.
But normally the research databases don't pay the freight, that is of a secondary nature. Patient safety reporting however may be a new reporting system and that may pay the freight. It may be better for us to pay hospitals for that data and let them figure out the most efficient way to do it. We believe the most efficient way to do it is with standards. We'll have to develop the definitions for what we want to collect. That should be done within the context of a standard developing organization, so that is does get built into their existing sets of standards.
So that basically is our incentives, our working with the SDOs to incorporate them into the new standards that are coming out, our paying for data that are in the format we think is best for research purposes and for reducing medical error, and then letting the hospitals, letting whoever is collecting the data from the hospitals and stripping off the identifiers, figure out the most efficient way of doing that.
DR. YASNOFF: I think first of all you should probably ask this question again at the next hearings when we have someone from NEDSS here. But there are two things I can this off as ideas that may or may not be good. One that I am pretty sure of is that CDC puts out clinical guidelines, and we are working on getting some of those guidelines translated into standard formats. And so we clearly would, could easily release those guideline only in the latest version of HL7 and in fact there is a guidelines group in HL7, and I suspect that whatever standards they come out with probably at this point will be, or I assume actually definitely at this point would be in Version 3 of HL7.
Does HL7 Version 2.4 have any guidelines, guideline standards? I don't think it does.
MR. BLAIR: Not that I am aware of. Michael, do you know of any? I'm not aware of any.
DR. YASNOFF: So one advantage to using HL7 Version 3 is that any organizations using HL7 Version 3, assuming there was a guideline dissemination standard when our new guidelines came out, they would immediately be able to use those and incorporate them in the system.
MR. BLAIR: Well the other piece is the DEEDS might take advantage of the RIM and come out as a Version 3.
DR. YASNOFF: The only other thing I could think of -
MR. BLAIR: DEEDS is (laughter), Data Elements for Emergency Department Preparedness.
DR. YASNOFF: Um, something like that. The only other incentive I could think of is, and again I don't wish to commit CDC to providing this, but a possible incentive is that if data were to be submitted say in HL7 Version 3, then CDC might be willing to consider providing reports back to the reporting organizations at no cost. Again that is a suggestion and does not mean to imply that CDC would be willing ever to do that, but it is an idea.
MR. BLAIR: Well it sounds like to maybe this discussion is one where we need to gather additional information to make these distinctions on what incentives might be helpful for Version 2.4 and Version 3. Now we sort of started it but we will probably get better ideas in December.
MR. COHEN: You might also review the previous recommendations of the full committee on PMRI standards, because I think there are pieces there already.
DR. YASNOFF: Another thing that I think might be useful in this process is that given this particular framework, it would be interesting to take a draft of this framework that was written up and circulate it back to our witnesses and get comments on it.
MR. BLAIR: Give it to the agencies to see what comments we get from the agencies.
DR. YASNOFF: No, the witnesses.
MR. BLAIR: Oh to the witnesses to see how they react.
DR. YASNOFF: Because we have heard a lot of testimony from a lot of different points of view, and certainly I think, and our recommendations reflect this, there is an overwhelming consensus that the government should do something in the standards area, but there certainly was not a clear message at all as to what that something should be.
So if we are now proposing a framework that is relatively specific, I think it would be very useful to circulate it back to those witnesses, and even if they disagreed with what standard we are putting in which category, if even we could get consensus on this type of framework as something that would be helpful, that would be a positive step I believe.
MR. BLAIR: Should we go on to our third major issue, which I think might be something we can figure out how we might be able to begin to address this in December. It seemed as if many, most, maybe all wound up encouraging us to also consider clinically specific medical terminologies, common data set definitions. And Simon are you all ready? We are thinking that we needed to get that on the agenda in terms of, you know, different code sets.
DR. COHN: Not for December.
MR. BLAIR: Not for December.
DR. COHN: I think that is something after we do our code set hearings early next year. I don't think that we should attempt to push forward on that in December.
DR. ZUBELDIA: Jeff, I think that is something we are going to continue to hear. Even if you are giving very focused questions and specifically avoid that topic, we are going to continue to hear about it.
MR. BLAIR: Okay.
DR. FITZMAURICE: I think it is possible that any recommendations or messages we send to the Secretary would also include the importance of this and the fact that the subcommittee will be looking at this in the coming year.
MR. BLAIR: We have, given that this, you know, that's the case with code sets, late tomorrow morning Jim Scanlon will be reviewing with us the HHS actions to address the PMRI, the 10 PMRI recommendations. He had started to do so in the conference call with us back in, what was it, September 24th I think it was, and late tomorrow morning Jim will finish that review with us.
And then the other item we had on the agenda was that when Margo Amateokin presented her summary, her analysis of the SDO questionnaire feedback, she had given us a list of it was either four or five areas where we may want to go back to the SDOs for additional clarification, and we were going to try to do that a couple of weeks ago when our trip to Washington was cancelled and we sort of deferred that until, you know, tomorrow morning.
Let me go ahead. I brought a copy of that and maybe Jackie can make copies of that so that we could all look at it tomorrow afternoon. Just wanted to remind you that that was on the agenda, and I'm not necessarily saying that we need to go back to the SDOs. I think we ought to just look at the list to see whether we should or not, and if we do, whether we want to go back with clarification on the issues that Margo had suggested, or whether that is still necessary.
And Simon, do you have some other issues that you think we should cover this afternoon?
DR. COHN: Really the remaining couple of minutes I think the only thing I wanted to do was to talk a little bit about the end of the year meetings and next year meetings, which we've got to get established at least two days for hearings into 2002. And I wanted to just reflect on what we were going to be doing a little bit.
First of all I think, as you commented, we have a meeting scheduled for December 13 and 14, which will hopefully be an opportunity to finish up what I believe is probably going to be a letter to the Secretary as opposed to some sort of a major report, at least that's what it is beginning to look like at this point unless we feel differently, and hopefully it will at least in my view sort of reflect a little bit on the previous recommendations that we made on PMRI standards, as well as these more specific standards, realizing that the current Secretary may have never received formally the initial PMRI report.
So at least I don't think we need to ship to the Secretary a 50 page report, but some reflection on the previous recommendations I think would be appropriate in addition to whatever letter we write about the next phase.
Now beyond that in the first half of next year we are going to be taking a look at code sets and perhaps a slight more traditional way we have previously in the sense of looking at procedures and diagnosis. - issues of medical terminology. On February 6 and 7 we have scheduled a hearing that actually Kepa will chair, related to procedure codes, and the focus of these hearings will be looking at what we identified earlier as holes in the X12 transactions related to various code sets and things related - proposed rule in responses to the - superimposed rule, and sort of seeing where we are with that in relationship to how for example those that made their concerns known feel about the current code sets and whether their needs are being met.
We will also hopefully be taking a look at local code set issues to see where we are now and at that point of course - level 2, the year 2002 will have been released and we will be able to reflect a little bit about how much progress we are making on the whole issue of local codes, and what sort of issues remain on that.
So there are going to be hearings scheduled for February 6 and 7, and the next set of hearings will be on April 9 and 10, and that will be an initial look at the whole issue of diagnosis codes. As we know this has been an issue on the table now for awhile about when and how we ought to move towards a new procedure code, actually a new diagnosis code on ICB10 CM or other such coding system, and we wanted to get input from the industry and health care community on what their feelings were in relationship to that, industry readiness, what it would take to help in any sort of implementation in relationship to new diagnosis coding system.
And we are also going to be scheduling a hearing for late May early June, the date needs to be determined. Hopefully it will be announced next week. The topic will be sort of to be determined, and it may be an opportunity for us to begin to, after these code set hearings, reflect a little bit on the issues of medical terminologies and where they fit into these other issues that we are identifying. There also may be some issues at that time related to actual HIPAA implementation, but we are just holding it as a set of dates for likely issues. Mike?
DR. FITZMAURICE: Simon, what was the date on the hearing for diagnosis codes?
DR. COHN: It is April 9 and 10. And we thank all of you who responded about availability. Questions or comments?
DR. ZUBELDIA: There is a couple, there's three other topics that we need to look at next year. We need to look at the electronic signatures and how the multi SDI project is progressing on that. Maybe we need to bring them in for a report. They have been building some definitions of case studies, business scenarios for which they needed signatures, and how that is moving along.
Another topic is the progress report on the HIPAA implementation, and we need inform - the progress report. So that's another topic. And then the Privacy Subcommittee has bounced the ball to us on the NACDS versus NCPDP request that they have concerning the privacy issues with the NCPDP transaction, whether it is always optional fields, and NACDS is saying that the optional fields this is what we should do with them and send very few, and - is putting together a process, a consensus based process and all that to identify what are the fields that actually should be sent in that transaction, and I don't know where that is now and how that is progressing, but I know that they are looking for some guidance from us on that topic.
DR. COHN: Okay, let me try to respond to each in turn. I do agree that the electronic signature is something that we should be updated on and I would look to you in terms of identifying when the likely time for that discussion should occur. So talk to them working on it and let us know and we can schedule that either as an add on to one of these other hearings or during one of our meetings during the full committee, in terms of where they are with electronic signature.
You are certainly right that every year one of our requirements is to draft a report on HIPAA implementation and I think the subcommittee, and full committee for that matter, stands ready as issues come forward, come up on HIPAA implementation, to identify them and make recommendations to Congress. We of course do have, as I said, a yearly report to Congress that we will be working on in the I guess winter - to review. Hopefully the issue of medical codes will begin to surface, some of the issues coming up in relationship to implementation. There certainly may be others.
And the final issue you brought up, which was an issue referred over from the Privacy Subcommittee that goes to the NCPDP use of optional fields is an issue as we understand has been actually sent and will be addressed one way or another by the Office of Civil Rights in terms of some response to NCPDP and so it would seem appropriate to hold any sort of investigation of that topic pending a response from the Office of Civil Rights. As such time as NCPDP does receive a response from the Office of Civil Rights, if there are still issues they need to bring before this subcommittee or full committee we will obviously be looking forward to hearing from them, but without a usual response from OCR, it seems inappropriate to query into that issue further at this point.
So certainly the first two issues I agree with. The third I would defer until further progress has been made on that issue. We will find ways to incorporate a number of these things. Jeff?
MR. BLAIR: When Clem and I were at HL7 we had time for lunch and we sort of discussing a lot of these issues, and we discussed the thought that I might create a first draft, an initial draft, of recommendations for the December meeting and maybe see if I could get that out maybe in early November to everyone, so that we could get a little bit of a running start, make comments and critique, so that by the time we came into our December meeting we might, you know, hopefully we could have gotten through one or two draft versions.
I don't think there is any deadline that we would impose upon ourselves, and I'm hesitant to put much of a burden, we are all so busy, but at least I would be willing to make that draft, submit it to all of you as soon as I can, maybe early November, and you know, depending on whether we each have time to review it and make comments, then try to see if we can get a second or third draft ready by December. Do you feel okay with that?
DR. COHN: I think that would be great. I mean the good news also is that we do have a non-scheduled in late January, early February, yet we need a little bit of time for final wordsmithing. And certainly I think we would encourage that. Thank you Jeff for volunteering and I know I'm sure that Mike Fitzmaurice will also be helping you on this one. So I want to thank you both for your efforts.
I also am very clear even now before our testimony tomorrow, that it is likely that there will be some other issues that we will be wanting to investigate in December, which may result in modifications to letters and recommendations. So you just need to be aware that we may need to be modifying this post December.
Are there issues, other reflections on what we need to be doing during early 2002, late 2001? Okay. Jeff, do you have final comments or should we adjourn this meeting until tomorrow morning.
MR. BLAIR: The only final comment I'd have is that Michael thank you so much for the way you pulled together all the testifiers and set up the agenda, because I thought that we had an extremely productive day today, and I am really grateful.
DR. FITZMAURICE: Thank you. As you can tell, the testifiers really did the hard work.
DR. COHN: I want to thank both of you for the subcommittee. I also think we made lots of progress today. Now we are going to adjourn in just a minute. We will reconvene tomorrow at 8:30 as I understand. So look forward to seeing you all at 8:30 as well as those on the Internet. Thank you very much.
(Meeting adjourned at 5:00 p.m.)