NCVHS ePrescribing Statement – McKesson Corporation

Presenter: John G. Faughnan, MD, MS
Product Architect, McKesson Provider Technologies
Contact: john.faughnan@mckesson.com

Revised: 5/26/04

Introduction

McKesson Corporation is the world’s largest (Fortune 16) healthcare services and information technology company.  Over the course of its 170-year history, McKesson has grown to provide pharmaceutical and medical-surgical supply management across the spectrum of care; healthcare information technology for hospitals, physicians, homecare and payors; hospital and retail pharmacy automation; and services for manufacturers and payors designed to improve outcomes for patients.

Questions and Responses

1.     What are the best standards or code sets to meet the requirements of the Law?

2.      Which of these standards/code sets do you use?

We make extensive use of NDC-11 codes across the continuum of care.

Within our applications we expect to continue to use First Databank’s NDDF-Plus terminology to represent medications and medication-related allergies and to provide decision-support for medication prescribing. We expect to use SNOMED CT to represent patient conditions and non-med allergies that may impact ePrescribing and to use SNOMED CT/LOINC to represent measurements that affect medication usage. In integrated applications patient conditions are usually related to ICD-9 billing codes — so these also play a role. We may also use ICD-9 codes to represent patient conditions in some ePrescribing transactions; however we have found that ICD-9 codes are unusable for contraindication support and are sometimes problematic when used to support “prescribe by indication”.

We expect to continue to use NCPDP SCRIPT messaging standards, with future extensions and evolution to support coded representation of the clinical SIG and other data elements (see below). We expect to use emerging standards for medication history, real-time pre-authorization, and formulary/tiered formulary queries and transactions.

We support RxNorm as an external representation of abstract and dispensable medications and medication ingredients, we encourage further development as needed to support data elements used in the “SIG” (such as the “clinical route” in addition to the dispensable route). We wish to encourage collaboration between the National Library of Medicine, SNOMED Inernational, drug knowledgebase vendors, and the NCPDP to support the growth of RxNorm.

3.     What are the strengths and weaknesses of the standards/code sets that you use?

NDC codes may have both process and technical issues, including provision of accurate updates, multiple NDC versions (although we use NDC-11) and issues with digit span in some versions of NDC. We encourage an evolutionary and incremental approach to addressing these issues in NDC codes, ideally extending the lifespan of NDC codes rather than replacing them.

We know that NDC codes can be used as a substitute for a dispensable identifier even in Prescriber transactions, but we would be more comfortable with transactions that used a true RxNorm dispensable identifier.

We have used FDB’s NDDF-Plus terminology for several years and have been pleased with the evolution of their knowledgebase over time.

In our experience with deploying medication knowledgebases that enable decision support we have experienced difficulties with some historic medication warnings (contraindications, drug interactions) that many clinicians feel are no longer valid or well supported. Some of these may even be FDA “Black Box” warnings that vendors and providers may not be comfortable overriding or deemphasizing.

We have begun using SNOMED CT. We encourage collaboration between SNOMED CT and FDB to facilitate the communication of patient conditions and non-med allergies between SNOMED CT and NDDF-Plus.

SCRIPT (NCPDP) is a mature standard for communication between pharmacy and payor. We encourage its evolution to incorporate RxNorm and SNOMED CT and to incorporate additional aspects of the Prescriber transaction including encoding of patient conditions using SNOMED CT, encoding of patient allergies and sensitivities using RxNorm and SNOMED CT, the clinical sig (clinical route, dose/tab/frequency, etc), longer text messages, and the encoding of Prescriber review and management of clinical alerts, formulary notices and prior authorization requirements.

4.     Is nationwide adoption of these standards/code sets necessary?

Yes, but this may not happen all at once.

We can’t build our applications around standards that are requested or needed in some parts of the country, but are unwanted in other parts. These must be national standards and compliant state regulations. Ideally standards licensing should be such that other national markets might also choose to adopt and/or adapt US standards.

Ideally we’d rapidly bring state laws in alignment with national standards and code sets. If this is not possible, then the next best alternative may be to focus on large markets and populous states and encourage others to follow as ePrescribing benefits become inescapably obvious.

5.     What are the e-prescribing standard/code set gaps?

a.       See discussion of SCRIPT, above.
b.      The formulary transaction set including tiered formulary.
c.       Real-time preauthorization messages and code sets.
d.      Medication history messaging standards.
e.       A politically acceptable method for identifying the patient to support patient specific transactions.
f.        Electronic signature and authentication that are accepted nationally.
g.       Standardized encoding of reason for rejection of a claim. These would enable automated initial responses of rejected claims in our pharmacy customers. For example, if an encoded claim rejection indicates a need for additional data that our systems manage, then we can write rules triggered by the claim rejection to resubmit the claim with the requested data.
h.       Identifiers for Durable Medical Equipment, devices, and supplies. The identification needs for these entities is similar to medications, we need identifiers that areanalogous to NDC codes, “dispensables” and “generic meds”. Ideally these identifiers should be consistent with emerging RFID identifier standards.

6.     What are the barriers to the development/adoption of these standards/code sets?

a. Customer readiness and acceptance

When adopting new messaging and code set standards, we vendors run the risk of getting too far ahead of our customers. Even if a common set of standards is implemented by all vendors, customers may choose to defer purchases of new solutions.

Customer readiness and desire to embrace messaging and terminology standards are potential barriers. A customer driven process will make both customers and vendors happier.

b. The need to create new applications to fully support powerful standards.

As messaging standards and terminologies grow more complex, and represent more knowledge, they increasingly determine the data and object models at the heart of clinical software. In other words, the “message is the model” – especially when the message and its contents (terminology) are financially important.

Consequently complex messaging and terminology standards may be difficult to fully support in existing applications. The full adoption of powerful standards and code sets may require new applications as well as partial adoption in existing applications.

c. Coordination and collaboration between messaging standards and terminology standards

Message structures, APIs, and terminologies cannot be developed in isolation, each must adapt to the other. The interface is not “neat”; these two worlds overlap and may contradict one another.

d. Integrating terminologies and transaction standards that are partitioned by domain (medication, condition, procedures, result).

The proposed standards for clinical terminologies (RxNorm, SNOMED CT, LOINC, etc) have been divided between different clinical domains (patient conditions, test results, medications, etc). Messaging standards may also vary by domain and be maintained by diverse organizations.

Since there is only one patient, and since healthcare crosses boundaries regularly, we expect that integrating these diverse messaging and terminology standards may be challenging.

7.     What incentives or other suggestions should the government consider to accelerate the development/adoption of e-prescribing standards/code sets?

a. Licensing costs and business models must be defined for standards.

Messaging and terminology standards are natural monopolies with high switching costs. Standards organizations must have a revenue stream that supports ongoing maintenance and development, but end-users and vendors need to know that any licensing costs will be low and predictable over the long term. Consideration should be made to managing international licensing costs as well.

b. Provide incentives that encourage end-users demand for standards-based solutions rather than primarily incenting standards adoption at the vendor level.

It is easiest for us to build and sell market-driven solutions that customers are eager to receive.

c. Incentives should be graduated and include “partial credit”.

Full adoption of powerful terminologies and messaging structures may require new applications, and major changes to interconnected healthcare applications and interfaces can lead to cascading updates. Incentives may need to be graduated and incremental, supporting an evolutionary process with several milestones. Milestones may be “reach” goals, but they should be feasible over 1-3 year timescales.

d. Recognize that accelerated evolution is the strategy most likely to succeed.

Messaging structures and terminologies will evolve over the next ten years. We will find bugs in terminologies and design flaws in both terminologies and messaging structures; we won’t get everything right the first time. Incentives should facilitate an evolutionary process, including funding the bodies or organizations that will do the maintenance.

e. Support the delivery of knowledge of all types to Prescriber (physician, etc), Dispenser (pharmacist, etc), and Patient.

McKesson believes that the Patient, Prescriber, and Dispenser all need knowledge about medications, about patient conditions and medications, and about fiscal constraints (conventional and tiered formularies, etc.)  In addition, Dispensers should know about decisions made by the Prescriber, including warnings reviewed, override justifications, and guidance on therapeutic substitution.

Although all parties need to access to formulary data, in the near term it may be most feasible to first provide patient and medication total cost data to the Dispenser (pharmacist). We recognize that patient-specific benefit information, including copay obligations, may be commercially sensitive. We encourage an approach that reconciles the need to provide this information to the point of care with consideration of the business needs of payors.

We recognize that the proposed messaging and code sets standards may deliver a large volume of data to the point of care. We have created solutions that allow Patients, Prescribers and Dispensers to efficiently integrate this data and enhance provider productivity and patient satisfaction, reduce errors, and improve resource utilization.

f. Incent and encourage collaboration between messaging standards and terminology standards, and between overlapping terminologies and different messaging bodies.

The National Library of Medicine, in particular, may have a key role to play in encouraging collaboration and cooperation between RxNorm, SNOMED CT’s medication data, and the NCPDP’s SCRIPT-oriented data sets for dosage forms, routes, etc.

More generally, there is a need for a neutral or trusted agency or organization that can monitor the health of the standard terminologies and messaging organizations, and provide a neutral forum to encourage collaboration and cooperation between clinical terminologies, messaging standards, and administrative code sets (ICD-9, etc).

g. Encourage review of the FDA “Black Box” warnings.

As vendors implement more sophisticated decision support systems, we will increasingly confront the problem of “spurious” alerting. We know that once clinicians become accustomed to overriding alerts that error rates will rise. It is difficult for vendors or providers to deemphasize “Black Box” warnings, even if many clinicians may feel the warnings are outdated. We encourage review of this issue.