Da Vinci - Payer Coverage Decision Exchange (PCDE)
1.0.0 - STU 1
Da Vinci - Payer Coverage Decision Exchange (PCDE)
1.0.0 - STU 1
This page is part of the Da Vinci Payer Coverage Decision Exchange (PCDE) FHIR IG (v1.0.0: STU 1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions 
This page is divided into three sections which outline the expectations for systems wishing to comply with the IG:
general context that implementers need to understand in reading the remainder of the guide;
a description of the technical data exchange mechanisms by which a patient requests and enables that information to be transmitted from the original payer to the new payer and how that transfer actually occurs; and
a description of the data structure to be shared that supports a transition of coverage responsibility from one payer plan to another
Before reading this formal specification, implementers should first familiarize themselves with two other key portions of the specification:
The Use Cases & Overview page provides context for what this formal specification is trying to accomplish and will give a sense of both the business context and general process flow enabled by the formal specification below.
The Technical Background page provides information about the underlying specifications and indicates what portions of them should be read and understood to have the necessary foundation to understand the constraints and usage guidance described here.
This implementation guide adheres to the conformance documentation conventions found in the HRex Conformance Expecations page, including expectations around the meaning of ‘Must Support’.
This specification makes significant use of FHIR profiles and terminology artifacts to describe the content to be shared as part of prior authorization requests and responses.
The full set of profiles defined in or used by this implementation guide can be found by following the links on the Artifacts page.
This IG defines custom codes for document types and sections. Implementers SHALL consider the codes ‘temporary’. After implementation testing and confirmation, these custom codes will migrate to standardized codes in an official code system - most likely LOINC.
This data exchange builds on the Da Vinci Health Record Exchange (HRex) and Payer Data Exchange (PDex) implementation guides, optionally leveraging the OAuth 2.0-based mechanism to enable data flow between two payer systems and the Task-based requested exchange mechanism to request the desired document. This section of the implementation guide provides details on that flow.
For this implementation guide to be applicable, the following conditions must be met:
A member of a covered plan has enrolled in another covered plan offered by another payer.
That member is currently being treated for some chronic or acute condition.
The new payer has performed a patient / coverage resolution process and has information about relevant prior coverage.
Both the new payer and the old payer must be able to recognize each other based on an agreed payer identifier scheme.
The new payer system knows the base FHIR API URL for the original payer endpoint and has basic business arrangements in place allowing query of data from it.
NOTE: Work to standardize how payer identification will be managed, as well as how the FHIR endpoint for a given payer will be found (e.g. through the use of a registry) is ongoing. For now, this is left to site-to-site negotiation.
This implementation guide inherits all of the requirements and guidance defined in the HRex Security and Privacy page. Conformant systems must familiarize themselves with and abide by the expectations established there for all functions enabled by this implementation guide.
Optional: The member uses an interface/portal or SMART app within the new payer’s system to authenticate to the original payer’s system and authorize the prior payer to allow the new payer to access the member’s clinical and treatment data. The original payer’s system provides an OAuth 2.0 token to the new plan.
The new payer executes a Member Match operation using the member’s old insurance information and demographics to determine the patient identifier on the original payer’s system.
The new payer’s system (possibly using the token provided in #1) requests a Coverage Transition Document from the prior plan by POSTing a Task to their system. Optionally, the new payer creates a Subscription on the old payer’s system, requesting notifications about updates to the newly created Task.
The source (original) payer either locates an existing document (previously prepared) or assembles the information needed and creates the requested document. Updates are made to the Task.status element and, optionally, human-readable status information within Task.businessStatus.text element as the task progresses through different states. (In PCDE, the Task is limited to the states ‘requested’, ‘in-progress’, ‘completed’ or ‘failed’.) The original payer updates Task.output with a reference to the document when Task.status is completed.
The new payer queries the original payer’s system for updates to the Task. This is either done by polling at regular intervals or by responding to a Subscription notification.
When the Task.status is completed, the new payer retrieves the Coverage Transition Document pointed to by the Task.output.
The new payer incorporates the information in the document into their utilization management / utilization review process for review and approval of the ongoing treatments for the new member.
The following diagram illustrates the workflow that is supported by this implementation guide:
This IG provides for the optional use of the same authorization process PDex uses for member directed exchange. By using the SMART on FHIR implementation of OAuth 2.0 and providing an appropriate access token from an original payer’s system to a new payer at the request of a member, the new payer’s application is able to authenticate to the original payer’s system and gain access to information authorized by the member.
Payers SHALL provide a method for past members to authorize the exchange sensitive information as defined by federal, state and, where appropriate, local statue. In the event that a member does not permit a payer to exchange sensitive data, the payer SHALL have a method to sequester such information and make it unavailable for exchange. This SHOULD happen as part of the authorization process.
The Token, if one is used at all, is only used to authorize the initial creation of the Task. It is not necessary to provide the token when establishing a subscription or polling to monitor the Task or to retrieve the Task and its linked document. The duration of the token will generally be short (hours at maximum) and so cannot authorize multiple Tasks soliciting information over time. Payers SHALL ensure that only authorized systems (typically just the requesting payer) are able to access PCDE Tasks and any coverage transition document created as a result.
Once the necessary token has been retrieved through the OAuth process, the new payer system will POST a PCDE Task request to the original payer system. The requester SHALL populate the Task.code and Task.status to indicate that a Coverage Transition document is requested. (See here for an example of a requested Task.)
If the receiving system does not recognize the member identified in Task.for or there are other structural issues with that Task (e.g. requesting payer is not recognized, Task doesn’t comply with profile, etc.), then the original payer SHALL respond with an appropriate 4xx or 5xx HTTP error accompanied by an OperationOutcome conveying the reason for failure.
In most cases, the creation of the Task will initiate a manual process within the original payer organization to create an appropriate Coverage Transition document. However, in some cases, a payer might choose to pro-actively create Coverage Transition documents when the patient’s coverage ends and is not renewed. If an appropriate pre-existing document already exists for the member, the original payer MAY simply update the Task to reference the existing document rather than creating a new one. In other cases, a human might review the document and ensure it was still relevant/appropriate but determine there was no need to create a new one. In either case, the Task would be updated as per usual to point to the existing document. However, the elapsed time from the posting of the Task requesting the document would be shorter because the document was pre-existing.
While fulfilling the request, the original payer MAY update Task.status or Task.businessStatus.text to reflect interim status information. (For example, indicating that the task is in-progress with a date when the document is expected to be ready.) An example can be seen here.
When the document is available, original payer SHALL update Task.status to completed and provide a reference to the Coverage Transition document resource in Task.output. An example can be seen here.
The payer may be unable to complete a request if the member is unknown or the information requested cannot be provided. In these cases, the original payer SHALL indicate that a request was not completed by updating Task.status to failed and, optionally, Task.statusReason. An example can be seen here.
There are two options for monitoring the Task to verify acceptance, determine progress and determine if the requested document is ready for retrieval: subscription and polling.
Payers SHOULD support subscriptions to allow monitoring of changes to the Task resource rather than relying on polling. Payers making use of subscription SHOULD comply with the Subscription Backport IG which allows pre-adoption of R5 subscription mechanisms in R4-conformant systems.
If no subscription was created, the new payer SHALL routinely perform a read on the original payer’s system using the id of the originally created Task to receive updates to the Task. Polling is performed by executing a GET operation using the id received from the original payer when the Task was created, optionally using the If-Modified-Since header to limit the data returned if the Task has not been updated since it was last polled.
Example:
GET [base]/Task/1135804
When the document is available, original payer SHALL update Task.status to completed and provide a reference to the Coverage Transition document resource in Task.output.
When the Task.status is completed, the Task will have an output element with the name ‘document’ that is a reference to the requested coverage transition document. On retrieving the Task and finding it in completed state, the new payer SHALL perform a ‘read’ on the specified URL for the document referenced in the Task.output element for the newly created document, again using the previously supplied token. The new payer can then process the document contents as necessary to ensure a smooth transition of care.
NOTES:
This specification does not, itself, impose any expectation on the duration of records retention after a patient’s coverage ceases, only that the payer expose all relevant information it still retains. If no details are retained, but the payer still recognizes the patient, the Task should be changed to a status of ‘Failed’ with a Task.statusReason indicating that no records remain to be shared.
The original payer SHALL make the Task resource and associated document available for a minimum of 7 days after transitioning to complete, or for at least 24 hours after a successful response is returned to a ‘read’ attempt by the new payer, whichever is less. This ensures the new payer has an opportunity to re-query the document if an issue occurs during the original read.
It is theoretically possible for multiple Tasks to point to the same document (e.g. if a patient is transitioning to coverage under two different plans, the payer MAY simply update the second Task to point to a coverage transition document originally created for another payer).
This IG uses a FHIR document approach to organizing the information shared by the original payer system. This aligns with the approach typically used for any other sort of transition of responsibility (be it clinical or administrative responsibility). The document approach allows arbitrary data objects (typically FHIR resources) in logical groupings for human consumption/review and allows human narrative to provide context and guidance on interpreting and using the information.
The original payer SHOULD send all information they have available they believe to be reasonably necessary for the new payer to make a determination of medical necessity. (Future versions of this specification are expected to tighten this requirement to SHALL.) The original payer is NOT expected solicit data from other organizations, merely to share the data it already has available. All information disclosed to the new payer is expected to be disclosed within the Coverage Transition document defined by this specification. Disclosure of information via phone, fax or other means is non-conformant.
While the eventual target of future versions of this IG may be to allow fully automated import and use of the provided payer data, it is likely that at least some cases will always require human review and, in the short term, most/all payers will incorporate human review in the consumption of the data shared. The document approach significantly simplifies this review process.
Da Vinci is looking for implementer feedback around whether this IG should mandate support (i.e. 0..*, must support) for ‘goals’ related to an active therapy. For example, STAR ratings quality measures. Please indicate whether this is something that would be useful and that your system would be able to support.
All Coverage Transition documents SHALL comply with the PCDE Bundle and PCDE Composition profiles. These profiles set out a document structure as follows:
An example of a Coverage Transition document can be found here.
There are two major sections to a Coverage Transition Document: Active Treatments and Other Documentation
This section should repeat for each “active treatment” the patient is receiving under coverage from the original payer at the time the document is prepared. Active treatments include any treatment that, to the best of the payer’s knowledge, is ongoing and for which the new payer might reasonably expect prior authorizations or claims, such as:
If a patient has no active treatments, there will be no sections specified. If there are no active treatments and no Other Documentation to provide, then no document will be produced and the final Task status will be ‘failed’ with a statusReason indicating there is no information to share.
Payer knowledge of what treatments are ‘active’ might come from prior authorizations, recently submitted claims or from clinical information shared with the payer as part of care management or other processes.
For each active treatment the following three sub-sections are available:
This mandatory section defines a single treatment. The CarePlan instance that is the entry will convey the following information:
This section will include the most recent relevant Claim(s) and/or Prior Authorization(s) associated with the treatment. The purpose is to give a sense of the number of authorized treatments, how many have already been performed/paid for, date of the most recently billed occurrence, etc. Section narrative may provide additional detail.
Prior Authorizations SHOULD comply with the PAS Prior Authorization and PAS Prior Authorization Response profile. As yet, there are no Da Vinci profiles available for Claim resources, so technically any FHIR-valid Claim and ClaimResponse resources are allowed, though alignment with the PAS Prior Authorization profiles is recommended. The US Core DocumentReference profile can be used to convey PDF or other non-discrete representations if full FHIR-encoding is not possible.
These sections provide additional information that supports the treatment decision. Examples might include past treatments that had been tried and proved ineffective, lab results or other reports that support the decision to perform the treatment, clinical orders that support the treatment, etc.
Each repetition must have one or more resource entries. The section narrative SHALL provide a human description of the relevance of the contained resource entries. Separate sections can be used to provide different groupings of resources that provide different types of support. For example, one repetition might deal with prior therapy. Another might contain the current order. A third might indicate dispenses to date against that order.
While it is technically possible to send raw NCPDP, X12 or other content in this specification wrapped using DocumentReference, the general expectation is that relevant claims information will be exposed as appropriate FHIR resources (e.g. Encounter, Procedure, etc.). In cases where discrete information can’t be appropriately exposed in FHIR, PDFs wrapped in DocumentReference are also an option. Transmitting raw legacy data should be used only as a last resort when the other two approaches are not feasible.
When interpreting information shared in a coverage transfer document, it is often helpful to understand the source and history of the information being shared. This also allows the receiving payer to better reconcile the shared information with data shared from other sources. For this reason, resources shared as ‘supporting’ information SHOULD be accompanied by Provenance instances complying with the PDex Provenance profile as additional ‘supporting information’ entries.
These sections allow conveying information that is not directly related to a current active therapy but which may be relevant to allowing the new payer to provide appropriate care. For example, conveying that a patient has had a double-mastectomy in the past. That may not be related to ‘active therapy’, but would still be relevant in terms of the new payer knowing not to send reminders for mammogram treatments.
The expectation is that the original payer may have this kind of information available and SHOULD send it where it could be relevant to ongoing care activities; however, there is not a requirement to send information unless it is associated with active treatment.
Multiple sections are allowed so that separate narratives can be used to group resources that are related together. Narrative-only sections can be used to convey information for which no discrete data exists or is relevant.
The exchanges covered by this implementation guide are subject to appropriate regulation regarding operations and consent, includingstate and federal privacy standards. The entities participating in these exchanges should be familiar with and adhere to these and other relevant regulatory requirements.
At the moment, this IG is quite flexible with how information is encoded. Future versions of this IG will likely impose additional expectations, at least for certain types of conditions/therapies, as it becomes more obvious where additional interoperability requirements can result in less manual effort/reduced time in processing transitions in coverage.
The US Core profiles impose terminology expectations that reflect commonly used clinical terminologies. These may not always align with commonly used billing codes. While billing codes may be sent as well (as additional translations), payers SHALL translate to the appropriate clinical terminology (e.g. NDC or HCPCS drug codes to RxNorm) in order to comply with the US Core profiles if an appropriate code exists in the US Core value set.
The Coverage Transition document structure is open-ended. Additional sections and sub-sections are permitted and additional data elements (including extensions) are permitted as part of the document instance. Additional elements should never be used in place of ‘standard’ elements but can be sent in addition to provide additional context to systems that understand the additional discrete data. All important information should be reflected in the resource narrative (text) elements and/or in the section.text elements.
IG © 2019+ HL7 International - Financial Management Work Group. Package hl7.fhir.us.davinci-pcde#1.0.0 based on FHIR 4.0.1. Generated 2020-12-23
Links: Table of Contents |
QA Report
| Version History |
Search |
|
Propose a change