Page tree
Skip to end of metadata
Go to start of metadata

Summary


The purpose of this of the Payer Coverage Decision Exchange (PCDE) supplemental guide (SG) is to provide further context on the detailed representation of the clinical data the data payload in a payer-to-payer exchange. FHIR examples demonstrating representation of this guidance are provided to illustrate the points made in the guide. 

It is possible that this content will be merged into the PCDE FHIR IG in a future release.


Overview

Background

PCDE covers active or pending treatment services for conditions (chronic or acute) that are being treated, tracked, or monitored, and may involve a care plan. By active treatment services, we mean visits, procedures, treatments, provisioning of durable medical equipment (DME) or other clinical interventions currently being performed or in the process of being approved at the time the member transitioned from an old health plan to a new health plan.


The PCDE FHIR IG provides general guidance on the broad types of clinical information to include into the bundle. Additional guidance on what actually is included in a payload for active treatments is lacking. This could result in the sending of sparse or incomplete supporting clinical data needed to determine medical necessity and reduce the goal of the exchange in reducing additional administrative burden by the payer and member in ensuring continuity of covered services.


PCDE SG differs from the PCDE FHIR implementation guide (IG) in the following ways:

  • The PCDE SG focuses more on the details on the representation of the admistrative and clinical data payload. It is possible that this content will be merged into the PCDE FHIR IG in a future release.


PCDE differs from the Payer Data Exchange (PDex) in its scope to ensure the member's current treatments by sending the member's treatment plan covered by the old plan. On the other hand, PDex has a greater scope of including the member's clinical health history and is mostly bound by conformance to US Core.

Scope and Assumptions


In Scope

The PCDE IG business requirements are focused on providing a framework in which a payer can indicate the following:

  1. current care that a member is receiving,
  2. conditions that led to the need for the current care,
  3. guidelines that were used to evaluate the need for the care the patient is receiving,
  4. prior authorizations that are in effect,
  5. successes or failures of prior treatment that are relevant to the current treatment, (e.g. step therapies), and
  6. the supporting clinical documentation that justifies the need for those specific treatments.


These business requirements further drive the payload data representation noted in the subsections to follow.


Current care received by the member

Current care includes active treatments that have already been approved, and pending treatments still awaiting a resolution.

Conditions related to current care

The conditions related to current care are embedded within each treatment activity as reason codes and reason references. Doing so maintains the emphasis on active and pending treatments and services ensuring continuity of covered services  rather than continuity of clinical care.  It is expected that a new health plan extract the reasons from each treatment and group them accordingly by condition if needed.


Guidelines driving the need for care

While not required, it is possible to include specific guidelines that drove medical necessity to cover an active treatment or service.  Such guidelines are scoped to be sent as unstructured document attachments in the supportingInformation or otherInformation sections at this time.


Prior treatments relevant to the current treatment

The PCDE bundle is scoped to active or pending treatments. Prior treatments that led to the selection of the current treatment could be useful in reducing potential duplication of efforts for alternate treatments that could have already been tried on the patient. If included, these prior treatments would be included under the supportingInformation attribute for the associated active treatment section in the PCDE bundle.


Out of Scope

The following will not be covered in this supplemental guide:

  • messaging, operations, search parameters. These should be covered in the PCDE FHIR IG.
  • payer-centric workflow – the PCDE SG does not specify a health plan’s internal processes or workflow in determining medical necessity for a member’s care.
  • Past treatments that are one-time and not in support of the patient’s current level of care. For example, a leg cast applied for an acute fracture 10 years ago would not be included in the PCDE bundle.



Overall Approach


The FHIR CarePlan resource was chosen as a construct for representing active treatments because it was the most appropriate fit for the properties that are sent.  It is however important to note that these are not care plans in the traditional clinical sense which focuses on disease management.  Rather, our focus is on treatment services and devices where the related diagnosis is referenced within the covered items.


Organizing Active Treatments


The organization of a PCDE bundle can vary depending upon how the health plan groups services as part of an active treatment. For example, if a health plan defines home oxygen therapy as an active treatment, then it is possible that one PCDE active treatment section will include a group comprising of medication and devices. A different health plan could have just included oxygen as a medication and its supporting equipment (e.g.: oxygen regulator) under a device section.


We present some additional guidance to minimize these variations:

  1. Each medication, therapy, DME, procedure, will have its own ActiveTreatment section.
    1. Activities under each ActiveTreatment CarePlan instance would be an primary medication, device, procedure, etc. Additional activities are added in that same CarePlan only if it is supporting that primary activity. For example, if there is an ActiveTreatment CarePlan for administering Oxygen, then the CarePlan would include additional supporting CarePlan activitiy types which supports that treatment:
      1. MedicationRequest: Oxygen
      2. DeviceRequest: Oxygen regulator
      3. DeviceRequest: Oxygen tubing
    2. It is possible for some medication therapies to be repeated if the form and condition reason for its provisioning is different.
      1. For example, a member-patient who is being treated for COPD and Obstructive Sleep Apnea (OSA) could be prescribed two forms of oxygen delivery systems: 1) portable oxygen for COPD, and 2) stationary oxygen to support a CPAP machine at night. In this case, although the member-patient was prescribed oxygen, they would be represented as two separate active treatments of oxygen.


Clinical domain considerations

Handling the following clinical treatment data:

  • durable medical equipment
  • medications
  • procedures
  • coordinated care in a multidisciplinary provider community
  • ancillary services – physical therapy, home health services, counseling, etc.
  • patient sensitive health information – mental health, infectious disease (HIV), drug abuse, etc.


Durable Medical Equipment / Disposable Medical Supplies

With the rise of home health services, the provisioning for DME has become more common. DME are prescribed or ordered by a provider, is reusable, and is appropriate for use at home. Examples include hospital beds, mobility aids, oxygen concentrators, monitors, kidney machines, to name a few.


Disposable medical supplies include blood testing strips, catheters, injection needles, incontinence products, etc [5].

Disposable medical supplies as noted in the above examples might not be structurally represented in the PCDE bundle. Rather, they could vary in how they are available to the old health plan:

  • indirectly referenced in a Certificate of Medical Necessity (CMN) as a FHIR DocumentReference entry for the related active treatment PCDE CarePlan entry.   
  • disposable supplies are grouped into a bulk monthly fee whereby disposable supplies will be listed in supporting documentation if requested. 
  • Needs revisiting after some in the PCDE community diagreed with this.

Guidance:

  • All disposable medical supply orders (gauzes, diapers, catheters, etc.) are categorized as a DeviceRequest.
  • If the disposable medical supplies are being paid for in a bundled way and the quantity is known on what's being paid for, then it SHOULD be included. 
  • Disposable medical supplies needed for a DME SHOULD be grouped under the top DME (e.g.: Glucometer as primary DME, lancets are grouped).

Medications

Information supporting active medication treatments will vary in how it is received by the old health plan. The types of information that could be present includes:

  • the provider medication order or prescription
  • the pharmacy medication dispense 
  • an explanation of benefit (EOB)
  • any one of the above as an unstructured document. (e.g.: adjudicated claim form)

It is possible for a combination of or only one of the above available by the old health plan to include in the bundle. The PCDE Bundle content will vary in how this would be represented. Given that, we provide additional guidance on representing each information type.

Provider-generated medication order or prescription

Specified in the CarePlan.activity.detail.product[x] or CarePlan.activity.reference attribute.

An example illustrating a medication in CarePlan.activity.detail.product[x] is shown in the code snippet below:

Provider ordered medication
"activity": [
	      {
            "id": "Med-spiriva",
            "detail": {
              "kind": "MedicationRequest",
              "reasonReference": [
                {
                  "reference": "Condition/1"
                }
              ],
              "status": "in-progress",
              "productCodeableConcept": {
                "coding": [
                  {
                    "system": "http://hl7.org/fhir/sid/ndc",
                    "code": "00597010061",
                    "display": "1 CARTRIDGE in 1 CARTON (0597-0100-61)  > 60 SPRAY, METERED in 1 CARTRIDGE"
                  },
                  {
                    "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
                    "code": "1552004",
                    "display": "Spiriva Respimat 2.5 MCG/ACTUAT Metered Dose Inhaler, 60 ACTUAT"
                  }
                ],
                "text": "Spiriva"
                },
              "description": "use 2 puffs daily"
            }
          }
 ],
etc…


Medication Dispense

PCDE Representation Guidance:

Pre-requisite:

  • The old health plan can build the following resources: MedicationRequest, MedicationDispense

In this use case, the old health plan does not have a provider order or prescription and instead, receives a confirmation from a pharmacy benefit manager (PBM) or the pharmacy that the medication has been dispensed.  In the PCDE Bundle, this is represented through a reference to a MedicationDispense resource in CarePlan.activity.outcomeReference.

Medication Dispense Example
"activity": [
          {
              "outcomeReference": [
                {
                  "reference": "MedicationDispense/1",
                  "display": "Medication dispensed"
                }
              ],
etc…


Claim

In this use case, the old health plan does not have a provider order or prescription and instead, has either a claim or an Explanation of Benefit (EOB). 


PCDE Representation Guidance:

There are three ways a Claim can be sent (in order of preference):

  1. an activity.outcomeReference to a FHIR Claim resource 
  2. an activity.outcomeReference to a DocumentReference which includes a base64 encoded X12 message for an EDI 837 transaction. 
  3. an activity.outcomeReference to a DocumentReference which includes a base64 encoded unstructured scanned PDF or text document for Claim.


Option 1: Claim FHIR resource

In the PCDE Bundle, this is represented through a reference to an Claim resource in CarePlan.activity.outcomeReference.

EOB as a FHIR resource
"activity": [
          {
              "outcomeReference": [
                {
                  "reference": "Claim/1",
                  "display": "Claim"
                }
              ],
etc…

A full PCDE example which contains a Claim FHIR resource can be downloaded in this file: Bundle-pcde-example-at03-MedClaimOnly.json


Option 2: Claim as a base64 encoded EDI-X12 message

Claim as a base64 encoded EDI-X12 message
"activity": [
          {
              "outcomeReference": [
                {
                  "reference": "Claim/2",
                  "display": "Medical Claim"
                }
              ],

	etc…

    {
      "fullUrl": "http://example.org/fhir/DocumentReference/3",
      "resource": {
        "resourceType": "DocumentReference",
        "id": "3",
        "text": {
          "status": "generated",
          "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Detailed Narrative</b></p><p><b>id</b>: 1</p><p><b>status</b>: current</p><p><b>docStatus</b>: final</p><p><b>type</b>: Claim<span style=\"background: LightGoldenRodYellow\">(Details : {LOINC code '64291-8' = 'Health insurance-related form)</span></p><p><b>subject</b>: <a href=\"Patient/14\">Patient/14</a></p><p><b>author</b>: <a href=\"Practitioner/1\">Practitioner/1</a></p><h3>Contents</h3><table class=\"grid\"><tr><td>-</td><td><b>Attachment</b></td></tr><tr><td>*</td><td></td></tr></table></div>"
        },
        "status": "current",
        "docStatus": "final",
        "type": {
          "coding": [
            {
              "system": "http://loinc.org",
              "code": "64291-8",
              "display": "Health insurance-related form"
            }
          ],
          "text": "Claim"
        },
        "subject": {
          "reference": "Patient/14"
        },
        "author": [
          {
            "reference": "Practitioner/1"
          }
        ],
        "content": [
          {
            "attachment": {
              "url": "http://example.org/Claim",
              "contentType": "application/edi-x12",
              "data": 
              "U1QqODM1KjEyMzR+DQpCUFIqSSoxOTIyLjg2KkMqQ0hLKioqKioqKioqKioqMjAxMTAxMDh....

					etc...

A full PCDE example which contains an embedded base64 EDI-X12 message can be downloaded in this file: Bundle-pcde-example-at05a-X12-837-claim.json  


Other: Brand to Generic Medication Substitutions

In some cases, a provider may prescribe a brand medication for the patient-member, but the pharmacy may substitute the equivalent generic medication to reduce cost. 

PCDE Representation Guidance:

Pre-requisite:

  • Old health plan can build the following resources: MedicationRequest, MedicationDispense

Representation steps:

  • Insert an action for Medication change to generic (SNOMED CT conceptID 407611006) in the PCDE CarePlan.activity.outcomeCodeableConcept attribute.
  • Insert the MedicationDispense reference for the medication substitution in the PCDE activity.outcomeReference attribute.
  • Reference the related prior authorization for the brand medication if one is available. This can be as a FHIR resource, or an unstructured document that can be embedded as a PCDE DocumentReference entry and referenced in the PCDE Composition supportingInformation section.


An example is shown in the FHIR code snippet below:

Medication Change
"activity": [
          {
            "outcomeCodeableConcept": [
                {
                  "coding": [
                    {
                      "system": "http://snomed.info/sct",
                      "code": "407611006",
                      "display": "Medication change to generic"
                    }
                  ]
                }
              ],
              "outcomeReference": [
                {
                  "reference": "MedicationDispense/1",
                  "display": "Medication substitution"
                }
              ],
etc…


Procedures and Ancillary Services

Procedures and ancillary services are represented as activities of type ServiceRequest within the PCDECarePlan profile. As with the MedicationRequest treatments, where the types of information delivered from the old health plan that could be present includes:

  • the provider medication order or prescription
  • the pharmacy medication dispense 
  • a claim or explanation of benefit (EOB)
  • any one of the above as an unstructured document.


An example is shown in the FHIR code snippet below:

Procedure Order
"activity": [
          {
            "detail": {
              "kind": "ServiceRequest",
              "reasonReference": [
                {
                  "reference": "Condition/1"
                }
              ],
              "status": "scheduled",
              "scheduledPeriod": {
                "end": "2019-12-05"
              },
              "productCodeableConcept": {
                "coding": [
                  {
                    "system": "http://www.ama-assn.org/go/cpt",
                    "code": "94726",
                    "display": "Pulmonary function test with spirometry"
                  }
                ],
                "text": "Pulmonary function test with spirometry"
              }
            }
          },
etc…


Sensitive health information

Examples of highly sensitive health information include psychiatric disorders, sexually transmitted diseases, and other conditions which the member considers private.  The exchange of such data may be handled as part of a confidentiality policy if the member has authorized the exchange and will vary with federal and the state regulations in which the information originates. 

If however, there is a need to identify additional protected information based on federal and state regulations in the PCDE bundle, this can be done through the use of FHIR security-labels.

Security-label identifies confidentiality, information sensitivity, and data handling caveats and is specified in the meta.security attribute of FHIR resources, as shown in the PCDE CarePlan code snippet below which represents a restricted confidentiality for a mental health disorder.


Sensitive Health Data
        "resource": {
          "resourceType": "Condition",
          "id": "1",
          "meta": {
            "security" : [
                {
                    "system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
                    "code" : "R",
                    "display" : "restricted"                    
                },
                {
                    "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                    "code" : "MH",
                    "display" : "mental health information sensitivity"
                }
            ]
          },
          "text": {
            "status": "generated",
            "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: 1</p><p><b>code</b>: J44.9 <span style=\"background: LightGoldenRodYellow\">(Details : {http://snomed.info/sct code '83225003' = 'Bipolar II disorder (disorder)')</span></p><p><b>subject</b>: <a href=\"Patient/14\">Patient/14</a></p><p><b>recordedDate</b>: June 5, 2019</p></div>"
          },
          "code": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/fhir/sid/icd-10-cm",
                "code": "F31.81"
              },
              {
                "system": "http://snomed.info/sct",
                "code": "83225003",
                "display": "Bipolar II disorder (disorder)",
                "_display": {
                  "fhir_comments": [
                    " SNOMED CT FSN for Bipolar 2 disorder "
                  ]
                }
              }
            ]
          },
          "subject": {
            "reference": "Patient/14"
          },
          "recordedDate": "2015-06-05"
        }
etc…

Note: It is important to consistently apply the security-label to all relevant resources that related to the active treatment.

For example, if there is an active treatment for receiving a drug used to treat a mental health disorder (e.g.: the drug Depakote for the treatment of bipolar II disorder), then the confidentiality and information sensitivity data should be applied for the following resources:

  1. the PCDE CarePlan resource referencing the ActiveTreatment
  2. the Condition resource identifying the mental health disorder
  3. the MedicationRequest resource for the drug treating the mental health disorder

The file below is a PCDE Bundle example demonstrating the usage of security-label for sensitive data:

Note: The PCDE FHIR IG assumes that the new health plan receiving a bundle with health sensitive data will process and manage access and authorizations for the specified FHIR security-labels per their organization privacy and security policies.

Other Considerations


Unstructured Documents

As written in the Interoperability and Patient Access Final Rule (CMS-9115), “As required at 42 CFR 422.119(f)(1)(iii), 438.62(b)(1)(vi)(C), and 457.1216 and 45 CFR 156.221(f)(1)(iii), data received via the payer-to-payer data exchange only need to be made available to share in the electronic form and format they were received from another payer [1].” If the old health plan received member clinical information through unstructured documents, then they are not required to translate that information into specific FHIR clinical resources to be sent over to the new health plan.  Given the current state of payer exchange, it is likely the most common way that electronic formatted data is stored today.


Recommendation: Standardize the classification of clinical and administrative documents.  If possible, use a LOINC Document Ontology code for the labeling clinical documents.


Note: An HL7 JIRA issue was created for US Core, requesting a change to add a new term for administrative-note to the DocumentReference.type value set.


Terminology Coding Considerations

Handling HCPCS Modifiers

HCPCS modifiers complement HCPCS Category 2 codes for DME.  Determination needed on whether to pre- or post-coordinate the modifier on to the HCPCS code.

For example:

HCPCS code E0435 (PORTABLE LIQUID OXYGEN SYSTEM, PURCHASE; INCLUDES PORTABLE CONTAINER, SUPPLY RESERVOIR, FLOWMETER, HUMIDIFIER, CONTENTS GAUGE, CANNULA OR MASK, TUBING AND REFILL ADAPTOR) can have different HCPCS modifiers which further describe more about the DME allocation:

  • QA - Prescribed amounts of stationary oxygen for daytime use while at rest and nighttime use differ and the average of the two amounts is less than 1 liter per minute (LPM)
  • QR - Prescribed amounts of stationary oxygen for daytime use while at rest and nighttime use differ and the average of the two amounts is greater than 4 liters per minute (LPM)


Example Clinical Personas

The content design considerations noted in this supplemental guide will be reflected in a number of clinical personas located here


Additional Use Cases for Consideration

These additional use cases have been identified during the PCDE Supplemental Guide review.

1.  Old Health Plan missing MedicationRequest 

  • The old health plan does not have the original provider order (e.g.: MedicationRequest, ServiceRequest, etc.) and all they have is the claim or dispense record (e.g.: from a PBM).

2. Sensitive health data

  • consider the privacy requirements at the state-level.
  • consider the source of the old health plans if there were several.
  • assumption: the most recent (last) plan are the source for all health sensitive data management. - focus is on continuity of care, not member portability.


Modified example for X12 1) Coordination of Benefits and for 2) Prior Authorization. Use Base64 with mime subtype EDI-X12.  An example is available here.