Stream: Da Vinci
Topic: Non-PHI CRD
Lloyd McKenzie (Jul 31 2018 at 21:47):
@Robert Dieterle or anyone else - what's the specific reason that CMS and others want to be able to invoke CRD without sharing PHI?
Robert Dieterle (Aug 01 2018 at 07:47):
There is no need for PHI when asking a question that is a general coverage question (e.g. does advanced imaging need authorization, what do I need to document to have home oxygen therapy covered). this is especially true for single plan payers (e.g. Medicare FFS and Medicaid). In addition, any federal environment that receives PHI needs to be managed at a much higher security level than one that just deals with publicly available information. If PHI is not necessary to answer CRD questions, then we should not be forced to exchange PHI and add the HIPAA security complications. The need for this option was identified up front in the use case . Yes, it will require two different profiles for patient demographics (one that provides a full set and one that only sends DOB, gender, and State). If we cannot handle it with CDS Hooks, perhaps we should go back to the FHIR operation.
Robert Dieterle (Aug 01 2018 at 07:56):
BTW when I refer to a much higher security level for a federal agency, it's requirements greatly increase the cost and time to establish such an environment and maintain it on an ongoing basis. In addition, to really utilize the PHI, there will need to be integration with the current operating environment that does contain PHI. All of these are unnecessary to answer the coverage questions anticipated for Medicare, Medicaid, and possibly some commercial payers where the specific plan is identified.
Lloyd McKenzie (Aug 01 2018 at 14:20):
The question is more about "where should the complexity live?"
From the EHR's perspective, they have a user who is undertaking a clinical or administrative action - creating an order, starting an encounter, etc. They have a whole bunch of clinical data that describes that action. The simple solution for EHR vendors is to expose the clinical data all the time as the payer is authorized to view it. Creating an anonyimized non-PHI view creates a considerable amount of effort on the EHR vendor side as they have to implement separate hooks in a number of places and the data provided for those hooks would have to be specific to the Payer usecase. They'd be faced with the prospect of doing something similar for different use-cases that would need different information because, unlike the PHI hooks which can use the query mechanism for extra data, in a non-PHI scenario, query to retrieve extra data is going to be very hard to do technically, and thus means all the data needs to be delivered up-front.
We'll need an answer from the EHR participants whether they're willing to accept that additional complexity/cost in order for the payers to avoid complexity/cost.
Robert Dieterle (Aug 02 2018 at 14:45):
We started this use case with the understanding and subsequent agreement by all of the parties that it will support both a non-PHI and PHI version of the request for coverage. Medicare patients should not be required to have their PHI shared with CMS every time the provider is asking a question regarding the requirements of public coverage rules and templates. Depending on the use case, it may not even be permitted by regulation. CMS provided in-kind resources to help with this use case, has promoted it internally and externally as the Documentation Requirements Look-up Service and is currently building out the ability to respond to a non-PHI query so they can pilot this fall. The IG for ballot in September needs to support this ability! If we went down the wrong path with CDS Hooks and the ability to support both the PHI and non-PHI version (BTW all stakeholders on the call , including the EHR vendors agreed that CDS Hooks approach supports all of the documented requirements), then lets move back to a custom operation.
Lloyd McKenzie (Aug 02 2018 at 16:07):
Ok. So the driver for the non-PHI version is not so much "CMS doesn't want to go through the paperwork/process to do a HIPAA-compliant PHI interface. The issue is that because this isn't strictly a "necessary" operation to provide payment, there are, at least for some scenarios, regulatory barriers that prohibit CMS from accessing PHI and even in the absense of those barriers, there's perception issues around PHI flowing to "government" when, strictly speaking, CMS doesn't actually need that PHI to perform the function. That makes sense.
Kevin Shekleton (Aug 02 2018 at 17:55):
Thanks for the additional context, Robert.
Last updated: Apr 12 2022 at 19:14 UTC
