Agree with Mark Savage that push messaging between participants is a critical component of functional interoperability, especially as relates to care coordination. Ad hoc push, in particular, is valuable for care team members to coordinate care.

I have made a presumption that individual access will be taken care of in a separate policy - perhaps that’s true of adding other push use cases

Most providers have the ability, through their certified EHR, to send a Direct secure message with appropriate attached documents, including a Continuity of Care Document, to other care team members with a Direct address available through the national directory. This is an inexpensive and readily available tool set to support the much needed coordination of care between medical and social/community service providers.

Yes, if both endpoints are Direct-capable. Users of certified systems likely have lots of options not available to those who do not.

Yes, and plenty of Health Information Service Provider (HISP) vendors provide inexpensive access to Direct via web-based apps that could be utilized by those without already capable/enabled software systems.

On slide 18, 1.a.ii. states that participant delivering the electronic HSSI must ensure participant is authorized to receive the data. We discussed this in the earlier DSA meetings, but this bullet implies consent-driven management and potential data tagging of data elements that require consent (Part 2 data, LPS, HIV test results in some cases, etc). Should language be added here to reference the "how" of consent-driven management?

https://www.healthit.gov/sites/default/files/page/2020-07/0720_Direct%20Secure%20Messaging%20Basics.pdf

That consent could be provided as part of providing consent for services and receiving the HIPAA Notice of Privacy Practices. If individuals need to opt in specifically to this exchange it will not scale.

I think the intent on securely destroy is just to make sure that the information that wasn’t supposed to be disclosed in the first place is disposed of in a way that doesn’t increase risk - maybe take care of in security P&Ps?

Fwiw, requiring secure destruction is consistent with the HIPAA security rule.

👍

For awareness around consent and authorization Not all participants use HIPAA notices of privacy practices. Most of CDPH is not HIPAA covered.

Yes - but we reference HIPAA standards for all participants in other aspects of these policies, as I recall, in order to try to create more of a level playing field. But consistent with Shelley’s comments, if you need to get consent before you share data, it would be your obligation to do so as the sender per the framework agreement (or if your particular legal obligations don’t allow you to collect data without a patient’s authorization/consent).

I think it would be really helpful to map out a bunch of expected use cases, and the obligations on each end of those transactions.

For different types of Participants

Agree that use cases with information flows would help tremendously to tweak the language in ways we've been discussing so far.

The standard for https://directtrust.org/standards/event-notifications-via-directsending ADT notifications via Direct:

Again, this is the standard for sending ADT notifications via Direct: https://directtrust.org/standards/event-notifications-via-direct

Minor thought for this ADT section - even though this is the technical req P&P, should it reference the real-time P&P here to let readers know that there are also timing expectations?

We should not assume that Event Notifications must go through a QHIO, unless that definition includes Direct as an appropriate method/HIO.

I think the QHIO provisions are intended to govern when QHIOs are utilized - I could see these, and other, provisions also part of the criteria for which HIOs are judged on whether they can be QHIOs. But if we are going to promote Direct in these policies, do we also need to include those standards or vet providers of those services if we’re going to recognize that methodology expressly in these policies.

Again, I do not think this policy requires use of a QHIO - just making sure that if a participant uses an HIO, they are using one that meets the requirements. Potentially we need similar requirements for other technologies we are encouraging people to use....

I believe that it should be A AND B are required, not one or the other.

To Bill's question, wouldn't the requirement to use one or the other means that if a.i.a. does not work (if one wants that), then must use a.i.b.

*mean

If a hospital is able to meet requirements to notify participants in accordance with required standards, why must it be required that they use a QHIO if they can fulfill the requests through other means (Direct or otherwise)?

Are the Hospitals required to notify the payers with ADT as well? They are players in this as well, not just providers.

The issue is with a provider who wants to receive notifications, but does not want to comply with the burden of a hospitals preferred method of delivering notifications, which often entails paying a 3rd party vendor.

It is unlikely that independent, small practices in larger networks like ACOs and IPAs will be able to accomplish direct exchange with hospitals. This has been a common problem. QHIOs are the most likely solution. But the goal of getting ADT information exchanged is a KEY priority for improving patient outcomes.

Having the hospital provide that ADT to a QHIO provides a digital safety net for those providers to receive that ADT notification from a QHIO.

How will all of this play in the Population Health Initiatives that are currently moving forward.

agree with Jason Buckner

Agree about QHIO being a digital safety net for ADT notification!

In this exchange purpose, do we have a plan to support limiting responses to the Minimum Necessary data required/requested?

Minimum necessary not required for treatment under HIPAA, fwiw. In general, we require senders to comply with applicable law in their responses, per Shelley’s earlier comment.

Many times a Continuity of Care Document (CCD), the most common response to an IHE query, contains more information than necessary for some use cases.

With these mandates for both hospitals and QHIO's is there funding to support this comprehensive model of ADT communications and appropriate management thereof

Explanation on what would qualify as an “appropriate null response or error message” would increase clarity corresponding participants

*responding participants

As community and social service providers will have access and ability to query, and we state that they must comply with HIPAA, does this imply that they need not request minimum necessary, or that data providers are excused from Min Necessary restrictions?

Do you consider a community and social service provider to be acting as “treatment” for the patient? If so, minimum necessary won’t apply under HIPAA.

(And care coordination, when done in the context of “treatment,” is considered treatment and not operations)

https://www.healthit.gov/sites/default/files/page2/2020-08/Health_Care_Provider_Definitions_v3.pdf

It seems that only certain community/social service providers meet the definition of “Provider” under applicable law. Is is acceptable to say that (categories of) individuals are providing Treatment if they are not a Provider?

Project US@ is pronounced “Project USA”

https://www.healthit.gov/isa/uscdi-data-class/patient-demographicsinformation#uscdi-v2

Maybe there is a requirement we should put in that requires those who query for data to ask for only what they need to meet the purpose, and the concomitant duty to respond is to provide the data requested, recognizing that in some cases it may be difficult from a technical standpoint to segment data not requested? And in push transactions, the obligation should be on the entity initiating the push to provide the data required in a way that is consistent with law.

(Correction - respondent is to provide the data requested consistent with law )

Good approach, Deven. 👍🏼

Here's HITAC's Interoperability Standards WG language: "Current and Previous Address should contain not only the components of address (number, street name, city, state, zip) in accordance with the Project US@ specification, but also must contain a value or values from the Patient Address Metadata Schema, which is able to represent homelessness or temporary addresses.”

Devon - so a requestor could ask for demographics, encounters, results and procedures. And the respondent should ONLY include those elements? Is that what you are proposing?

Good to see that this review will be completed at least annually.

Jason, where technically feasible, yes. But where those elements requested are part of document that has other elements in it, like a CCD, and it’s not possible to carve those out, then the CCD could be sent in order to meet the needs of the requestor. Just trying to think about how to address Steven’s concerns about minimum necessary, including in the context of social services where it’s not clear they would be exempt from minimum necessary under hIPAA’s treatment exemption. Trying to balance fair information practices with practical realities of document-centered exchange architectures.

Got it and it makes a lot of sense when considering technical feasibility.

I anticipate that many providers will be reluctant to send a full CCD to community care organizations that are not clearly HIPAA covered entities even if we say, as part of the State DxF, that those individuals are bound by HIPAA.

I agree with Steven...we need to align communications and common language with the Feds...Otherwise it is going to complicate and confuse. It is already confusing enough

second Jason and Mark on no need to change the name

thank you

Referring to it as the California Information Blocking Rule would be clearer for those participants only subject to the rule through this policy

And the Early Exchange P&P states that these effective dates don't apply to early exchange.

Under the federal rules it is HHS OCR that determines whether an action constitutes Information Blocking. 
https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6

No, actually it’s OIG (Office of the Inspector General). For state policy violations, there will need to be an enforcement body/entity to decide whether blocking has occurred.

Thanks!

Do we anticipate a parallel State process for adjudicating InfoBlocking complaints?

If so, could this, perhaps, apply only to actors in CA not covered by the federal InfoBlocking prohibitions?

https://www.healthit.gov/sites/default/files/page2/2020-03/InformationBlockingExceptions.pdf

Do we really want a health care provider being able to charge a fee to a social services agency for sending them data? The could if they rely on the info blocking fee exception in terms of the scope of that fee

Perhaps we could specifically prohibit that, Deven.

This does seem a reasonable approach to expanding the scope of this authority.

That’s what I was talking about in terms of making sure the fee and licensing exceptions wouldn’t apply to that type of exchange, while making sure that entities/organizations providing the “interoperability elements” (mechanisms for exchange) could operate consistent with the federal fee and licensing exceptions.

Helpful FAQ: https://www.healthit.gov/sites/default/files/page2/2020-03/InformationBlockingExceptions.pdf

The FAQ above provides detail regarding Type of Harm and how this applies, under InfoBlocking and HIPAA, based on the requestor.

Change to applicable law is appreciated.

Apologies. Am going to log back on, as I am experiencing some technical difficulties.

"California Information Blocking Prohibitions"?

👍🏼

good with California Information Blocking P&P

Good suggestion Diana and Steven, thank you!

It may be helpful to refer to the timeliness of making data available as opposed to the timeliness of exchange, as delays in the exchange itself may not be under the control of the data holder.

ONC InfoBlocking FAQ: When would a delay in fulfilling a request for access, exchange, or use of EHI be considered an interference under the information blocking regulation? https://www.healthit.gov/faq/when-would-delay-fulfilling-request-access-exchange-or-use-ehi-be-considered-interference-under

I second that comment by John Helvey

I am also concerned that the introduction of “as soon as practicable” and “no more than 24 hours” add a loophole to our CA law that is NOT supported by federal requirements.

“It would likely be considered an interference for purposes of information blocking if a health care provider established an organizational policy that, for example, imposed delays on the release of lab results for any period of time in order to allow an ordering clinician to review the results or in order to personally inform the patient of the results before a patient can electronically access such results (see also 85 FR 25842 specifying that such a practice does not qualify for the “Preventing Harm” Exception).To further illustrate, it also would likely be considered an interference:where a delay in providing access, exchange, or use occurs after a patient logs in to a patient portal to access EHI that a health care provider has (including, for example, lab results) and such EHI is not available—for any period of time—through the portal.where a delay occurs in providing a patient’s EHI via an API to an app that the patient has authorized to receive their EHI.”

Technology restrictions = “infeasibility”

Operational delays = information blocking

Or may

I believe that the CMS rule or FAQs may call out timing of ADT notification timelines we can reference.

👍🏼

Early Exchange - as long as you clarify what you just stated in this policy it will help eliminate confusion

Good question, Deven.