Questions for Consensus - Data Format

[Prescription Drug Monitoring Program]

As we build toward a consensus view of a data format to enable automatic exchange of patient prescription information from a PDMP to an EHR, we can use this topic to host those questions briefed at meetings, as well as any that come up during meetings.

[Prescription Drug Monitoring Program]

Given that EHR vendors are unlikely to implement NIEM-PMP in the short term, how effective would CCDA (already required by MU-2 for EHRs) be in our patient encounter use case?

[Prescription Drug Monitoring Program]

What actions could the PDMP S&I community pursue to provide a CCDA compatible form of prescription information for a patient?

[Prescription Drug Monitoring Program]

What other formats should we also consider? It was proposed during the meeting that we should analyze NCPDP Script, HL7 2.x RDS, and other prescription message types. Are there others? What are the pros and cons of each?

[Thomson Kuhn]

I am no expert on eprescribing, but I do like the notion of considering NCPDP Script. This is required for eprescribing, which is mandated by CMS outside of MU. It is also what is used by everyone in the eprescribing workflow. It might be a better fit.

 

One concern that we have with use of the fill history transaction is that prescribers must attest that they have patient permission to retrieve the fill history. This permission step does not exist in many office prescribing workflows and effectively precludes the use of the transaction. Whoever has the authority to eliminate the need for this permission needs to eliminate it ASAP.

CCDA can be used to generate a medication summary for a patient without any further specification as far as I can tell.

 

Thom

 

 

Thomson Kuhn

American College of Physicians

tk...@acponline.org 

[Prescription Drug Monitoring Program]

Some concerns were presented at our second meeting on January 28 as to whether the "Short List" - of data elements a PDMP system should send back in response to a query by an EHR of patient data elements - was adequate.  An example was posed of whether "Dose" was also needed.  Are there any other "Short List" elements (defined by the Work Group, and available in the slides on the Meeting Materials page on the S&I wiki) this community should consider proposing?

[Chad Garner]

I'm not so sure that EHR vendors are unlikely to implement NIEM-PMP in the short term. My experience has been, once the IT people see it, they realize that it is pretty easy to implement. Several in Ohio have already done it. I think you are more likely to get EHR vendors to implement NIEM-PMP than you are to get PMPs to implement another data exchange format. Most PMPs have no IT staff.

[Chad Garner]

I missed a sentence of this question before posting my original reply. Let me try again. It appears that the "Short List" covers the information that the PMPs have. I was not present on the call, so I'm not sure what all fields were requested, but per the question, regarding dose, the "Short List" includes the Quantity Dispensed and the Days Supply. So, if a patient was dispensed 120 Vicodin 500MG/5MG with a Day's Supply of 30, we have to assume that the patient is supposed to take 4 per day. It could be that the patient was instructed to take 3 to 4 a day as needed, but the PMP does not receive that information. The PMP can't report information they don't have access to.

[Chad Garner]

A lot of different formats are being thrown around here, and I know that I am only familiar with 2 of them. Is there a way that we can post some information about each (with permission from their respective owner's, if necessary)? Since I am currently responsible for the NIEM-PMP format, you can access the actual IEPD here: http://niem.gtri.gatech.edu/niemtools/iepdt/display/container.iepd?ref=Y9MPHRjRYsI

[Prescription Drug Monitoring Program]

Posting this on behalf of Kathy Zahn (with her permission - we want to capture the whole conversation including emails to preserve the discussion as much as possible for those who may join later)

 

---------------------------------------------------------------------------------------------

 

Dear Stakeholders,

 Is there a list of data that the different formats collect that we could compare side-by-side? I’m not familiar with these data formats and it would be helpful to have a visual aid, if possible.

Regards,

Kathy

Kathy R. Zahn, Program Administrator
Prescription Drug Monitoring Program
North Dakota State Board of Pharmacy
1906 E. Broadway Ave.
P.O. Box 1354
Bismarck, ND 58502-1354

[Prescription Drug Monitoring Program]

Kathy,

 

Thanks for your question.  Actually, you can find several slides from our WebEx yesterday on the Materials -> Meeting Artifacts tab on the S&I Wiki site.  Here you will find the slides on Analysis and Recommendations for PDMP-to-EHR Interface - Data Format.pdf.  Slides 8 and 9 discuss the abbreviated "short" list, and the full list of data elements recommended by the Work Group.  Slide 11 shows a side-by-side comparison of the original three standards considered - ASAP, HITSP C32, and NIEM PMP - for all the data elements.  Slide 17 shows the additional consideration of the CCDA format, but only for the "short" list (the longer list including CCDA is in the backup for reference.)

 

The PDMP Team

[Eric Hilman]

 

I do not feel competent to recommend a specific format.  However I would suggest that two criteria be used to evaluate the different formats:

·         * Any difference in the likelihood that EHR vendors implement PMP integration functionality

·         * Ability for the EHR software to process the PMP data to implement innovative new functionality as may be conceived of in the future

A possible third criterion is the impact on the states’ PMP systems in place and the ease of supporting whatever is recommended.

Note for this discussion EHR systems include clinical systems used in Emergency Departments which may be legacy clinical systems and not certified EHR technology.

EHR vendor adoption

Given that use of PMP systems is not part of the Meaningful Use requirements getting the EHR vendors to support any query of state PMP may be somewhat of a challenge. 

In my opinion, the criteria for format selection should include a heavy emphasis on making it as easy as possible for the EHR vendors to integrate PMP query and display into the clinical workflow as seamlessly as possible.  Health Information Exchanges (HIE) are emerging as a standard way for providers to securely communicate amongst themselves and to submit information to Departments of Public Health (immunization reporting, cancer case reporting, syndromic surveillance data to name a few).  These HIEs are using the ONC DIRECT standard (www.directproject.org ) as the underlying transport. To the extent that the EHR vendors are already producing these interfaces, extending such an interface to include query of PMP data might be the path of least resistance for them. It would make it relatively easy for states (at least our state – MA) with HIEs in place to establish the state PMP system as a node on the HIE to communicate with providers. The DIRECT standard does not specify the contents of the message payload so from that perspective the message format per se is less of a concern than that the message traffic can travel securely over an already established infrastructure.  One might expect less resistance from the EHR vendors if the message format were familiar to them and similar to (identical to if possible) message formats that they already use.

EHR system usage of the data and future extensibility

It should be possible for the EHR system to have the flexibility to display PMP results to meet the preferences of the user.  Some clinicians may prefer to see summary information, say, number of scripts, number of prescribers, and number of pharmacies at a glance.  Others may prefer to see summary by medication or perhaps more detail on the first look.  It should also be possible for the EHR systems to automatically apply clinician specified “highlighting” criteria and indicate problem drug use (say by color or special message) for those patients who meet the criteria.  The criteria might be some combination of the counts noted above.  One can imagine a EHR configured to automatically query the PMP system (subject to state regulations about screening) when the patient checks in at the front desk so that there are at least a few minutes for the data to load and when the patient and clinician meet in the exam room the data is already in place. Thus the format selected should provide for appropriate data fields. 

A related format selection criterion might be the ability for the EHR software to analyze the data to automatically determine cases which exhibit patterns consistent with abuse and highlight those cases to the clinician in real time. For example, to the extent that the EHRs already receive all insurance paid medication history from networks like Surescripts, comparing PMP dispensing history with Surescripts medication history is possible. Differences could be used by the EHR software to identify those patients who have received significant quantities of controlled substances outside of the insurance system suggesting the possibility of abuse. 

One can imagine other innovative approaches to detecting abuse to emerge an the format should contain suitable data to enable such innovations to be implemented.

Impact on PMP systems

Enabling any PMP system to communicate with EHR systems will involve a software development effort.  This effort can be minimized to the extent that the PMP system is interfaced to an HIE already in place (or being established).  The HIE can handle the “lower layer” message transport tasks, including security.  Using an HIE also minimizes the work required by the EHR vendors to the extent that they have already integrated with the states’ HIEs to address Meaningful User requirements. Subject to all the other concerns, one would hope that one standard would not be dramatically more expensive to implement than another. Clearly whatever standard is selected should encompass data that is already collected, but not necessarily all the data since clinicians do not need all the fields that are collected and do not have the time to review the complete data set for each patient.  Some data in PMP systems might be represented as codes (such as the NDC code).  Codes could continue to be used, but the information included in the code such as brand name, generic name, or strength should also be transmitted in recognition of situations where the EHR systems might not have the master data tables and that there might be licensing requirements for such tables.

Thus my recommendation is that we back up and discuss use cases and data format selection criteria rather than standards per se at this point.

[Chad Garner]

One other thing - I see a lot of emphasis on the information being provided from the PMP to the EHR. However, PMP's work under a request/response format. Do any of these formats define a request for information?

[Eric Hilman]

At the lower layers HIEs can support query with synchronous or asynchronous reply.  The message format/protocol in the PMIX documents supported query. 

[Bill]

Rick: Yes there are others. Specifically I refer you to the recently published Implementation Guide for the ASAP Prescription Monitoring Program Web Service Standard, which is attached.

This is designed to provide bidirectional electronic connections between pharmacies, prescribers, and PMPs.

The standard can be used in one of two ways. It can be used for Ad Hoc queries on a POI or it can be used to automate a daily polling of a PMP for "threshold" POIs. In both cases either the ad hoc query or the automated polling can take place from within the pharmacy management system or the EHR system. We simply moved the functionality required from a Web portal to these system. This way a prescriber or pharmacist does not have to step out of the workflow to access the PMP repository.

The Web Service standard uses NIEM tag names. There was considerable push-back from the ASAP workgroup on a fully compliant NIEM implementation, due primarily to the complexity of NIEM. We had two presentations on NIEM at the recently concluded ASAP annual conference last week and we heard once again the complexity issues with NIEM. Keep in mind that this is not a revenue generator for the system vendors so we have to keep it simple. Also, PMPs lack IT resources and something that overlays on what they are doing now should be an easy transition for them.

I also want to point out that the ASAP standard can support "pick lists" and reference numbers and you can see how this works in the attached. In addition, we provide the program code to facilitate implementation.

We had 11 prescription monitoring programs participate in our workgroup (plus system vendors and large drug chains) and a few already have it on their agenda for implementation.

My reply here addresses the other email questions regarding CCDA. I am not sure this is a workable solutions. Not a good fit for PMPs. Question also whether Surescripts is tailored to handle the query/responses based on my involvement in the development of the ASAP Web Service Standard.

I feel it would be an injustice to ASAP and the S&I workgroup to not share the work we have done.

Bill

[Cathy Graeff]

This is already in process. NCPDP WG10 Professional pharmacy Services Medication Therapy Management Task Group has created a CDA to be used when performing a comprehensive medication review. It is in the ballot reconciliation process I believe. Shelly Spiro is the Task Group lead and can provide more information

[Prescription Drug Monitoring Program]

As of the last meeting on 11 February, the community has identified the following data format standards for consideration for the PDMP-to-EHR exchange use case:

• ASAP Web Service
• NCPDP Script
• PMIX PDMP Schemas (based on NIEM)
• Consolidated CDA

These are the candidates we will evaluate and discuss at our next meeting on 25 February.

[Prescription Drug Monitoring Program]

The following are the proposed qualities for assessing the standards, including what was discussed on the 11 February meeting.  They are grouped here qualitatively, and will be used in an evaluation of the standards, which will be presented and discussed at our next meeting on 25 February.

 

Very Important

• Availability of an XML format
• Ease of adoption and integration by EHRs/HIEs– includes technical complexity
• Speed of adoption into the EHR/HIE Ecosystem– how widely used is it, plus others

Important

• Wide use of the XML version of the format
• Suitability for the PDMP-to-EHR Patient Encounter Use Case– coverage of necessary data elements
• Separation of transport and content

Less Important

• Ease of adoption and integration by PDMPs
• Speed of adoption into the PDMP Ecosystem
• Available at no cost
• Accredited standards body

 

[Prescription Drug Monitoring Program]

Apologies - the previous posting contained an error.  The following links should be correct.

Google Groups seems to have an issue posting an attachment, but you can find the Assessment of Standards document on the Meeting Materials tab on the PDMP S&I Framework Wiki. The document details the assessment process MITRE used in assessing the four standards against the ten attributes. We will be briefing this on the next PDMP S&I Framework meeting, February 25th, working toward a consensus recommendation for a data standard for our use case.

[Will Lockwood]

[Posted on behalf of Bill Lockwood]

Rick: I take issue with the ratings you just published. 

1. There is no consideration given to the data elements that could be included in a response to a query. These must sync up with those reported to a PMP. 

2. A response to a query just doesn't list the medications for the person, but the physicians who wrote the prescriptions and the pharmacies and locations where they were filled. You are not factoring this into your ratings.

3. Contrary to what you state, there is no fee associated with ASAP standards for PMP and government agencies.

4. There is no inclusion in the the rating criteria for "pick lists" to ensure a match, reference numbers, and summaries (number of different prescribers, number of different pharmacies, within a specific date range).

5. Medication histories via Script are not used in pharmacy. If they were to be used there would be transaction charges associated with these.

6. Were PMPs involved in the development of the standard? This should be a rating criterion. There were 11 PMPs involved in the development of our standard.

7. The ASAP standard is for real-time query/response. Can this be said of all the others as well? This should be a rating criterion.

8. There is no inclusion in the rating of an automated polling model we include in the ASAP standard. This will save state PMPs time and money from having to send emails, faxes, and use regular mail to send out alerts.

9. You are failing to recognize physicians who dispense, veterinarians, the VA, Indian Health Service. All report to PMPs and should be able to query the PMPs database as needed right from their existing computer systems using a standard that replaces a Web portal. Not all prescribers e-prescribe and have access to the medication history.

10. You grossly overestimate the cost to implement  the ASAP Web Service standard. For a PMP supporting a Web portal for queries, the ASAP standard is an easy, minimal cost transition. We even provide the XML program needed for implementation.

11. Accredited standards body should not be a rating item. As noted above, experience with PMPs should be!

12. While Script may be used in the pharmacy industry, it is not tailored to PMPs. Also, I believe you are referring to the Medication History component of Script, not Script itself and this is not used as mentioned above.

13. The only two proposed methods on your list that fit the PMP query/response model are ASAP Web Service and PMIX/NIEM. NIEM XML, however, brings complexity with it that the ASAP workgroup decided would be very costly to implement and support. 

14. A few states have already shown interest in the ASAP Web Service standard and several major system vendors have committed to its implementation.

[John Poikonen]

My 2 cents:

1.       There is no consideration given to the data elements that could be included in a response to a query. These must sync up with those reported to a PMP.  

<< It seems reasonable that a minimum data set be determined.  Which data elements are must haves versus nice to have. >>

 2.       A response to a query just doesn't list the medications for the person, but the physicians who wrote the prescriptions and the pharmacies and locations where they were filled. You are not factoring this into your ratings.

<< Seems like the above fields are all ‘must haves’ >>

 3.       Contrary to what you state, there is no fee associated with ASAP standards for PMP and government agencies.

<< Are there fees for EMRs and Pharmacy systems?  What are they?  Any fee for this group of vendors will decrease the feasibility of implementation in a reverse logarithmic factor proportional to the fee. >>

 4.       There is no inclusion in the the rating criteria for "pick lists" to ensure a match, reference numbers, and summaries (number of different prescribers, number of different pharmacies, within a specific date range).

<< This seems like a “nice to have” >>

 5.       Medication histories via Script are not used in pharmacy. If they were to be used there would be transaction charges associated with these.

<< Pharmacies do send out medication history transactions.  The fee is charged by Surescript.  This would be a deal killer. >>

 6.       Were PMPs involved in the development of the standard? This should be a rating criterion. There were 11 PMPs involved in the development of our standard.

<< Do not understand this at all.  Do you get points for being at the table? >>

 7.       The ASAP standard is for real-time query/response. Can this be said of all the others as well? This should be a rating criterion.\

<< I certainly hope this is the case for all of the standards.  If not, it needs qualifying. >>

 8.       There is no inclusion in the rating of an automated polling model we include in the ASAP standard. This will save state PMPs time and money from having to send emails, faxes, and use regular mail to send out alerts.\

<<  Is this in the scope of the current work?  It does not seem to be.  >>

 9.       You are failing to recognize physicians who dispense, veterinarians, the VA, Indian Health Service. All report to PMPs and should be able to query the PMPs database as needed right from their existing computer systems using a standard that replaces a Web portal. Not all prescribers e-prescribe and have access to the medication history.\\

<< The EMR vendors in this group would still be supporting CCDA for sharing of other types of information, unless I am missing something. >>

 10.   You grossly overestimate the cost to implement  the ASAP Web Service standard. For a PMP supporting a Web portal for queries, the ASAP standard is an easy, minimal cost transition. We even provide the XML program needed for implementation.

<< All PMP’s need to support this for non EMR physicians, so I do not see this part of the equation for data interchange >>

 11.   Accredited standards body should not be a rating item. As noted above, experience with PMPs should be!\

<<  Disagree, this is a huge issue in getting realistic implementations, especially with EMRs.  >>

12.   While Script may be used in the pharmacy industry, it is not tailored to PMPs. Also, I believe you are referring to the Medication History component of Script, not Script itself and this is not used as mentioned above.

<<  Yes, it should be specified as the Medication Hx Component>>

13.   The only two proposed methods on your list that fit the PMP query/response model are ASAP Web Service and PMIX/NIEM. NIEM XML, however, brings complexity with it that the ASAP workgroup decided would be very costly to implement and support.

14.   A few states have already shown interest in the ASAP Web Service standard and several major system vendors have committed to its implementation.

<< Physician EMR vendors is a large constituent than pharmacy vendors.  Which vendors are you referring to. >>