Data Standard Consensus Voting (Committed Members Only)

[Rick Cagle]

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]

where do we vote?

[Ken Majkowski]

My vote is for the NCPDP Med History REQ/RES.

[Rick Cagle]

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]

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]

[Maria D Moen]

I would vote to support the NCPDP standard.

[Kerri Paulson]

[Chad Garner]

NIEM

[Derrick]

My vote is for the NCPDP standard

[Charlie Oltman]

I vote for the NCPDP Med History Request and Response

[L GIlbertson]

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]

I vote for the NCPDP Med History Request/Response standard

[Bill]

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]

I will go with NCPDP script.

[Scott Serich]

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_R1dot1_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]

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]

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]

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]

This looks like an opportunity to bring the issue to the Feds.
https://www.federalregister.gov/articles/2013/03/07/2013-05266/advancing-interoperability-and-health-information-exchange

[Scott Serich]

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).