Washington, D.C.
The Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics held hearings on October 9 and 10, 2001, at the Hubert H. Humphrey Building in Washington, D.C.
The Subcommittee on Standards and Security held hearings October 9 and 10, 2001 in an ongoing process focused on HIPAA administrative simplification. During the two days, the Subcommittee heard 14 presentations and talked with four panels populated mainly by vendors and users, listening to perspectives and insights on patient medical record information (PMRI) message format standards.
Mr. Dickinson said essential criteria for selection of standards include: an American National Standards Institute (ANSI) accredited standards development organization (SDO), technology independence, completeness of coverage, validation and proof in practice, and market acceptance. Per-Se assessed HL7 v2.x Data Interchange and ASTM Extensible Markup Language (XML) Specification standards as: ANSI accredited, open, consensus, and balanced. HL7 had widespread industry acceptance, but Mr. Dickinson noted deficiencies remain in enabling a robust electronic health record (EHR). ASTM lacked validation and industry acceptance. HL7 v2.x was most applicable with Per-Se’s products and had the benefit of major market demand. Mr. Dickinson said HL7 covered about 25 percent of Per-Se’s requirement for interfacing with external or foreign applications; another 10-25 percent often could be covered with Z extensions. Per-Se gauged HL7 coverage against their product and experiences implementing interfaces, framing their assessment in the context of design and trust objectives.
Cerner believed data content standards were needed before standardized message formats could be developed and implemented efficiently in the marketplace. Cerner recommended that regulations referencing standards be version number specific. Regulators should resist the temptation to use the most current versions, if benefits of standardization were to be achieved. Mr. Garton said investments of healthcare organizations also had to be considered. He noted the lack of specific data content references or standards as part of these regulations had caused confusion, delay, and higher costs. Cerner clients primarily requested HL7 v2.x standards. Most provider sites Cerner supported were v2.1; v3.0’s major weakness was it hadn’t been proven yet in the market; its strength was the object-oriented modeling. Cerner called for standards for data definitions and content, via a controlled medical vocabulary, prior to any regulations regarding format for clinical data messages. Mr. Garton recommended that HHS invest in the creation of an affordable, controlled medical vocabulary, in synchronization with UMLS and SNOMED.
Mr. Addy said HL7 was the protocol for addressing PMRI. HL7 v2.x was the de facto standard for electronic data exchange intra- and inter-facility between systems providing patient care. Noting most implementations were v2.2, he said there were no business incentives to migrate. Mr. Addy noted the lack of skilled integration staff; even the most prestigious facilities used consultants to implement major projects. Interface engines centralized knowledge, which helped small integration staffs, but had a high entry cost. Mr. Addy recommended: keeping and building upon current v2.x standards, adding transactions, segments and fields that address issues not currently handled, defining standard field values and vocabulary across systems and facilities, and adding a voluntary migration path to an HL7 version of v2.x XML schema.
Addressing the entire suite of message formats, which he described as building blocks, Mr. Meyer said only HL7 addressed the full spectrum of message exchange relevant to PMRI. Mr. Meyer said HL7 was the only viable messaging standard relevant to the exchange of PMRI. Given its widespread use, Mr. Meyer said designation of HL7 v2.x as the national PMRI messaging standard wouldn’t be too much of a burden on the healthcare industry. But he added McKesson didn’t believe that decision would benefit the quality and safety of patient care. The current iteration of HL7 v2.x still required significant negotiation to resolve its ambiguities. McKesson believed v3 was the next generation of healthcare messaging standards, and recommended the Committee support the designation of HL7 as producer of the national standard and allow the adoption of any ANSI-accredited version.
Mr. Guinan noted the importance to ProxyMed’s business of establishing operating policies and procedures that applied to all transaction sets. He recommended that the physician-to-pharmacy e-prescribing transaction set be addressed and covered by HIPAA and that NCPDP SCRIPT standard be adopted as the standard for these transactions. Mr. Guinan said the most prevalent version (1.5) was sufficient for current functionality requirements (except for code sets issues), but he suggested the segment of the pharmacy industry linked to physician-to-pharmacy connectivity would benefit if v4.0 or higher were mandated. Mr. Guinan noted three code sets required improvement and assistance by the federal government. And he emphasized the need to advance the content of messages between physicians and pharmacies, if physicians were to adopt these systems. A lack of proper identifiers resulted in a loss of functionality and applications had to be “dummied down,” because enough data couldn’t be provided in the message to perform advance drug interaction checking. He also suggested that mandated standards tighten up the use of optional and mandatory fields, which often resulted in interoperability issues.
Ms. Kennedy said HL7 and Digital Imaging and Communications in Medicine (DICOM) addressed Siemens’ highest priorities for exchanging PMRI electronically and were the only logical choices for clinical interfacing, but to be comprehensive they had to be supplemented with person identification, security and vocabulary standards. HL7 v2.2-2.4 were used for most of Siemens’ structured clinical data exchange; DICOM v3 was used for multimedia interfaces. She said both SDOs were working towards improving interoperability and recommended giving priority to HL7 and DICOM and establishing clear, specific message guidelines for data definition. Siemens’ believed the federal government could best help by providing financial incentives to increase private sector participation in the development and implementation of appropriate standards, participating in these standard-setting efforts, endorsing medical terminology standards proven and integrated into a consistent, systemic terminology model, and using the standards and terminologies within their systems.
Noting XML was rapidly becoming the data portability standard enabling exchange of information between many systems, Dr. Aita predicted it would take several years to build a semantic foundation for healthcare interoperability which positioned v3.0 to take advantage of XML. Dr. Aita noted HL7’s three advantages: the simple protocol to implement and understand, the complete set of messages for application integration, and wide industry support of messages. MedcomSoft implemented v3 because it matched their system’s future architecture and flexibility. MedcomSoft recommended: (1) the Committee support the appointment of an organization to facilitate testing and provide the proper mechanics for vendor compliance and certification, (2) a specific but standard implementation guide employed by all vendors for each kind of PMRI message, (3) the organization provide a means for testing implementation of each transaction set the standard supports (e.g., a Web site for vendors to send messages and receive message format validations), (4) creating mechanics for certification, (5) creating one standard format with both healthcare terminology and message format standards, and (6) message formats that establish minimum and maximum data elements, providing a common reference point for all vendors.
Allscripts recommended including electronically transmitted prescriptions and computer-to-computer communications between physicians and pharmacies within the electronic healthcare transactions and adoption of the SCRIPT Standard message format. HL7 has a message standard supporting inpatient drug orders, but only SCRIPT Standard addressed requirements of outpatient prescription transactions. SCRIPT Standard supports: new prescriptions from prescriber to pharmacy, requests for refills or prescription changes from pharmacy to prescriber, and prescriber responses. Although agreement remains to be reached on common code sets, identifiers and data elements, Allscripts was satisfied with the SCRIPT Standard message format. Allscripts utilizes v1.5, which is used by the few pharmacies that have implemented electronic prescribing software, and will upgrade to v4.0 as pharmacies implement it. Recommending flexibility in adopting a specific version, so the rules do not mandate obsolete versions, Dr. Berman suggested choosing the version in current use and subsequent releases.
Mr. Wagner said the Veterans Health Administration (VHA) noted the standards identified didn’t address the high priority area of vocabularies and code sets. Mr. Wagner said even earlier 2.x versions met many VHA’s needs and that they improved with each release. However, they require extra work to implement due to optionality, a problem he expected v3 to reduce. Mr. Wagner noted the need for a scanned document standard that includes file format and annotation capabilities. He suggested DICOM, which already has annotation capabilities, could be enhanced to handle document images. He also identified the need for an EKG standard, a project he noted DICOM was already working on.
Dr. Overhage said the Indianapolis Network for Patient Care (INPC) had created a community-wide electronic medical record system using HL7 as the primary message standard. HL7 was a workable choice for information exchange in a heterogeneous environment and, along with DICOM and Internet standards, met current and immediately anticipated needs. INPC planned to evolve to HL7 v3.0 as developers of commercial clinical information systems deployed that capability. But he noted there was no reason to wait until v3 to take advantage of the functionality provided by current versions. HL7 was chosen, in part, because fields contained in HL7 messages had clear semantic homes in INPC’s databases and the message content was easily mapped into INPC as information models, a single set of monitoring and control functions could manage all the data flows, and performance was acceptable--processing the large volume of HL7 message created over an entire community. INPC planned to evolve to HL7 v3.0 as developers of commercial clinical information systems deployed that capability. But Dr. Overhage noted there was no reason to wait until v3 to take advantage of the functionality provided by current versions.
Dr. Huff said IHC primarily uses HL7 and DICOM but found an important role for the C-CAL standard in integrating the state immunization database into applications and sharing that data within IHC. IHC was beginning to use clinical LOINC for some typical clinical measurements. IHC chose HL7 because key vendors and commercial interface engines support HL7; consultants and program managers are on hand to install interfaces; interface development kits, tutorials, and training materials are readily available; and an open, consensus SDO is responsive to new needs. Dr. Hoff said the single most important need was for a standard for signs, symptoms, and clinical diagnoses. He recommended implementation guides for high-volume, highest-return transactions that removed vagueness and specified terminology for particular messages. IHC had a million transactions a day of v2.4 non-compatible data; it would be premature to go to v3. He said the biggest improvement for DICOM would be standardizing terminology.
Dr. Zubeldia reflected everyone agreed on HL7 and a standard for nomenclature or a common data dictionary; most believed at least some transactions needed a well-defined implementation guide, though some preferred open-ended adoption of a standard or SDO. Dr. Cohn noted agreement with the evergreen concept and questioned whether more open-ended standards were still an issue. Noting they’d heard a need for vocabulary, terminology, codes, Dr. Fitzmaurice said interactions between codes and vocabularies and what was needed for drugs versus recording clinical notes were more complicated than they might be able to formulate in a letter. Dr. Cohn added they’d heard people favoring incentives and benefits. They’d heard there was rationale for tighter use of the prevailing standard and related data requirements with a number of submissions to the government. Dr. Fitzmaurice noted several testified the government’s role was to lead and support--no one said strongly enforce.
Mr. Blair said he’d heard of three major areas where there was need for consensus: the message format standards on the table, the language used to recognize each level of the evergreen, and next steps regarding terminologies and data definitions. Clearly, HL7 was on the table and there was general acceptance for DICOM and NCPDP SCRIPT standards between physicians and retail pharmacies. IEEE’s standards for medical devices was an open issue. Dr. Yasnoff noted that in addressing SCRIPT they had to at least state that both a process for establishing more effective coding systems and clinically specific drug terminologies had to be included. Dr. Zubeldia noted a common theme about the need for testing and compliance verification of interoperability.
Members discussed whether they should get guidance from the Department identifying covered entities under HIPAA or PMRI or simply continue to follow their mandate under the administrative simplification provisions of HIPAA. They’d received broad HHS support for all ten recommendations, including number two that specified recommendations on specific PMRI standards and three and four that were incentives to promote new standards.
Members clarified HL7 was on the table and they wanted more information about DICOM and NCPDP. They discussed the evergreen concept. Dr. Yasnoff identified three issues: which version should be at each level, what the incentives should be, and where there should be conformance testing and how it should relate to incentives. Dr. Yasnoff suggested four categories of standards: the old, supported standard (v2.1), the current standard (v2.2-2.3), the new standard (v2.4), and the emerging standard (v3.0).
Members discussed gathering additional information before deciding incentives for versions 2.4 and 3 at the December meeting. Hopefully they would finish up a letter to the Secretary at the meeting scheduled for December 13-14. During the first-half of 2002, the Subcommittee will look at code sets, medical terminology, and procedures and diagnosis. Hearings on February 6-7 will focus on procedure codes. Hearings on diagnosis codes and industry readiness were scheduled for April 9-10. Hopefully, a date for late May-early June hearings (probably on HIPAA implementation and medical terminologies issues) will be announced next week. Dr. Zubeldia noted three other topics for next year: (1) the electronic signatures and the multi SDI project’s progress building case studies and business scenarios, (2) the progress report on the HIPAA implementation, and (3) the NACDS versus NCPDP request concerning privacy issues with the NCPDP transaction.
Mr. Blair targeted distributing a draft of recommendations early in November for comment and critique and one or two more drafts by the December meeting. Dr. Cohn noted probably there would be other issues to investigate in December that modified any letters and recommendations.
Ms. Lorenzi described hidden complexities and interface problems that came with the integration of different departments and people. She said HL7 was chosen because it covered pressing interface needs, was the only widely implemented standard, and the HL7 Working Group impressed them. HL7 exceeded their expectations. It was comprehensive and compatible, backwards and forwards. Ms. Lorenzi said the responsiveness of the HL7 community also exceeded expectations. HL7’s major weaknesses were: (1) too much optionality; (2) ambiguity; (3) artifacts left to retain backward compatibility made it unreadable; (4) conformance testing couldn’t be specified or automated; (5) complicated, esoteric encoding rules; and (6) no standard vocabulary. Her biggest concern was whether or not vendors, who didn’t understand Chapter 2 in v2, would able to successfully implement v3. Ms. Lorenzi suggested developing and sharing conformance profiles and encouraged vendors to use Messaging Workbench, a tool supported by the special interest group for conformance.
Mr. Tsiolis expressed concern with the suggested standards lack of overall PMRI structure. Contending that HL7 v3 provides such a global framework, he said the order entry and observation reporting transaction sets provided a rich order entry and results review functionality crucial for the success of their clinical applications. EPIC Systems encouraged the Committee to include the version of the HL7 transaction sets on ballot in its recommendations.
Noting radiology departments were largely digital and used PACS to assemble clinical information, Dr. Horii said DICOM’s primary role was to make it simpler, less costly, and more reliable to connect equipment to PACS. Dr. Horii said DICOM had become the predominant standard for radiological imaging and was rapidly being adopted by other specialties that generate digital images. He said its wide adoption and implementation were a testament to how well it worked. It was rare to find an imaging equipment vendor that didn’t support DICOM. The work of the DICOM standards committee and a joint working group with HL7 (volunteers from industry, medical professions, and standards organizations) was an example of how a standard could be built through collaboration.
Mr. Scanlon said the updated draft status report noted a considerable number of activities underway related to the PMRI standards. He said the priority in the IT area was internal improvements within HHS and the federal government (e.g., standards, interoperability, security). Enterprise Information Infrastructure Management, a HHS initiative run by CIO focused on e-government and other federal government initiatives in IT. The other major initiative in this area was HIPAA, which served as a framework for much of the data activity within HHS and its partners within which improvements in PMRI standards and related national health information infrastructure (NHII) activities took place. HHS saw HIPAA as the major initiative leading to PMRI standards and NHII. As agencies thought of new data and communication systems, standards and vocabularies, they were beginning to look, first, at the HIPAA framework. Noting the report formed a “single snapshot” tracking how the Department was responding, members discussed keeping it updated on the Web, with a caveat clarifying everything was subject to funding. Mr. Blair observed that HHS took the recommendations seriously and supported them. Mr. Scanlon commented the Committee provided impetus for looking at this in a future-oriented way; it was a way of having the agencies work together towards the future.
Dr. Cohn noted the security and the attachments were expected out by December 31. Mr. Scanlon said whether or not they had the means to arrange for the national provider identifier depended on the 2003 budget. The Deputy Secretary had said modifications to the transaction recommendations were aimed for later this year and changes in the requirement for the code to use in the pharmacies and the fast track set of changes were projected by January.
The Subcommittee will meet briefly during the November 15-16 full Committee meeting. The December 13-14 meeting will focus on PMRI issues, implementation, administrative simplification and collating information on electronic signature work. Ms. Greenberg noted the Work Group on Quality was trying to coordinate a session on patient safety issues with the Subcommittee’s December 13-14 meeting; the Subcommittee for Population was invited. Staff was lining up speakers for the afternoon of the 12th. Dr. Cohn added that preparation for the annual report to Congress had to begin by the end of the year. Noting a number of participants had travel needs to meet, Mr. Blair deferred reviewing the survey areas where they might seek additional clarification from the SDOs and will e-mail members for comments and suggestions.
Dr. Cohn announced Kathleen Fyffe was leaving the Subcommittee and expressed appreciation for her involvement and participation. Mr. Blair explained to the Subcommittee that in addition to other responsibilities related to the administrative simplification provisions of HIPAA, NCVHS has responsibility for studying issues related to the adoption of PMRI standards , theirelectronic exchange and providing a report to the Secretary submitted in August 2001. That report (available at ncvhs.hhs.gov) had ten recommendations and a framework for how to proceed as a Subcommittee. This meeting followed up on their second recommendation that, by February 2002, NCVHS aimed to make recommendations on PMRI message format standards. The Subcommittee on Standards and Security focused first on message format standards, believing them to be easier to address and bring to consensus. In March, SDOs were asked to review a questionnaire seeking feedback on PMRI message format standards. The questionnaire was updated based on the SDO's comments and was then distributed in April. A report to the group in August summarized findings from many of those message format PMRI SDOs. Today the Subcommittee is seeking responses and insights from vendors and users.
Mr. Dickinson said Per-Se believed it was essential that the standards be from an ANSI-accredited SDO. Main objectives were: openness and inclusiveness, no undue financial barriers to participation, balanced process and membership (i.e., producers, consumers, government, academia, others), open consensus process, and a ballot leading to full resolution of negative comments. Other criteria include: technology independence, completeness of coverage, validation and proof in practice, and market acceptance.
Per-Se assessed HL7 v2.x Data Interchange and ASTM XML Specification standards as: ANSI accredited, open, consensus, and balanced. HL7 had widespread industry acceptance, but Mr. Dickinson said deficiencies remain in enabling a robust EHR. He noted HL7 recognized current deficiencies in section 1.8 of HL7 Standard v2.4. Mr. Dickinson said ASTM lacked validation and industry acceptance. Per-Se profiled DICOM v3 Imaging as a consortia, unbalanced (dominated by producers), and not fully open or consensus-based, but with wide industry acceptance in the imaging market. NCPDP SCRIPT v4.0 was ANSI accredited, open with consensus and balance, but had uncertain industry acceptance. The IEEE Medical Device Communications standard was also ANSI accredited, open with consensus and balanced, but lacked validation and industry acceptance. OMG CORBAmed was another consortia: there was a substantial financial barrier to participation, specifications were technology dependent, and there was minimal industry acceptance.
Mr. Dickinson said HL7 v2.x was most applicable with Per-Se’s products and had the benefit of major market demand. ASTM and OMG were also applicable, but lacked market demand. The domain was not applicable with DICOM, NCPDP, or IEEE. He said HL7 covered about 25 percent of Per-Se’s requirement for interfacing with external or foreign applications. Another 10-25 percent often could be covered with Z extensions. The systems’ architectures were incompatible, and Per-Se ended up with a large disjointed domain and no effective way to communicate information or function.
Mr. Dickinson explained that as Per-Se interfaced with foreign applications with heterogeneous architectures, a loosely coupled paradigm was implemented based on the HL7 v2.x common denominator (scope of coverage included interchanges directly enabled by the specification, trigger events, message segments, data attributes and types, and the v2 vocabulary with its code sets and classification schemes) extended by Z extensions for additional functionality. Mr. Dickinson said achieving full EHR integration and tightly coupled application interchange often involved overcoming difficult impediments (disparities in architectures or lack of will, budget or resources).
Per-Se gauged HL7 coverage against their product and experiences implementing interfaces, framing their assessment in the context of design and trust objectives. HL7 v2.x has about 40 percent coverage of the key design objectives for medical/legal health record and the care continuum. In terms of the timeline continuum, HL7 covers about 60 percent of retrospective, 40 percent of concurrent, and 20 percent of prospective. HL7 covers about half the individual health record and some 40 percent of the health record continuum. In the area of healthcare delivery clinical workflow management, HL7 covers 40 percent of the integrated scheduling, performance, and completion of health service events, but only 20 percent or less of other areas. In terms of functional (business) integration, HL7 has about 60 percent coverage of inter-disciplinary integration and 40 percent coverage of intra-organizational coverage. HL7 covers about 60 percent of the continuity and completeness of the health record and 40 percent of the healthcare delivery process. HL7 has about 40 percent coverage of clinical decision support. HL7 currently has negligible support for clinical-knowledge-base requirements. In the area of localization, HL7 covers about 20 percent of master files, data definition and identifiers; support beyond that is negligible. HL7 support for synchrony is also negligible. In terms of version control, HL7 covers some 20 percent of vocabulary and messaging standard version control, but has negligible support at the application level.
HL7 v2.x has about 20 percent coverage of the key trust objectives for developing a uniform privacy and security infrastructure. In terms of accountability and traceability, HL7 covers about 40 percent of accountable parties and actions, but only 10 percent of accountable agents. HL7 has negligible support for access control, defining discrete privacy, and security policy domains, and single point of administration and configuration across the enterprise. Entity authentication has about 10 percent coverage; data authentication and message authentication about 20 percent. In terms of objectives related to audit trails and audit inspection, HL7 covers 40 percent related to healthcare delivery and workflow events and about 20 percent in the areas of record chain of trust events and record integrity/continuity. V2.4’s coverage of security incident, systems management events, and access events is negligible. With data integrity, HL7 covers about 20 percent of the uniform data definition and vocabulary as well as the persistence, permanence and indelibility criteria; HL7 has negligible coverage for accuracy, consistency and completeness. In terms of health record “chain of trust,” audit events, HL7 has 40 percent coverage of record origination and amendment and verification, but little to offer in other areas.
Mr. Dickinson recommended several references: the ISO 18307 specification Healthcare Informatics-Key Characteristics for Interoperability and Compatibility in Messaging and Communications Standards, ASTM’s Standard Guide for the Properties of Electronic Health Records and Record Systems, and HL7 v2.4, Section 1.8, which describes in detail deficiencies in HL7 v2.
While, in general, Cerner favored any technology that reduced IT costs, Mr. Garton said they were not convinced tightly regulated transaction and message formats, without data content definitions, would reduce clients’ costs. When the transaction or message formats didn’t require corresponding data content definitions, benefits of standardization could not be achieved. Cerner believed data content standards were needed before standardized message formats could be developed and implemented efficiently in the marketplace.
Mr. Garton observed that many standards were owned by multiple organizations and listed or sourced in different ways and locations. A typical HIPAA-compliant enabling interface between two healthcare IT systems could encompass up to 20 different standards. Each was balloted, accepted and updated on its own cycle, many yearly. The standards were controlled by different organizations with different memberships and publication processes. Maintaining currency in each was difficult and expensive. In order to provide a stable environment for implementation, Cerner recommended that regulations that reference standards be version number specific. Regulators should resist the temptation to use the most current versions if benefits of standardization were to be achieved.
He pointed out that investments of healthcare organizations had to be considered. Cerner Corporation, along with their clients, created over 3,500 interfaces that must be maintained and supported. 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 additional confusion, delay and costs--e.g., the confusion created by the delay in finalizing the National Person ID number as part of current HIPAA regulations.
Mr. Garton said HHS’s push to create regulations that force standards into an open market system with relatively short, 24-month implementation timeframes, would increase costs and time commitments, diverting the limited pool of resources from improving the process and quality of the healthcare system. He queried which was more important: reducing medical errors or standardizing clinical data transactions as part of HIPAA?
He noted that Cerner clients request HL7 v2.x standards most. The standard is highly market driven, but no site pushed to v2.4. Most provider sites Cerner supported were v2.1. The major weakness of v3.0 was it hadn’t been proven yet by the market, and so wasn’t ready to be considered a major national regulatory requirement. V3.0’s strength was that it used object-oriented modeling, which was both more flexible, from an implementation perspective, and more rigid from a programmer’s perspective. Balloting by HL7.0 was completed in September and hadn’t yet passed. Cerner received only one request for the IEEE standard for Medical Device Communication; none for COBRAmed or ASTM specifications.
Mr. Garton said Cerner would like to see standards for data definitions and content, via a controlled medical vocabulary, prior to any regulations regarding the format for clinical data messages. A consistent controlled medical vocabulary would not only benefit the message format standards, but was key to the portability of medical records by the mobile population and to comparable outcomes data required to improve the quality of care. Noting there were no well-accepted standards for a comprehensive, controlled medical vocabulary, Mr. Garton recommended that HHS invest in the creation of an affordable, controlled medical vocabulary in synchronization with UMLS and SNOMED.
Mr. Addy said Superior provided expertise to over 1,900 clients and his experience was with product development and interface engines interconnecting and integrating systems in large facilities. He said HL7 was the protocol for addressing just PMRI and not other data issues: HL7 v2.x was the de facto standard for electronic data exchange (ADPAs, orders results, charge information) intra- and inter-facility between systems providing patient care.
He noted pre HL7 integration there were: no integration standards; interfaces were point to point; vendor proprietary fixed-length, fixed-field flat-record messages weren’t easy to extend; adding new data required customization; support and maintenance issues; and the facility’s integration staff required extensive knowledge of each system. Mr. Addy said HL7 was a widely accepted and implemented mature industry standard, forward compatible, vendor supported, customizable with new segments and fields, with dynamic length in both segments and fields allowing substantial, new information to be passed.
Noting most implementations were v2.2, Mr. Addy said there were no business incentives to migrate. Later versions added segments and fields to address data not defined earlier, but facilities addressed undefined data with custom segments and fields. Interfaces were up and running; there was no spur to “fix” them. Mr. Addy commented on several issues: (1) the location of some data was open for interpretation (e.g., enterprise-wide patient tracking numbers or internal note tracking numbers for passing between lab and main order-entry systems), (2) a lack of standardization of field values for facilities and groups, (3) HL7 was not fully integrated by vendors into some products, adding problems into the messages (e.g., some systems still allow the entry of HL7 delimiters in free-text data-entry fields), and (4) HL7 was still an evolving spec for specialty issues.
Mr. Addy said implementation time was a function of vendor systems, vendor specifications, transaction type and the vendor’s and facility’s knowledge base. Simple interfaces took 120-200 man-hours to implement and test on an interface engine--longer if other systems needed to be modified. More complex interfaces took 500 plus man-hours, depending on the complexity of the interaction and “handshaking” between systems. Implementation costs varied depending on the number of systems, interfaces and customization. Mr. Addy noted the lack of skilled integration staff; even the most prestigious facilities used consultants to implement major projects and their own staff for maintenance, support and smaller projects. Interface engines centralized knowledge, which helped small integration staffs, but had a high entry cost.
Superior estimates the cost of a new standard (other than HL7) at about $250,000.00 per medical facility for the interface engine alone. With practices, payers, vendors and supply chain, costs rise exponentially. Other cost considerations are: training and learning curve expenses, integration and retesting of every function of every system in the facility, plus inter-facility messages, HIPAA’s two-year implementation window might not be realistic with current skilled resources, and procrastination by facilities.
Mr. Addy noted later HL7 versions add new segments and fields to address specialty issues. For example, v2.4 added breed and species fields, which benefits veterinarians. He said a simple XML implementation of HL7 would allow position independent data within messages, but added there probably wasn’t enough business incentive to move quickly. Mr. Addy recommended: keeping and building upon current v2.x standards, adding transactions, segments and fields that address issues not currently handled, defining standard field values and vocabulary across systems and facilities, and adding a voluntary migration path to an HL7 version of 2.x XML schema.
Mr. Meyer said only HL7 addressed the full spectrum of message exchange relevant to PMRI. He noted when he talked about vHL7 2.x, he meant the entire suite of message formats: which he described as building blocks. The patient administration message set was the one most widely implemented; other transactions sets built off them or had ancillary functions.
He said IEEE was unparalleled in its ability to communicate patient telemetry data, but its purview was limited to scenarios requiring automated patient monitoring. IEEE filled a unique niche in the conglomerate of information that formed the patient medical record. He considered OMG’s CORBAmed the leader in component-based healthcare messaging, but, by its definition, it was limited to client/server applications and it, too, didn’t support the full and essential exchange of information necessary to qualify as a PMRI messaging standard. Beyond facilitating portal operations, CORBAmed achieved little penetration as a messaging standard in the healthcare environment. DICOM was used widely for the exchange of radiological images. But Mr. Meyer noted it was complex, restricted in scope to the exchange of such images, and had made little or no penetration in the general healthcare market.
He pointed out that ASTM was only represented by two “enabling” draft standards in ballot, which did not serve to enable a higher standard of interoperability. Observing that they were “incomplete clones” of the HL7 Clinical Document Architecture and professed to be CDA compliant, he questioned why an ASTM working group tried to replicate an ANSI-accredited standard without the infrastructure to support implementation. He noted ASTM E31 standards hadn’t received wide spread industry support. Mr. Meyer said the NCPDP SCRIPT standard for a prescriber-pharmacist interface was well conceived, designed and documented--but constrained by definition and domain. NCPDP was the standard in use for retail pharmacy transactions in the United States, and McKesson believed it would be adopted for that domain, but wasn’t a workable solutions for the full spectrum 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 were negotiating a cooperative messaging development agreement, initially focused on vocabularies.
Mr. Meyer said HL7 was the only viable messaging standard relevant to the exchange of PMRI. McKesson has long relied on HL7 as their integration tool of choice and it was broadly implemented within their library of health information technology applications. He noted this was mirrored by general industry acceptance of HL7 as the standard of choice for clinical content. Beyond the domain of the provider-payer, HL7 was the industry leader in health information exchange with implementations reaching beyond the traditional acute care arena. HL7 has 18 international affiliates and was used in such diverse applications as home health, public health reporting of proscribed laboratory results, and the Centers for Disease Control’s (CDC’s) immunization registries project. New Zealand Health Services’ Ambulatory Care Service was based entirely on HL7 messaging.
As a vendor of health information technology McKesson Information Solutions was largely market drive. Customers’ high demand for HL7 led to extensive development and use of the HL7 messaging standard. McKesson had implemented thousands of HL7 v2.x interfaces and consider it the de facto standard for the exchange of PMRI. Given this widespread use, Mr. Meyer said designation of HL7 v2.x as the national PMRI messaging standard wouldn’t be too much of a burden on the healthcare industry. But he added McKesson didn’t believe that decision would benefit the quality and safety of patient care. The current iteration of HL7 v2.x still required significant negotiation to resolve its ambiguities. Many vendors had a long history of conducting such negotiations and developing mechanisms to speed the process. Nonetheless, it was time consuming and expensive. Even though HL7 had committed to continue developing v2.x standards as long as the industry demanded it, there remained the issue of backwards compatibility. He said it should also be recognized that, to a large extent, the insistence on continued v2.x enhancements was driven by international affiliates.
Noting the large number of earlier versions in use, Mr. Meyer applauded the forward thinking in choosing v2.x, given that the current ANSI accredited version was v2.4. This accommodated the installed industry base and might recognize that later v2 iterations should be considered when designating a national standard. But he contended it didn’t think far enough forward. McKesson believed v3--based on a common reference information model (RIM), well-defined methodology, and a comprehensive tool set--was the next generation of healthcare messaging standards, easily extensible to cover all facets of healthcare data interchange requirements. Rather than tie the industry to a given version of a standard, McKesson recommended the process support the designation of HL7 as producer of the national standard and allow the adoption of any ANSI-accredited version. This approach would further validate the dual track approach supported by HL7 and foster systems enhancements supporting the next generation. Mr. Meyer said, after experience with the process of adopting standards for administrative simplification, they shared the industry’s concern that the methodology adopted must improve the timeliness of the process--not mandate adoption of a standard already obsolete.
McKesson was committed to incorporating the v3 process into its product development cycle. While waiting accredited messaging standards, they instituted a process of basing data exchange and integration on the RIM and quasi-proprietary refined message information models. Wherever possible, they used proposed components and stood ready to convert to the accredited messages.
Testifiers described their company’s size and the healthcare segments they served. Mr. Meyer described McKesson Information Solutions as the country’s preeminent healthcare information technology vendor, with over 3 billion dollars a year in business ranging from a single physician’s office to the Mayo Clinic. Mr. Addy said Superior Consultant had hundreds of clients worldwide, contracts with some 1,900 facilities, and about 1,000 professionals consulting on every aspect of healthcare. Mr. Garton said Cerner Corporation had some 3,000 employees and over 3,500 interfaces. Mr. Dickinson said Per-Se had some 6,000 employees in three divisions: software, E Health (a clearinghouse function), and physician services (practice management and billing).
Mr. Dickinson remarked that HL7 had to be extended heavily to implement a robust EHR with communication and foreign applications. Customers often didn’t want to invest in extensions on a site-by-site, case-by-case basis and used a common denominator (HL7 v2.x) that was constrained and lacked messaging and communication interchange requirements. The existing standard had good structures and capabilities, but was far from complete and v3 was a retooling that didn’t cover the extra domain Per-Se thought necessary to implement a robust EHR. Without a security and privacy structure infrastructure in place that included accountability, authentication, and auditability, organizations couldn’t have a robust electronic health solution. With its modeled foundation, Mr. Dickinson agreed that HL7 v3 would improve interoperability and bring the industry closer to plug and play. But he said what was needed for full range interoperability was wrapped up in v3’s interaction models and application roles, which were still so diverse and “fuzzy” it wasn’t clear the claimed interoperability would ever come forth.
As customers weighed cost to benefit, Mr. Garton said they moved to a single repository approach and replacement of product rather than interface. He predicted the next product wouldn’t use another version of HL7, but sit on top the current repository--without any interface. Mr. Addy agreed. The issue was the return on investment to rebuild interfaces and a migration path that could be pursued on an “as needed” basis. Another issue was that v3.0 had to be mature, fully specified--and a one-time cost. Mr. Meyer said he couldn’t disagree about the reticence of the customer base to change interfaces; as Mr. Garton pointed out, that only happened when replacing an ancillary system or the major HIS. But he expressed McKesson’s belief that this activity underway would move the industry toward a more robust, open standard. He recalled that the X12 transaction set hadn’t been accepted or widely implemented when adopted; yet the industry came together, despite extensive costs, because it was comprehensive and did a better job. Given the bureaucracy’s relatively “glacial” implementation process, he said a five-year window for mandate of clinical standards wasn’t unrealistic--And v3 was a viable candidate.
Dr. Zubeldia said it was fascinating to see four vendors agree on one thing: HL7. But Per-Se vied for v2.4, Cerner for v2.1, Superior for v2.2, McKesson v3. He asked how far they should go in their recommendation: Down to the implementation guide--or stop at a higher level? Mr. Meyer opted for designating at the SDO level, with HL7 continuing to evolve enhanced v2.x while moving to accredit v3. He pointed out that half of McKesson’s interaction with laboratory systems was with Cerner and v2.1 and v2.2 interfaces. Vendors had develop a process that supported the full range of available interface implementations, which could be accomplished through an interface engine, as Superior proposed, or a comprehensive software suite that was a back end to the application set that did composition and transferring communications. Mr. Addy clarified that Superior wasn’t advocating v2.2, but believed that’s where the industry sat. Integration people would always be trying to negotiate the details of merging new data types and formats; a good standard locking down as much of the definitions as possible would allow them to move forward. Asked if he was recommending going down to the implementation guide level, Mr. Addy said the comments he heard were about standard definitions for different fields and the data content. When systems first integrated in a single facility, there were problems translating fields between systems; now, so many healthcare groups trying to converse compounded the issue. Mr. Addy clarified common HL7 RIM, LOINC, and/or SNOMED could provide definitions. And he emphasized that, once past v2.1’s and v2.2’s initial learning curve, the handshaking and enterprise tracking numbers, it became easier to interconnect systems.
Even though Cerner had 3,500 interfaces, Mr. Garton said they believed the most effective way to improve the quality of healthcare, run rules, and use a database to its full extent was with a single repository that received information from a variety of sources and locations: e.g., radiology, lab, patient care, home health. Pushing the market to HL7 v3.0 would create an unnecessary demand and cost for Cerner and its clients. Instead, they needed content standards so they knew what they were exchanging was the same across multiple systems. Asked if he meant there should be standard vocabulary and the industry should do whatever it wanted for the interchange standards, Mr. Garton said they should consider the standards released and their timing. Coming out with new standards every 12 months brought considerable cost to the market.
Mr. Dickinson noted the v2.x family of standards was backward and forward compatible from v2.1 forward. Changes to the underlying model in v3 altered the way messages were structured and HL7 would no longer have forward compatibility. He also pointed out that interfacing didn’t yield integration or interoperability. In most cases, interfacing within a common denominator brought much less than was needed to achieve human operability between applications. A big gap would remain for the foreseeable future.
Mr. Meyer noted HL7 had been widely implemented in unique non-hospital environments: (1) McKesson Information Solutions supported communications between acute care and home care facilities, (2) McKesson’s Home Health Division had a process underway to communicate between their home health product, patients, and the supplier of durable medical equipment, and (3) the entire ambulatory care services group within the New Zealand Health Services Organization was based on HL7 messaging. Mr. Addy said Superior mostly supported systems at hospitals and interconnected other healthcare facilities and large groups, but also brought HL7 out to practitioner offices and external labs. Mr. Garton said Cerner also supported home health and ambulatory care. Mr. Dickinson said Per-Se ran the gamut; home care was the one area where they hadn’t done any HL7 messaging.
Asked what business incentives drove the market to v2.1 and v2.2 and why people weren’t driven to v3, Mr. Dickinson said when a new system was acquired, typically one adopted the current version of HL7. Once that investment was “sunk” and everything worked, you left it alone. There was little incentive to go to the next version, unless it had something compelling for that interface. Mr. Meyer observed that when McKesson wanted to promote another version, they ran into a problem inherent in any interface: bilateral function. They couldn’t unilaterally change interfaces, though they could promote it as part of their next release. There was another player, and it was “a love triangle” that often went awry. Installations with multiple versions implemented had started out with an ADT interface and moved up, adding a radiology system that jumped to v2.2 or v2.3, then another ECG or EKG. The capabilities in later versions drove those niche products to support a higher standard, and they interfaced to those. Mr. Addy observed that the original incentive for going to HL7 was that it made the support maintenance costs and knowledge base necessary to do proprietary point to points manageable. From an ADT point of view, once an interface was up and running, you were talking to 20-30 different systems; there was no incentive to change that and face reintegration testing and cause and effect ripples. Another issue was backwards compatibility and the information that would be dropped. Mr. Garton concurred. Without a significant goal, updating interface wasn’t worth an organization’s time or money.
Mr. Meyer explained that he’d recommended that they designate the SDO (e.g., HL7), rather than a specific version of a standard, so the industry could have more flexibility. Interfaces already implemented under HL7 could continue, while they moved forward with new functionality and products driving the next generation. Dr. Fitzmaurice said he’d heard HL7 was the most advanced and most used standard, and that a common medical vocabulary (or, at least, a data dictionary) was needed. But he suggested a larger question was how they’d record and transmit EHR--How they’d transfer images or prescribe outside the hospital setting. As they moved on from EDI (e.g., sending information through the Web) it might be important to replace technologies, but they couldn’t veer from vocabulary and content. Should NCVHS push toward a common medical vocabulary or data dictionary, not bound to existing technology but looking forward to higher-level versions that brought them to future ways of transmitting this information? Mr. Dickinson expressed concern about controlling medical vocabulary within standards. Data interchange occurred at the back end, but clinical practice was front end. If standards weren’t visible up front, fidelity and authentication were lost in translation. The issue was how to practice medicine at--and insure the vocabularies were used at--the clinical front end. Information capture needed to be irrefutable without the original.
Mr. Addy agreed with the summary points. But, noting the tremendous overhead cost and “hit” to healthcare and the hangover from Y2K, he cautioned against doing everything now. Mr. Meyer said the summation reflected exactly where HL7 was driving with v3, which recognized the importance of standard data types and vocabularies and sought methodologies for implementing within the context of a diversity of technology specifications. V3 kept as independent and clean as possible. Echoing Mr. Dickinson’s response that whatever was done in the back end had to be compatible with the way medicine was practiced, Mr. Meyer noted HL7’s diverse membership included many clinicians representing practices and facilities so focused on patient care and the impact of common vocabulary, it sometimes became their major topic.
Mr. Guinan said ProxyMed, one of the largest healthcare EDI companies, primarily provides EDI services (encompassing all business and clinical transaction sets) to the physician community. ProxyMed, the second largest medical claims clearinghouse and major provider of laboratory result distribution devices and services, operates the oldest and largest physician-to-pharmacy network. PreScribe.net, with over 5,000 registered physicians, has processed more than 10 million EDI e-prescription transactions. ProxyMed also provides software applications and Web-based application services to facilitate e-prescribing and connectivity to pharmacies. Over 1,600 physicians use their e-prescribing system.
Noting ProxyMed lacked guidance on implications of HIPAA for their pharmacy and lab EDI businesses, Mr. Guinan emphasized the importance to their business of establishing operating policies and procedures that applied to all transaction sets. Different regulations across sets and being covered as provider for some transaction sets, but business associate for others, increased implementation and ongoing costs and confusion. Pointing out that the transactions’ content was equivalent in terms of need for privacy, confidentiality, and security, he recommended that the physician-to-pharmacy e-prescribing transaction set be addressed and covered by HIPAA and that NCPDP SCRIPT standard be adopted as the standard for these transactions. ProxyMed participated in NCPDP SCRIPT work groups and Mr. Guinan said they were satisfied NCPDP SCRIPT standard v1.5 met this transaction set’s requirements and that NCPDP would evolve the standard to meet emerging needs. Modifications to v4.2 would not be costly to implement and ProxyMed supported pushing forward with future versions.
As a network service provider, ProxyMed had used the SCRIPT standard to implement physician-to-pharmacy connectivity for a broad, diverse set of trading partners including: seven physician office software vendors, three EDI networks, two major retain pharmacy chains, the three largest pharmacy software systems, one of the largest pharmacy benefit managers, and a large health system with its own in-house electronic medical records system. Mr. Guinan said the most prevalent version (1.5) was sufficient for current functionality requirements (except for code sets issues), but he suggested the segment of the pharmacy industry linked to physician-to-pharmacy connectivity would benefit if v4.0 or higher were mandated, forcing participating companies to become compliant. A large number of these interfaces were implemented and worked well, but interoperability issues surfaced as more companies used these interfaces. Mr. Guinan recommended the government mandate a more current standard.
Mr. Guinan said the cost of developing and implementing an interface using the SCRIPT standard to connect to PreScribe.net was around $25,000 for a standard interface. Ongoing interface and services support fees to vendors were on a negotiated basis. ProxyMed also distributed developer tool kits based on the SCRIPT standard that include: implementation guides, software programming objects, and, in some cases, complete communications applications. Mr. Guinan said organizations have implemented the SCRIPT standard in 60 days with the SCRIPT standard and tools. ProxyMed implemented the SCRIPT standard using XML with two training partners and built XML-based tools into the tool kits. Mr. Guinan said XML was their method of choice for data representation in transactions and data storage.
Mr. Guinan noted three code sets needed improvement and support by the federal government; (1) there was a complete lack of national standards for unique identifiers at the heart of SCRIPT, including unique IDs for physicians, physician office locations, patients and drugs, (2) the routing of SCRIPT physician-to-pharmacy messages was based on IDs for physicians and their physician offices, yet there is no unique ID for either entity, resulting in a proliferation of proprietary ID schemes and interoperability issues, and (3) the physician ID issue extended to ProxyMed’s other EDI transaction sets, including especially lab-related transactions. Mr. Guinan emphasized that lack of a standard patient identifier resulted in substantial problems in transferring PMRI. Mistakes made in merging patient data from transactions could have severe consequences to the patient if the data was applied incorrectly. The lack of standard identifiers for physicians and patients was perhaps the single biggest issue in deploying physician-to-pharmacy connectivity.
Mr. Guinan emphasized the need to advance the content of the messages between physicians and pharmacies, if physicians were to adopt these systems. A lack of proper identifiers resulted in a loss of functionality and applications had to be “dummied down” because enough data couldn’t be provided in the message to perform advance drug interaction checking. He also suggested that mandated standards tighten up the use of optional and mandatory fields. Although the rationale behind decisions to make a data element optional were logical and, on their own, probably correct, they often resulted in interoperability issues.
Ms. Kennedy said Siemens was firmly committed to the development of industry standard message formats and vocabulary and incorporated them into its line of integrated solutions to the healthcare industry. (Clinical specialities served by Siemens Medical include: diagnostic imaging; audiology; picture archiving and communication systems (PACS); healthcare information systems; and oncology, critical, and respiratory cares.) She agreed that HL7 and DICOM were the dominant standards for the exchange, management, and integration of structured clinical data and images across all healthcare settings. Both standards address Siemens’ highest priorities for exchanging PMRI electronically, but to be comprehensive she said they must be supplemented with person identification, security and vocabulary standards. HL7 v2.2-2.4 were used for the bulk of Siemens’ structured clinical data exchange; DICOM v3 was used for multimedia interfaces. She said they were the only logical choices for clinical interfacing.
Ms. Kennedy said HL7, the message format of choice in the United States and many countries, was the widely adopted, ANSI-approved standard for the exchange of clinical data. HL7 proved it was flexible enough to accommodate the data diversity that existed across all case settings in the healthcare community. Many government organizations moved towards embracing HL7, including the Centers for Medicare and Medicaid Services and CDC. HL7 had 14 international affiliates and was submitting HL7 v2.4 to ISO for approval. Most these points also applied to DICOM. Virtually all suppliers of imaging products adopted DICOM, which provided a comprehensive set of services fully supporting radiology workflow. It was international in scope, involving more than 50 industry vendors, with strong market visibility.
Ms. Kennedy said Siemens used HL7 for communication within its applications and across various healthcare settings in their own and other systems. Customers implemented thousands of interfaces using the HL7 standard supported in Siemens’ integration engine. Without a standard, she said each interface would have required significant analysis and higher implementation costs. With HL7 and DICOM, method and structure were predefined and the effort focused on the data content and requisite mappings to other systems’ data requirements. The bulk of the costs were incurred developing interfaces mapping to and from non-standard vocabularies. Greater stringency and conformance requirements built into DICOM streamlined implementations. Complexities still arose when dealing with old machines and old DICOM (and HL7) versions.
Ms. Kennedy cited reasons HL7 v2 fell short of achieving plug and play: (1) lack of a common vocabulary pertaining to data elements defined within medical and non-medical coding systems, (2) elements of the standard were subject to broad and non-standard usage that often conflicted with the data element’s named, (3) overuse of the optional attribute for HL7 data elements, and (4) relatively little conformance testing of message format standards. She noted some issues were addressed with v2.4. Products designed to interface with HL7 v2.x couldn’t work together without site-specific negotiations, increasing implementation time and costs and making meaningful certification testing impossible. DICOM confronted similar problems, but its concept of conformance helped overcome different interpretations. Both HL7 and DICOM are working towards improving interoperability. Their joint work group’s main goal is harmonization of the standards, bringing information and imaging systems closer together.
Ms. Kennedy said HL7 v3 promised to enable interfaces that came closer to out-of-the-box plug and play compatibility. V3 messages were derived from formal, rigorous models developed within HL7 technical committees. Capitalizing on the effort to fully understand and depict the healthcare process through object-oriented design techniques and widespread stakeholder involvement, message models reduced the need for optional data elements. HL7 Vocabulary Technical Committee was also directly addressing v2’s major deficiencies.
Noting there wasn’t time or money for other standards, Ms. Kennedy advised giving priority to HL7 and DICOM. Migrating from HL7 v2 to v3 would require significant effort and the critical domain had to follow the financial X12 lead and establish clear, specific message guidelines for data definition. Ms. Kennedy said the federal government could have significant impact in standardization of vocabulary by: (1) limiting the number of SDOs operating and encouraging HL7 and DICOM to continue working together, (2) adopting one or more non-overlapping clinical vocabulary standards, (3) leading in development of reference terminologies at the integration point, and (4) placing the adopted standard in the public domain and the SDO process.
Ms. Kennedy said Siemens’ believed the federal government could best help by: (1) providing much-needed financial incentives to increase private sector participation in the development and implementation of appropriate standards; (2) participating itself in these standard setting efforts; (3) using these standards within the government; (4) endorsing medical terminology standards proven and integrated into a consistent, systemic terminology model; and (5) taking an active role in this effort and using the terminologies within their systems. Ms. Kennedy emphasized that changes won’t occur without clear financial and regulatory incentives to invest in change. HIPAA and future legislation and regulations must require that standards, once defined and adopted, are fully integrated into the healthcare system if the overall health of populations was to be improved.
Dr. Aita said MedcomSoft’s new generation of electronic patients record systems support the capture, aggregation and secure communication of structured and codified records. The MedcomSoft platform was developed to facilitate the business transaction and the exchange of information between all entities in the industry. MedcomSoft adopted the highly structured Medcin Nomenclature to capture clinical data. Dr. Aita said the nomenclature facilitates the degree of granular detail required for medical documentation standards in a codified format. MedcomSoft implemented within its data engine the ANSI X12 for claims data transmissions and the HL7 standard for other patient-related medical transactions. MedcomSoft’s data engine supports HL7 standards v2.1 to v2.3 with all transaction sets. They are implementing HL7 v-3.
HL7's earlier versions used informal, ad hoc development methods and lacked plug and play functionality. V3.0 introduced more formal development methods used in object-oriented analysis and design techniques. The use of the Message Development Format (MDF) and RIM provides an advanced and comprehensive object-oriented information model for clinical healthcare. The increased specificity of the RIM in v3.0 enables greater interoperability between healthcare information systems. However, even with XML’s support in v3.0, problems of semantics weren’t resolved without significant effort. XML was rapidly becoming the data portability standard enabling exchange of information between many systems, but Dr. Aita predicted it would take several years to build a semantic foundation for healthcare interoperability that positioned v3.0 to take advantage of XML.
The HL7 messaging format had become the industry’s de factor standard for communicating patient-related clinical information. Using HL7 format, the MedcomSoft system communicated with most third party vendors and other healthcare participants with similar systems. The initial implementation took 12 months. Support for higher versions was completed in two weeks. Dr. Aita anticipated implementation of v3 would require at least 18 months, due to the new record structure and XML. MedcomSoft implemented v3 because it matched their system’s future architecture and flexibility. Development costs include: 20 person-days for education, three person-years for the interface engine, 20 person-days per message set, 10 person-days-per-year for the custom coding, and 10 person-days-per-year for maintenance. Membership is $3,500.
Dr. Aita noted HL7’s three advantages: the simple protocol to implement and understand, the complete set of messages for application integration, and wide industry support of messages. She also recognized HL7’s weaknesses: (1) the organization didn’t provide a mechanism for testing; (2) the openness of user-defined segments could lead to extensive vendor customization, interfering with timely, low-cost systems integration; (3) a lack of implementation guides left too much room for vendors to develop their own implementation guides; (4) the more information exchanged between systems, the higher the likelihood the interfaces wouldn’t work properly; (5) lack of a certification body that provided conformance testing; and (6) lack of standard codes to ensure the format and content of the transmitted message.
MedcomSoft recommended: (1) the Committee support the appointment of an organization to facilitate testing and provide the proper mechanics for vendor compliance and certification, (2) a specific but standard implementation guide employed by all vendors for each kind of PMRI message, (3) the organization provide a means for testing implementation of each transaction set the standard supports (e.g., a Web site for vendors to send messages and receive message format validations), (4) creating mechanics for certification, (5) creating one standard format with both healthcare terminology and message format standards, and (6) message formats that establish minimum and maximum data elements, providing a common reference point for all vendors.
Dr. Aita reiterated that HL7 should remain the preferred messaging standard, with an additional broadly accepted scripting standard, such as NCPDP messaging standard. Dr. Aita noted that NCPDP’s Telecommunication Standard v5 Release 1, already named in HIPAA’s final rule, dealt primarily with direct electronic submission and adjudication of transactions in an online, real-time environment and had huge implications for pharmacies. However, the NCPDP SCRIPT standard, which was developed for the purpose of transmitting prescription information electronically between prescribers and pharmacists, seemed the most relevant NCPDP standard for MedcomSoft’s purposes. It adhered to UN/EDIFACT syntax and, where possible, utilized standard EDIFACT and ASC X12 data tables. The standard addresses electronic transmission of new prescriptions, prescription refill requests, prescription fill status and cancellation notifications. Dr. Aita also noted the NCPDP v5.0 standard was comprehensive and included many extensions (e.g., controlled substances, eligibility, and drug utilization). Previous experience with the conversion of claims adjudication software to incorporate NCPDP v5.0 standard format versus NCPDP v3A standard format required 3,857 hours of development time at an internal cost of $212,570. This included only the new NCPDP v5.0 formats related to claims processing.
Dr. Aita pointed out that many data items in NCPDP v5.0 duplicate items in the HL7 standard format, particularly as it relates to patient information. Duplications in NCPDP should be eliminated, while still providing NCPDP as an extension to existing HL7 data standards. Dr Aita encouraged creating a medical vocabulary standard to help providers at the point of care adopt electronic medical records.
Asked whether the NCPDP SCRIPT should be considered part of PMRI or be an administrative transaction, Mr. Guinan said if clearinghouses had to handle financial and clinical transactions differently to comply with regulations, they’d need two different companies and two sets of costs. He contended they shouldn’t be classified a business associate for some and covered provider for others; the policies imposed and the compliance effort should be the same. Dr. Aita suggested SCRIPT could be included as part of the clinical set, because of some extensions and the way it handled prescriptions. Mr. Guinan said it shouldn’t be considered a loose clinical transaction, but covered more like the administrative transactions, nailing down as many aspects as possible--wiggle room in the standard caused the biggest problem in implementing. Even with the small number of organizations participating, there were interoperability issues; pharmacy benefit managers and retail pharmacies with different business goals pushed things apart. The more stringent the implementation guide, the more value they’d get from the transaction. Dr. McDonald remarked it wasn’t fair to characterize clinical transactions as loose and sloppy and others as defined. Clinical areas couldn’t be defined as well as machine-to-machine. Any physician knew trying to represent a prescription as an NDC number wouldn’t work. He noted HL7 and FDA were working on what might be described at the clinical level granularity.
Mr. Guinan said that, from a practical standpoint, the solution to the drug coding problem probably would be a solution layered on top of the NDC code set. The cost of starting over would be enormous--Instead, they might devise a scheme at a different granular level than the NDC, and, as suggested, use the HL7 standards body to carry forth this vocabulary issue. He noted NCPDP did a good job of adopting the other X17 code sets. He suggested one organization should be responsible, and the other could adopt that code.
Dr. Aita reflected this was broader when you looked at the granularity of the code to adopt, especially when there was a specific action, such as drug interaction. The industry viewed drug interaction as drug-to-drug, but actually it extended to drug-to-condition, drug-to-applications, drug-to-pregnancy. Clinical information needed to be structured to perform that task. Standards that hook with these extensions came from a pure, clinical condition that had to provide the data to do the transaction: e.g., not only tie to its chemical composition, but to functionality, grouping all beta blockers together. Dr. Aita said they mapped the FDB database to the Medcin database and had a total inter-organization between them in doing drug interaction to conditions, lactation and pregnancies, without being confined to the structure of FDB, but using all the extension of Medcin that classifies drugs in a logical, clinical way.
Asked about NCPDP’s efforts at eliminating the optional data elements, Mr. Guinan said there were gains, but some of the work group’s livelier discussions still revolved around this issue. Without a business reason, it would take an outside force to move it along. A nudge from the Committee could help. Dr. Fitzmaurice questioned if problems with the HIPAA transactions and codes and the privacy rule weren’t enough of a spur. Mr. Guinan replied everyone still waited for guidance on how that applied to the transactions.
Given the number of organizations with interfaces up and running and interfacing lab data and other information, Ms. Kennedy said it would be naive to start with v3 from scratch. She noted changes that needed to occur at the database, application and messaging level would take significant effort--They needed to work with existing organizations to integrate v3. Asked if this implied a business need for another interface (e.g., HL7 and a v3 interface to convert things to XML), Ms. Kennedy said they could have a migration layer. Scraping what existed and doing a conversion overnight would be potentially difficult, but could be done incrementally, incorporating components of HL7 v3. Dr. McDonald commented that most people assumed the messages being balloted for v3 corresponded well with v2 messages, even though there was no obligatory backward compatibility, and that interface engines would make those transitions. Ms. Kennedy said they’d begun educating on advantages of v3, but in light of declining revenues and reimbursements, vendors were challenged trying to create the business case for end users. Unless a system or vendor drove it, there was no intrinsic benefit or business value in moving towards a newer version. Until the government took a leadership role in driving this forward, they were challenged with capturing information at the point of care and communicating it within facilities and across the nation in order to identify outcomes. The biggest business driver they had to bring to facilities was patient safety, but that was always a challenge.
Dr. Aita said it was difficult to recommend whether HHS should fund implementation guides for v3 or for v2.x or both. MedcomSoft had to adopt versions widely used and be backwards compatible because they had to interface with institutions with no other capacity. But their recommendation was to support implementation of v3.
Mr. Blair clarified that Dr. Fitzmaurice’s summary of recommendations at the end of the first panel converged closely with Ms. Kennedy’s view of major areas of focus for the Committee in terms of improvements in PMRI standards: the data security area (which Mr. Dickinson referenced in the previous panel); greater interoperability; and better data definitions, terminologies, and the standardized codes around them. Mr. Blair said he heard everybody indicating that: (1) HL7 v2.x was the de facto standard; (2) any new versions had to be justified by business case issues; (3) until v3 was further along, business case issues weren’t a driving factor; and (4) they wound up with interoperability issues where they couldn’t move without business partners willing to work on a new version. They seemed to be saying any NCVHS recommendations should recognize HL7 v2.x as the de facto standard and not threaten user and vendor investment in HL7 v2.x. He also heard from Dr. Aita, Ms. Kennedy and Mr. Meyer about a dual strategy recognizing v2.x as de facto, but also considered incentives to accelerate or strengthen development of v3.
Dr. Aita concurred. Non-adoption of electronic medical records stemmed from the fact that existing medical records produced text at the end that wasn’t easily aggregated and couldn’t be analyzed or left to the computer to use. A new system with codified, structured clinical data would trigger a quantum leap in the adoption of vocabulary--and demand for v3. Ms. Kennedy agreed. From a business perspective, driving forces around safety, outcomes, and improving the process of care delivery made current versions and v3 attractive.
Noting virtually every testifier emphasized the need for a common medical vocabulary (a major focus in 2002 for the Subcommittee on Standards and Security), Dr. Fitzmaurice asked why MedcomSoft chose Medcin nomenclature over SNOMED. Dr. Aita said the 72 links between Medcin’s data elements enabled a presentation of the point of care that let the physician assimilate the data and capture and quickly view clinical information structured the way the physician worked. Dr. Aita said Medcin was the only nomenclature that allowed the physician to transform the practice of medicine “from an art to an absolute science.”
Noting everybody else talked about facilitating customization of the interface through the interface engine or using the same standard with interoperability, Dr. Zubeldia asked if the conformance testing Dr. Aita sought wouldn’t stifle flexibility. Dr. Aita said that depended on whether they looked at a broader end result where the data was exchanged across facilities, regardless of the business relation, or looked to facilitate customization between entities. MedcomSoft took the broader view, wanting regulation to ensure everyone could read a message standard adopted. MedcomSoft didn’t believe in interface engines, even though they had to use them, because that meant translating rather than having the same data field in the same structure. Dr. Aita reiterated that the more they structured upfront, the less interfaces and customization were needed at the end.
Mr. Guinan added that the National Association of Chain Drugstores (NACDS) proposed a similar idea. Sure Script was to act as a certification body for the implementation of any standard the industry chose. NACDS agreed that an accreditation body, monitoring, and ongoing compliance as everyone changed systems and software would help compliance and lower its cost. Noting the Committee had decided to push for conformance testing, Dr. McDonald said he didn’t think they were dealing with a contradiction; there was value to users in knowing this was at least in range. Dr. Zubeldia said he was a big proponent of performance testing and compliance, but expressed concern it could stifle implementation of HL7. Dr. Aita clarified that MedcomSoft was recommending that a government-regulated organization be established and funded that let people behind the standard do the conformance testing and take the mandates off implementing the rules.
Dr. Aita said institutions had as much interest in HL7 and X12 as a single doctor’s office. The core, clinical part of a patient’s medical record and the way the provider worked on it was the same; only the interfaces differed. Ms. Kennedy concurred. Siemens had experience with HL7 and DICOM in the emergency, critical care, medical surgical unit, physician offices, ambulatory clinic, and home health areas. Mr. Guinan said ProxyMed participated solely in the ambulatory physician marketplace, connecting the physician’s office with its business partners.
Mr. Blair asked for Dr. Aita’s perspective on which HL7 messages met his companies needs from an ambulatory and Internet perspective. Dr. Aita said MedcomSoft believed that, in terms of electronic patient records, there wasn’t a difference between any sets of institutions because, ultimately, a proper electronic medical record had to go through institutions to give continuity of care. They had to think of the medical record as a separate entity in order to understand how it would operate between institutions and how messages would be exchanged. But they were most interested in working towards proper aggregation of data passing between systems. Proper disease management depended upon the data collected in one institution integrating with the data collected in another--allowing providers to instantly view it in an integrated fashion and act on the patient. Dr. Aita depicted electronic medical records as a spreadsheet. On one side were data elements; on the other side, time. Value was given to each data element in time. The vendor system, itself, was irrelevant, so long as the end data in each cell of the spreadsheet pointed to a data element that was codified and pointed to time and patient. Any data elements could be graphed and aggregated together, providing a total view of the electronic medical record. Ms. Kennedy commented that nurses collected much of this data and needed a common reference terminology.
Allscripts recommended including electronically transmitted prescriptions and computer-to-computer communications between physicians and pharmacies within the electronic healthcare transactions and adoption of the SCRIPT Standard message format. Over 5,000 physicians use Allscripts’ wireless applications for e-prescribing, lab orders, dictation and charge capture. Allscripts’ Rx+ software performs drug utilization review (DUR) against other drugs prescribed for the patient to identify drug interactions, therapeutic duplication or drug disease contra-indications, and alerts to possible problems with drug allergy and dosing. The Rx+ software indicates whether the chosen drug is included on any formulary administered by the patient’s prescription drug benefit plan; if not, it identifies formulary alternatives. The software creates a legible electronic prescription and offers three options: printing a hard copy the patient takes to the pharmacy, electronically faxing the prescription from the physician’s computer to the pharmacy, or electronically transmitting the prescription between computers via SCRIPT. While all three formats are superior to handwritten prescriptions, Dr. Berman said the computer-to-computer format, which eliminates rekeyboarding the prescription, holds the most promise for decreasing medication errors. Some mail service pharmacies and the largest chains have begun implementation, but computer-to-fax and electronic paper prescription formats still dominate.
Allscripts implemented SCRIPT Standard in 1998 at a cost of about $25,000. Implement took about two months. SCRIPT Standard transactions are routed to the pharmacy through a switch; about six weeks of testing was required for each connection to a new switch. HL7 has a message standard supporting inpatient drug orders, but only SCRIPT Standard addressed requirements of outpatient prescription transactions. SCRIPT Standard supports: new prescriptions from prescriber to pharmacy, requests for refills or prescription changes from pharmacy to prescriber, and prescriber responses. Although agreement remains to be reached on common code sets, identifiers and data elements, Allscripts was satisfied with the SCRIPT Standard message format.
Allscripts utilizes v1.5, which is used by the few pharmacies that have implemented electronic prescribing software, and will upgrade to v4.0 as pharmacies implement it. Recommending flexibility in adopting a specific version, so the rules do not mandate obsolete versions, Dr. Berman suggested choosing the version in current use and subsequent releases.
Mr. Wagner said the VHA is a major user of message format standards for the exchange of PMRI. VHA first implemented HL7 v2.1 in the early 1990s and has had experience with almost all of the standards except the IEEE medical device standards. He noted the standards identified didn’t address the high priority area of vocabularies and code sets.
VHA participated in and was a co-chair of the ASTM E31.25 Subcommittee. VHA implemented the Draft Specification for Health Care XML DTDs as a demonstration project. DTDs developed were based on HL7 CDC and designed to provide detailed healthcare information normally associated with level 3 of the HL7 CDA. Mr. Wagner said issues encountered in implementing the draft specification were due to a natural disconnect between the currently defined level 1 header of the HL7 CDA and a level 3 implementation, since level 2 CDA wasn’t yet fully defined. VHA believed once level 2 was fully defined and the DTDs were revised, ASTM XML DTDs would be useful standards for exchange of PMRI.
VHA found the DICOM v3.1 standard a relatively easy upgrade. Noting they issued a set of requirements further limiting optionality, Mr. Wagner said v3.1 was comparatively easy to use. V3.1 met VHA’s needs and they reported no major weaknesses. VHA was evaluating structured reporting, which he said would be useful for exchanging imaging reports.
VHA had implemented and/or evaluated nearly all the listed HL7 standards. Mr. Wagner said even earlier 2.x versions met many VHA’s needs and each release improved. However, they require extra work to implement due to optionality, a problem he expected v3 to reduce. VHA had only implemented a v3 demonstration project based on the clinical document architecture (CDA). Mr. Wagner predicted the messaging portion would be a significant improvement over v2.x. He noted only level 1 had been implemented and CDA currently met only a limited amount of VHA’s needs. But VHA believed most its needs could be met, once level 2 was fully defined. VHA hadn’t yet implemented or evaluated NCPDP v4.2 or the prescriber-pharmacist part of the standard, but Mr. Wagner said the part of v3.2 related to claims submissions met VHA’s needs. They also found v5.1 (the version required by HIPAA for claims submissions) acceptable.
As a part of the Government Computer-based Patient Record (GCPR) project, VHA evaluated and implemented the OMG Person Identification Service (PIDS) specification and the OMG Clinical Observation Access Service (COAS) specifications. Implementation of both standards, including training, took about 18 months. Mr. Wagner noted both had minimum functionality compared to more robust implementation of these standards, but were reasonably easy to use.
Mr. Wagner noted the need for a scanned document standard that includes file format and annotation capabilities. He suggested DICOM, which already has annotation capabilities, could be enhanced to handle document images. He also identified the need for an EKG standard, a project he noted DICOM was already working on.
Dr. Overhage explained that researchers from the Regenstrief Institute organized the ASTM committee that originated HL7 standards in the 1980s and remain involved in evolving HL7. He spent six years implementing a city-wide electronic medical record project, INPC, that 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 inpatient and emergency department care in the Indianapolis metropolitan statistical area, as well as a significant fraction of the outpatient laboratory and radiologic services. Laboratory result data and most encounter data are received directly from the hospital’s operational systems in HL7 format. Pulmonary function test results, electrocardiographic reports and tracings, radiologic reports, echocardiogram reports, emergency department triage records, physician notes, vital signs from bedside devices, and about a dozen other reports are received from hospitals. Emergency department logs and other data not received as HL7 are converted and processed for storage. About a-quarter-of-a-million HL7 messages are processed daily.
Most messages conform to v2.2, but v2.1 and v2.3 are also accepted. The addition of richer data types (e.g., extended person name) in recent versions extended functionality. DICOM is also used to receive and process radiographic, conventional radiographs, CT, MRI and Ultrasound images (and, soon, echocardiographic and gastroenterologic). Software links images to reports describing them, and they can be retrieved and manipulated using a Web-based image viewer built into the electronic medical record.
INPC utilizes HL7’s plug and play capability to provide an electronic laboratory reporting function for public health. The electronic lab reporting system capitalizes on the HL7 message processor that reads each message, parses out separate components, and determines whether the result bears evidence of a reportable condition. If so, the software places a copy into another message cube serviced by a reportable condition processor. The software uses the wire tables (CSTE CDC) utilizing LOINC codes to define reportable conditions. INPC has identified and stored reportable conditions in real time for over three years and these data are available to the county and state health departments for use in case findings and surveillance. Ongoing evaluation studies indicate INPC identified cases sooner and more completely than traditional reporting methods. Dr. Overhage noted the system demonstrates important components of CDC’s National Electronic Diseases Surveillance System (NEDSS) project.
Dr. Overhage said HL7 and DICOM work well as a foundation for building a community-wide electronic medical record. HL7 was chosen for the INPC project because: (1) it is the most widely supported message standard for the exchange of clinical information between computer systems--80 percent of hospitals in a 1998 survey of CIOs reported they used HL7 and 13 percent expected to in the near future; (2) fields contained in HL7 messages have clear semantic homes in INPC’s databases and the message content is easily mapped into INPC as information models; (3) a single set of monitoring and control functions manage all the data flows; and (4) performance is acceptable--today’s hardware systems process the large volume of HL7 message expected to be created in a large integrated delivery system or, as INPC demonstrates, over an entire community.
Message preprocessing software in the stream modify messages to conform to the HL7 standard. The most common variance was data misplaced in HL7 fields. Units, normal ranges, and results were often sent as separate HL7 OBX segments. Alternatively, the OBX 3 field, designed to carry actual results, also contained normal range, units, interpretive comment, and information about the test location. Problems increased as other systems passed 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 INPC, could become less structured in the process. In recent years, HL7 messages created by clinical computer systems conformed more to the standard and required less preprocessing. A typical new interface required only one man-day. Ongoing efforts educating software developers and vendors on how to implement the standard would accelerate this process. HL7 v3 RIM, with its clear descriptions and precise definitions, would help ensure that developers create HL7 messages that conform to the standard
Dr. Overhage summarized that they had created a community-wide electronic medical record system using HL7 as the primary message standard. HL7 was a workable choice for information exchange in a heterogeneous environment and, along with DICOM and Internet standards, met current and immediately anticipated needs. INPC planned to evolve to HL7 v3.0 as developers of commercial clinical information systems deployed that capability. But he noted there was no reason to wait until v3 to take advantage of the functionality provided by current versions.
Dr. Huff said Intermountain Health Care was a not-for-profit healthcare provider with 22 hospitals, numerous urgent care clinics and emergency rooms, and a health plans division. Dr. Huff manages the interface and data dictionary/coded terminology teams. A dozen people create and maintain interfaces, eight maintain coded terminology for IHC’s electronic medical record.
IHC primarily uses HL7 and DICOM. HL7 is used to interconnect outpatient and inpatient systems, accept data from stand-alone emergency room, pathology and external transcription systems, and share immunization data on children with the Utah State Health Department. IHC processes about a million transactions per day of HL7-formatted data. Some 20 kinds of HL7 messages (e.g., source of records; laboratory and microbiology orders; medication orders, allergies and administration; and microbiology results) are used in their environment. IHC has over 200 running incidences of HL7 interfaces connecting various hospitals, facilities, and laboratories.
Dr. Huff said IHC found an important role for the C-CAL standard (not a traditional messaging standard) in integrating the state immunization database into applications and sharing that data within IHC. IHC primarily faxes prescriptions from their systems to outpatient pharmacies. Interfaces vary from v2.2 to v2.3.1. IHC is testing and upgrading some versions to v2.4. Dr. Huff noted HL7’s backwards compatibility requirements make transitions easier. IHC chose HL7 because key vendors and commercial interface engines support HL7; consultants and program managers are on hand to install interfaces; interface development kits, tutorials, and training materials are readily available; and an open, consensus SDO is responsive to needs. He noted HL7 is: (1) “intuitive to people who work with clinical data” and easy to understand, (2) allows for integration of standard terminologies (e.g., LOINC and/or SNOMED, or other standardized drug terminologies) as an integral part of the standard, and (3) allows appropriate references to those external vocabularies. He agreed a lack of standard terminology was the biggest problem.
Depending on the interface, implementation took a week to six months. Simple interfaces (e.g., admit, discharge, transfer) in use longer and more standardized set up quickly. Anything more complicated (e.g., microbiology culture results) took longer to match up data models, terminology and process and learn how to update. Purchasing interfaces from vendors cost from a couple thousand dollars up to $25,000, based on the number of kinds of transactions supported in the interface. The most extensive work was vocabulary mapping between sending and receiving systems. Once implemented, interfaces were easy to use and maintain.
Lack of a standard terminology also meant people couldn’t do standard kinds of conformance testing for the interfaces. LOINC served a strong role in laboratory data and IHC was beginning to use clinical LOINC for some typical clinical measurements. Dr. Hoff said the single most important need was for a standard for signs, symptoms, and clinical diagnoses. He recommended implementation guides for high-volume, highest-return transactions that removed vagueness and specified terminology for particular messages.
IHC has done early prototyping using the v3 data type standard, but hadn’t tried to implement a prototype for v3 messages. IHC anticipated moving to v3, but Dr. Hoff echoed Dr. Overhage’s comment: a lot could be gained by standardizing v2. IHC had a million transactions a day of v2.4 non-compatible data; it would be premature to go to v3.
Dr Hoff remarked that DICOM was less visible in IHC because it came bundled with the PAC system and was part of instruments and devices used to collect digital images. He said IHC didn’t use the visible light supplement or structured reporting capabilities of DICOM; structured reporting heavily overlapped with HL7, and IHC didn’t want to support two ways to send clinical data between systems. All clinical data went in HL7; the image data was sent in DICOM.
Vocabulary mapping and aligning information models and terminology roughly gauged DICOM implementation across interfaces. Typically, this required three months work. Interface costs came bundled with the system; Dr. Hoff estimated implementing DICOM interfaces throughout IHC’s enterprise cost between $75,000 and $125,000. He noted DICOM interfaces were stable and hadn’t caused any problems. Dr. Hoff’s major concern was that DICOM standardized less than he’d expected. Internally, it involved standard wraparound proprietary image representations rather than a truly application-and-vendor-independent rendering. Dr. Hoff suggested the next generation might resolve these issues and some more broadly Internet-based technologies (rather than medical technologies for imaging) might gain market share and acceptance. He reiterated that the biggest improvement for DICOM would be standardizing terminology. DICOM used parts of the SNOMED subset to represent body locations and the dyes and radioisotopes used in procedures, but wasn’t standardized on diagnosis names or other clinical day-to-days associated with the x-rays. IHC hadn’t investigated future versions, and used the current DICOM.
Dr. Huff elaborated on how DICOM was a wraparound of the proprietary representation supported by the vendor that branched down and encapsulated the vendor’s non-standardized bit-level representation. Going from one vendor to another required interfacing and, with bit-level differences, it wasn’t clear transformation was fully possible. Asked if this required another proprietary view, Dr. Huff explained people had generic DICOM viewers, but another layer down support specified particular binary formats or “flavors” of DICOM protocol that interface or viewer supported. DICOM images were stored in a DICOM archive. When rendered for viewing on the Web, that image was transformed into an Internet standard image transmission form. Dr. Huff noted IHC had a separate server for images. Other servers held clinical data from the more textual or numeric-based coded part of the electronic medical record. IHC used DICOM as the format between the imaging device and its archive, enabling them to keep and contain a high-fidelity image. But he noted a general-purpose rendering was sufficient to serve up and transmit as part of the electronic medical record for clinicians to review. Dr. Overhage remarked pragmatically that DICOM was probably the only way to extract images, near or intermediate term--At least they had a “common thread” for reaching a variety of clinical imaging systems.
Recalling a number of testifiers commented on overlaps and duplications between standards, participants discussed ways to reduce redundancy and inconsistency between SDOs and ways NCVHS and the federal government might help. Dr. Huff noted natural ongoing collaborations. Discussions between NCPDP and Working Group 11, which creates and maintains the SCRIPT standard, centered on similarities and differences between the standards. Their first work item was correlating the terminology for describing forms and routes of administration and making information content the same between SCRIPT and HL7. NCPDP and HL7 were also working to coordinate information content. And a joint special interest group with DICOM and HL7 members was discussing imaging as it relates to DICOM’s integration with newer versions of HL7. Dr. Huff suggested the government could stimulate movement towards consistency by adopting good standards and providing incentives for using them. Dr. Overhage agreed this was a natural process. Groups with an immediate need to fix them identified weak areas in existing standards. They fixed them and expanded into broader areas where more crowding occurred. Noting their history of collaboration, evolution, and incorporation, he said standards wouldn’t conflict for long if they evolved together for good reasons.
Mr. Wagner said VHA saw NCHISB’s effort for a metadata registry as a way to identify and evaluate duplication and overlap. Registered in the metadata registry, message standard formats could be compared and problems and priorities identified, so SDOs could address them. Dr. Berman concurred with Dr. Overhage; Allscripts supported common means of identifying drugs, patients, providers, and disease states across the message formats. Dr. Cohn observed a DSMO process was in place for changes to current standards. He noted it was less clear how this applied to new standards, and said the question was whether or not all the right people were there to reach agreement: everyone had to sign off on a standard.
Dr. Berman clarified Allscripts’ belief that SCRIPT standard’s message format was broad enough to encompass various options (e.g., the length of the fields) to resolve issues around common identifiers for responding and referring to physicians, patients, and drugs. But he pointed out that the industry had to agree what those identifiers were. Dr. Zubeldia concurred that the identifier question was a big problem. Typically, the social security number or pharmacy identifier issued by prescription benefits was used. But when the identifier didn’t match, the prescription couldn’t be easily matched with the hospital stay or outpatient services rendered.
Dr. Overhage described evidence that reportable conditions were detected earlier using INPC’s system. On average, reports of last year’s Shigella outbreak in Indianapolis reached the health department six-and-a-half days sooner via electronic laboratory reporting than traditional methods. A study comparing data the health department received from hospitals and the electronic lab reporting showed INPC’s input about seven days earlier across the board.
Asked about difficulties with HL7, Dr. Overhage reiterated that the interpretation of the standard wasn’t uniform and that created most the tending. People either encoded multiple components of the information into a single field or used completely independent OBX segments to send the data—making it difficult to sort. He agreed the codes were a major issue. Doing INPC’s city-wide projects would have been easier if they hadn’t had to map all the vocabularies and terminologies of the different healthcare entities into a compilation. He noted many of the day’s participants spent a substantial portion of their year pouring over mappings. The method standard was adequate, but differences in the codes made life hard.
Asked if HL7 was ever used to send messages to a retail pharmacy, Dr. Overhage said they didn’t electronically send data to any retail pharmacies not affiliated with the hospitals directly. But they used HL7 to send a message from the clinical system that generated the prescription to a system that generated the fax to the pharmacy, and that message was in HL7 format. Dr. Huff described a similar practice. The message structure was correct, but they were not currently using HL7, NCP, or SCRIPT to send that data to outpatient, community-based pharmacies. Dr. Berman said Allscripts and the rest of the outpatient providers used SCRIPT standard exclusively. HL7 could be developed to work in that market, particularly for prescription ordering. But SCRIPT standard already had in place the fine transaction and message types for refill requests, responses to change requests for generics, and therapeutic alternatives that happen frequently on the outpatient side. Virtually every pharmacy had SCRIPT standard for adjudication. There was benefit to utilizing the SCRIPT standard for all pharmaceutical transactions, whether they be adjudication, SCRIPT standard, or some future pre-adjudication where a prescriber will pre-adjudicate a claim to see if the drug is covered. Mr. Wagner said VHA had created consolidated, mail-out pharmacies that performed many of a retail pharmacy’s functions, including refills, which was cost beneficial. Transactions between their facilities and the consolidated mail-out pharmacy were in HL7 format.
Dr. Zubeldia rephrased a question asked the first panel. Should their recommendation: (1) identify an SDO per se independent of versions, (2) go down a level, recommending a version within and specific message format transactions, or (3) go down to a third level, specifying an implementation guide to support the other levels? Dr. Berman noted they’d heard from Mr. Wagner that VHA was at v3.2 on the telecommunications side for adjudication. Allscripts also supported v3.2 in the adjudication end of their business. Dr. Berman suggested making the standard the version currently used in the industry (v3.2) and all subsequent versions. Asked if the standard should have no optionality or maximum flexibility, Dr. Berman said Allscripts believed a prescription and all the communications between a physician and a pharmacist were clinically based, but agreed with Mr. Guinan that this shouldn’t be considered a loose clinical transaction, but nailed down more like the administrative transactions.
Mr. Wagner said the VHA perspective depended upon the timeframe and backward compatibility. Talking three-to-four years out, he’d say HL7 v3; within 18 months, v2.x. With standards that were backward compatible, he’d say v2.2 or later, along with implementation guides for each version. For v3, they needed to be specific; later versions depended on whether or not HL7 committed to making them backwards compatible.
Dr. Overhage suggested they focus on SDOs, rather than specific standards. The standards evolved for good reasons and they had to evolve with them. He concurred with specifying a minimum version number. He observed SDOs recognized areas where there were opportunities for interpretation and were moving to narrow those boundaries. But whatever they said; it wasn’t easy for vendors to change how messages were structured and delivered. It took time for the market to catch up. They had to be realistic and build on what’s available. Dr. Huff said they needed to specify a specific version and implementation guides to get to a beneficial level of interoperability. In addition, they needed to specify an orderly process defining a future version and date and how that evolved. While they specified details in implementation guides about how to do the pharmacy order or a lab result, a set of people from government, SDOs and enterprises needed to implement prototype systems, field testing new versions and advancing the standard. Dr. Berman cautioned that presupposed the newest version was always the one to be chosen.
Dr. McDonald remarked that, although HL7 had chapters with different content, they all used the same data types and syntax--Dividing them up probably wasn’t helpful. He said he’d assumed all along they wouldn’t achieve standardization in the clinical world at the level of discipline or severity they had in the business world; this was more complicated and created backlash. He suggested stating the ideal, giving targets, and recommending that federal and state agencies stimulate the industry by saying certain messages should be sent to them in a particular format and at a select level of standard. Dr. Huff agreed. There was a business case when data was sent to a public health department, HCFA for Medicare case review, as part of claims attachments, or one participated in a clinical trial. If the standards were properly constructed, the data to be sent to agencies was already in their systems and could be sent electronically. Dr. Huff observed another business case accrued to providers and purchasers of software. If IHC bought new systems that were compliant, they decreased their cost to purchase, install, and implement. They could move faster to get the data in an electronic form and create a more integrated electronic medical record.
Mr. Blair reflected they’d heard some convergence on thoughts and directions NCVHS might take with recommendations. Mr. Meyer had advised considering a dual strategy recognizing message format standards that were virtually de factor standards in terms of market acceptance, where vendors and users had invested and there wasn’t a business case for changing. Another strategy was to recognize things HL7 identified for v3 (e.g., increased interoperability, clinically specific terminologies and data definitions) and take advantage of PMRI recommendations addressed at accelerating development of standards and government support and assistance making implement easier: looking at federal funding, v3 implementation guides, conformance testing, and government licensure of clinically specific terminologies that locked all that in and related back to and supported RIM. Mr. Blair said Dr. Yasnoff had noted that a business case was needed by public health and the CDC to support funding for the development of more clinically specific and timely information. Mr. Blair suggested that some HHS projects (e.g., NEDSS and immunization records) might be areas that justify government incentives for v3. Participants also noted that the implementation guide for the claims attachment was specific with a number of HL7 look-ups for multiple applications.
Dr. Huff said the de facto standards in use were HL7, SCRIPT, and DICOM. He agreed both prongs were good strategies, supported implementation guides, and noted the need for input. It was reasonable to fund accelerating what they needed in the future. Dr. Overhage remarked that talking about vocabularies and terminologies went deeper than changing the messages. How the data was stored and structured in the microbiology system used to interpret the response of the various antibiotics of a particular organism would be fundamentally impacted. Getting data out of those systems meant changing how people’s work flowed and some systems’ guts. It would be a valuable, but slower process.
Dr. Yasnoff said the question to ask wasn’t what single message format standard to recommend for adoption. He noted testifiers mentioned standards were a process. This wasn’t a situation where they could say, “All electricity will be 115 volts,” and be finished. They couldn’t do it with vocabulary, because it changed as their knowledge changed. He suggested a framework used for other technology-related standards that incorporated three standards: (1) one or more old standards that were acceptable and still used, but shouldn’t be implemented for anything new, (2) the current fully-supported standard everyone was expected to have, and (3) the future standard everyone worked toward. There might be incentives and migration was gradual. After a set number of years, old standards were no longer supported. The current standard became old, the new one became current, and there was another new one. Periods were adjusted based on the standard and how fast it must change. They might recommend that HL7 v2.2 was the old standard. If you had it, you kept it. It would be supported and you could send data back-and-forth, but couldn’t implement anything new. When implementing, the current standard might be HL7 v2.4. But there would be incentives to move people to HL7 v3. And anyone using v2.2 and v2.1 had to recognize that in X years, it would no longer be supported. Everyone moved along the continuum. Dr. Yasnoff said the model would be effective, provide predictability, and move things along.
Dr. McDonald said he couldn’t disagree with Dr. Yasnoff, but worried this was too much like the first nine standards and would cause a backlash. He proposed saying v2.4 was the ideal, new things were coming, and the government would encourage its use in their communications. Mr. Wagner remarked that what Dr. Yasnoff proposed mirrored a process that worked fairly well that the VHA called enterprise architecture, based on the belief that architecture had to be evergreened. Dr. Huff said he agreed with the evergreen concept, the obsolete standard, current and future targets, and set windows of time. And he concurred they should offer incentives, not penalties. He said this was the idea he’d been searching for, but couldn’t define as an ongoing process adjusted over time. He foresaw tremendous movement based on bees-to-honey incentives.
Dr. Zubeldia said they needed to consider the use of the standards: who would use it and if it was enforceable. Standards defined for interchange of data between outside entities and the healthcare institution (e.g., reporting to Medicare or public health) could be readily verified and enforced. Standards for use internally were probably outside the meaningfully enforcable scope. Dr. Overhage noted another advantage was that this approach gave vendors direction. If they implemented v2.4, people would want it; vendor’s had a business case. With the future or current standard implemented, they might compete better. Besides monetary motivation, Dr. Overhage said this approach stimulated implementation with the guides and other things making it easier.
Dr. Zubeldia reflected that everyone agreed on HL7 and some standard for nomenclature or a common data dictionary. Most believed at least some transactions needed a well-defined implementation guide. Though some preferred open-ended adoption of a standard or an SDO, instead of an implementation guide. Dr. Cohn added most agreed with the evergreen concept. And he questioned whether, with that layered on top, more open-ended standards would still be an issue. Dr. Zubeldia suggested people were thinking about one-size-fits-all when they considered open-ended standards; here there was a tight implementation guide for some messages and an open-ended evergreen approach for everything, including messages that weren’t standard.
Noting he’d heard support for HL7 and DICOM and positives about SCRIPT, Dr. Fitzmaurice said they should consider all three. He’d also heard about overlap between DICOM and HL7, and the SDO’s were talking about how to get along even better. They’d heard a continual need for vocabulary, terminology, codes. The interaction between codes and vocabularies and just what was needed for drugs versus recording clinical notes were more complicated than he thought they’d be able to formulate in a letter to the Secretary. Noting Dr. Cohn had mentioned he’d like to study that in 2002; he said they’d talk more about that the next day or in December. Mr. Blair noted they had a lot to say to the Secretary. He wasn’t certain though that they’d be suggesting a HIPAA standard--If they did choose HL7, which version would they pick? But they were getting close to saying what they’d heard and what they thought the Secretary ought to consider.
Dr. Cohn added he’d heard people were against strong regulatory dictums, favoring incentives and benefits, though this varied depending on whether it was an internal organizational standard or involved exchanging information externally. They’d heard a number of examples where there was a good rationale for tighter use of the prevailing standard and related data requirements when sending things to the government. Dr. Fitzmaurice noted several testified the government’s role was to lead and support--no one said strongly enforce.
Mr. Blair said he’d heard of three major areas where they might need to come to consensus: the message format standards on the table, the language used to recognize each level of the evergreen, and next steps regarding terminologies and data definitions. Clearly, HL7 was on the table and there was general acceptance for DICOM and NCPDP SCRIPT standards between physicians and retail pharmacies. IEEE’s standards for medical devices were an open issue. Dr. Yasnoff suggested they weren’t hearing about IEEE because it wasn’t an issue in inter-institutional communication; it was for devices within an institution. Mr. Blair pointed out that it was one of the first points of data capture of clinically specific information, especially in intensive care units. Participants discussed getting additional testimony from IEEE, manufacturers, and users. Dr. Fitzmaurice noted they hadn’t yet been successful at getting names of users; the standard was often embedded in a company’s product and transparent to users. Members decided to take IEEE medical device standards off the table until they had additional testimony.
Dr. Zubeldia suggested getting guidance from the Department identifying covered entities under HIPAA or PMRI. Dr. Cohn noted only the SCRIPT standard looked like it might be a HIPAA recommendation; he didn’t think the issue was germane. Mr. Blair said all the PMRI standards would be used by providers, who were already covered entities. Mr. Blair said they should continue to follow their mandate under the administrative simplification provisions of HIPAA, which called for them to make recommendations on uniform data standards for PMRI. They’d received broad HHS support for all ten, including number two, which specified recommendations on specific PMRI standards, as well as three and four that were incentives to promote new standards. PMRI standards were used within provider settings; the fact that they also might be used outside of the provider setting was a separate issue. Noting overlapping with at least one other standard, Dr. Cohn said he’d want bilateral agreement with other SDOs before supporting it.
Dr. Yasnoff remarked, consistent with earlier testimony, they’d heard codes were a problem in SCRIPT. Before recommending SCRIPT to the Secretary, at the least they wanted to state a process for establishing more effective coding systems and clinically specific drug terminologies had to be included. Asked if this wasn’t true for HL7 as well, Dr. Yasnoff said they consistently heard testimony that there wasn’t a good system for drug coding--that day they’d heard it specifically for SCRIPT. Dr. Zubeldia said the problem with SCRIPT was so severe that the current implementation didn’t use a code for the drug prescribed, but described it in its text. Dr. Cohn said the only question was did they hold off recommending drug terminology. Dr. Yasnoff said they weren’t saying that; but if they recommended SCRIPT, they needed to point out it had to be supported by their other recommendation. Without codes, its usefulness would be diminished.
Dr. Fitzmaurice said other SDOs should concur with favoring SCRIPT or provide information. Dr. Cohn remarked SCRIPT came close to an interface between other standards. Dr. Fitzmaurice agreed. Anytime they had a particular standard for a given function and something else covering a range of functions included that, they should coordinate rather than “start a fire.” Dr. Zubeldia noted a common theme about the need for testing and compliance verification of interoperability.
Members began discussing the next issue (linking conformance testing and recommendations for HHS funding for implementation guides to the evergreen levels) by reviewing message format standards on the table. Noting many large manufacturers of radiology equipment were major users of DICOM, Dr. Cohn said he suspected it was a good standard, but hadn’t heard enough testimony to validate that. He hoped in December they’d hear from radiologists. Members noted confusion about categorizing DICOM, though clearly its intent was to move images institution-to-institution. Mr. Blair clarified HL7 was on the table. They wanted more information about DICOM and NCPDP. IEEE and CORBAmed were off the table. Dr. Cohn noted there’d been a suggestion that DSMOs sign off on any version before it became a standard. Dr. Zubeldia said that was a big issue. The NCPDP implementations for SCRIPT were either v1.1 or v1.5, and the current v4.0 wasn’t even NCPDP syntax. Newest versions might not be appropriate.
Members discussed the evergreen concept that had the virtue of being non-threatening and non-coercive to those who’d already invested in current HL7 versions, while providing incentives for development and implementation of future versions. Dr. Yasnoff defined the three levels in the evergreen concept in terms of HL7. V2.1 and v2.2 would be supported. The current version was 2.4. V3 was the emerging standard. He noted the need to define how levels were treated. Could “still supported” be sent outside the institution and should people be willing to accept it? Or could it be sent outside, people would accept it, but not happily? Did the current standard have to be used in reporting to CMS or CDC. And what would the emerging standard be used for? He noted they also had to be more specific about incentives. If you used still-supported standards, did you get nothing? Did you get a transaction fee if you used the current standard--and a higher one if you used the emerging standard? Instead of fees, Mr. Blair suggested incentives to encourage people to install the new standard ( v3.0). They could encourage early adoption within the federal departments and agencies. And they could have funding for a single implementation guide and/or conformance test. Dr. Yasnoff identified three issues: (1) which version should be at each level, (2) what the incentives should be, (3) where there should be conformance testing and how should it relate to the incentives, if at all. Dr. Yasnoff suggested conformance testing all versions--How else would they know anyone’s HL7 transaction was correct? Mr. Blair saw conformance testing as an incentive to move to newer versions. Dr. Zubeldia agreed it would be a strong incentive for the current and emerging standards. Other versions were running and “you didn’t touch them.”
Mr. Blair said he came into this discussion with the idea they’d apply incentives to v3, but the way Dr. Yasnoff defined it, he thought people should be encouraged to go to v2.4 for a few years. He agreed with incentives for v2.4, but suggested designating v3 as the emerging standard. Mr. Blair noted v3 was going through its first of several ballots. Demonstration projects would take four-five months. By the second-half of next year, v3 probably would be considered implementable.
Dr. Yasnoff suggested four categories of standards: (1) the old, supported standard (v2.1) you don’t throw away, but realize its life is limited and, in time, you’ll need to replace it, (2) the current standard (v2.2-2.3), (3) the new standard (v2.4) you move up to when you purchase (which can also use the current standard), and (4) the emerging standard (v3.0) that couldn’t be implemented yet, but had incentives for demonstration projects.
Ms. Burke-Bebee suggested defining standards as ones voted upon and concluded standard by the SDO. The incentive could be a timeframe with testing an attractive component. They’d heard there wasn’t much difficulty going from v2.1 to v2.2 or v2.3. Members discussed compliance testing was one incentive for the new and emerging standards. Other incentives for the new standard were implementation guides, government usage, and paying for submissions in the current format. Funding demonstration projects was another incentive for the emerging standard.
Mr. Blair said both CDC (with NEDSS) and AHRQ (the National Guideline Clearinghouse, tracking for outcomes, and patient safety) had need for getting information with greater clinical specificity in a timelier manner. He asked about additional incentives (beyond what they’d already identified for the new level, v2.4) appropriate for v3.0. Noting they funded researchers who then bought data, Dr. Fitzmaurice said they might convince researchers to pay more for data in v3. They could work with SDOs to see that specific data needs (e.g., medical error reporting) were incorporated into the new standards, reducing the cost of complying with patient incident reporting. And they could pay hospitals for patient safety reporting data and let them figure out the most efficient way to do it. Dr. Yasnoff said they needed to ask someone from NEDSS about this at the next hearings. He noted CDC put out clinical guidelines and was working on translating some into standard formats. And so they could release guidelines only in the latest version of HL7. He noted there was a guidelines group in HL7 and said he believed whatever standards they come out with would be in HL7 v3. Assuming there was a guideline dissemination standard when new guidelines came out, any organizations using HL7 v3 would immediately be able to incorporate them in the system. Mr. Blair said Data Elements for Emergency Department Preparedness (DEEDS) might take advantage of the RIM and come out as a v3. Noting he couldn’t commit CDC to this, Dr. Yasnoff said they might be willing to consider providing reports back to reporting organizations at no cost as an incentive for submitting the data in HL7 v3.
Members discussed gathering additional information before the December meeting in order to decide incentives that might be helpful for v2.4 and v3. Dr. Cohn suggested reviewing the full Committee’s previous recommendations on PMRI standards. Dr. Yasnoff suggested circulating a draft of this framework for witnesses’ comment. They’d heard numerous points of view and their recommendations reflected overwhelming consensus that the government should do something in the standards area, but there hadn’t been a clear message about what. Even if witnesses disagreed on specifics, consensus on framework would be helpful.
Dr. Cohn said a third major issue, the clinically specific medical terminologies and common data set definitions so many encouraged them to consider, should be scheduled for after the code set hearings early next year. Dr. Fitzmaurice noted the recommendations sent to the Secretary could indicate the importance of this and that the Subcommittee would look at it early in 2002.
Mr. Blair noted that the next morning Mr. Scanlon would finish his review of HHS actions addressing the 10 PMRI recommendations begun during the September 24 conference call. An item on the agenda from Margret Amatayakul’s earlier analysis of the SDO questionnaire feedback was a list of areas they might want to revisit with SDOs for additional clarification. Originally planned for the cancelled Washington meeting, it had been rescheduled for tomorrow.
Dr. Cohn said at the meeting scheduled for December 13 and 14 they would hopefully finish up a letter to the Secretary that reflected on previous recommendations on PMRI standards as well as more specific standards, realizing the current Secretary might not have received formally the initial PMRI report. During the first-half of next year, the Subcommittee will look at code sets, issues of medical terminology, and procedures and diagnosis. A hearing on February 6 and 7 on procedure codes will look at holes in the X12 transactions related to various code sets, the proposed rule in response to the superimposed rule, and if the needs of those that expressed concern about the current code sets are being met. Local code set issues and the status of corrective measures will also be reviewed. Hearings on April 9 and 10 will take an initial look at the issue of diagnosis codes, gain input on industry readiness, and when and how to move towards a new diagnosis code on ICB10 CM or another coding system. Hopefully, the date for a hearing scheduled for late May or early June will be announced next week. Dr. Cohn noted it might be an opportunity to reflect on medical terminologies issues and how they fit with other identified issues. There also might be issues related to HIPAA implementation.
Dr. Zubeldia noted three other topics to look at next year: (1) the electronic signatures and how the multi SDI project progressed on building definitions of case studies and business scenarios, (2) the progress report on the HIPAA implementation, and (3) guidance on the NACDS versus NCPDP request concerning privacy issues with the NCPDP transaction (whether it was always optional fields). Dr. Cohn said Dr. Zubeldia should tell them when to schedule a report on the electronic signatures. He noted each year they were required to draft a report on HIPAA implementation and the Subcommittee and full Committee stood ready to identify issues on HIPAA implementation and make recommendations to Congress. Hopefully, the issue of medical codes would surface along with implementation issues. Noting the Office of Civil Rights was addressing NCPDP’s use of optional fields, Dr. Cohn said they would hold any query pending response.
Mr. Blair targeted getting a draft of recommendations out early in November, so everyone could comment and critique. Hopefully, by the December meeting they’d get through one or two more drafts. Dr. Cohn noted they had unscheduled time late January or early February, but also needed time for wordsmithing. It was clear, even before tomorrow’s testimony, there were likely to be other issues to investigate in December that might modify any letters and recommendations.
Ms. Lorenzi defined a healthcare interface as the successful integration of disparate systems, applications, data, vendors, functions, businesses, institutions, and users. Noting that non-trivial interface problems came with the integration of different departments and people, she described hidden complexities. Vendors who coded interfaces on their patient administration system never anticipated admitting people would cancel discharge and transfers on patients that died, trying to “fix” the admit dates and transfer trails--creating the "ghost in the ICU" quandary. Suddenly, people came back to life in the system. At one point, formulary mapping for pharmacy orders involved choosing between 20 different entries for ampicillin oral. Ms. Lorenzi said HL7 provided a critical starting point for interface negotiations.
New York Presbyterian hospital employs the HL7 V2.x suite: patient administration, observation reporting, order entry, financial management, and scheduling. Ms. Lorenzi said HL7 was chosen because it covered pressing interface needs, was the only widely implemented standard, and the HL7 Working Group impressed them. HL7 exceeded their expectations. It was comprehensive and compatible, backwards and forwards. When they took an interface and sent it to another system and “the other half broke,” she said it wasn’t because of version incompatibility, but because the vendors who implemented didn't follow HL7’s receiving rules: if new repetitions, fields, and segments were ignored, everything worked. Ms. Lorenzi said the HL7 community also exceeded expectations. She could keyboard a question in the middle of the night and a detailed e-mail from some expert in the field explained every possible nuance. By morning, there’d be 19 more e-mails and a discussion about a point she’d brought up. Whatever the problem, someone in HL7 was already working on it, wanted to hear about it, and worked to fix everything.
Proprietary to/from HL7 usually took 3-7 man-months to implement; interface engine preparation, about 18 man-months; HL7 to HL7, 1-3 man-months. Estimates included design, development, testing, and production planning. Ms. Lorenzi emphasized it also took time to communicate. A lot of people had to “chit-chat” to do an interface. Some projects took longer. A new ADT financial system involved replacing an integrated sytem with an interfaced system split and pasted unto itself and implementation of all fields in V2.3 specification. Doing a physician orders interface to a pharmacy system meant understanding the business processes, vendor application differences, and vocabulary issues.
Ms. Lorenzi established that HL7 was not easy to use: each new interface required evaluation of vendor specific interface specifications (and a full understanding of HL7 functional chapters), each implementation required conformance testing, code tables that matched on each interface, and reading the messages and troubleshooting was difficult (requiring thorough knowledge of the HL7 control chapter). While 2.3-plus versions were clearer with better definition, vendors didn’t necessarily read them clearly. Ms. Lorenzi said she had to read every field and event, checking everything matched. She then clarified that HL7 was easy in the sense that, with education and experience, they could: develop interfaces more rapidly; realize more rigid interpretations of the standard; require vendors to solve compliance and table issues and not depend on interface engine work; develop boilerplate design, test plan, and production plan documents; and create and utilize automated tools for interface support.
Start up costs involved interface engine installation and HL7 classes. HL7 membership cost several thousand dollars per year. Maintenance and growth cost New York Presbyterian about $2 million per year. About 95 percent was for staff, which produces about 15 interfaces a year. Some 400 were already in production. Without HL7, Ms. Lorenzi said costs would be greater.
HL7’s major weaknesses were: (1) too much optionality; (2) ambiguity--lacking definition (e.g., some trigger events in HL7 v2.2 patient administration had no definition, field definitions were totally inadequate)--v2.3 provided good definitions of what already existed; (3) artifacts left to retain backward compatibility made it unreadable and, occasionally, a vendor implemented something marked backward compatible six years ago; (4) conformance testing couldn’t be specified or automated; (5) complicated, esoteric encoding rules; and (6) no standard vocabulary. Ms. Lorenzi emphasized that HL7 was working to strengthen these weaknesses.
She suggested developing and sharing conformance profiles and encouraged vendors to use Messaging Workbench, a tool supported by the special interest group for conformance. The XML tool walks vendors through implementation. It takes two vendor specs written with the tool and lists differences. The tool is still in the prototype phase, but profiles can be shared on HL7’s Web page. Ms. Lorenzi recommended utilizing XML for v2.x and upgrading to newer v2 versions. And she advised reading the latest version of HL7, even when evaluating a v2.1 or v2.2 interface: better definitions made it possible to understand what those fields should have meant and realize strategic solutions. She also recommended upgrading whenever there’s a business case. She reiterated that v2.3 plus was developed in the “spirit” of v3 and had a large jump in functionality.
Ms. Lorenzi noted the importance of being actively involved in v3’s development, ensuring it was understandable and worked as advertised. Her biggest concern was whether or not vendors, who didn’t understand Chapter 2 in v2, could successfully implement v3. She wanted folks in the hospitals to understand what the standard said. Ms. Lorenzi called the August ballot a major milestone and said she hoped to see the first vendor implementations in two years.
Mr. Tsiolis said, for most practical purposes, the suggested standards addressed EPIC Systems’ highest priority for exchanging PMRI information, but he expressed concern with a lack of overall PMRI structure. EPIC Systems believed the standards provide the means for exchanging pieces of the PMRI structure, but not a consistent, overall framework. Contending that HL7 v3 provides such a global framework, Mr. Tsiolis focused on HL7 v2.x order entry, observation reporting, patient administration financial management, patient administration, scheduling, medical record/image management transaction sets, and the clinical document architecture framework.
Mr. Tsiolis said the order entry and observation reporting transaction sets provided a rich order entry and results review functionality crucial for the success of their clinical applications. The transaction sets enabled them to provide this functionality to Kaiser-Permanente Northwest, Harvard, Vanguard Medical Associates and other large groups. He said EPIC Systems selected these specific transaction sets based on the relative completeness of data elements included in the standard, coverage of customers’ representative workflows, vendors’ growing acceptance of the sets, and data representation in abstract, application-neutral format.
Along with incorporating data elements included in the standard within clinical applications, EPIC Systems implemented the general framework (hierarchical model) of HL7 messaging. Based on this generic framework, implementation of the transaction sets was relatively simple. Mr. Tsiolis said the initial interface development (both interfaces) following the standard took about six months. However, he noted interface development was an ongoing process as the standard evolved and more options and functionality were added to the interfaces and applications. The usual implementation time today (analysis, interface installation, application setup, custom programming, and testing) was between 3-6 months, depending on the project’s complexity.
Mr. Tsiolis noted reasons for the relatively long implementation and testing time: (1) not all vendors follow the standard and often had to compensate, (2) ambiguity and optionality in the standard specifications (individual transactions addressed were not designed to be a part of the global PMRI framework--e.g., the standard suggests a “preferred” way to transmit microbiology results that was precise and contained all the required information; however this wasn’t required and many vendors implemented microbiology results reporting in an ad hoc, less precise way). Mr. Tsiolis said basing the standard on a solid foundation using advanced methods and tools in modeling and systems design could ensure internal consistency among transaction sets and greatly improve interoperability. He noted HL7 realized this requirement and developed a RIM as the basis of new v3 efforts. EPIC Systems encouraged the Committee to include the version of the HL7 transaction sets on ballot in its recommendations.
EPIC Systems participated in HL7 demos at the HIMSS expositions for three years and developed prototypes for v3 of these transaction sets, each time adapting their prototype to the current format and specifications. Mr. Tsiolis noted it was relatively easy to implement because of two features: (1) the format is based on XML and tools are freely available in the prototyping implementation, (2) the underlying RIM facilitates reuse of computational objects (source code, programming libraries, configuration settings) and provides a consistent framework for implementation. EPIC Systems actively participates in the v3 balloting and plans to implement once the new version is approved. The balloting process is expected to be completed in the middle of 2002.
Mr. Tsiolis explained that the v3 clinical document architecture defines a mark up of clinical documents based on artifacts that exist in today’s healthcare environment, providing uniformity for today’s document formats while preserving local expression. EPIC Systems implemented a prototype for the HL7 HIMSS 2001 demo and, as a vendor, offers varied clinical documentation functionality in applications of its comprehensive, computerized patient medical record system. The standard complements this functionality by allowing customers to express this documentation in a common format.
He reported that, because the standard was part of the HL7 v3 effort and based on the RIM, it was east to reuse parts developed for the HL7 v3 messages. Prototype development took about one month; full implementation would require more time and effort. Mr. Tsiolis agreed with Ms. Lorenzi that HL7 v3 was the future and encouraged the Committee to consider it carefully. He noted several reasons: (1) v3 is based on a comprehensive, abstract RIM, the result of taking into account and ensuring compatibility globally; (2) development occurred over a significant period of time with the participation of almost every major player in the healthcare information technology field; (3) because of the model’s comprehensive nature, issues like security could be addressed as part of a standard rather than future add-ons; (4) the methodology requires formal descriptions of application roles and interactions for every transaction set, providing a level of conformance requirement not available in previous versions; (5) the XML format used by HL7 v3 allows implementers to use freely existing tools to process different transactions--increasing interoperability, quicker adoption, and a lower implementation cost; and (6) v3 also provides format independence, a better format for these transactions could easily be adopted by the standard without changing the meaning expressed in existing transaction sets.
Mr. Tsiolis noted three possible arguments against considering HL7 v3. First, development of the new version wasn’t completed--but it was mature and would be available well in advance of the adoption of any requirements. Secondly, v3 had no installed base, while v2.x was widely adopted. Mr. Tsiolis noted that even though the HL7 v2.3.1 transaction sets had existed for years, were required for claims attachments under HIPAA, and were widely adopted, the specificity needed required significant effort in removing ambiguity and optionality from the standard and as much effort in implementation as a wholly new transaction set. In contrast, v3 incorporated features within its development methodology that would enable a specification close to, if not identical with, the one used by organizations in cases falling outside the realm of exchanging PMRI. And third, making v3, with its different format and methodology, a requirement would significantly increase implementation costs. Mr. Tsiolis reiterated that implementing a new specification for exchanging PMRI required significant effort, regardless of the version. The specificity of the standard enabled implementers to use development efforts with greater ease; v3 would result in lower costs long term. Properly engineered applications would have little difficulty switching to v3 over several years. And adopting v3 transaction sets in standards specification would improve competition in the marketplace, as better engineered applications gained appropriate advantage. Mr. Tsiolis clarified that EPIC Systems would continue supporting v2, while making v3 available.
Dr. Horii explained that DICOM, which originated with the American College of Radiology and the National Electrical Manufacturer's Association in 1984, was a multi-member, international standard with representation from Europe, Asia, and multiple medical specialties.
Noting radiology departments were largely digital and used PACS to assemble clinical information, Dr. Horii said the standard’s primary role was to make it simpler, less costly, and more reliable to connect equipment to PACS. The specific standard he discussed was DICOM 3.0 - 2000. Newer versions were generally supersets of earlier versions, differentiated by the year. The 3 derived from the original DICOM 3.0; the multi-part standard currently consisted of 15 parts differentiated 3.1 through 3.15 (e.g., 3.15 – 2000).
The University of Pennsylvania implemented DICOM up to the present 2000 version. Dr. Horii said the major factor in choosing DICOM was its availability from multiple vendors. DICOM implementation by manufacturers support functions needed to get data from imaging equipment into PACs--and diagnostic and review workstations and short-and long-term storage. Dr. Horii said supporting automated movement of PMRI from radiology information systems (RIS) to imaging equipment reduced manual work and errors.
Dr. Horii reported that installing new equipment that conformed to DICOM was sometimes nearly plug-and-play. DICOM was usually a standard feature or option on image-generating equipment and implementation time was largely the installation time for the hardware. He remarked that cost had to be considered in comparison to custom interfaces. Hardware and software development was cost neutral, if not a savings over customer interfaces. Development of custom interfaces for imaging equipment required 4-6 person/months of computer programmer and engineering work. Staff must also support the equipment, which tended to be expensive. DICOM however was a low-maintenance implementation. It relied on off-the-shelf communications hardware and protocols (TCP/IP and IEEE 802.3), which, because of wide use in the information technology sector, were reliable and inexpensive. The only problems Dr. Horii noted were when vendors upgraded software, and that occurred rarely and wasn’t a great problem for vendors to solve.
Dr. Horii noted a weakness of DICOM is a function of its voluntary nature: conformance can only be enforced with market forces. Anyone claiming to support DICOM was required to submit a conformance statement, done in a standard fashion, so it was readily possible to put statements side-by-side and quickly determine implementations that wouldn’t work. Another weakness was the lack of a database query standard. The “query” and “retrieve” mechanism was particular to the standard and implementations couldn’t take advantage of SQL and other standard database query mechanisms. Some, believing DICOM’s real value was in the information models, considered the way it specifies all the way down through network hardware a weakness, contending it should cut off and run over network hardware. Others say the specified network hardware matures along with the requirements; as requirements in imaging increase, network speeds increase, enabling continued use of the existing DICOM protocol.
Dr. Horii said WG 10’s (Strategic Advisory’s) task is to monitor what's happening in other standardization efforts in healthcare and technology advancements that might benefit DICOM. Noting that DICOM’s security mechanisms were examples of advancements identified and incorporated, Dr. Horii said the group was focused on improving the database aspects of the standard long term.
Pointing out a heavy manufacturer dependence, Dr. Horii said they relied on vendors to supply them with current, updated versions of DICOM implementation, and also updated purchase contracts and RFPs to include the most current DICOM publications. He said they’d also specified functionality that derives from “profiles” defined for the Integrating the Healthcare Enterprise (IHE) effort (e.g., in a recent PACS RFP they’d specified the functionality needed between PACS and RIS by requiring vendors to conform to the “IHE Year 2” profiles). He recommended the Subcommittee review how IHE took existing standards and produced profiles identifying what needed to be done when operating in a clinical scenario (e.g., getting patient registration information from radiology and hospital information systems and scheduling information into PACS, which could “pre-fetch” the patient’s previous studies from long-term storage.) Another example was propagating the correct name to the record of an unconscious John Doe in the emergency department. What had been easy in the days of film required interaction between different information systems in the digital PACS environment, bringing the strength of IHE into play. More information is available at www.rsna.org/ihe.
Dr. Horii summarized: DICOM had become the predominant standard for radiological imaging and was rapidly being adopted by other specialties that generate digital images (cardiology, ophthalmology, endoscopy, dermatology). He said its wide adoption and implementation were a testament to how well it worked. It was rare to find an imaging equipment vendor that didn’t support DICOM. The work of the DICOM standards committee and a joint working group with HL7 (volunteers from industry, medical professions, and standards organizations) was an example of how a standard could be built through collaboration.
Dr. Horii clarified that working with how imaging fit in with the PMRI was a major task of the working group. There was a piece that just said patient in their information system. Identifiers and attributes went with it, but it wasn’t as robust or complete as HL7. There was an effort to ensure that the two information models didn't conflict and that, wherever possible, DICOM employed what's used in HL7.
Asked how, over time, one moved from v2.x to v3, Mr. Tsiolis said EPIC believed the major issues of information exchanged with the interface would still deal with patient identification. What changed were the standards and how the format was built in v3. He said organizations without an existing v2.x interface gained most from going to v3: the clarity and lack of optionality minimized implementation and maintenance costs. Organizations that upgraded also gained clarity in information exchange as applications behind these interfaces changed and evolved. Mr. Tsiolis noted v3 was less technology dependent. Possibly they’d have an interface engine or conversion that went v3-2.x. Bottom line, v3 was XML; so there were tools to convert formats. At the same time, Mr. Tsiolis expressed concern about the extra functionality and presentation of pieces of information that could be incorporated in v3 that didn't have a counterpart in v2.x.
Ms. Lorenzi said she worked in an interface engine group and was about ready for the challenge of upgrading to v3. She said the problem was that it was an interim thing. She wanted, eventually, to be able to throw code away--But instead, vendors said, “You have an interface engine; deal with the differences.” In reviewing the ballots, she said she’d be looking for version conversion for applications such as results and patient administration. Noting the pharmacy and lab HL7 v3 work was sophisticated, she said she hoped to get both vendors implementing v3, so she got closer to plug and play. Responding to her concerns and a question he said was on the minds of many big users, Mr. Tsiolis said EPIC would continue supporting v2.x while offering the alternative v3. Dr. Horii pointed out a similar situation from DICOM’s early days. They’d started out with the AC standard that wasn’t object oriented and used a 50-pin parallel interface no one else used. They kept that in DICOM for backward compatibility and vendors made boxes that transitioned between the standards until, gradually, that phased out.
Ms. Lorenzi observed that most of what was needed in v2.2 was already defined, but lacked ample definitions and had ambiguity. V2.3 and v2.4 had definitions explaining what was already defined. Mr. Tsiolis predicted older versions would remain until a need for additional information and capabilities was recognized. V2.2 didn’t have the MDM transactions introduced with v2.3 for transcription. There was a need and v2.3 provided functionality. Organizations that needed that would upgrade. Mr. Tsiolis said it wouldn't take too long; applications changed rapidly.
Asked if DICOM was used extensively for exchange of images between institutions, Dr. Horii said the standard addressed images recorded on removable media, CD, optical disk. And there was electronic transfer over the Internet using DICOM. He said there wasn’t a gold standard for conformance testing, but market forces drove the DICOM community. A testing activity (a large demonstration in a public forum) occurred at the Radiological Society of North America (RSNA); participants who could hook into a DICOM network and send images were DICOM conformant. There was also offline testing and third-party vendors built boxes that output test patterns and standard pieces in DICOM format. But no one certified testing. He noted RSNA had standards for exhibitors. ACR, NMA, and RSNA funded an effort by the Mellon-Carnegie Institute of Radiology at Washington University to develop software that could be downloaded to do DICOM. Vendors received code after it was developed and implemented against it.
Dr. Horii noted cardiologists were big users of DICOM for medical images. Their information object was similar to what vascular radiologists used. A number of ophthalmology (fluorescing and fundoscopic) and gastronuerology (endoscopic) images were also digital and utilize DICOM implementation. Pathologists worked on applications and digital microscope cameras provided DICOM data. Cardiology, ophthalmology, and dentistry were the biggest non-radiology users of DICOM. DICOM had also been applied to non-medical applications (e.g., x-ray jet engine parts) through Digital Imaging and Communicating for Non-Destructive Evaluation (DICNDE).
Responding to the previous day’s discussion about DICOM being “a wrapper around several different types of image objects” that advocated a Web interface so images could be shown through a Web browser, Dr. Horii noted DICOM objects could be e-mailed. Vendors had taken the bitmap and patient information from the DICOM image coming out of equipment and used proprietary codings and their own transfer syntaxes or communications protocols to create products that sent images across the Internet. He said a number of institutions favored this as a way to distribute images across a campus. He said it worked, but wasn’t yet DICOM conformant.
Asked about vendors’ proprietary bitmaps and the difficulty for clinicians to represent DICOM images quality, Dr. Horii pointed out an advantage of film was that the image was acquired and the only variable was the individual's perception and the quality of light. Dr. Horii said DICOM had done two things to ensure, when using the Internet, that the images clinical decisions were based on were stable. A gray scale display function standard enabled calibrating displays using a visual mathematical model, and presentation state context’s image processing steps displayed the DICOM images exactly in the way the radiologist viewed it, including annotations.
Mr. Tsiolis said the current HL7 standard and v3 had a good way of getting the clinical data from one place to another. The problems they’d seen were the ambiguity and that it took time to make sure they were both saying the same things. Ms. Lorenzi agreed. The amount the HL7 vocabulary group produced in a couple years was impressive. She encouraged the Committee to get vendors to provide more information on conformance. She wanted to be able to put two conformance statements side-by-side, as Dr. Horii described with DICOM, and say it's not going to work. She said a conference where vendors were “shamed into it” would be great. She said she hoped some big vendors would take responsibility for bringing out v3 and new vendors with niche systems would utilize v3 and the combination would make it the main standard.
Dr. Horii said the problem wasn’t gaps in standards, but how to integrate. They had imaging information and were beginning to integrate the healthcare and radiology information systems. With new work DICOM and IHE did with the HL7 group, notification from the radiology information system that a patient registered triggered pre-fetching that data and loading it into imaging equipment. A message back to the information system signaled when the technologist’s examination was done, so the family could be told the patient was on the way. Dr. Horii emphasized that if they were going to have patient medical record systems, an integration effort was needed to span information sources. He encouraged the government to provide more forums, research funding and other incentives.
Dr. Cohn thanked the panelists, saying they’d reconfirmed much of the Subcommittee’s initial thoughts. The directions they’d pointed out around conformance testing were useful, and the Subcommittee would follow up on the IHE and HL7/DICOM working group efforts. They’d heard that the standards area was crowded and, just as there were holes in standards around vocabulary, there was concern about things not integrating well around the edges. They’d investigate that in December.
Mr. Scanlon completed an update begun during the September conference call on recommendations and legislative proposals for PMRI standards. One recommendation in the report Mr. Blair presented to the HHS Data Council in September 2000 set out a process for the Committee to identify and recommend PMRI standards to the Department. Corollary recommendations included specific activities and suggestions for agency action. HHS agencies were asked to review the recommendations, identify issues and opportunities, and describe activities each agency was taking or planning to address them. Mr. Scanlon said the updated draft status report noted a considerable number of activities underway related to the PMRI standards. Noting that morning’s discussions about incentives, Mr. Scanlon said the framework for PMRI standards HHS considered wouldn’t necessarily take the same path as the regulatory framework for HIPAA. The nature of the new assessment and implementation depended on the nature of the standard and implementation recommended and considered.
Mr. Scanlon noted the priority in the IT area was internal improvements within HHS and the federal government (e.g., standards, interoperability, security). Enterprise Information Infrastructure Management, a HHS initiative run by CIO focused on e-government and other federal government initiatives in IT. While internally focused, the initiative had an external relationship with HHS’s partners. Mr. Scanlon said it would be a big part of the efforts and spending within HHS. The other major initiative in this area was HIPAA, which HHS viewed as the framework within which improvements in PMRI standards and related NHII activities took place. HHS saw HIPAA as the major initiative leading to PMRI standards and NHII. As agencies thought of new data and communication systems, standards and vocabularies, they had begun to look, first, at the HIPAA framework. ASPE and CDC had a project exploring the utility of the standard clinical vocabularies for infectious disease reporting in public health surveillance. Another group was studying existing state reporting systems for patient safety occurrences. And national data standards architecture had turned to the HIPAA framework and existing and developing standards as a future-oriented framework.
The National Library of Medicine had always supported research in informatics and applications. CDC supported public health informatics training and the health awareness network invoked September 11. NIH and AHRQ have long traditions of supporting informatics research. Telemedicine had research efforts. In terms of policy, work continued on the security regulation and modifications to the privacy regulation. HHS was in the middle of the recommendations to deal with national policy such as security and assuring confidentiality and people were beginning to see the HIPAA framework as the platform for these actions.
Mr. Scanlon reported HHS activity in virtually every area supporting the recommendation to provide immediate funding to accelerate the development and promote early adoption of PMRI standards. He noted two major multi-agency projects. HHS agencies were participating in and supporting the US Health Information Knowledge Base. And the Indian Health Service (IHS) and other parts of HHS worked on the GCPR project with the VA. In supporting the initiative, HIS was implementing HL7 standards in their clinical and administrative information systems.
FDA was engaged through the International Conference on Harmonization (ICH) in development of the MedDRA terminology for drug/biologic regulatory affairs and, along with Data Council’s Health Data Standards Committee, on standards for safety data collected during clinical trials. FDA also moved forward with the National Library of Medicine and the Data Standards Committee on making NDC database registry information publicly available. CDC was working to adopt PMRI standards for querying immunization status of individuals (promoting collaboration with AMA to map immunization codes to AMA CPT codes) and integrating the HIPAA framework and HL7 standards for electronic medical records into the next version of DEEDS. All 50 states have received some funding for NEDSS and planning and implementation efforts.
Mr. Scanlon said HHS’s position on recommendation four (funding activities supporting each standard the Committee recommends) was that as recommendations were considered, appropriate ways of funding, support, and implementation (e.g., development of implementation guides, conformance testing procedures, licensure or other ways to make standards available for use at little or no cost) will be considered. He noted that the whole set of recommendations relating to recommendation four would await NCVHS’ upcoming recommendations.
Recommendation five was to support demonstrations of the benefits and measurement of the cost of using uniform data standards for PMRI. HHS had begun to support literature reviews of the benefits and costs of healthcare and public health; a study initiated this summer compiled a review on systematic studies of the benefits and costs of EDI in healthcare setting and an update of the cost benefit analysis was under consideration. Recommendation six was to support increases in funding for research, demonstration, and evaluation studies. With CDC, AHRQ and NOM, HHS had funded basic and applied research in health informatics and other areas. CDC planned to support public health informatics via peer-reviewed extramural investigator-initiated proposals. FDA was reviewing its Medical Product Surveillance Network adverse event reporting system aimed at post-market surveillance and reporting of problems with medical devices and medicines by manufacturers, doctors, and providers. FDA was compiling a large proposal for revamping a number of systems to integrate the biological with the device report and upgrade.
Recommendation seven was to accelerate development and implementation of NHII. Health Alert Network worked directly with state and local government, health departments and DSS. Funds had been awarded to all 50 states to assess current information system architecture and plan for NEDSS compatible systems. CDC has also given additional grants to 35 states to develop systems. Recommendation nine, concerning equitable distribution of costs for using PMRI standards among all major beneficiaries of PMRI, might take the form of incentives for submission of data using PMRI standards including quality improvement. Much depended on the nature of the standards. Recommendation ten dealt with encouraging enabling legislation for use and exchange of electronic PMRI, including comprehensive federal privacy and confidentiality legislation. HHS had already issued final HIPAA regulations describing standards to protect the privacy of health information and major policy issues were resolved with the security rule. The final rule would be out later this year or next.
Mr. Scanlon observed that HIPAA served as a framework for much of the data activity within HHS and their partners. He noted some of the activities underway depended on funding, authorization and recommendations the Committee decided to send to HHS. Federal agencies were in FY02 and funded on a continuing resolution: no agency would make a big commitment now and all planning was premised on the idea that funding would be available. Dr. Cohn noted a response from Claude Allen to the Committee’s June letter indicating he expects the security and the attachments to be out by December 31. The national provider identifier would probably not be released until FY03. Mr. Scanlon said whether or not they had the means to arrange for the ID depended on the 2003 budget. He reported that the Deputy Secretary, responding to earlier letters, had updated them on the status of the standards and his commitment. Modifications to the transaction recommendations were aimed for later this year. Changes in the requirement for the code to use in the pharmacies and the fast track set of changes were projected by January. Security was working its way through.
Noting the report formed a “single snapshot” tracking how the Department responded, members discussed keeping it updated on the Web, with a caveat clarifying everything was subject to funding. Dr. Yasnoff noted impressive cost benefit data from a cancer information infrastructure built by the National Cancer Institute that allowed for electronic collection of clinical trial information. Mr. Scanlon said it was useful as an application of a subset of NHII and how standards and vocabulary were important.
Mr. Blair observed that HHS took the recommendations seriously and supported them. It was also noted that many projects and plans, some independently projected, were subject to funding. The effort will be updated quarterly and disseminated broadly as a working document in progress. Dr. Cohn remarked that many of their original recommendations (e.g., conformance testing) could be woven into the document. Once they had standards, they could propose implementation guides and conformance. Mr. Scanlon noted the Committee provided impetus for looking at this in a future-oriented way; it was a way of having the agencies work together towards the future.
Dr. Cohn thanked the Subcommittee and staff for their support and activities. The next meeting will be a brief session at the meeting of the full national Committee on November 15 and 16. Another meeting will be December 13 and 14. The first day is devoted to PMRI issues; the second day focuses on administrative simplification and collating information on electronic signature work and implementation. Dr. Cohn noted that preparation for the annual report to Congress had to begin by the end of the year. Ms. Greenberg remarked that the Work Group on Quality was trying to coordinate a session on patient safety issues with the Subcommittee’s December 13-14 meeting; the Subcommittee for Population was invited. Staff was lining up speakers for the afternoon of the 12th. Noting a number of participants had travel needs to meet, with members’ permission Mr. Blair deferred reviewing PMRI recommendations Ms. Amatayakul presented in August as a follow up with SDOs for verification and clarification. Mr. Blair said he would e-mail members for comments and suggestions. Dr. Cohn thanked everyone for a day-and-a-half of useful panel hearings and sessions, and the meeting adjourned at 11:15am.
I hereby certify that, to the best of my knowledge, the foregoing
summary of minutes is accurate and complete.
/s/ 12/28/2002
_________________________________________________
Chair Date