FHIR Chat · Coordinate HIE Efforts With Patient Empowerment Group

Stream: patient empowerment

Topic: Coordinate HIE Efforts With Patient Empowerment Group

Josh Lamb (Jan 17 2021 at 22:44):

Hello,

I am currently workshopping a technical correction that may be of interest to the Patient Empowerment community. The technical correction will help ensure advanced patient access and that patients are always included during health data exchanges.

Despite CMS's comments to the contrary, this approach reduces patient engagement requirements while allowing for HIPAA protections to stay in place. This approach relies upon industry standards and existing capabilities, unlike the current proposal.

I am maintaining a narrative and a series of infographics to help illustrate this concept on my LinkedIn: https://www.linkedin.com/posts/josh-lamb-686238149_the-following-infographics-illustrate-an-activity-6756850035817771008-D-Ma

Let me know if this is interesting for this group.

@Debi Willis and @Dave deBronkart FYI, this relates to a comment made by CMS to coordinate with Patient Empowerment on this issue: https://www.cms.gov/files/document/11521-provider-burden-promoting-patients-electronic-access-health-information-e-prior.pdf

Thanks,

Josh

Dave deBronkart (Jan 18 2021 at 00:33):

@Josh Lamb I love that CMS directed readers to come work with us! Pretty good for a rookie WG, huh people?? cc @Grahame Grieve @Lloyd McKenzie and all :smile:

Seriously, though, I / we / the patient community out there ... to advocate on this as informed citizens, I / we-all need to understand what the problem is that you're solving, and why you (apparently?) assert that CMS is doing it wrong. Doing what wrong? What ARE they doing that you think is wrong?

Don't get me wrong - I'm thrilled that we find ourselves at this amazing intersection of policy, technology, industry interests (including finance) and consumer empowerment. Who out there can help us unpack this?

Dave deBronkart (Jan 18 2021 at 00:41):

Update: working back through messages, I now see your post yesterday explaining what this is about. I apologize but I for one don't even know enough to understand what you're even talking about.

Help, policy wizards! I'm starting now to appreciate the value of "consumeristas" in HHS like Lygeia Ricciardi and Deven McGraw and Sherry Reynolds.

@Steve Posnack HELP! Who can de-Greek this for us?? @Ryan Howells do you have unpacker / de-Greekers? Should we bring in Ian Morrison to enlighten us with futurist wisecracks?

Again, @Josh Lamb , I'm grateful for this but I really need help.

Josh Lamb (Jan 18 2021 at 04:54):

Thanks for raising alarm bells @Dave deBronkart!

We will soon build out new infrastructure to support business-to-business health exchanges. CMS has required that implementers use a specific technical guide to perform these exchanges. I am attempting to highlight a better approach that will reduce costs, improve quality, and empower patients. This alternative utilizes current capabilities and existing Patient Access to fuel inbound business-to-business communications. This step is important for aligning interest across healthcare. Currently, contention exists between patient-directed exchanges and business-to-business exchanges. If we can reduce the number of outbound mechanisms used to communicate patient information, we can improve our existing Patient Access API quality. Using the Patient Access API to support business-to-business needs will eliminate this contention.

Perhaps I can join a WG session to introduce the issue? Unfortunately, the issue is complex and will be difficult to digest for the folks who have not been in the DaVinci PDex workgroups.

The LinkedIn post I referenced above is currently my best attempt at summarizing the issue in an "easy" to digest format. I realize I have more work before this is a reality.

The Patient Empowerment community may assist with aspects of this proposal affecting engagement, data quality, and establishing best practices.

Debi Willis (Jan 18 2021 at 15:55):

Josh Lamb said:

Let me know if this is interesting for this group.

Debi Willis and Dave deBronkart FYI, this relates to a comment made by CMS to coordinate with Patient Empowerment on this issue: https://www.cms.gov/files/document/11521-provider-burden-promoting-patients-electronic-access-health-information-e-prior.pdf

@Josh Lamb Thank you Josh. Anything that impacts patients is always interesting to us! I read your LinkedIn article and have questions. I imagine others in the Patient Empowerment Workgroup would also have questions. It would be good to get you on our calendar for February to have you present and let the group ask questions. Would you like to do that?

I am thrilled CMS is recommending connecting with our workgroup when building data collection workflows. That was a nice surprise. That is what we are here for...to help brainstorm and give feedback from the patient perspective.

Josh Lamb (Jan 18 2021 at 17:30):

@Debi Willis, thanks for offering to discuss these important issues. I have already learned a lot by observing the Patient Empowerment community. I would love to dig deeper into the various ways that Patients can engage with care delivery and health data. Today's "E" patient can help establish best practices and pilot new technologies.

There is limited time to address the technical change I am requesting. I will need to gain an audience with Chairs on the Financial Management Workgroup and implementers within the DaVinci PDex workgroup. I will also attempt to leave a formal ballot comment (Jira Ticket) requesting this change. A minor technical change will allow the PDex Implementation Guide to support Patient Access for authorized data releases. The leading proposal requires that we develop new mechanisms to deliver patient data. Creating new Payer and Provider Access APIs will result in redundant work, low-quality/segmented data, reduced patient access, and this work competes with the existing Patient Access API.

This change ties into Patient Empowerment for several reasons.

Rather than workshop this on my LinkedIn, I will place updates on a Google doc, maintained here:
https://docs.google.com/document/d/1yU-4ur5TBxU1RQXwCJi19xNk6LAahTVOTM2Ap4068PU

Thanks again.

Bart Carlson (Jan 19 2021 at 03:42):

While I may not understand all the subtleties in your diagrams without further discussion, I do believe many of the ideas you have included in your diagrams have merit. For example, when we were designing our new enterprise-based Lifetime Clinical Records Platform, we became convinced that standardizing the backend infrastructure and streamlining the processes of retrieving, storing, and/or distributing clinical data from/to multiple endpoints would expedite adoption and empower Payers, Providers and Patients. We also believed it could help empower 100s if not 1,000s of life saving health apps fulfill their end-goals for Patients by reducing the access burden for clinical data to a single click.

I would like to learn more about your vision. And, please let me know if I can help in anyway.

Josh Lamb (Jan 20 2021 at 04:42):

Hi @Bart Carlson ,

Thanks for reviewing the diagrams! I agree that a complete medical picture, connected to all data producers, will allow applications to fulfill many powerful roles.

Using existing Patient Access API sources to receive data is trivial (compared to new APIs). The resistance to this suggestion occurs because of two reasons:
1.) A Misconception that the Patient Access API will cause HIPAA protections to be lost (Payer and Provider applications will register with each other and can directly query other sources).
2.) A Misconception that the Patient Access API will require additional consumer engagement. The work needed to enable free-flow exchanges between data holders have not yet begun and will compete with the Patient Access API. Instead of building out new APIs , we can reduce patient engagement requirements to connect to Patient Access API sources.

A payer/provider application can use consumer opt-in preferences to perform exchanges without engagement/internet access. This only requires that a consumer activate a portal account and opt-in (can be automatic).

The following diagram illustrates how connections to the patient access API can be added (using current technology):
Accumulate-Consumer-Connections.png

Josh Lamb (Jan 20 2021 at 20:03):

@Dave deBronkart and @Debi Willis and @Josh Mandel and @Bart Carlson
and @Steve Posnack , Is the below punchy enough for everyone?

As a community of healthcare data producers, we have an important decision to make: Do we improve patient access and reduce costs (while helping businesses), or do we build out expensive new infrastructure that is only usable by businesses?

A national healthcare policy, CMS-9123-F, requires the use of DaVinci PDex (a FHIR Implementation Guide). PDex defines allowed interactions between CMS impacted data producers (payers and providers). But PDex does not specify the exact exchange mechanism. PDex IG also does not prevent using the Patient Access API to perform trusted B2B exchanges (we will have a registration process in place that will allow us to understand who is a trusted B2B connection, protected by a BAA).

With ZERO changes to CMS policy or to the PDex Implementation guide, we can decide to use the existing Patient Access API or to create new Payer/Provider-specific APIs.

In other words:
Payer Access API: This is when a Payer uses the Patient Access API
Provider Access API: This is when a provider uses the Patient Access API

We do not need to create new B2B only APIs.

Healthcare data producers (payers and providers) are free to choose which API they use to exchange data. If we encourage the implementer community to focus on the Patient Access API instead of new APIs, everyone will benefit.

Healthcare data producers have an important opportunity to help consumers accumulate a collection of connections (that they can interface with through a consumer application or a payer/provider application).

Focus on patient access API also ensures that development work, testing, and enhancements remain on the Patient Access API (all improvements and testing will benefit everyone).

The Patient Access API, powered by seamless data transfers, is potent when placed into a consumer's hands. The work to enable seamless transmissions of data between Payers and Providers will not allow seamless access to the Patient Access API for consumers. Suppose we use the patient access API instead. In that case, we can enable a consumer to take advantage of the payer and provider trusted connections to deliver all information from a single source (this could be any node in the healthcare network).

Payer/provider applications can mediate transfers, even for consumers without a device or internet access (with opt-in).
We cannot require communication, on a national scale, with identities we do not recognize. The only entity in healthcare that everyone can communicate with is the consumer, making the Patient Access API a great choice to fuel data exchanges.

Focus on Patient Access API (instead of new APIs) will:
• reduce redundancy: one API, one registration process, one connection
• improve data quality: one model instead of three
• reduce costs: 1/3 the effort
• align interests: everyone focuses on Patient Access API
• Promote economy of scale: One model and one data exchange

All payers and providers will be creating FHIR applications and registering these FHIR applications with all other Payers and Providers. We will use an independent service to inform the status of other data producer endpoints (CAQH endpoint discovery is an example of the work to create a payer endpoint directory). An endpoint directory of trusted b2b connections is required, regardless of approach.

A payer application can interface with the Patient Access API to receive data if the consumer has opted for this exchange. The opt-in process can be automatic due to CMS-9123-F. The data exchanged will never leave control of the two business associates who are performing the exchange.

Steps to summon a complete medical picture, on-demand:
1.) Find approved B2B endpoints (CAQH endpoint directory, already in progress)
2.) Send the requested FHIR search to each endpoint: e.g., [base]/Patient?_identifier={some identity proofed id}/Patient-everything
3.) Use the B2B application to perform meaningful interactions (application handles inbound data from other data producers only, and data never leaves HIPAA protections)

The full narrative is maintained here (best viewed in print mode):
https://docs.google.com/document/d/1yU-4ur5TBxU1RQXwCJi19xNk6LAahTVOTM2Ap4068PU

Bart Carlson (Jan 21 2021 at 04:18):

Thanks for sharing. I look forward to learning more about your thinking on the diagram.

Josh Lamb (Jan 21 2021 at 15:55):

@Viet Nguyen FYI, the discussion is occurring here. I want to be sure we capture the patient empowerment communities feedback too.

Josh Lamb (Jan 21 2021 at 16:36):

Goal:
To raise awareness within the implementer community, we can use the Patient Access API to support B2B use cases and consumer-facing use cases. We can use the Patient Access API without any changes to CMS policy or to the PDex IG. I have been preparing for some complex argument, but I am finding that this issue is not contentious once we can develop a shared understanding of what I am proposing.

Benefits:
B2B enhancements to the Patient Access API also improve the consumer-facing patient access API. B2B exchanges are developing a network that will allow a complete medical picture to be summoned for all connected sources without a portal account/a device when applied to the patient. Connections to the Patient Access API can be shared by all connected sources, which creates a substantial benefit for the patient and businesses.

Focus on Patient Access API (instead of new APIs) will:
• Reduce redundancy: one API, one registration process, one connection
• Improve data quality: one model instead of three
• Reduce costs: 1/3 the effort
• Align interests: everyone focuses on Patient Access API
• Promote economy of scale: One model and one data exchange

If all data producers took this approach, many powerful opportunities are created.

Point against Patient Access API:
Focus on Patient Access API will not work. Payers and Providers must expose three APIs due to the CMS policy.

Counterpoint for Patient Access API:
CMS does not define a Payer Access API or a Payer Access API. CMS only defines Payer Access and Provider Access functionality. PDex IG does not cover the exchange mechanism between data holders (this is addressed under ONC Fast initiatives).

As both the rules are currently written, we can leverage one API for all data exchanges: Patient Access, Provider Access, and Payer Access. This only requires that appropriate permissions are in place, and we can determine who is calling our API. The act of one data producer registering with another data producer as a BAA will let us know who is a payer or who is a provider (and determine access rights).

In other words:
Payer Access: This is when a Payer uses the Patient Access API

Provider Access: This is when a provider uses the Patient Access API

Josh Lamb (Jan 21 2021 at 16:40):

@Bart Carlson, would you like to jump on a call? It seems to be easier than trying to digest this mountain of information directly.

Josh Lamb (Jan 21 2021 at 16:49):

@Jason Teeple @Cille Kissel Watkins @Pat Taylor @Amol Vyas @Ryan Howells:

Can we discuss this at the implementer forum? It seems that this discussion is an implementation decision that can fall under several IGs.

Josh Lamb (Jan 21 2021 at 20:51):

Hopefully, this makes it clear how we can perform data exchanges, even for low engagement patients, using current technology.
Data-Exchanges-Without-User-Engagement.PNG

And this image details why it is important to create connections around patient access:
Accumulate-Consumer-Connections.png

Dave deBronkart (Jan 22 2021 at 02:04):

DO we have a decision to made, or has the rule already been whelped, for better or worse?

Josh Lamb (Jan 22 2021 at 04:31):

Hi again @Dave deBronkart ,

I believe you mentioned that there would be an opportunity to bring this in for WG discussion in February? We can probably slow the text discussions until then.

Regarding a decision
Payers and Providers will decide how they implement the B2B requirements in the CMS policy. We can enhance the work we have already done for the Patient Access API (to accept B2B requests, too) or separate them into new APIs. Implementers are free to use Patient Access now, without any policy changes, with excellent consumer benefits. The decision to use Patient Access or B2B access only connections will be opaque to consumers.

How does this relate to patient empowerment?
Patient empowerment is relevant because this decision impacts a patient's ability to interact with data. Payers and providers who exchange data using Payer/Provider Access will make it impossible for patients to interact with the exchanged data. The most a patient can request is a consumer-facing version of B2B data (it is not always the same). Converting data from multiple formats may introduce errors that patients will be unable to help fix.

A patient-centric model is preferable for highly engaged patients. Patient-centered connections will allow the patient a chance to verify the accuracy of all health data.

As @Debi Willis mentioned, patients would like to have an opportunity to suggest corrections before data is shared. A patient-centric model will allow the "E" patient maximum control because they will be mediating all transactions (automatically or manually), and they will always have access to the same data used by businesses (their healthcare providers and insurers).

John Moehrke (Jan 22 2021 at 12:28):

the vision I have for the patient corrections is NOT limited to EHRs. It is just as applicable to the data held by a payer.

John Moehrke (Jan 22 2021 at 12:34):

The data flowing along a b2b exchange really needs to be visible (accounting of use) to the patient. That is to say the patient not only needs the ability to enable/disable ALL communications (including B2B between care and payer), but also needs the ability to see and accounting of ALL communications. Today these exchanges with payers are excluded from Accounting of Disclosures, they should NOT be excluded. Knowing the fact that these communications are happening is important to the Privacy Principles. The FHIR AuditEvent fits this need. It is ready and able. Transparency is important. An AuditEvent holds who, what, where, when, and why. Each of these are FHIR References, so the patient (given they have ability to read-their-own-records) can pull a copy based on those references and see exactly what was communicated (AuditEvent.entity.what). This is not a replacement for having the ability to read-their-own-records at the Payer, this is needed too as we all know that what was communicated is not always what gets imported/persisted. The AuditEvent enables these.

John Moehrke (Jan 22 2021 at 12:41):

IHE has for 20 years included in their Implementation Guides (IHE Profiles) mandatory audit logging, HL7 has not included this in their Implementation Guides. The IHE Document Sharing implementation guides (XCPD/XCA, PDQ/XDS, PDQm/MHD, etc) all have well defined audit log events into the schema of the FHIR AuditEvent. The technology and standards exist... what does not is that many networks have removed this from their requirements, or moved the requirement to a "you should keep your own logs". both of which means that there is no way to get a unified view of all the communications that-have-happened, or more likely no possibility at all. This will only change with regulated "access log reporting" requirements. The standards are ready, use AuditEvent.

Debi Willis (Jan 22 2021 at 14:27):

@Josh Lamb Thank you for explaining a bit more. This is all very foggy because I have not been involved in any of the discussions before, but one sentence in your last post got my attention and helped me understand an important impact of what you are trying to do: "A patient-centric model is preferable for highly engaged patients. Patient-centered connections will allow the patient a chance to verify the accuracy of all health data."

There is such a high percentage of errors in EHRs and as interoperability removes barriers, incorrect data will flow more quickly and become harder to manage. Incorrect data is not just an annoyance on the patient. It can be life threatening.

If you need anything from our group or have time to talk to us more about this, please let us know.

Josh Lamb (Jan 22 2021 at 16:45):

@John Moehrke, great points. Long term, we want to allow consumers, who are engaged, to keep the ability to facilitate B2B transactions. We cannot do this if we use b2b specific outflows of data.

@Debi Willis, would you like to jump on a call? I believe that @Dave deBronkart mentioned a chance in February to bring this to a WG session.

John Moehrke (Jan 22 2021 at 16:49):

I don't think you understood... the B2B transactions are good... they just should create AuditEvent instances at both ends of the communication, AND the patient should have access to those AuditEvent instances... so that they can see that data did flow, for what reason it flowed, who initiated it, who was involved, and when.

John Moehrke (Jan 22 2021 at 16:51):

this can be done with a single audit event repository, a bunch of them, or even a patient directed one (patient preference is registered that all accesses should be recorded using an AuditEvent create to XYZ FHIR repository)

Josh Lamb (Jan 22 2021 at 17:09):

@John Moehrke I agree that B2B flows and audit events are good. My point is specific to using the same patient data to support B2B and B2C.

The audit event will still be needed against access requests against the Patient Access API too.

All data exchanged must be available to the patient, as per CMS policy. If a data producer begins to convert data to new formats and exchange data using an outflow the patient cannot access, we have violated the policy's intent. B2B only outflows (not using patient access API data) will contain data the patient can never interact with or see.

John Moehrke (Jan 22 2021 at 17:33):

good. yes, data often gets transformed between clinical and payer. note this is true even FHIR-->FHIR there will be transforms...I agree that the patient should always be able to get all data in what ever format it exists in. the AuditEvent supports ALL kinds of data, it holds a Reference or Identifier. Thus AuditEvent is good with FHIR resources, but also good with anything else that has a unique identifier... but agree that accessibility is critical. AuditEvent might tell you that something happened, but knowing an identifier without being allowed (acccessibility) to see the content is only half the story. It still is useful to know that something happened, but better to be able to see the data communicated. To me, getting the AuditEvent(s) is more important, as it shows patters of data-use that the patient can be aware of, can question, and can have comfort that an appropriate communication did indeed happen.

Josh Lamb (Jan 22 2021 at 17:39):

Thanks @John Moehrke , Despite all of the infographics and my best attempts, I am finding that I agree with everyone. It just takes me a long time to realize we are saying the same thing (in most cases). :upside_down:

John Moehrke (Jan 22 2021 at 17:43):

making incremental improvements is the key to success. Huge leaps are rarely successful. A common goal, however distant in the future, is important to set direction of these incremental steps.

Debi Willis (Jan 22 2021 at 22:38):