Payer Member Discovery

Back to Payer Member Discovery Workgroup

Link to original Google Document (to see comments):

 

Version 1.1 - 12/12/19

Relevant to the following Implementation Guides:


At the Philadelphia Da Vinci Connectathon two questions were raised that each have two parts:

1.1  How does a Health Plan know where to send the communication request and also 

1.2 How to identify that a request was from a legitimate sender

2.1 Does the old payer need to provide data they may have received from a previous payer? (In the case where the new payer is the third payer in the 5 year period)

2.2 Who is responsible for getting data from the oldest payer?

Guidance:

1.1  How does a Health Plan know where to send the communication request


This question is more broadly: How does a Health Plan know where to connect to the API endpoint for another Health Plan?

Out of band business process between two payers. An additional aspect of a formal business relationship.


Previous discussions have identified the need for Payers to maintain a list of contact points for other plans. In the short term that might be a list/file that is exchanged amongst plans to identify plans and the appropriate API endpoints. The scope of the CMS Proposed Interoperability Rule in terms of impact to plans makes this approach feasible as an interim approach until a better solution can be implemented.

In the future it may make sense to consider using the “.well-known” folder in a domain to publish a unique identifier for a plan and associated endpoints. These could then be compiled into a list with the plan in control of their own data.

1.2 How to identify that a request was from a legitimate sender?


Using the OAuth2.0 protocol each Health Plan would effectively be registered with Health Plans the wish to query. They would use a set of Application Credentials (Key and Secret) that identifies the application and the scopes they are permitted (i.e API queries) to perform.

This is not a standard user Oauth2.0. This will be a system to system authorization with a persistent token. 

A reference to the Unified Data Access Protocol was incorporated into the Health Record Exchange IG since an implementation of that specification would enable Health Plans to establish a common validating authority that would issue a verifiable software statement that identified the application and scopes etc together with a certificate to enable authenticity to be verified. I have been referring to this approach as “Trusted Dynamic Client Registration Protocol (Trusted DCRP)”. This would enable a Health Plan to register a Patient Query application once and then present the certificate and software statement to any other Health Plan that trusted the issuing validation authority.

By using this approach a Health Plan could use the OAuth2.0 authorization to verify that a query was coming from a legitimate source.

2.1 Does the old payer need to provide data they may have received from a previous payer?


This is a policy issue that may be resolved by the publication of the Interoperability rule. A Da Vinci IG should not be creating policy by defining data retention rules. It is for the implementer to implement the IG in a manner that is consistent with current legislative requirements that they operate under. 

For PCDE the Implementation Guide addresses the exchange of any current treatment plans. In general, this implies that the request would only be made to the last Health Plan to provide coverage. The Treatment plan may contain data that supports the determination of the treatment. As usage of PCDE expands across payers and extends over time it becomes more likely that Health Plans may include information provided from a prior Health Plan in their determination of appropriate treatment. 

We should remember that an impetus behind the PCDE IG is to reduce the burden on Members and Providers in the process of enabling continuity of care during Health Plan coverage transitions.

In the PDEX IG there is no definition of the time period covered by member health records.

As with other Da Vinci IGs as adoption expands across the industry and over time it will become more likely that Health Plan members may choose to transfer the Health Records as they move from Plan to Plan. If a Health Plan imports a Member’s health record from a prior plan it is assumed that the information would be made available to the Member. Hence the data would be part of the Member’s Health Record and should therefore be incorporated with new data generated by the current Health Plan and would be available for exchange to a future Health Plan. 

In support of this scenario where a member develops a more inclusive longitudinal health record with their Health Plan the PDEX IG also raises the importance of recording Provenance around the member’s health record data. It is important for a Health Plan to preserve provenance information and provide provenance on any new data created.This is important to downstream users of the data to be able to understand the source of the data and any transformations that have been performed on the data. For example when converting a claim record received via X12 into a US Core clinical resource.

The 5 year window in the proposed rule refers to the time window during which a member can go back to a prior payer and request their records. It is not referencing the year’s worth of data that a payer needs to maintain. Rather it identifies how long a payer needs to retain whatever information they have on a prior member incase they come and ask for it. 

2.2 Who is responsible for getting data from the oldest payer?  


As the PDEX IG is currently written the Member authorizes the exchange and so it would be the member that would connect to the old health plan and authorize the data to be shared with their new health plan.

Common Member Query for non-member mediated exchange

One of the common aspects of both PDEX and PCDE is the need for a common member query between plans. This can be seen as a precursory operation that occurs before the core activity defined in the IG takes place.

Assumptions

  • Health Plans have appropriately authorized application credentials
  • Access to these search operations are restricted to HIPAA covered entities (or Business Associates acting on behalf of a covered entity).


There are two scenarios to consider when a Member is enrolling in a new Health Plan:

  1. The new member provides only the name of one, or more, previous Health Plans. This name will need to be definitive enough to enable the new Health Plan to identify a unique old Health Plan. For example, providing “BlueCross BlueShield” does not identify which of the BCBSA affiliates the person was a member of.
  2. The new member provides the full details of their prior coverages (eg. Member or Subscriber Id, Group etc.)


In Scenario 1 the new Health Plan identifies the old Health Plan and their API endpoint. Using an authorized application the new Health Plan queries the old Health Plan’s /Patient endpoint using the demographic information they have collected from their new Member with a $match operation (http://www.hl7.org/fhir/patient-operation-match.html).

The old Health plan will return:

  • 404 - Member Not Found
  • 200 - Unique Member Found (Returning Patient record)
  • 4xx - No unique match - too many members found


The question for the No Unique Match is whether the Old Health Plan should return a bundle of possible Member matches, or return the 4xx status code and not return information. This would require the Health Plans to go “out of band” to resolve a member match, or the health plan could supply more demographic data to attempt to identify a unique match.  

A proposal is that If the query returns fewer matches than the limit then the old Health Plan would return all those potential matches in a Bundle. If the query returns more matches than the limit then an error code would be returned. 

Options for HTTP response codes: 

  • 403
  • 451

We can allow implementers to impose a limit this way and let them pick the limit. Some health plans might choose to impose a limit of 1, and thus would never return a Bundle.

In Scenario 2 the combination of Coverage information and Patient Demographics should yield a unique match. 

Should this be confirmed by the New Health Plan performing a /Coverage search to confirm the /Patient/{id}

Once the new Health Plan has received a 200 response with a Patient resource the information could be passed to the functions in the PDEX or PCDE IGs to make subsequent queries for that member. For example in the case of PCDE the new Health Plan would compile a CommunicationRequest and include the New Health Plan Coverage, Old Health Plan Coverage and Patient resources.

  • No labels