Google Groups Discussion Topics for the
PDMP Community
Purpose:
This document is a collection of all discussion topics presented between January 4th and March 29th,
2013. Where possible, the “threading” or “response to” structure is implied by the choices of
indentation. The archive is still available for viewing at
https://groups.google.com/forum/?fromgroups=#!forum/prescription-drug-monitoring-program
As of Friday, March 29th the Group was disabled for further input.
Prescription Drug Monitoring Program: Topic for Consensus: Choice of
Bindings
(4 posts by 4 authors)
Prescription Drug Monitoring Program
Mar 12
From our 11 March WebEx: Based on the outcome of discussion on the transport for the query use case
topic, one of two topics must be pursued.
If the consensus is a single binding, will it be HTTP or SOAP?
If the consensus is more than one, HTTP and SOAP are obvious choices – are there others?
We would like to open the topic for comment here, and plan to discuss at our next meeting on 25
March.
Toby Cabot
Mar 19
Here’s an example of a binding that uses existing standards (specifically OpenSearch and
hData/RHEx) to transfer patient prescription history in NCPDP XML format over HTTP. It
consists of two components: a PDMP testbed written in Ruby on Rails that simulates a PDMP
serving prescription history, and a plug-in module for the OpenMRS electronic health record
system written in Java. Both are open source.
hData is what’s known as a “RESTful” style transport. It’s very flexible. We originally
implemented both components using a Green CCDA, but when the working group reached
consensus on NCPDP as a data representation, I was able to add NCPDP to the testbed in a
completely back-compatible way: existing clients saw the CCDA data that they wanted to see
while new clients saw the NCPDP format. This allows old clients to co-exist with new ones so
you don’t need complicated “flag day” upgrades.
The spec is https://raw.github.com/project-pdmp/spike/master/doc/srpp.txt.
You can find background info on OpenSearch at http://www.opensearch.org/, Project RHEx at
http://wiki.siframework.org/RHEx and hData at http://www.projecthdata.org/ .
The code for both the testbed and OpenMRS module is at https://github.com/project-pdmp .
Comments welcome!
Cathy Graeff
Mar 21
Some of us that are nusiness SMEs but not technical may need a primer before we are able to
participate in these discussions.
Eric Hilman
Mar 25
Is the question presuming a new custom transport mechanism?
I would suggest that we try to use an existing transport such as the DIRECT
(www.directproject.org) standard based Health Information Exchanges (HIE) being implemented
by all the states. The DIRECT standard is being promoted by ONC. HIEs are emerging to be the
embodiment of the much ballyhooed National Health information highway. My understanding
and assumptions:
ALL EHR vendors will have an interface to HIEs to meet the requirements of Meaningful Use. ALL
is a big number and wont happen soon, but eventually it will.
While the DIRECT protocol per se is standardized now, there are still some potential variances in
how to implement these. Over the coming quarters these variances will be standardized so that
a single HIE interface will work for all states HIE
ALL providers will implement EHRs with HIE interface and be able to exchange clinical
information with other providers to meet the requirements of Meaningful use. ALL is a big
number and wont happen soon, but eventually it will.
Submissions to state registries such as Immunization and Cancer will happen via HIE. This is
already starting in some states.
The HIE transport mechanism will include all security encryption using x.509 certificates
The HIEs will support a Query model as well as Push. The earlier implementations focus on
Push.
Establishing the state PDMP software as a node on a HIE to support Query will be work, but not
a lot of work, since all the security and other technical issues are worked out at the HIE level.
There will be web service calls to the HIE and the PDMPs must accept web service calls. There is
an opportunity to standardize this across the states.
So my net is that by reusing the HIEs that are already in place we minimize the work required by
the state PDMP teams as well as by the EHR vendors. We will still need the EHR vendors to add
some workflow functionality to make the use of PMP much more seamless for the providers. I
can write on my vision for workflow later and in a more relevant topic.
Eric Hilman
Prescription Drug Monitoring Program: Topic for Consensus: The
Number of Transport Options for Query Messages
(1 post by 1 author)
Prescription Drug Monitoring Program
Mar 12
From our 11 March WebEx: Both HTTP and SOAP bindings seem appropriate for the query use case. Is it
necessary to choose a single standard or could multiple bindings co-exist? During the meeting, the use
of Direct was also suggested, as it has bearing on a subsequent topic of security protocols.
We would like to open the topic for comment here, and plan to discuss at our next meeting on 25
March.
Prescription Drug Monitoring Program: Topic for Consensus: Transport
for Unsolicited Messages
(1 post by 1 author)
Rick Cagle
Mar 12
From our 11 March WebEx: Direct encrypted email protocol is suitable for the task and is an open
standard with significant and growing deployment. Feasibility was already demonstrated as part of the
Phase 1 Pilot tests. It therefore seems like the most appropriate candidate for this use case.
We would like to open the topic for comment here, and plan to discuss at our next meeting on 25
March.
Prescription Drug Monitoring Program: Data Standard Consensus
Voting (Committed Members Only)
(21 posts by 15 authors)
Rick Cagle
Feb 27
The presentation of the assessment and the discussion at our meeting on Monday February 25 resulted
in two data standards as strong candidates for our use case – NCPDP and CCDA, with NCPDP slightly
ahead based on the evaluation. With these leading candidates, we ask that all Committed Members of
the PDMP S&I Framework please vote for one or the other.
Please register your vote here as a response to this topic, along with any comments. As per S&I
Framework policy, only votes by Committed Members will be counted toward consensus.
The voting process is open as of today, Wednesday, February 27, 2013, and will close on Wednesday,
March 6, 2013. We will report the results via Google Groups, and note as well in our next scheduled
meeting, Monday March 11.
If you missed Monday's meeting, the slides are available via the ONC S&I Framework wiki.
Cathy Graeff
Feb 27
where do we vote?
Ken Majkowski
Feb 27
My vote is for the NCPDP Med History REQ/RES.
Rick Cagle
Feb 27
Hi Cathy - please simply reply to the topic with a vote similar to the format Ken used in
his post below. Indicate the standard and supply any comments.
Rick Cagle
Feb 27
To verify if you are a Committed Member of the PDMP S&I Framework Community, please
review your registration on the S&I Charter and Membership tab on the S&I Wiki.
Shelly Spiro
Feb 27
My vote is for the NCPDP Med History REQ/RES.
Maria D Moen
Feb 27
I would vote to support the NCPDP standard.
Kerri Paulson
Feb 28
My vote is for the NCPDP Med History REQ/RES
Chad Garner
Feb 28
NIEM
Derrick
Feb 28
My vote is for the NCPDP standard
Charlie Oltman
Feb 28
I vote for the NCPDP Med History Request and Response
L GIlbertson
Feb 28
As a comment, the NCPDP SCRIPT Medication History Request and Response transactions and
the Clinical Document Architecture (CDA) are really not an either/or. There are valid uses for
transactional exchanges between entities. There are also valid uses for the exchange of a
document between entities. There are valid uses of the combination. Other NCPDP transactions
include the transactional context and in addition support an optional CDA attachment. For
example, in Clinical Information exchange transaction, the pharmacy system might request
patient allergy information of a physician system. The response transaction contains
transactional information and a CDA attachment.
Cathy Graeff
Feb 28
I vote for the NCPDP Med History Request/Response standard
Bill
Mar 1
I vote for neither, since I feel the rating criteria were not adequate and the two standards
proposed did not have input in their development from PMPs.
Bill Lockwood
Srinivas Velamuri
Mar 5
I will go with NCPDP script.
Scott Serich
Mar 5
Here are my recommendations regarding the vote.
I perfomed these assessments on my own time (on lunch break right now). No time was charged
to any Federal grants to arrive at these conclusions. These do reflect IJIS Institute positions.
I believe there are two threshold criteria that any candidate specification should meet (even
before it can be included for further consideration in the compensatory weighted-scoring
model).
Firstly, the candidate specification must be NIEM-conformant. The IJIS Institue passed a formal
resolution endorsing NIEM in 2007, and I believe this threshold is consistent with the IJIS
position.
Secondly, the candidate specification must contain sufficient detail to enable two developers to
independently write orchestration code from the spec and have the results be interoperable.
Otherwise the way forward is littered with polyglot. Why bother.
I considered a third threshold criterion, that they be non-proprietary. But decided that this
didn't rise to the level of being a ground for disqualification. It may be an important one to some
stakeholders, however, so I believe it should remain in the weighted scoring model.
I have not seen the NCPDP SCRIPT candidate specification yet. So I cannot in good faith assert
that it meets either criterion and vote against it on both grounds.
Assuming that the CCDA candidate specification is what is described in
"http://www.hl7.org/documentcenter/private/standards/cda/CDAR2_IG_IHE_CONSOL_DSTU_R
1dot1_2012JUL.zip", it is not NIEM-conformant. Hence I would vote to reject it on this ground.
It's not clear whether it should be rejected on the second ground or not. The specification
included 10 sample XML files, which showed promise. Unfortunately, none of these samples
seemed to address the target user story. In particular, none of them contained a "Medication
Dispense" entry. So I don't feel confident that this spec contains sufficient detail to enable two
developers to independently write orchestration code and have the results be interoperable. I
would vote to reject the CCDA option on this ground as well.
While I have the stage, let me opine that from what I've been able to gather over the past
several days, the CCDA specification itself is a wonderful work product. The document
"CDAR2_IG_IHE_CONSOL_DSTU_R1dot1_2012JUL.pdf" contains over 140 strongly constrained,
reusable design components plus sample XML snippets. Perhaps whoever was behind it is now
working on harmonizing HL7 and the new NIEM Health Domain? It doesn't hurt to ask.
I greatly appreciate the opportunity to voice my views. My apologies if my bluntness has
offended anybody. Short, life is.
Chris Traver
Mar 6
Like another commenter, I have doubts about whether the rating criteria were the most
appropriate. If I recall, the difficulty to implement on the part of EHR's was the highest
importance, but the difficulty to implement on the part of the PDMP's was the lowest
importance. I'm sure that I missed an opportunity somewhere along the way to weigh in on
that, so for that I apologize, but some of the criteria weights struck me as unusual. Also if it is
true that PDMP's themselves had limited input to this point, then I would suggest that no final
decision be reached until there is an opportunity to engage the PDMP community at large.
Perhaps this is already part of the plan, but just signaling my support for that course of action.
But lastly and most importantly, I think we need to refactor how we are framing the decision.
While PMIX is a particular implementation of NIEM, it is very different from saying that PMIX 'is'
the NIEM option. My personal vote (and I believe I can speak for my agency - BJA - in this regard)
is that PMIX should be the preferred mechanism, having been carefully crafted over years of
direct work with PDMPs and their partners. But even barring that choice, I believe that any
solution must be based on NIEM, which is rapidly becoming a government-wide standard for
data sharing, including within HHS. NIEM is designed to be an inter-domain sharing model,
which is precisely what this scenario requires. It acts as a translation layer between the
standards being adopted across healthcare and justice, rather than serving one or the other.
And HHS is also working as we speak toward the creation of the Health Domain in NIEM, which
could directly support this effort both in terms of developing meaningful specifications, as well
as pushing the policy and funding levers to facilitate rapid adoption.
DOJ and certain components of HHS and DHS also require the use of NIEM for grant funded and
contractual activities, meaning that a non-NIEM solution would go directly against growing
cross-Departmental agreement on use of common data standards. NIEM also fits cleanly within
the Global Standards Package, which is the consensus model developed by state and local
justice practitioners that also includes service (SOA) standards, identity and access management
tools, and privacy protection protocols. Therefore it is a no-brainer from a justice perspective.
While this immediate issue perhaps does not seem to be of much relevance to justice, there are
significant ramifications to DOJ funded PDMPs (Harold Rogers funds require NIEM and PMIX; so
do SAMHSA grants). Also, as we begin work on broader justice/health collaboration activities
like continuity of care for individuals that come in contact with the criminal system or become
incarcerated, paving the way for a common data platform for exchange of relevant information
becomes even more critical.
For all these reasons, I believe that we may need to reconsider how we are evaluating the
various options, and consider refactoring NIEM as a foundational standard on which subsequent
solutions should be built.
John Poikonen
Mar 7
I think the PDMP folks have some valid points, but let me be frank. There are 50 State PDMPs,
400,000 MDs, 7,000 EMR vendors, 60,000 pharmacists 12,000 Pharmacies(?) that need the data
to enhance the care of our patients. The tail should not be wagging the dog.
Scott Serich
Mar 8
These facts are helpful, thanks. And I appreciate the frankness.
I certainly don't speak for the State PDMPs. We have clashed often in the past, and many of
them may be diametrically opposed to my comments below. But it may be helpful to at least
explore why the metaphor of one tail wagging one dog may be misleading. I'd proffer that there
are actually 50 tails and several dozen dogs, and the shared national goal is to somehow getting
them all wagging and walking in perfect harmony (please don't ask me to diagram it).
The tails are the 50 sovereign state governments, each of which must be sensitive to the
parochial needs of its constituents, even if this does fail to serve a purported broader "national"
mission (and causes my hair to gray prematurely).
The several dozen dogs are all the domains in which the States wish their electronic records
systems to interoperate, including transportation, public safety, courts, motor vehicles,
homeland security, the various health domains, etc., etc. PDMP is but a tiny slice that stretches
across multiple domains (at least several health sub-domains plus law enforcement, perhaps
others).
The SCRIPT specification may represent the best expression of interoperability standards ever
developed. From a state perspective, however, adopting it for PDMP exchanges would likely
engender little benefit for any of the other "dogs" (other domains). They could just as readily
argue that the current Initiative is attempting to have the SCRIPT tail wag the state
interoperability dog.
NIEM is at least intended to serve multiple domains. A state decision to adopt a NIEM-based
data interoperability specification for PDMPs is entirely consistent with the holistic state goal of
utilizing a common data modeling approach across all domains. SCRIPT would likely not serve
this purpose (probably never intended to do so).
It may also help to bear in mind that the states don't enjoy nearly the fiscal flexibility that the
Federal Government does. By adopting both NIEM and SCRIPT, a State would necessarily be
draining resources away from some other area. It's a zero-sum game for them.
On the other hand, if funds were being provided externally, with no hit to any state fisc, the
resource constraints might not be so binding and multiple standards could be justified.
Otherwise, faced with having to use more of their own scarce resources, the states might be
able to defend a NIEM adoption decision more readily to their constituents. They could even
argue that they're serving a broader national interest at the same time.
In fact, some of the states may be scratching their heads wondering why the Federal
Government itself isn't of a uniform mind in this regard. Perhaps the wagging tails number more
than merely 50?
Alternatively, somebody could start lobbying for a national PDMP and have all the data flow
directly to the Federal Government (let me know how that effort goes).
John Poikonen
Mar 8
This looks like an opportunity to bring the issue to the Feds.
https://www.federalregister.gov/articles/2013/03/07/2013-05266/advancing-interoperabilityand-health-information-exchange
Scott Serich
Mar 8
I agree. I'd be happy to help out with informal fact-finding, lessons learned, etc. A formal RFI
response would probably require backing (IJIS runs very lean).
Prescription Drug Monitoring Program: What does the label
"Accredited" mean?
(4 posts by 3 authors)
Scott Serich
Mar 2
The document "PDMP Standard Assessment.pdf" asserts that the PMIX/NIEM data model (a NIEM IEPD)
should score "1" on the criterion called "Accredited." What precisely does that mean? The only clue I
could find in the document itself is that the label stands for "Accredited standards body," but it doesn't
say who was not an accredited standards body for this model. Could somebody put a detailed
explanation in writing so that it can be shared with others?
I honestly don't know whether I agree or disagree with the assessment. I just don't understand what it
means at this point (for any of the candidates). I suspect that others might find the explanation valuable
as well. Perhaps it could shed some light on what might be expected (or not) in the new NIEM Health
Domain.
Thanks.
Prescription Drug Monitoring Program
Mar 4
HL7 (for CCDA) is an accredited standards development organization; and NCPDP is accredited by ANSI.
Scott Serich
Mar 4
Thanks. Bear with me a bit more. I just want to ensure that I understand the distinction between the
proposed initiative candidates that would merit some of them being labeled as "Accredited" and others
not. Is the proposed position of the Initiative that the organization responsible for the XML Schema
Definition Language on which NIEM is based is not an accredited SDO? Or just that the PMIX NIEM IEPD
specification itself was not authored by an accredited SDO?
Even if it's the latter, some components of the Federal Government have been sending signals to state
and local governments that they will be viewed favorably by adopting NIEM-conformant interoperability
specifications, while another component is now sending a signal that the adoption of such specifications
is going to be penalized. This puts the States in a bind, and one could easily imagine why they might
hesitate in adopting any Federal recommendations with respect to interoperability standards in the
future for fear that their decision might leave them in an unfavorable position down the road.
Is there some way to reconcile these conflicting messages?
By the way, the comment on the February 25 call that no State PDMPs are currently exchanging data
using the PMIX NIEM specification is entirely untrue. I believe the number of States using this
specification as the basis for exchanges today numbers in the double figures.
Chad Garner
Mar 4
"By the way, the comment on the February 25 call that no State PDMPs are currently exchanging data
using the PMIX NIEM specification is entirely untrue. I believe the number of States using this
specification as the basis for exchanges today numbers in the double figures."
Not only are the number of states using the PMIX NIEM specification in the double digits, several states
are using the PMIX NIEM specification to exchange data with EHR/EMR systems and HIEs.
Prescription Drug Monitoring Program: Solve for X
(3 posts by 2 authors)
Scott Serich
Mar 4
This has been nagging me aside from the upcoming vote, so I figured it merited its own separate
discussion topic. Again, I offer this from my own personal perspective as the former PMIX project
manager. They don't necessarily represent the views of the IJIS Institute or BJA.
Apparently over 500 people were dying every day in 2008 from preventable errors in hospitals. This had
actually been a longstanding problem, brought to the attention of many in the IOM "To Err is Human"
report in the late 90's. Forward 10 years... the 2009 HITECH Act resulted in a $20 billion appropriation to
"electronify" the nation's medical recordkeeping. Billions of dollars of incentive payments continue to
flow to hospitals and other healthcare providers under the Meaningful Use program. Kudos to
everybody involved... it looks promising.
Today there are over 50 people dying every day from prescription drug abuse. Here's a simple algebra
problem that the vast majority of taxpayers would readily understand (no reverse logarithm functions
required): if 500 deaths per day merits a $20 billion Federal appropriation, then 50 deaths per day
merits X. Solve for X.
By my calculation, it's in the neighborhood of $2 billion. If the Federal Government is taking the
prescription drug epidemic seriously, then it doesn't seem unreasonable for it to back up its words by
making some significant portion of the HITECH amount available to the State PDMPs to develop and
(more importantly) sustain the capability to interoperate with EHRs. A mere 0.1% of the HITECH
appropriation ($20 million, no?) would probably do the trick for year 1, and there might even be funds
left over to cover several years of maintenance to boot. Otherwise, the State PDMPs are going to have
the same challenge they've faced for several years now, struggling to find ways to meet payroll every
month and accepting funds from just about anybody willing to help out. Can we blame them?
No disrespect intended toward BJA or the Rogers PDMP grant program. I think the program has been a
smashing success and the nation should be thankful. But its magnitude pales in comparison to HITECH.
The Rogers program simply doesn't go far enough.
As I alluded to in an earlier post, this S&I Framework PDMP Initiative is also valuable in its own right. But
it might end up being an academic exercise if the State PDMPs continue not participating because they
don't see it addressing the more pressing problem of how to pay for these new exchange capabilities. By
my count, there were three State PDMPs on the last teleconference, which was arguably the most
important meeting of the entire initiative. Perhaps there is some plan to try to ram the results down the
throats of the other 47 States whether they partipate or not? No, I can't imagine that was the intent of
the initiative sponsors.
I don't know all the intimate budget details of every State PDMP that's out there. If they are all flush
with cash and don't know how to spend it all, then I am willing to stand corrected and will promise to
shut the heck up. Otherwise, the State PDMPs may not need $billions, but a couple tens of million would
probably magnify the value of this S&I Initiative many times over. And I suspect that the State PDMP
participation rate would skyrocket.
This message has been deleted.
George Shemas
Mar 4
You raise some excellent points in your post Scott. The recent S&I Committee calls have not
really discussed the funding issues related to support new standards adoption by State PDMPs.
The cost discussions have been limited to citing the larger numbers (count) of EHR vendors and
users versus the smaller numbers of State PDMP operations. Knowing that state agencies often
rely on Federal grants to enhance their operations, the recent discourse in Congress is
worrisome for funding initiatives such as this and it make take many years for PDMPs to acquire
the funds to enhance their systems.
Funding of system enhancements such as the ones proposed have frequently been easier and
more timely if done via participating private sector organizations.
---------------------------------------Google legal signature----------------------------------------------This e-mail transmission may contain confidential, proprietary and / or legally privileged
information and is intended only for the individual or entity named in the e-mail address. Any
disclosure, copying, distribution, or reliance upon the contents of this e-mail not authorized by
the sender is strictly prohibited. If you have received this e-mail transmission in error, please
immediately reply to the sender, so that proper delivery of the e-mail can be effected, and then
please delete the message from your Inbox. Any content of this message and its attachments
that does not relate to the official business of Saama Technologies Inc. or its subsidiaries must
be taken not to have been sent or endorsed by any of them. Email communications are not
private and no warranty is made that e-mail communications are timely, secure or free from
computer virus or other defect.
Prescription Drug Monitoring Program: Limitations on "non-public"
initiative activities
(1 post by 1 author)
Scott Serich
Mar 4
Gotta do this one quickly, while on lunch hour. At about 54:30 of the February 25 call, the point was
made that HIMSS does not rise to the level of being a "public forum," hence no official initiative activity
could take place ("information-only").
Does this also mean that any of the proposed PDMP-EHR exchange specifications for which members of
the public must pay a fee to inspect should also be considered "information-only"?
How can members of the public weigh in at all on the merits of any of these proprietary specifications?
It seems as if significant participation in the initiative's deliberations are being limited to just those with
the wherewithal to purchase these specs.
It also seems to raise a potential conflict of interest if those with a proprietary interest in selling copies
of the specifications are also engaged in the analysis of their merit.
Am I misunderstanding something?
Prescription Drug Monitoring Program: Who are the true stakeholders?
(8 posts by 6 authors)
Scott Serich
Feb 28
In reviewing our committed membership in the PDMP initiative, I noticed that the Charter only lists
"EHR vendors" and "HIEs" as the project stakeholders It seems odd that the State PDMPs, Pharmacy
interests, broader healthcare organizations, narcotics enforcement agencies, Federal interests,
pharmaceutical manufacturers, and perhaps others were excluded. Does the Charter accurately reflect
the only intended stakeholders or is this section just out-of-date? Thanks.
Vickie
Feb 28
I second that Scott. I feel that the scope of this project has been limited to prescribers and their
EHR process which is not the same as the pharmacy process. I feel there should be a second
initiative to review specifically what is best for pharmacy workflow, especially since all
pharmacies will not have an EHR like prescribers will. Let's not forget that pharmacies are the
ones reporting the data today (in ASAP). They are the ones that ultimately dispense the
medication to the patient. They are a very important stakeholder.
I was on the original work group that defined the fields for display back to the prescribers AND
pharmacies. We didn't segment one area from the other. Why are we doing so here if the
initiative is to satisfy both. EHR was not our immediate stakeholder then so why it is now?
Prescription Drug Monitoring Program
Mar 1
Vickie – the initial focus of our working group for the S&I initiative has been on the gap between
the PDMP and the EHR/HIE system and proposing a data standard to best tackle automating
that connection. We will capture your suggestion that a follow-on initiative address the
pharmacy workflow.
Chad Garner
Feb 28
I think this is a question that needs to be considered seriously. Looking at the members of this
group, I only recognize a couple of us as representing a Prescription Monitoring Program. We're
currently voting on which data format to transmit data with, but if the decision is largely
decided by EHR vendors and HIEs, I'm not sure what has really been accomplished. If we were
talking about exchanges of information between EHRs and HIEs, then it would be great. But, in
this case, it is the PMPs that you are looking to get data from. If they don't support this data
standard, then what have we accomplished? Currently, PMPs are supporting 2 data standards one of which is viable for Request/Response. As a whole, we don't use either of the standards
being considered. What is the PMPs' incentive for supporting a new standard, which duplicates
work that is already in place?
John Poikonen
Feb 28
<<< What is the PMPs' incentive for supporting a new standard, which duplicates work
that is already in place? >>>
How about relevancy? Unless the data from PMP's is transacted, there is little value for
them, IMHO.
May not want you want to hear, but the EHR world is beating to the NCPDP and CDA
drum. Let's not let the good get in the way of the perfect.
P.S. I have little skin in this game other than the practice and progress of pharmacy and
medical care.
Chad Garner
Feb 28
That would make sense, if PMPs were private sector businesses. Asking for additional
taxpayer dollars in order to "stay relevant" is a good way to become immediately
irrelevant.
James Dyche (Pennsylvania)
Mar 4
There are some very good points being brought up here. Since we are deviating a little
from the stakeholder question a little bit. Its seems to me that there may be a good
business model for someone/some business to perform transformation between
government and industry (assuming the Government stakeholders don’t belong). Like it
or not the Federal Government and many states are moving to the beat of the NIEM
drum…. Many states have already started mandating business and industry partners to
conform to their standards and keep them from implementing every different nuance of
“standards” implementations. Many of the current CDA standards really don’t
interoperate due to their specific implementations. It’s expensive for government to
address non interoperable standards implementations ….and who pays for that ….you
and I as tax payers… Alright enough of that….
Regarding the original stakeholder question. If we agree these stakeholders should not
weight in per this group….Should a new group be formed with the stakeholders
mentioned by Dr. Serich to address the other half of the drug monitoring/enforcements
standards problem?
Prescription Drug Monitoring Program
Mar 1
Scott – the section was out-of-date, and we have corrected that on the charter – thanks for
pointing it out. I added the State PDMPs, which better reflects participants on the meetings.
The update also reflects the use case we've focused on - automating the interface between
PDMPs and EHRs/HIEs.
Prescription Drug Monitoring Program: Did I miss the earlier coverage?
And some additional questions...
(3 posts by 2 authors)
Scott Serich
Mar 2
I'm going back through my notes and trying figure out how this new "NCPDP SCRIPT" model arose and
led to a vote so abruptly. Did I miss it when it was covered earlier?
As best I can tell from the Wiki and my email records, it wasn't even introduced until the February 11
Initiative call, whereas the other three candidates have been under consideration since as long ago as
the April 2012 Work Group finding (ref. slide 10 of the file "Analysis and Recommendations for PDMP-toEHR Interface - Data Format.pdf").
Was I asleep at the switch with regard to this new option? Or was it in fact not introduced until just a
couple weeks ago?
Given my very busy day job (just like everybody else), I can't imagine that I'll have sufficient time before
Wednesday to perform anything resembling due diligence (and that assumes that I'll have a reviewable
copy of the specification in my hands soon).
Is there any way to postpone the vote?
Alternatively, if the State PDMP stakeholders feel comfortable that they sufficiently understand the
NCPDP SCRIPT specification to make an intelligent vote already, I'll withdraw my request.
On a related note, whoever gave this spec a score of "2" on the PDMP Speed criterion, while giving the
PMIX/NIEM option a "1" must know something about the State PDMP systems that I don't. In fact, if
somebody could let me know which States *have* already implemented the SCRIPT spec, and which
States have *not* already implemented the PMIX/NIEM spec, this info would be very helpful as well
(thank you).
Thanks.
Chad Garner
Mar 2
Thank you, Scott for asking the questions that a lot of PMPs should be raising if they had the opportunity
and the time to participate. Rather than have a disproportionate group of stakeholders voting on data
standards that many of us have little or no knowledge of, wouldn't it make more sense to get
organizations which represent each group of stakeholders together to study the materials available and
see how they could apply to their membership? For example, the Alliance of State Prescription
Monitoring Programs would be in a much better position to put together a technical team to study this
and see which, if any states could support each format. As it stands, I believe so far two states have said
they could support one of the two formats preferred by the ehr vendors. Scott has been involved in data
exchanges involving PMPs for quite some time. The fact that he doesn't seem comfortable with the
direction this is heading should be a cause for taking a closer look.
Scott Serich
Mar 3
Thanks for the clarification, Chad. So it sounds as if it's the case that the State PDMPs are not of a
unanimous, like mind in believing that the current top candidate would represent a full consensus
recommendation of the identified stakeholders. In that case, I'll leave my request on the table that the
vote be postponed to allow more time for this new candidate specification to be examined and
assessed.
Personally (not necessarily reflecting the opinion of IJIS or BJA), to say that I'm not comfortable with the
direction the initiative has started heading is perhaps understating my concerns. There have been other
discomforting events. For example, the scoring model assigned weights of "Very important" (=3) to EHR
ease and speed of adoption, while assigning weights of "Less important" (=1) to PDMP ease and speed
of adoption.
I can't find anywhere in the record indicating that any State PDMP concurred with this weighting
scheme, which appears to be clearly biased against the State PDMPs. Maybe some or all of them did
concur, and I just haven't found the right spot in the record yet. Can anybody help me find the correct
location? Otherwise it seems peculiar that this scheme would go entirely unchallenged and casts doubt
(in my mind) as to whether it is a legitimate reflection of consensus on behalf of one of the identified
stakeholders.
It might also help all the participants to keep in mind that the identified State PDMP "stakeholder" is
actually a loose community of participants representing 50 sovereign governments. The fact that, in the
past, they have concurred on a common ASAP data model specification for reporting and a common
PMIX/NIEM data model for interstate exchange is, at some level, quite an accomplishment for which
they deserve credit rather than derision (ref. an earlier comment "Do you get points for being at the
table?"). If the initiative wishes to claim "consensus" including a stakeholder identified as "State
PDMPs," then the initiative probably *should* lose points for not have more State PDMPs at the table. It
might even make sense to list them as 50 independent stakeholders.
Alternatively, the "State PDMPs" stakeholder could be removed from the list entirely and replaced by
the Federal initiative sponsors. It might not be ideal, but it would probably better reflect the nature of
the actual "consensus" being reached.
Cutting to the chase, at the end of the day, the State PDMPs are severely resource-starved. If the
Federal Government or the EHR community wants them to adopt yet another exchange standard, this
could be accomplished more readily if this desire were backed up by sustained funding to the States to
meet the added burden. Consensus in the current initiative would clearly be desirable. But, frankly, the
funding commitments (or lack thereof) may end up being more determinative of the eventual outcome.
Prescription Drug Monitoring Program: Where can the CCDA data
format standard be found?
(4 posts by 2 authors)
Scott Serich
Mar 1
Has a copy and/or link to the CCDA specification that was referenced in scoring that candidate been
made available? I've searched both wiki and web trying to find it, but it's not clear which is the
authoritative source:
http://www.hl7.org/documentcenter/public/wg/structure/20111202_Consolidation_Publication_Draft.z
ip?
Is it this one perhaps:
http://www.hl7.org/documentcenter/public/wg/structure/20111202_Consolidation_Publication_Draft.z
ip?
Or this one:
http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=32?
If none of the above, could somebody point me to a copy or send me the link of the correct
specification? It probably wouldn't be important except that this option outscored two of the other
three candidates.
Thanks.
Thomson Kuhn
Mar 1
Here is where you will find the ONC-specified version.
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258
Thomson Kuhn
ACP
Scott Serich
Mar 1
Thanks Thomson.
Just so it's clear to any of the vendors (or in-house developers) who are trying to evaluate the effort &
time that might be required to develop exchange capabilities against the CCDA option, is it correct to say
that a typical response would be constrained by "Section 3.42 Medication Supply Order" on page 156 of
the document "C-CDATemplateLibrary_2012_12_21.docx"?
If not, can you point me to the correct location in the specification? Sorry for being so dense, but this is
new territory for me. Thanks.
Thomson Kuhn
Mar 1
Scott,
I am not familiar with "C-CDATemplateLibrary_2012_12_21.docx"
The correct document is titled "CDAR2_IG_IHE_CONSOL_DSTU_R1dot1_2012JUL.pdf"
The key section is "4.33 Medications Section 10160-0" which begins on p. 252 of that document.
"Medication Supply Order" is one of many possible entries that can be contained within a "Medications
Section," but I think that others would be more relevant, such as "Medication Dispense."
Thom
Prescription Drug Monitoring Program: Where can the NCPDP SCRIPT
data format standard be found?
(1 post by 1 author)
Scott Serich
Mar 1
I probably should have anticipated this in my earlier post, but where can the authoritative version of the
NCPDP SCRIPT specification be found?
Is the only way to obtain a copy before voting by paying to join NCPDP first?
If so, I'll probably end up having to abstain.
Thanks.
Prescription Drug Monitoring Program: Questions for Consensus - Data
Format
(27 posts by 8 authors)
Prescription Drug Monitoring Program
Jan 28
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
Jan 28
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?
Chad Garner
Jan 29
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.
Prescription Drug Monitoring Program
Jan 28
What actions could the PDMP S&I community pursue to provide a CCDA compatible form of
prescription information for a patient?
Cathy Graeff
Feb 7
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.
This message has been deleted.
Prescription Drug Monitoring Program
Jan 28
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?
Bill
Jan 29
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
Thomson Kuhn
Jan 28
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.
Thomson Kuhn
American College of Physicians
Prescription Drug Monitoring Program
Jan 28
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?
This message has been deleted.
Chad Garner
Jan 29
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.
Prescription Drug Monitoring Program
Jan 29
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-byside? 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
Jan 29
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
Chad Garner
Jan 29
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?
Chad Garner
Jan 29
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
Eric Hilman
Jan 29
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.
Eric Hilman
Jan 29
At the lower layers HIEs can support query with synchronous or asynchronous reply. The
message format/protocol in the PMIX documents supported query.
Prescription Drug Monitoring Program
Feb 19
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
This message has been deleted.
Prescription Drug Monitoring Program
Feb 22
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
Feb 25
[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
Feb 25
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. >>
Prescription Drug Monitoring Program: Data element "Strength
Qualifier"
(3 posts by 3 authors)
tjea...@cdc.gov
Jan 31
I was reviewing the data elements presented on Monday (screen shot of slide is attached). Does
“Strength qualifier”= dose?
Tammara (Massey) Jean Paul
Centers for Disease Control and Prevention
Janet Johns
Feb 1
Hi Tammara
No, strength is not the same as dosage. The strength is the concentration of the medication and dosing
is administration units.
(from HITSP C83)
The strength should be in the coded product or brand name if it describes the strength or concentration
of the medication.
The dosing is in administration units (e.g., 1 tablet, 2 capsules).
Chad Garner
Feb 1
I think there is some confusion in the terminology that we are using. I don't know the HITSP C32
standard at all, so I can't speak to it. Neither the NIEM nor ASAP contain anything called Strength
Qualifier, so I'm not sure exactly what this is. If it is "Strength", as Janet mentions, such as 5mg/ml, then
this is derived from the NDC code. If it is Dosage Unit, called Drug Dosage Units Code in ASAP 4.2, then
this is Each (ea), milliliters (ml) or grams (gm). This still does not tell you the actual daily dose that a
patient is receiving. This mostly valuable when you are dealing with a pure substance, like Testosterone
Powder. A simple quantity really wouldn't tell you anything without it. It still does not tell you if the
patient is to take 3 caps per day or 2-3 caps per day. Again, I don't know about HITSP C32, but the Drug
Dosage Units Code is available in ASAP 4.2. The NIEM format was created based on ASAP 4.1, which did
not have this value, so the NIEM does not currently have it, but will be updated at some point to reflect
the changes in ASAP.
Chad Garner
Chief Technical Officer
Ohio State Board of Pharmacy
Prescription Drug Monitoring Program Topic: Discussion of Work Group
Recommendations: Data Format Standards
(7 posts by 5 authors)
Prescription Drug Monitoring Program
Jan 7
Please use this area for discussions of the PDMP Phase 1 Work Group Recommendations for Data
Format Standards. We would like to reach consensus on a data format for sharing prescription
information between a PDMP system and an EHR/HIE system, and focus on how to best serve the
Healthcare Domain and Patient Quality of Care.
Prescription Drug Monitoring Program
Jan 9
(Posting this on behalf of Bill Lockwood of ASAP):
I wanted to get back to you with clarification on a few things regarding ASAP.
1. The statement was made that there are a variety of versions of the standard being used. This
is not true. The vast majority of the states are either using 4.1 or 4.2 and the differences
between the two are minor. I have also had word from several states that they are planning to
move to 4.2 from earlier versions.
2. In the past it has been the policy to review the standard every two years to see where
improvements were needed in order to increase the quality of the data reported. The last
update was in September 2011, when we introduced 4.2. The forward of 4.2 explains the
changes made to 4.1. Again, minor stuff, but important in improving data quality. There are no
plans to publish a new version in the near future.
3. The ASAP standard is a standard, not a specification. State PMPs publish the specs on how
they want the standard used. For example, some states may need data elements in the AIR
segment, while other states may not. But all work within the standard, Codes cannot be added,
field definitions cannot be changed, field lengths cannot be increased. I mention this because
you referred to the ASAP standard in Monday's call as a specification.
4. Versions 4.1 and 4.2 can be used to submit prescription records in true real time, if a state so
decides to support real-time capture at the time of prescription processing.
5. In addition to the ASAP standard used to report to PMPs, ASAP also developed a Zero Report
standard, which is being used now in a few states, when no controlled substances were
dispensed during the reporting cycle. The other is an Error Report standard that states can used
when there are problems with the prescription records received that must be corrected and
resubmitted.
6. Our latest initiative, which we just wrapped up, is a new standard to allow bidirectional
connectivity to PMPs. The attached press release explains the purpose and design of this
standard. Work on the development spanned six months. Our workgroup had participation from
25 individuals representing a range of stakeholders, including a number of PMPs.
John Poikonen
Jan 10
As much as I love Bill L and have no opinion of Surescripts, there is a case to use the
established standard already implemented with systems. Unless of course, there is a
compelling reason or lack of functionality in the existing standard.
On the EMR side:
Many (most) EMR currently have capabilities to use the Script/Surescript standard to
pull in a patients medication profile. Utilizing current capabilities will increase adoption
time dramatically. I would be interesting in the delta and compelling reason for using
ASAP in lieu of this standard already in place for EMRs. Perhaps I am missing something.
On the Pharmacy side:
Pharmacy systems are not as entrenched with the Surescript profile standard or the
Script prescription standard. Therefore pharmacy system vendors may have to build
capabilities for incoming data with one Standard or another. Submitting a dispensing
event for real time support of the PMPs with the current claim Standard from NCPDP is
not adequate. Using the ASAP standard here makes a lot of sense.
On the PMP side:
Supporting one standard for outgoing data to EMRs and Pharmacies and another for
incoming transactions (Pharmacy only) seems to me to be the preferred option.
The press release mentioned was not attached, so I will look to read and understand
that as well.
Regards,
John Poikonen, Pharm.D.
Vickie (vickiepatterson@charter.net)
Jan 14
I am very much in agreement that we should use the ASAP standard to retrieve PMP
history. I have saw the latest implementation guide for the ASAP prescription
monitoring program (Version 1 Release 1) for retrieving historical data. I think it is a
good solution to use. It makes sense from a consistency standpoint to retrieve PMP
history using ASAP, which is the same that we use to transmit the data to the PDMPs. If
additional data was added to the current ASAP format for uploading data to the PDMPs,
then it could be easily reciprocated by the same entity for the change to the historical
feed if applicable. If we introduce NIEMs or any other format, then we are adding
another vendor/process/roll out to the mix. I have worked for a pharmacy software
vendor for 15+ years now, and I can't recall where we have ever mixed entity standards
in the same business objective between the pharmacy and the vendor. It would be like
saying use NCPDP D.0 to transmit claims but use another format for the response. Or
use Script 10.6 to transmit prescription refill requests but another standard to accept a
new rx.
On a side note, I am also a member of NCPDP, where issues such as these are
addressed. Wouldn't these questions be best answered with participation from NCPDP?
Members of NCPDP include prescribers, pharmacies, and software vendors.
Maria D Moen
Jan 17
It appears that I just posted my reply in the wrong location, perhaps I need some
standards brought to bear on my behalf? :o) Here goes again:
From a data format perspective, it is my opinion for LTPAC specifically, that there are
two potential standards on the table and both are attractive from a vendor perspective
and therefore, from a provider perspective. The NCPDP SCRIPT 10.6+ formats
incorporated the changes needed to address the specific nuances of LTPAC, and were
called out in some legislation related to the ePrescribing exemption. The HL7 data
structures used currently by LTPAC to exchange data are another option, less rich in
terms of messaging and quality of data exchanged, but more pervasive currently in
terms of use.
There are a number of pharmacy interfaces in use by LTPAC across the country, some
are proprietary and not standard and you know who you are, many are emerging that
achieve some level of standardization through HL7 and less commonly, by NCPDP
SCRIPT. We prepared a position/comment letter to CMS less than 6 months ago and
recommended that the NDPDP SCRIPT 10.6+ standards be part of lifting the exemption
from LTPAC - this position was prepared by NASL and had the full cooperation and buyin of many of our software vendors. They are poised to integrate the new standard into
their products, but as with most things in life, there needs to exist a compelling business
case to take on the development cost. And provider demand due to lifting the
exemption qualifies nicely.
I look forward to discussions with this workgroup so that a cross-pollination between
different perspectives can be brought to bear and we can all learn something from one
another.
Chad Garner
Jan 11
Bill Lockwood has done a great job at getting all of the stakeholders together to decide what
fields are required to exchange data between PMPs and Pharmacies. Yes, states do implement
ASAP in slightly different ways, but at the end of the day, if you just account for the entire
standard, you should be okay. The only problem with the ASAP standard is that the X12 format
that is used is quite cumbersome.
The PMP community has spent a great amount of time and energy developing the PMIX IEPD,
which is a NIEM (federal standard) conformant XML schema, to exchange data between PMP
systems. All of the major PMP vendors have already developed this model. This schema was
developed with the ASAP format as a guide - so we leveraged the great work that Bill has
already done. The format can be used for data submissions or request response. It can also be
easily extended to fit other needs. It is already being used in Ohio to allow hospital EMR systems
to request prescription history reports in an automated, real-time fashion via a Health
Information Exchange as well as directly with another EMR system used in local physicians'
offices. Ohio is currently in the planning stages to do the same in pharmacies. I believe (although
someone would have to verify) that the PMIX format is also being used in Indiana and Kansas to
exchange data between their PMPs and local HIE's. So, if we're looking for a standards-based
data format for exchanging prescription information, I don't think you have to look much further
than the PMIX IEPD. It has already been developed, it's flexible, it's free, and it is already in use
in multiple states across multiple sectors of the healthcare industry.
Chad Garner
Chief Technical Officer
Ohio State Board of Pharmacy
Prescription Drug Monitoring Program
Jan 14
There is much good discussion here so far - thank you to all who have responded, and looking
eagerly forward to more input from others as well.
As a reminder, we wanted to focus our initial efforts on reaching consensus on the format for
data exchanged between a PDMP system and prescriber system, emphasizing the Healthcare
Domain.
Could we also hear more feedback from various EHR systems vendors, users, etc. on existing HIE
standards, and impacts of Meaningful Use requirements. How can the PDMP community help
to lower the barrier of entry for prescribers to use the data available? What are the standards
EHR systems can support? What standards are already in place, and how does MU2 or MU3
affect plans for standards?
Prescription Drug Monitoring Program Topic: PDMP General Questions
(1 post by 1 author)
Prescription Drug Monitoring Program
Jan 7
In this space, please post any questions about:
General Project Information
The Phase 1 PDMP Background information
Working Group Recommendations
Your questions and feedback will be responded to shortly by a member of the PDMP project
team. Thank you for your interest!