Hubert H. Humphrey Building
200 Independence Ave. S.W.
Washington, D.C. 20201
Response for March 20, 2001
Helen L. Stevens
Senior Project Manager Data Standards Center
McKessonHBOC – Information Technology Business
McKesson HBOC, Inc., a Fortune 40 corporation, is the world’s largest pharmaceutical supply management and healthcare information technology company. McKessonHBOC provides pharmaceutical supply management and information technologies across the entire continuum of healthcare, including market-leading businesses in pharmaceutical and medical-surgical distribution, information technology for healthcare providers, services for payors and outsourcing.
McKessonHBOC’s Information Technology Business solutions include enterprisewide patient care, clinical, financial and strategic management software, as well as Internet-based and networking technologies, electronic commerce, outsourcing and other services to healthcare organizations throughout the world.
Please comment and critique the appropriateness of these criteria for the selection of PMRI Message Format Standards:
McKessonHBOC Comments:
We feel that these are very appropriate selection criteria. Due to the increasing complexity and size of information standards it is important that the standard be published in a database, XML or tool format that would assist in its implementation. We would recommend that NCVHS include a question regarding the publication method of the standard. For example, Publication methodology supports use and implementation.
Please comment and critique the following set of questions.
McKessonHBOC Comments have been inserted after the question to which they apply. Questions where comments have not been provided were considered satisfactory as proposed.
a.Specific purpose of this standard.
b.Has this standard been balloted for approval by the full SDO?
c.What portions of the standard are complete and implementable now?
d.Status of ANSI accreditation. Indicate one of the following: ANSI accredited, ANSI accreditation applied for, or not ANSI accredited.
A. Estimate the percentage of implementations that have been achieved without user customization of this standard
B. If user customization is necessary, how is this handled? (e.g., optional fields, interface engines, etc.)
C. Is an implementation guide for the standard available?
D. Is the implementation guide approved by the SDO?
E. Is a conformance standard specified?
F. Are conformance test tools available?
McKessonHBOC Comments:
In this series of questions the term ‘user’ is used, however it is unclear as to if this is referring to a vendor/developer of applications using the standard or to a customer implementing an application? We suggest that a more specific term be used to reflect the committee’s intent.
We submit that the question of customization needs to be very specific as the design of some standards allows for customizations to satisfy differing implementation requirements. We would suggest that point B present a series of questions:
B. If user customization is necessary:
A. If the standard includes or assumes clinically specific data sets/code sets, which ones are they?
B. How are these data sets/code sets referenced by the message structure (for example, through the use of tables)?
C. How do you coordinate issues of inclusion, licensure, and maintenance with the data or code set developers?
D. How are the data sets/code sets acquired?
E. Are there user guides or some other assistance available for the data sets/code sets?
F. If some of the data sets/code sets are under development, what are the projected dates of completion and implementation?
McKessonHBOC Comments:
McKessonHBOC recognizes that there are in some cases many alternate vocabularies for a single concept and different vocabularies may be adopted for different jurisdictions or functional domains. We therefore suggest that a question be added to this section asking if the SDO allows for domain/jurisdiction specific vocabularies and if so how these are managed and reconciled for cross-jurisdictional messaging.
A. How does this standard and/or implementation guide maintain or improve data quality?
1.Minimize instances of incomplete or missing data
2.Promote standard data definitions and standard units of measure
3.Minimize translation errors
4.Promote accuracy, precision and non-ambiguity
B. How does this standard and/or implementation guide, maintain or improve data accountability?
1. Identify the source of data clearly and consistently
2. Retain the source of data as the message flows through multiple nodes of a network.
C. How does this standard and/or implementation guide, maintain data integrity?
A. What number or percentage of relevant vendors have adopted the standard?
B. What number or percentage of healthcare institutions have adopted the standard?
C. What number or percentage of government agencies have adopted the standard?
D. Is the standard being used in other countries? If so, which ones?
E. Are there any other relevant indicators of market acceptance?
McKessonHBOC Comments:
In the questions regarding market acceptance, it is important to determine the commitment of supporting application vendors to the standard in question. We suggest adding a question asking, “Are there generally available tools designed to assist in the implementation of the standard?”(e.g. message parsers and generators, compliance tools, specification management tools and interface engines.)
A. Describe the relationships with other standards, such as inclusion, dependency, interface, overlap, conflict or coordination.
VII. Identifiable cost. Indicate your best estimate for the following:
A. Cost of licensure.
B. Cost of acquisition (if different from licensure).
C. If external data sets/code sets are used, what are the costs? Are the costs included, discounted, or are they separate?
D. Cost/time frames for education and training.
E. Cost/time frames for implementation.
F. Any other cost consideration, such as annual or usage fees, updates, maintenance, and so forth.
VIII. Timely standards development procedures. Include separate statements for:
A. What is the process for adding new capabilities or fixes to the standard?
B. What is the average time frame between versions?
C. What methods or tools are used to expedite the standards development cycle?
McKessonHBOC Comments:
Timely standards development procedures are critical to ensure that they remain current with business requirements. However, the validity and market acceptance of a standard is often indicated by the level of participation in its development. We suggest adding a question to establish the SDOs structure in supporting and encouraging input from all stakeholders. Stakeholders would include all affected vendors, providers, payors, academic institutions and, of course, governmental agencies. The inclusion of a large number of stakeholders in the development of a standard ensures that the standard will meet their requirements and ensures stronger commitment to the standard’s use and implementation.
A. Systems environment (is the standard associated with or limited to a specific hardware or software technology).
B. What makes your SDO responsive to changes in healthcare or technology (for example: SDO processes, methods, models, etc.).
McKessonHBOC Comments:
In determining the flexibility to respond to new requirements we suggest adding a question regarding the separation of the model on which the standard is developed; the actual messaging specifications; and technology used to implement the standard (e.g. XML). Ideally the standard should be built upon a thorough and stable information model and the message specifications should be stable but subject to change as business requirements change. However, implementation technology must be able to rapidly adjust to technological improvements without negatively impacting the message specification or the underlying model.
NCVHS: Please comment and critique the following list of PMRI transactions to be considered for HIPAA standardization in the first phase of PMRI standards selection.
McKessonHBOC Comments:
We feel that there are two areas that are absent and worthy of consideration:
a) EMR Exchange: from one EMR system to another EMR system to accomplish the exchange of full or partial records for a person. We feel that this is important to derive benefit from the construction and population of EMR systems, which support discrete, coded data. A couple of examples of this type of transaction would include the transfer of Hospital Discharge Summaries or Physician History and Physicals between a physician office and a hospital setting that include discrete-data problem lists, medication lists, and allergy lists as well as discrete-data laboratory summaries.
b) Identification reconciliation: from an ADT, HIS or EMR system to another to reconcile multiple occurrences of the same person with different identifiers. An example of this type of transaction is the reconciliation of a temporary “John Doe” identifier with an existing medical record once the true identity of the patient is established. This is sometimes referred to as a “patient merge” transaction.
McKessonHBOC Comments:
Vendor / Provider Questionnaires:
McKessonHBOC supports the distribution of specific Vendor and Provider questionnaires to provide feedback on the selection of PMRI standards. This will provide NCVHS with an outline of the existing support for a standard and pre-identification of any issues that Vendors or Providers expect to encounter in its implementation.
Consideration of scope:
In considering the scope for the first phase of selecting a PMRI standard it is critical to assess the impact on the industry when the standard is selected. Any changes to applications must include an evaluation of the cost, both financial and operational, against the expected benefits. The proposed list of transactions is very broad including areas of patient administration, clinical care, pharmacy, laboratory and radiology among others. The impact upon the vendor community to modify its interfaces for all of the transactions identified would be significant resulting in prohibitively high impact on the customer base and consequently affecting a vendor’s ability to improve and market its products.
At this time the PMRI message format standard supported by McKessonHBOC is the HL7 2.x standard. Due to McKessonHBOC’s size and number of customers the range of versions supported for these interfaces is 2.1 to 2.4 with most live interfaces currently at the version 2.2 level. The primary barrier to upgrading the interfaces to newer versions is the operational impact to an organization during the upgrade. As with any software upgrade a testing cycle is necessary to ensure that errors are not introduced into a production environment; however, when an interface is involved this testing impacts two systems (often from different vendors) and can be expensive, time consuming and disruptive. The “if it isn’t broke, don’t fix it” attitude is prevalent with customers preferring to adjust existing interfaces to satisfy new requirements rather than replacing them with newer versions.
However, the development of a National PMRI Standard is an extremely beneficial goal and it is therefore submitted that the scope be defined in several incremental phases. This can be done by narrowing the scope of the transactions within each phase and by narrowing the system interactions affected in each phase.
The question of prioritizing the transactions becomes a question of identifying the primary area of concern. The prioritization should address first domains that would provide the maximum benefit through being standardized and will complement the existing HIPAA standards such as administrative (financial and patient) and demographics management. Medications management including treatment/medication orders and prescription information should also be a primary concern.
McKessonHBOC submits that NCVHS may wish to focus first on transactions related to person demographics and identification. This would include the Admission / Discharge / Transfer transactions as well as the Identification Reconciliation or ‘merge’ and EMR Exchange transactions. We believe that this would focus the industry on improving the messaging for the foundation domains of the PMRI. Subsequent phases can introduce the remaining transactions identified above.
International Considerations:
McKessonHBOC would recommend that NCVHS consider the international implications of defining an American national standard. Ensuring that the national standards are synchronized with existing and future international standards will help organizations such as the CDC by supporting reporting requirements from the World Health Organization and the success of global disease management strategies. This will also result in reduced costs in standards development as valuable contributions from other nations are leveraged.
As a company operating throughout the world, McKessonHBOC actively promotes the internationalization of standards and requirements to reduce expensive regional customizations in our products. Towards this goal, we recommend that NCVHS consider existing efforts toward international standards in healthcare informatics and ensure that any new standards developed are presented to the appropriate international forums for adoption worldwide.
Conclusions:
The development of PMRI depends not only on the development of standard messaging transactions, as outlined above, but also on the adoption of uniform data standards. McKessonHBOC anticipates that the current NCVHS activities to define a PMRI standard will extend to include not only messaging transactions, but also the required definition of a data standard in the form of a common information model. The common information model supported by explicit vocabulary and message standards will help ensure that the benefits of complete and comprehensive PMRI are delivered.
McKessonHBOC recommends that NCVHS select a PMRI standard that is built upon a single comprehensive information model so that additional transaction sets can be added to the standard as required in the future without changes to the underlying model and impact on existing transaction sets.
End.