The AHRQ National Resources Center for Health Information Technology (AHRQ-NRC) convened a group of experts in the field of e-prescribing standards in Jacksonville, Florida, on February 18, 2008. The all-day meeting focused on a moderated discussion of next steps for three e-prescribing standards that were determined not to be ready for mass adoption by the evaluation of the first generation of e-prescribing pilots funded by the Agency for Healthcare Research and Quality (AHRQ) and the Centers for Medicare & Medicaid Services (CMS): RxNorm, Structured and Codified Sig (Sig), and Electronic Prior Authorization (ePA).

Goals and Objectives

The primary objective of the meeting was to assemble a group of experts with differing perspectives on e-prescribing to generate ideas for both the technical work required and the research and testing that must occur for the standards to be recommended for widespread adoption. Given the complexity and breadth of technical issues that needed to be discussed, the meeting was structured into three workgroups, one for each standard. Each workgroup was moderated by a facilitator with expertise in the standard discussed. The objective of the workgroups was to discuss in depth the various ideas that experts had regarding the standards, and to prioritize a set of technical work and research (including research questions) that must be addressed before the standards are recommended for mass adoption. Attachment 1 includes the meeting agenda.

Pre-Meeting Activities

Three teleconferences via WebEx were convened to brief meeting participants on the current state of each of the standards so that more time could be dedicated to the discussion of next steps during the meeting. Slide decks presented during the WebEx teleconferences are included in Attachments 2 (RxNorm), 3 (Sig), and 4 (ePA).

Meeting Participants

Invitations were circulated to a set number of participants who represented several different industry perspectives: pharmacists, physicians, prescription benefits managers (PBMs), prescribers, members of the National Council for Prescription Drug Programs, Inc. (NCPDP), as well as Federal agencies such as CMS and AHRQ. Workgroups were limited to no more than 20 participants, and members were assigned so that all groups aptly reflected the various industry perspectives that were present. Attachment 5 includes a list of all meeting participants by workgroup.

Summary of Workgroup Discussions

RxNorm Workgroup

Facilitator: Chelle Woolley, Woolley and Associates, Inc.

Participants:

Doug Bell

RAND Corporation

Tom Bizzaro

First DataBank

Ajit Dhavle

SureScripts

Karen Eckert

Wolters Kluwer Health

Oscar Espinosa

AHRQ-NRC

Steve Franko

CVS Caremark

Seth Joseph

CVS Caremark

Don Lees

Veterans Administration

Patsy McElroy

NCPDP

Drew Morgan

CMS

Stuart Nelson

National Library of Medicine

Carrie Tort

Gold Standard

Introduction

The facilitator prefaced the morning session by stating that AHRQ and CMS would like the workgroup to identify specific research questions and metrics they believe to be useful since initial pilots did not have adequate time to fully explore and analyze the data they collected on RxNorm transactions. Given the challenges experienced by the first generation of e-Rx pilots, the group was asked to first define RxNorm as a way to establish a baseline and framework for moving forward. The facilitator had previously provided a set of questions to review and consider prior to the workgroup meeting (see questions at end of the section).

Need for a Clear, Consistent Operational Definition for RxNorm

Several participants expressed their disappointment with the initial pilot conclusions and with how RxNorm was defined and tested. This was mainly due to the fact that all pilots had their own preconceptions about what RxNorm was designed to do, and what it should do as a standard for electronic prescribing. Establishing a common operational definition for RxNorm is needed and should be a requirement for future analysis. Workgroup participants agreed that RxNorm in simplest terms could be defined by breaking the word down into its two parts, ‘Rx’terms, Rx and ‘Norm.’ Rx simply means prescription and Norm refers to concepts with normalized names. Moving forward, there needs to be an initial step where each of the potential grantees engage in a mapping process where they develop a logic model that includes; all participants in prescribing process, all points of contact between different entities; and the information transmitted that requires the RxNorm process model.

Pilots’ Misconceptions About RxNorm

From the onset, there was a misconception regarding the level of accuracy of RxNorm in relation to matching on National Drug Codes (NDCs). Pilots assumed in their evaluation models that they could achieve 100 percent accuracy in mapping to NDCs with a one-to-one match with an RxNorm identifier“RxNorm Concept Unique Identifier” (RxCui). It is important to understand that presently, RxNorm testing did not result in a 100-percent match but closer to 98 percent. There was some debate over whether RxNorm could achieve 100-percent accuracy as more users begin using the standard. However, it was noted that even though accuracy levels will increase, RxNorm will never be a 100-percent match because there will always be drug exceptions (new drugs, changed drugs, lag in NDCs, and so on).

The pilots assumed in their models that the list of NDCs was complete and would not change during the course of their grant. RxNorm is able to provide only NDCs it believes to be accurate. No central repository of NDCs currently exists, which makes it challenging to create RxCUIs to represent the intended prescription 100 percent of the time. In fact, one physician pointed out that out of 300,000 NDCs, about 20,000 are in conflict. Conflicting NDCs therefore limit RxNorm’s ability to become a complete, error-free source.

RxNorm is intended to cover all prescription medications approved for human use in the United States. Prescription medications from other countries may be included as opportunities allow. RxNorm is not a nomenclature to describe medical supplies. Over-the-counter (OTC) medications will be added and covered, as well, when reliable information about the medications can be found. Medications, whether prescription or OTC, with more than three ingredients are not fully represented at the present time.

Radiopharmaceuticals, because of the decay in strength over time and the requirement that they be ordered and prepared especially for a given time of administration, are listed only as ingredients.

Additions to the vocabulary will be made as new products are put on the market. Additions to RxNorm since the initial pilot tests ended include RxCUIs that indicate packaged medications BPAK (branded) and GPAK (generic).

What RxNorm Could and Should Be

Workgroup participants discussed what the industry needs and must do in regards to moving forward with RxNorm if it is to be the standard nomenclature for electronic prescribing. First, the group reached consensus that striving to attain a perfect or 100-percent matching of NDCs to RxNorm is a primary goal to achieve. Establishment of a central repository of NDCs should be achieved and will require the efforts and collaboration of multiple entities including the National Library of Medicine (NLM), National Council for Prescription Drug Programs (NCPDP), and the Food and Drug Administration (FDA). There was unanimous agreement that a single entity is needed to take responsibility for proper mapping and to ensure integrity of the communication between prescribers and pharmacies. That single entity must have the ability to conduct quality control checks with data coming from multiple sources. Another key requirement was the need for a uniform policy/requirement for sources to submit NDCs to a single entity, including what and how information must be sent.

One of the current challenges faced by industry participants is the accuracy and timeliness of the information being accessed. Currently, RxNorm is updated monthly. Workgroup participants agreed that in order to be most effective, updates should occur more frequently and the ability to quickly communicate changes to the system from one update to another needs to be easily attainable. Participants also reached consensus on the potential uses for RxNorm code, which include Formulary File (RxNorm as drug identifier) and Prior Authorization and Drug Utilization Review (DUR) processes.

Defining the Need for Future Pilots to Test RxNorm

To adequately and comprehensively test RxNorm in future pilots, there must be agreement on an operational definition that includes a list of requirements and functionalities. A standard procedure for communication between all stakeholders involved in the pilot must be established at the onset. Physicians emphasized the need for a common clinical concept for a drug. Because every drug information system that is commercially available today follows somewhat different naming conventions, a standardized nomenclature is needed for the smooth exchange of information, not only between organizations but also within the same organization. The goal of RxNorm in electronic prescribing is to allow various systems using different drug nomenclatures to share data efficiently at the appropriate level of abstraction. In other words, “Determine how well the RxNorm clinical drug, strength, and dosage information can be translated from the prescriber’s system into an NDC at the dispenser’s system that represents the prescriber’s intent.”

One significant stakeholder missing from the current e-prescribing process that involves the use of RxNorm is the FDA. The way you can map an NDC to RxNorm is through an online process map RxNav. RxNav is a browser for RxNorm, the NLM repository of standard names for clinical drugs. RxNav displays links from clinical drugs, both branded and generic, to their active ingredients, drug components and related brand names. An individual accesses the RxNav application, enters the name, strength and formmaintained on a monthly basis.

In order to maintain the integrity and accuracy of this mapping process, information must be updated on a frequent and regular basis. This requires the FDA to send label information as soon as it completes an approval process. Once label information is received, the RxNorm database can be quickly refreshed. Without this timely up-to-date information, the use of RxNorm’s effectiveness is called into question.

Vendors and physicians believe one missing entity in this process is the FDA. The FDA is working on fixing their processes, and will have to identify the structure of their product label. Although FDA has done a tremendous amount of work going from paper-based system to an electronic system, it will need to understand that the rest of the industry is a step ahead. The FDA will need to take measures that address quality and dependability to ensure the successful adoption and use of RxNorm.

Busy practicing physicians who write numerous prescriptions daily need not have an understanding of the architectural makeup of RxNorm and NDC mapping. They simply need the tools that allow them to write a prescription using e-prescribing technologies and be assured that the information they send will be accurately transmitted to the pharmacy for fulfillment. The payers will participate as formulary and drug utilization processes will be enhanced with the use of RxNorm.

Workgroup participants representing the physician practice agreed that the current process does not meet today’s need for real -time information; therefore, more frequent updates of the RxNorm system is needed urgently. To truly be a standard that is readily adopted and utilized, RxNorm must meet the needs of the fast-paced electronic world we live in now. “Today we need real time information. Within the next 6 months, it is anticipated that RxNorm vendors will have weekly updates based on the labels received from FDA. Right now this is not in place and will need to be implemented.” The group reached consensus that more frequent NLM updates with documentation as to what changes were made since the last update, will provide the end user with a better understanding of what has been changed in a certain timeframe.

RxNorm Testing Parameters

To demonstrate “industry usage” future pilots will need to involve more users that will stress test the system and uncover any potential areas of weakness. A physician asks a pharmacist, “How many scripts do you currently receive electronically?” The pharmacist replies, “About a 1,000 scripts per month.” There is currently 98 percent accuracy in RxNorm in that the drug prescribed by the physician is the drug filled and given to the patient. All experts believe that the 2 percent error is very large and the only way to achieve a small fraction of error is if more users begin using the system.

All experts agree that mapping is a critical need in this process. Experts believe RxNorm is the mapping and a prescribing system can be built once a set of normalized names have been created. The current issue is that all data knowledge vendors provide full listings of their NDCs. That makes validation and quality assurance on the RxNorm providers a difficult task. One of the possible compromises supported in theory by the representatives from the data knowledge vendors is that they would provide the NDCs with the current proprietary information to be used ONLY for quality assurance (QA) purposes and with assurances that the information would not be passed, reused or available for public review.

Experts believe that NDCs are used as proxies; therefore, vendors should provide enough additional information to ensure accuracy of certain elements. Physicians and pharmacists agree that having two different NDCs mapped to the same concept is a major issue; therefore, there needs to be a process for mapping that feedback and establishing QA processes.

Experts strongly agree mapping cannot be owned by multiple entities; therefore, there can be only one entity who owns the mapping. The salient question is, “Who will own the mapping?” Meeting participants have suggested NLM should take on mapping responsibility. What goes to the entity and what comes out will need to be identified via a simple navigation tool (interface).

Also, the sources of RxNorm for over the counter (OTC) medications are unreliable. Pharmacists and physicians agree on a need for DUR and medication history. Participants expressed a need for OTC drugs to be included while ensuring integrity of prescription drugs.

Experts point out that even though RxNorm is a simple process, users will need to be very careful to ensure accuracy of usage. To ensure accurate usage, users will need to develop a set of rules and practices to follow. RxNorm may look complicated at first glimpse, but experts would like to make users aware that it is indeed a very simple process. There is a need to provide users with the right education on RxNorm and its usage. Perhaps it will take some time to understand the procedure, but once educated, users will find this very easy and helpful to use.

RxNorm Functionalities

In March 2008, RxNorm will be implementing a number of changes to the RxNorm model to allow certain prescriptions like pre-filled syringes to be added to the source. Physicians go on to identify syrup and non-syrup drugs and drugs containing “hundreds of ingredients” as great concerns. One physician pointed out the difference between historical (mass of drugs) that exists today and drugs that are coming to the market will require additional review. Users should be aware that what is on the market today will change constantly. The facilitator asked “Is there some world where what exists is accurately represented in RxNorm today and the real challenge is the new drugs?” Physicians do not believe new drugs will be the problem “The problem is multiple NDCs mapped to a concept, for example, multi-vitamins.” Meeting participants mentioned that they would like the public to start using the RxNorm model and start identifying and document problems that can then be systematically addressed and resolved. Once users start using this model, exceptions will become identified.

There have been concerns about multiple definitions of RxNorm. Meeting participants said that the following as new functionalities of RxNorm (post pilot): Semantic clinical drug (SCD) Refers to the normalized form of the generic drug name, which contains the ingredient(s), the strength, and the dose form.

, Generic Pack (GPCK), Branded Pack (BPCK), and Semantic Branded Drug (SBD) Includes ingredient, strength, dose form, and brand name. . One pharmacist defined RxNorm as a common clarification for strength, form, and ingredients.

Drug data base code qualifier is the field sent to RxNorm. When using electronic tools, the physician selects a drug, and depending on the system, multiple drugs with strengths will be shown to the physician, who then will select the right drug and print off a label. In this model, the system is translating in a script message a chosen name and not a prescription concept unique identifier (RxCui name).

One physician provided a brief overview of the system. “The drug name always gets sent, but the system should map on the back end. The application populates the script message chosen by the prescriber (drug name). ” One participant asked, “How do we know that the drug name chosen by the prescriber is accurate?”

Barrier to Conducting Routine Quality Control Checks

A significant barrier to RxNorm’s ability to conduct quality control checks is the inability of sources sharing proprietary NDCs. There are no uniform policies and requirements for sources to submit NDCs therefore NLM will be limited due to multiple entities submitting NDCs.

Testing RxNorm

Test 1 The objective of this test is to provide answers to the following questions:

Using RxNorm for each of the standards (Formulary, Prior Authorization, DUR), can RxNorm represent the physician’s intent?, and Will that intent be accurately represented at the end?
To what extent does RxNorm represent the prescriber’s intent? Does RxNorm RxCui represent intent?
Can the pharmacy interpret the script?
What was the result of the filling of the scriptdid the customer get the prescriber’s intent?

The meeting participants agreed that RxNorm represents the prescriber’s intent, but are not certain about the extent of representation. This can be tested behind the scenes retrospectively. Some data can be interpreted differently. Once the prescriber selects the name, it will have to capture the RxCui that was sent by the prescriber. The problem is that no one is using the RxCui today and pharmacies are missing message ID. How drug files are represented is very important and a there is a need to understand how each of the various data knowledge vendors provide information to the application vendors. Again, what is critical for success is the ability to cross reference (map) RxCui to NDCs. This should be done with very little development cost and negative impact to prescriber systems.

Operational Considerations

RxNorm names are not part of primary vocabularies. For example, Category 3 is for use in a real-life application, the user must be licensed from their source. Meeting participants thought that the pilots will test real prescriptions prescribed by physicians to real pharmacies in near real-time (within 24 hours). In order to get various perspectives, the pilots should include all data knowledge vendors, all pharmacy types (retail, mail-order, chain), and a variety of Rx application vendors (physician and pharmacy) and test multiple transactions in different settings (NewRx, Refills, RxHistory, Formulary, ePA, Sig).

Transaction-specific Testing Parameters

NewRx - will be retrospective (but close to real time). There will be select prescribers and select pharmacies. Experts would like NewRx to be able to accommodate Free Text review on both sides (prescriber and pharmacy). Prescriber will input new message with Free Text, Dispensed as Written (DAW), Sig, RxCui and NDC, NCPDP ID, and Prescriber Order Number (PON). Information will be transmitted to the pharmacy, which will transmit Free Text, RxCui, quantity, date supply, DAW (dispense), NDC, and PON number back to the prescriber. Therefore prescriber systems will store the Prescriber Order Number, Free Text, RXCUI, NDC, DAW, NCPDP ID, Sig, and Quantity. Pharmacy systems will store the Free Text of what pharmacy dispensed, NDC, Prescriber Order Number, RXCUI of dispensed, and Dispense As Written, Sig, and Quantity.

RxRefill - Prescriber’s response to a changed prescription will be treated as a new prescription by the pharmacy; therefore, it should be accompanied by a PON number. Test will include e-prescribing application vendor confirmation of drug requested for refill and match on RxNorm for data dispensed by pharmacy.

Formulary - RxNorm will decrease the amount of information sent to communicate coverage information. Depending on the level of formulary, file size will be minimized by a factor of 50. Current issue is much redundancy in the formulary file due to redundant NDCs.

Pilots will identify the number of drugs not covered on formulary. Pilots will test text usefulness (usability) of RxNorm name and self presentation, its intuitiveness, clarity, and length of field (number of characters represented). Pilots also will test accuracy of data as presented to the prescriber and mapping of Payer/Developer of formulary to RxCui.

Pre-Meeting Preparation Questions

1. Diagram out each step of the prescription process including all data requirements, source of data, transaction requirements, and desired outputs by each stakeholder group including:

Physicians (prescribers)
Patients (consumers)
Pharmacies (dispensers)
PBMs/Payers (adjudication)

2. This process should be completed for the following:

- New Prescriptions
- Refills
- Renewals
- Change/Cancel

3. Include in diagramming exercise all processes that are included in prescribing, dispensing and adjudication:

Drug interactions
Allergy checking
Proper dosing
Duplications
Brand or Generics

4. Identify what is currently working in the use of RxNorm

5. Identify what is not working or requires improvement

Many to one listing
Locally generated NDCs
Compounded drugs
Repackaged drugs
Products that involve administering drugs
10-digit versus 11-digit conversion
Lack of a central repository

6. Identify current sources of NDCs for RxNorm

First DataBank
VA (National Drug Formulary)
Multum
Gold Standard

7. Should mapping accuracy be retested in future pilots?

8. What additional features and functions of future pilots should be addressed for testing and for ensuring

the establishment of a final standard?

9. What additional areas of study or research are needed prior to instituting RxNorm as a final standard?

[Establishing the Roadmap for Moving From NDCs to RxCUIs]

10. Understand how implementers are going to follow the standards. What are the potential barriers to

doing so?

11. What are potential solutions to overcoming these barriers?

12. What specific areas should be highlighted in future pilot tests of RxNorm that addresses technical,

implementation and operational needs?

13. If CMS is to move from NDCs to RxCUIs, then what are the necessary steps?

Structured and Codified Sig (Sig) Workgroup

Facilitator: Laura Topor

Participants:


LuAnne Barron Department of Veterans Affairs Mike Bordelon Talyst Dale Chamberlain Gateway Pharmacy Consulting Brian Eith Epic Systems Lynne Gilbertson NCPDP Dr. Paul Gorman AM IA Jim Hancock QS1 Dr. Peter Kaufman DrFirst	Casey Kozlowski Walgreens Kittye Krempin NCPDP Doris McGinnis SNOMED Frank McKinney Achieve Healthcare Charles Rego Zix Corporation Anita Samarth ASTECH Consulting Ken Whittemore SureScripts

Introduction

The session began with introductions of all participants and a brief recap of how the Sig Task Group was formed. The facilitator clarified that Sig is not a separate standard, but a format that can be incorporated into existing standards such as NCPDP, SCRIPT, and HL7. The facilitator then walked through slides that reviewed the scope of the Structured and Codified Sig, findings from the 2006 pilots, the current status of the format, comments from the preparatory Web-ex session held on February 1, 2008, and the tasks for the group for the day.

The facilitator asked the group to identify specific research questions and metrics they believe are needed to demonstrate the viability of Sig as well as to anticipate broader adoption of e-prescribing in the next 3 to 5 years.

Scope

The group spent a significant amount of time discussing the intended scope of use for the Sig format. The format that was developed is narrowly limited in scope from the prescriber to the pharmacy to the patient, as indicated in the Implementation Guide.

It is intended to facilitate communication between prescribers and pharmacists, to improve the efficiency of the prescribing and dispensing activities and to help reduce the opportunity for errors.
For prescriptions that are transmitted via electronic means, this establishes a convention to be used with standards that support electronic prescribing for the consistent expression of the directions for use to a patient for the corresponding prescription

While the group acknowledged that there are potentially other uses in areas such as long term care, reimbursement and research, it was felt that these areas may be outside of the scope of a near-term pilot. However, if a pilot participant wished to explore the viability of other uses they would be free to do so as long as the pilot criteria are satisfied.

Interoperability

The group wanted to understand the status of harmonization with HL7. HL7 members have been involved in the development of Sig, but efforts are not currently under way to harmonize the current version of the format with HL7. The group stated that when harmonization occurs, it must be with HL7’s version 3, and should not be attempted with earlier versions of HL7.

The group also discussed the inclusion of FMT (Federal Medication Terminologies) in the format, as that was a change from the initial version of the format. The facilitator indicated that it will be important for the pilots to validate the applicability of SNOMED v. FMT, as well as identify operational issues related to using different sources for codes.

Challenges and Barriers

Scope definition was the first challenge the group identified. This was addressed by proposing several phases for piloting Sig. This was done so that the pilot would attract a range of participants who would focus on the applicability of Sig to their business practices.

A second challenge identified was that of implementation. The 2006 pilots documented some concerns about implementation and end-user acceptance. It will be important to gather qualitative data during a pilot that measures end-user reaction to Sig. Such data will be used to assist in future implementations. Also needed is the ability to demonstrate the financial and clinical impacts of using Sig so that end users can understand the benefits of “what’s in it” for themselves and their patients. Pilot participants should consider how to capture metrics that can separate implementation issues from any deficiencies found in the Sig format.

Pilot Outline

The group spent a great deal of time discussing the phases and metrics needed for a robust, successful pilot of Sig that would clearly demonstrate its viability and value to stakeholders. The following outline lists some of the criteria identified.

Scope:

Recommended scope and phasing:

Phase I: Prescriber to patient

; bi-directional where appropriate LTC, renewal/refill/change

Phase I prescriber to patient retail, mail, LTC
Phase II pharmacy to prescriber retail, LTC, mail? (informed by, dependent on Phase I)
Phase III Inpatient (HL7 v3 assuming harmonization is complete)

Out of Scope:
- Specialty pharmacy (Specialty pharmacy services can be delivered through mail as well as retail.)
- Specialty
- Other and/or ED, inpatient discharges, transfer of care (medication reconciliation) settings (unless included in phases outlined above)
- Transfer of care
Focus: “People, Process, and Technology”

Metrics:

What percent of Sigs that are written are covered via the format?

What percent of systems are participating?

Complexity number of Sigs, number of repeating segments

Quantitative
- # of prescribers
- # of pharmacies
- # of patients
- # of unique scripts
- # of errors
- Implementation costs
- # of Sigs
- # of repeating segments
- # of abandoned eRx due to Sig
Workflow
- Prior volumes paper/fax/electronic

# of errors

Related call volumes (before/ and after)

Pediatric scripts

Long Term Care setting

How many of Sigs that were sent as text could have been codified?

Could be mapped?

Were mapped?

Mechanism for detecting errors? Validation of what was sent and what was received by the patient

Pharmacy intervention on Rx modifications, etc. Type of prescription (type of modification e.g., dose, frequency)

e-Rx abandoned due to Sig?

Cost to implement Sig only time and materials

Benefits of using Structured and Codified Sig clinical decision support, etc.

ADE impact

Other metrics related to accreditation

Not all measures can be delineated to Sig from e-prescribing (volumes)

Data Integrity
- Mechanism for detecting errors (validation of what was sent and what was received by the patient)
- How many could have been mapped?
- How many were mapped?
Qualitative
User feedback user acceptance
Implementation benefits
Complexity
Terminology feedback (FMT vs. /SNOMED)
Accreditation-related metrics
Patient safety metrics

Participants:

Prescribers and staff

Providers
Pharmacies
System vendors
Networks
Facilities
Patients (awareness of impact of Sig beyond e-prescribing)

Pilot Enablers:

Funding Sources
Principal Investigators
Analysts
Investigator
Funding source
Vendor market penetration
CMS
AHRQ

Participant Parameters

Market Penetration
Provider Practice Size
Provider Specialty
Geographical? (Rural vs. urban/Metropolitan, Regional)
Long Term Care

Requirements

Already using e-prescribing
Able to provide “lab” and end-to-end testing environments
Include only prescriptions that SCRIPT v10.5 supports

Deliverables

Pilot Findings
- Clinical impact statement

Measurement and metrics (especially those that may support accreditation activities)

Development of validation/certification scenarios (implementation/testing plan)

- Financial impact statement

Clinical impact

Measures and metrics (especially accreditation related)

Recommendations
- Implementation guidance
- Testing scenarios

Assumptions

Out of scope:
Human interface issues

Free text (translation available)

Security
Independent Free text visible
Sig pilot is independent of RxNorm and Prior Authorization pilots
Funding, especially in lab-only phase, can support development without government ownership of work product

Issues on implementation roadmap

ROI constraints
Workflow
WIIFM (what’s in it for me?)

Considerations/Acknowledgements

- Leverage data from 2006 pilots
Address other activities that may impact or compete with Sig pilot timeline and resources
1. 1. HIPAA 2
  2. RxNorm
  3. Prior Authorization
- HL7
  1. Collaboration
  2. V3 implementation timeline

Electronic Prior Authorization (ePA) Workgroup

Facilitator: Tony Schueth, MS, Point-of-Care Partners, LLC

Participants:


Terri Byrne T. Byrne & Associates Dr. Reid Coleman, MD Lifespan Avi Ehrlich Wellpoint David Fidler Medco Lynne Gilbertson NCPDP Mark Gingrich RxHub Seth Joseph CVS Caremark Stuart Kersky, RPh Walgreens Health Solutions	Greg Laird Veterans Administration Dr. Ross Martin, MD Bearing Point Jeff Mays MediMedia Frank McKinney Achieve Tim McNeil RxHub Shelly Spiro R. Spiro Consulting Sue Thompson NCPDP Bruce Wilkinson CVS Caremark

Introduction

The facilitator began the Electronic Prior Authorization (ePA) session by describing his goals for the group. He charged the group with producing a roadmap, a prioritized set of next steps and an agenda for future research. Mr. Schueth explained that the prospect of working with a group of this size may make it difficult to produce a consensus report, making a majority opinion more reasonable.

He then explained the current model for prior authorization, highlighting the communication channels between various parties. He explained both the solicited and unsolicited model, although the solicited model has only been tested by one pilot site (Brigham and Women’s). Mr. Schueth emphasized that no standardized questions or answers exist between prescribers and payers. Additionally, the formulary and benefit standard tested by Avi Ehrlich’s team is unsolicited and supports conditional criteria. Jeff Mays then pointed out a few issues with the pilot, indicating that prior authorization (PA) responses were denied because they were not necessary in the cases tested. This would not have happened had the tests been done at the point of care (POC).

The facilitator then highlighted the issues raised in the WebEx conference call session on ePA held before the expert meeting:

Development of LOINC archetypal questions
Possible development and testing of something other than batch
Testing of ePA should be in “live” setting
ICD-9 codes
1. Efforts to match
2. Pros and cons
3. Pros and cons of ICD-10
Pros and cons of GELLO
Is it possible to leverage existing standards to move ePA forward?

GELLO (Guideline Expression Language)

The facilitator then introduced Dr. Ross Martin to speak about his work on and thoughts about the ANSI-accredited standard, Guideline Expression Language, Object-Oriented (GELLO). The reason, the facilitator explained, was two-fold. First, GELLO had potential to present questions in a structured, codified manner, and the ability to query a clinical database thereby pre-populating an ePA request. These were two areas that were not addressed in the pilots. Second, in thinking through the way that GELLO could be applied to ePA, Dr. Martin would present a bigger, long-term picture. This kind of macro thinking was what the facilitator was encouraging for the day.

A former employee of Pfizer, Dr. Martin is currently at Bearing Point. He has not worked on GELLO for more than a year and emphasized that he is not an advocate for GELLO specifically. More important to Dr. Martin is that he was happy to provide his thoughts on the standard that he sees as a lingua franca to ensure that all parties are speaking in a universal language.

He began by reviewing the similarities in questions asked. In his view, questions can be categorized into roughly 7-8 question types, making then relatively easy to codify. The process, he then explained, was comparable to elementary school testing, where there was a book with a set of questions that would be matched to a test sheet based on a number that is on the book.

Dr. Martin also emphasized the important role GELLO can play in working with an EHR. He explained that GELLO can query an EHR for diagnosis and other clinical data and can work in the reverse to write new data into the EHR itself so that questions are not asked repeatedly. It is not clear where the additional information would be physically stored. Additionally, the formulary and benefits standard could be used in queries, with a computable form taken from the human language query.

Dr. Martin argued that the most information possible should go to the doctor. This includes the PA logic to reduce the number of questions doctors are asked. The work group then discussed the reasons why PBMs ask physicians questions rather than divulging the logic from the outset. Representatives from PBMs indicated that they do not always set the rules and define the questions asked of physicians; instead they serve as a pass through for health plans.

Jeff then indicated that some payers provide the “answer key” to physicians. These payers could clarify why they do so. One reason provided by the group is that some States such as New Jersey require the answer key to be provided.

Dr. Martin pointed out that PA is currently very expensive for PBMs to process. In some cases, PBMs will rely on payer data to approve or deny medications and procedures without even realizing that a PA request is included. Another workgroup member suggested that PA fraud is a major problem that will not necessarily be addressed by ePA. Tracking for controlled substances is another issue that needs to be addressed in moving toward ePA. This issue is particularly important for law enforcement. Dr. Martin then clarified that GELLO would be able to compute diagnosis and timing conditionality, determining if a patient had a given disease or disorder at a given time.

GELLO offers the advantage of using a common language (whether it is based on V3 or some other language). GELLO would allow smaller, outside groups to create new questions that would otherwise be too esoteric for larger firms such as Allscripts to map to. Using the common language, these new questions can be answered easily by querying existing data. Dr. Martin then clarified that GELLO is more clinical than other messaging languages (such as SOA) and is based on HL7. Mr. Schueth added that the reason GELLO may make the most sense right now is that it has the ability to query and present human readable language in a structured way.

Dr. Martin also provided an example of GELLO’s utility, explaining that it could help researchers find physician practices that include specific types of patients for clinical trials. This could save significant amounts of money and time in the research process. Additionally, GELLO could be used to create more precise labeling for biosurveillance purposes. The possibility of using GELLO in these cases, along with ePA, make it a more appealing option than if it were for ePA alone. GELLO can also be used to create new labels based on the findings from clinical studies. These could be applied to a virtual medical record (VMR) and published through DailyMed. Dr. Martin emphasized that this labeling process does not present great earnings potential, lending itself more to an open source solution.

Dr. Martin emphasized that the advantages for physicians are plentiful, indicating that they would undoubtedly still have to fill out PA forms, but that once the question is answered, they would never have to answer it again. Dr. Martin indicated that once more progress has been made going toward GELLO, an easy way to develop GELLO expressions would be necessary to ensure that smaller companies can work with it. The value of using GELLO comes from all entities using the same language.

A participant brought up the idea of standardizing the administrative section of PA forms. This could be independent of using GELLO. Standardizing clinical criteria could be a part of this process, but it is not necessary for moving forward in standardizing administrative sections. Another participant suggested that using the existing resource links as an intermediary step in the time before GELLO is implemented.

Vision

The facilitator began the discussion by challenging workgroup members to think about what they want ePA to look like in 5 years. As a part of this, he indicated that it is important to think about what physicians’ offices will look like in five years. He indicated that a consensus view might not be possible.

Dr. Jon White then put forward his assumptions that the group should keep in mind as they were considering their 5-year vision for ePA:

Most prescribers will be e-prescribing
ePA should happen (Dr. White’s belief)
We should not take a bad process and make it quicker or more standardized
Policy makers want to make e-prescribing happen
PA participants should have no reason to not take part in ePA

The group later added the following assumptions for the next 5 years:

Multiple connectivity devices
Market demands support ePA

The workgroup then discussed the reasons for using PA generally. Some indicated that it has been used as a way to dissuade providers from prescribing expensive drugs and procedures. Others emphasized that PA serves as a way for physicians to justify expensive or exceptional medications. A participant noted that the needs and barriers to ePA use in long-term care (LTC) facilities. She indicated that incorporating ePA in these settings may take further consideration.

The workgroup then briefly discussed the value proposition and return on investment (ROI) for ePA. Some members felt that these should be the first step in moving ePA forward, necessary to provide motivation for implementation. Others pointed out that payers and PBMs may be more motivated than we assume and that generally the group should assume that e-prescribing will be implemented. This would make the ROI for ePA more clear and understandable. A participant then discussed the value for physicians. He said that ePA offers physicians additional information and could serve an educational function. Dr. Reid Coleman then suggested that the information provided in PA answers could be seen as more valuable and worthwhile if the information is standardized and reused in the future.

The workgroup then moved on to discuss the role of EHRs and other forms of connectivity in ePA. Members indicated that having an EHR could influence the value of an EHR in a given situation. Others discussed the prospect of connecting ePA to HIE data. The group concluded that ePA and e-prescribing should not be dependent on EHRs and HIEs, but should allow for connectivity with them.

The workgroup briefly discussed the importance of notifications throughout the PA process, especially for patients. Some members indicated that it would be helpful and more efficient to notify patients electronically of their PA status. Others pointed out that regulatory concerns and provider systems may make electronic notifications difficult.

Various subgroup members discussed the idea of creating a list of providers that are either automatically approved or rejected for PA requests. Ultimately, the group agreed that such a “white” or “black list” would not be workable. A member then brought up the importance of getting PA requests into the claims system, an important concern for payers currently. Another member then suggested that an electronically available form could serve as a starting point for individuals to build from.

Others then brought up the point that, however helpful, a real-time check would only indicate, in many cases, that a response is not possible immediately. Streamlining the PA process through quicker real-time checks is much more appealing to PBMs than standardization alone. Dr. Martin then indicated that PA amounts to clinical decision support (CDS) wrapped around a benefit. Viewing PA and ePA as CDS can help identify the most important cases to focus on and could help gain support from AHRQ. A participant suggested that future research and other efforts should take into consideration the perspectives of all physicians, not only the physicians engaged in e-prescribing.

Thinking Through the ROI for ePA

The group discussed the prospect of having an established ROI for ePA. Some suggested initially that we should aim for an ROI for all stakeholders. Others suggested that differences in value are inherent in the prescribing system. The real target, in their eyes, should be if ROI generally goes up and complaints from other stakeholders do not increase. Another subgroup member then added that ROI and measurements of success could be another meeting entirely.

Mr. Schueth then brought some of the group’s comments together, saying that one of the goals should be to prescribe the right drug for the patient for the right reason at the right time. Standardizing questions would be helpful, but past efforts have shown that this is very difficult to achieve. Other group members added that a more incremental approach could be more realistically achievable.

Timeline Constraints

One work group member indicated that a timeline of five years may not be helpful for a vision. He argued that the group should come up with an idea of where they are going and then apply a timeline to the development of ePA. Another subgroup member then explained that an open-ended vision may not motivate vendors to buy in. In the eyes of vendors, there is no reason to bother with saying no if yes is meaningless. Other workgroup members then discussed the specific goals for the next 5 years. Jeff argued that we should at least be able to standardize demographics in 5 years.

The group then revisited the issue of patient notifications. Reid indicated that physicians should not be held responsible for explaining benefits decisions to their patients. Additionally, he said that contact information and preferred contact methods may be difficult to extract from physicians’ records.

Other members of the subgroup then brought up the role of pharmacies and their needs. Pharmacists have a role to play in consultation of patients (recognized by HIPAA). In this light, pharmacists would benefit from having clinical data for their customers available. However, pharmacies differ in LTC settings. Some members then discussed the specific elements of the NCPDP telecom standard used to communicate between the pharmacy and the payer.

Other members argued that it would be beneficial to inform pharmacies of PA status changes.

Mr. Schueth then summarized the group’s work into a vision for the next 5 years:

Every stakeholder will want to be engaged in ePA
- Implementation will be fully functional
- There will be a clear ROI for all stakeholders
Providers will be given the information they need to make the right decision
The right drug will be provided to the right patient at the right time
It will be easy to transmit information between providers and PBM/plans
There will be a clear method for creating standardized Q&A
- At a very minimum, demographics should be standardized
- There will be a tool to automate the population of as much data as possible
There will be a real-time benefit check that verifies the relevance of PA for the patient
Some ePA will be automatically processed
There will be mechanisms to support automation in both the MD office and at the payer
There will be a mechanism for notifying a member or his/her agent of the status of the PA request
PA requests will processed in real-time and at the POC
There will be a mechanism to alert pharmacy of the PA status

Developing a Roadmap for ePA

The group then moved forward, applying a 5-year timeline to the vision. Group members discussed the role of GELLO and agreed that GELLO may not be necessary to codify demographic information. Other members brought up the idea of modifying existing standards. Stuart then suggested that we use the existing resource links as a stop gap measure while additional research is done on more specific standards requirements. Mr. Schueth then explained that the pilots used the 278 standard because it was named in HIPAA. After speaking with officials at CMS, it is now clear that we do not have to use 278, allowing greater freedom to come up with an entirely new standard moving forward, if the group deemed that this was an appropriate next step.

The group then addressed the specific steps necessary to figure out the standards for 2008. Some group members brought up the problems with the previous set of pilots and ways to address these problems in future pilots. Other members discussed the potential differences in timeline needed for the two options of starting over or using 278. Ultimately, the group concluded that it will not matter if we start from scratch or not.

Dr. Martin then pointed out the importance of informing e-HI and HIMSS to ensure that standards are not set in stone through legislation. It will be important to allow the process to be business-driven and then have legislation once the solutions are identified. Reid then suggested that the roadmap itself will convince stakeholders to engage in ePA. Without a roadmap, legislation will dictate how we move forward.

Other group members asked about funding for ePA initiatives. Mr. Schueth explained that there may be some funding, but no specific details have emerged about this. In response, the group agreed to identify funding sources whether they are through AHRQ or some other entity. Other group members suggested that pilots could serve as a good way to get things moving. There was some discussion of the degree to which ePA is dependent on a real-time benefit check. Various group members clarified that there is a dependency on the formulary and benefits information.

Identifying appropriate pilot participants may also be important. One work group member suggested that there was not a high enough percentage of specialists involved in the previous pilots. Additionally, criteria in the past pilots were not based on ICD-9 codes, but on the judgments of the physicians involved. Others pointed out that fewer questions may be asked, but that leads to more pointed questions that are more difficult to standardize. Reid pointed out that it would be helpful to physicians if the questions were more evidence-based so that EHRs could potentially provide the necessary information.

The group then discussed specific goals, producing the timeline below:

2008

*Real time benefit check (being developed by RxHub)
*Use resource links in Script to provide some short-term ePA support
*Requesting no legislation around ePA standards
*Identify funding sources for additional research, pilots
*Modify Formulary & Benefit standard for step medication & quantity limits
Fully understand the industry business models that need to be supported
- Study value proposition for each key stakeholder
Identify regulatory burdens impacting ePA
Pilot planning
- Identify which standards should be pilot tested (create and modify ePA transactions)
- Determine pilot participants and involve them in planning
- Establish metrics for success
- Establish timeframe and timeline for pilots

2009

Phase 1 of ePA pilot
- Pilot test transactions (end-to-end, but format-only)
Analysis of standardized clinical questions

2010

Complete Phase 1 of ePA pilot
- Analyze findings
- Report outcomes
Begin planning of Phase 2 of ePA pilot
- Establish timeframe, success criteria
- Establish owner of repository
- Understand business model for all participants/key stakeholders
- Determine pilot participants and involve in the process

2011

Phase 2 of ePA Pilot
- Pilot test standardized clinical questions

2012

Complete Phase 1 of ePA pilot
- Analyze findings
- Report outcomes
Take standards to industry

* = Priority areas

Additional Research

The group also briefly discussed areas for future research, based on the group’s earlier discussions:

* = Priority areas

*Value proposition for different stakeholders (MDs, payers, pharmacies)
*Identify regulatory hurdles to ePA
- Feedback loop to patients
Evaluate how coverage data and presentation/UI impacts outcomes
How may ePA questions be answered from data from EMR

Workgroup Report-Outs

RxNorm

The facilitator noted that before the government moved forward on funding additional research and development of RxNorm, there needed to be consensus on an operational definition of RxNorm. Most of the discussion centered around various users’ definitions of RxNorm.

Important considerations in thinking through an operational definition of RxNorm include the fact that compounded drugs, packaging, and radio pharmacology are not covered. Additionally, there is no complete list of NDCs. However, RxNorm has been vastly improved since the evaluation of the e-prescribing pilots, RxNorm has tested SCDs and SBDs, and there have been major improvements in mapping to NDCs.

One recommendation that the group felt strongly about was that updates are available only on a monthly basis, but they need to be more frequent to avoid significant mapping issues. Additionally, no uniform policy requirement exists for submitting NDCs and different editorial policies exist that could be worked on.

The group also agreed that further testing is needed in the lab setting and then in real-time. Vendors need to be included in the testing and multiple pilots and multiple transactions need to be tested for RxNorm to be recommended for mass adoption. One meeting attendee asked about mismatches. The facilitator explained that if mismatches are sent to RxNorm, they will be corrected, but the source will not necessarily change.

A detailed list of testing parameters and scenarios that were presented and are included in Attachment 6.

Structured and Codified SIG

The facilitator began by saying that their group wanted to specify criteria, testing requirements, and deliverables. The facilitator highlighted the scope and phasing work done by the group, indicating that specialty pharmacies were specifically left out of scope. The group’s paradigm was “people, process and technology.” The facilitator also brought up the potentially significant role HIPAA 2 could play in the future.

The group focused on metrics. Some of the metrics discussed will lead to identifying costs and benefits and accreditation requirements also played a significant role in the group’s discussions. The facilitator also highlighted the importance of qualitative user feedback, specifically on the sources and methods of collecting data. The group also addressed participant and enabler stakeholders. Questions about vendors, practice size, and patients may be important.

The group produced the following requirements:

You have to be using e-prescribing
Must be able to provide both lab and end-to-end testing
Only scripts that are supported in SCRIPT v. 10.5+ will be considered

The group also discussed the following deliverables:

Clinical impact statements (patient safety)
Financial impact statement (ROI)
Updated implementation guidance

Attachment 7 includes the slide deck used to present the workgroup’s conclusions and recommendations.

Electronic Prior Authorization

The facilitator provided a brief synopsis of the ePA workgroup’s conclusions. He started by laying out the assumptions put forth by Jon White:

Most prescribers will be using e-prescribing
ePA should happen
We should be rethinking the process it doesn’t make sense to automate a bad process
Policymakers will support this work and make it happen
Multiple connectivity devices
Market demands support ePA

The facilitator also presented the group’s 5-Year Vision:

Every stakeholder will want to be engaged in ePA
- Implementation will be fully functional
- There will be a clear ROI for all stakeholders
Providers will be given the information they need to make the right decision
The right drug will be provided to the right patient at the right time
It will be easy to transmit information between providers and PBM/plans
There will be a clear method for creating standardized Q&A
- At a very minimum, demographics should be standardized
- There will be a tool to automate the population of as much data as possible
There will be a real-time benefit check that verifies the relevance of PA for the patient
Some ePA will be automatically processed
- There will be mechanisms to support automation in both the MD office & at the payer
There will be a mechanism for notifying a member or his/her agent of the status of the PA request
PA request will processed in real-time and at the POC
There will be a mechanism to alert pharmacy of the PA status

Summary of Next Steps for e-PA


Year	Activity
2008	Real time benefit check (being developed by RxHub)*
	Use resource links in Script to provide some short-term ePA support*
	Requesting no legislation around ePA standards*
	Identify funding sources for additional research, pilots*
	Modify Formulary & Benefit standard for step medication & quantity limits*
	Fully understand the industry business models that need to be supported Study value proposition for each key stakeholder
	Identify regulatory burdens impacting ePA
	Pilot planning Identify which standards should be pilot tested (create and modify ePA transactions) Determine pilot participants and involve them in planning Establish metrics for success Establish timeframe and timeline for pilots
2009	Phase 1 of ePA pilot Pilot test transactions (end-to-end, but format-only)
	Analysis of standardized clinical questions
2010	Complete Phase 1 of ePA pilot Analyze findings Report outcomes

	Begin planning of Phase 2 of ePA pilot Establish timeframe, success criteria Establish owner of repository Understand business model for all participants/key stakeholders Determine pilot participants and involve in the process
2011	Phase 2 of ePA Pilot Pilot test standardized clinical questions
2012	Complete Phase 1 of ePA pilot Analyze findings Report outcomes
	Take standards to industry

* Priority areas

A meeting attendee asked if the timeline could move faster. The facilitator responded by stating that the group hoped to address some of the back-end payer system issues that were not addressed in the 2006 pilots. Jon White also added that moving faster is always desirable, but not always possible. Attachment 8 includes the slide deck used to present the workgroup’s conclusions and recommendations.

Closing Remarks

Dr. Jon White concluded by asking for remaining items and issues. One attendee pointed to the short turnaround time in the last pilot. Dr. White explained that there are no longer legislative mandates and that there is a tension between moving the timeline along faster and giving more time for the pilots and other stages. Another attendee asked about next steps for CMS and AHRQ. Dr. White indicated that he cannot describe the next steps at this time but that the input provided by the experts during the course of the meeting would be considered in any steps taken in the future.

Meeting Participants

Determine pilot participants and involve in the process

2011

Phase 2 of ePA Pilot

Pilot test standardized clinical questions

2012

Complete Phase 1 of ePA pilot

Analyze findings
Report outcomes

Take standards to industry

* Priority areas

A meeting attendee asked if the timeline could move ffaster. The facilitator responded by stating that the group hoped to address some of the back-end payer system issues that were not addressed in the 2006 pilots. Jon White also added that moving faster is always desirable, but not always possible. Attachment 8 includes the slide deck used to present the workgroup’s conclusions and recommendations.

Closing Remarks

Dr. /span>Jon White concluded by asking for remaining items and issues. One attendee pointed to the short turnaround time in the last pilot. Dr. White explained that there are no longer legislative mandates and that there is a tension between moving the timeline along faster and giving more time for the pilots and other stages. Another attendee asked about next steps for CMS and AHRQ. Dr. White indicated that he cannot describe the next steps at this time but that the input provided by the experts during the course of the meeting would be considered in any steps taken in the future.

Phase I: Prescriber to patient; bi-directional where appropriate LTC, renewal/refill/change