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

Track Orientation 

Payer/Provider Information Exchange WG (PIE)

Justification and Objectives

Electronic medical records/attachments are a high priority for processing claims and other payer/provider interactions. Current thinking has attachment submissions occurring via X12 transactions. However, there is substantial interest in experimenting with FHIR-based messaging for exchanging attachments. This track will explore the feasibility of this approach.

This track will enable Payers and Providers to share clinical data using FHIR API guidance specified in the CDex and HRex implementation guides that will be balloted in July (Early September Ballot). CDex track will use 4.0 version of FHIR

The Connectathon track will allow us to confirm the quality of the IG materials, gain experience with testing, and show us where additional revisions to the IG may be helpful for implementers.

FOR:

PDex - please refer to Da Vinci Payer Data Exchange Track

Prior Auth - please refer to Da Vinci Prior Authorization Track

BlueButton2 - please refer to CARIN Blue Button Track


Scenario 1


Clinical Data Exchange (CDex):

CDex workflows are designed to enable medical record "chart chase" requests and additional information queries from our provider community. We specifically are interested in knowing what EHR  and Vendor Clearinghouse systems have begun to support the FHIR Workflow paradigm and can process Task resources. CDex track will use 4.0 version of FHIR

Attachments will use 4.0 version  of FHIR.  Hapi server = http://fhirtest.uhn.ca/baseR4  

Clinical input requested (if any)

Does your track have a need for input from the clinical community? If so, what are the needs?

chat.fhir.org

re: Submitting WG/Project/Implementer Group

Patient Care/Da Vinci

Justification and Objectives

This track will enable Payers and Providers to share clinical data using FHIR API guidance specified in the CDex and HRex implementation guides 

The Connectathon track will allow us to confirm the quality of the IG materials, gain experience with testing, and show us where additional revisions to the IG may be helpful for implementers.

This track will use the HL7 Da Vinci draft CDex IG  Draft CDex Implementation Guide

Clinical input requested (if any)

It would be helpful to learn if the Task-based workflows we are designing to enable medical record "chart chase" requests and additional information queries seem feasible and valuable to the clinical community. We specifically are interested in knowing what EHR systems have begun to support the FHIR Workflow paradigm and can process Task resources. Also, hoping to determine if the Task-based workflow for solicited communication and unsolicited communication would be the preferred approach (hence dropping use of the non-task-based approach previously demonstrated by the Attachments Track.)

Related tracks

This track is a part of the larger Da Vinci Program. It also is related to the Attachments Track.


Proposed Track Lead

Durwin Day and Christol Green -Track leads must be registered users on http://chat.fhir.org

Implementation Guides

Links to CDex Implementation Guide: 

There are two additional extensions that are important to note. Both are in the payload element of the CommunicationRequest.

Link to HRex Implementation: 

System Roles

For a data query, the technical actors are an Information Client and an Information Server.

For an unsolicited communication there is an Information Sender (provider) and an Information Recipient (payer).

For an asynchronous solicited communication, an Information Request Sender (payer) sends a communication request to an Information Request Recipient (provider). The system acting as the Information Request Recipient processes the request as a task that gets completed, then acting as an Information Sender returns information to the Information Recipient (or Recipients) indicated in the communication request. The system that plays the role of the Information Request Sender may or may not be an Information Recipient. Other systems may play the role of Information Recipient.


System Access Information

How to request a sandbox account: Sign up for HSPC Sandbox Reference Implementation

Testing Server End Points

Server NameRoleEndpoint
Open Endpoints:
HSCP Reference Implementation Sandbox 1Payer Systemhttps://api-v8-r4.hspconsortium.org/DaVinciCDexPayer/open/Communication
HSCP Reference Implementation Sandbox 2EHR Systemhttps://api-v8-r4.hspconsortium.org/DaVinciCDexProvider/open/CommunicationRequest

Anyone who needs OAuth application-level access to the sandboxes should ask Rick Geimer


Patient Story

Ted Williams is a 76-year-old male from the southside of Chicago.  Ted has a 13-year history of Type 2 diabetes. Ted experienced a left foot amputation five years ago (at age 71) due to circulatory complications from his diabetes. The story also shows how Ted's PCP shares clinical information with a specialist and home health agency to provide greater continuity of care. Ted's medical information is used by a Payer during information gathering to support their HEDIS hybrid measure period.  Ted's clinical information also is used to audit paid claims and to inform more accurate risk profile creations.  

Da Vinci CDex Patient Story - Ted Williams


Patient Data to Support Scenario Testing

Link to an html view sample files:  html document html document html document

Download a sample xml file:  20180305103000 History and Physical   |  20180415090000 ConsultationNote     |   20190211101700 ContinuityOfCareV3.xml 

Link to a viewer to render the C-CDA documents.

Link to download of the synthetic data associated with this patient story: Zip file of all Synthetic Data


Data Representation Reference Information

Structured Document Clinical Note Types

Use this information to request clinical note(s) (DocumentReference or Composition, DiagnosticReport, CarePlan).

The Pull (Solicited Request) information exchange mechanism enables Information Request Sender to request a general type of document and permits the Information Request Recipient to respond with any of the more specific document types defined to be in that note type category.

The Pull (GET) information exchange mechanism requires the Information Client to use specific codes when querying the Information Source. 

Reference the various types of clinical note types via the concepts in the associated value sets.

Clinical Note Type

General Code

(LOINC)

Specific Types Value Set Name

Value Set Reference (available in VSAC)

History and Physical Note34117-2HPDocumentType2.16.840.1.113883.1.11.20.22
Progress Note11506-3ProgressNoteDocumentTypeCode2.16.840.1.113883.11.20.8.1
Referral Note57133-1ReferralDocumentType2.16.840.1.113883.1.11.20.2.3
Consultation Note11488-4ConsultDocumentType2.16.840.1.113883.11.20.9.31
Procedure Note28570-0ProcedureNoteDocumentTypeCodes2.16.840.1.113883.11.20.6.1
Care Plan18776-5Care Plan Document Type2.16.840.1.113762.1.4.1099.10
Continuity of Care Document34133-9N/AN/A


Helpful Communication Request Recipient Organization Endpoint format codes (this is only relevant for the Request (Solicited Communication) Information Exchange mechanism

Profile

Format Code

Media Type

When to use

HL7 C-CDA R2.1 using a structured bodyurn:hl7-org:sdwg:ccda-structuredBody:2.1text/xmlTo receive document bundles that contain C-CDA R2.1 structured documents
HL7 C-CDA R2.1 using a non-structured bodyurn:hl7-org:sdwg:ccda-nonXMLBody:2.1text/xmlbinary resource 
HL7 C-CDA-On-FHIR using a structured Composition
text/xml
HL7 C-CDA-On-FHIR using a structured Composition
text/json
HL7 C-CDA-On-FHIR using a non-structured body
text/xml
HL7 C-CDA-On-FHIR using a non-structured body
text/json


Sample Structured Data Codes

Note: there are many search parameters and other details for the FHIR search API.  Refer to the FHIR specification for details.

Data Element DescriptionC-CDA Entry TemplateC-CDA data codingFHIR ResourceFHIR Resource data coding
What are the A1C results after 2018-01-01 for this patient?
FHIR Query String: 
  • Observation?patient=[the patient's id]&date=ge2018-01-01&code=4548-4
Test Result: A1C
4548-4 Hemoglobin A1c/Hemoglobin.total in Blood (LOINC)

What are the patient's vital sign measurements in reverse chronological order?

FHIR Query String:

  • Observation?_sort=-date&patient=[this patient's id]&category=vital-signs
Vital Sign: weightVital Sign Observation29463-7 Weight (LOINC)

Vital Sign: heightVital Sign Observation8302-2 Height (LOINC)

Vital Sign: BMIVital Sign Observation39156-5 Body Mass Index (BMI)

What are the patient's active conditions?

FHIR Query String:

  • Condition?patient=[this patient's id]&clinicalstatus=active
Condition/Diagnosis: Type II DiabetesProblem ConcernE11 (ICD-10) Type 2 diabetes mellitus

Condition/diagnosis: Amputated left footProblem Concern

Z89.432 Acquired absence left foot (ICD-10)

Condition
Condition/diagnosis: HypertensionProblem ConcernI10 (ICD-10)Condition
What is the patient's current smoking status?
  • Observation?patient=1032702&code=72166-2&_sort=-date&_count=1
Social History: Smoking StatusSocial History Observation
72166-2 Tobacco Smoking Status (LOINC)


What medications is the patient taking?
  • MedicationStatement?patient=[this patient's id]

Medication Activity


Medication:Medication Information316151 Lisinopril  10 MG (RxNorm)


Indication38341003 | Hypertensive disorder, systemic arterial (disorder) (SCT)

What devices does the patient have?
  • Device?patient=[this patient's id]
Device: Wheel chair

Non-medicinal Supply/product instance

58938008 | Wheelchair device (physical object) | (SCT)

Device: CrutchesNon-medicinal Supply363753007 | Crutches (physical object) | (SCT)

Device: Prosthetic left footNon-medicinal Supply449694008 | Implantation of prosthetic device of lower leg (procedure) | (SCT)

What procedures has the patient had?
  • Procedure?patient=[this patient's id]
ProceduresDiabetic Retinal Exam67028 Diabetic Retinal Exam (CPT)

Procedures:Procedure activity Procedure46786008 | Fitting of prosthesis or prosthetic device of leg below knee (procedure) | (SCT)

Procedures:
Implantation of prosthetic device of lower leg (CPT)

Who is the patient's Primary Care Provider?
  • Patient/this patient's id    (note: parse the generalPractitioner field)
Primary Care Provider for PatientPerformer or ResponsibleParty functionCode

446050000 Primary Care Provider (SCT)

or PCP Primary Care Provider (ParticipationFunction)



What type of health insurance does the patient have?
  • Coverage?patient=[this patient's id]&status=active    (note: parse coverage resource to get the fields you need.)
Coverage: Health Insurance typeCoverage Activity / Policy ActivityNeed help


FHIR Resources Utilized in this Track

Resource

Profile

Brief Description

PatientUS Core PatientUsed to share patient information, ie name and key demographic information like gender, DOB, address, race, ethnicity, etc.
PractitionerUS Core PractitionerUsed to share information
PractitionerRoleUS Core PractitionerRole
OrganizationUS Core Organization
RelatedPersonFHIR RelatedPersonUsed to represent the patient's son, who also is his Healthcare Proxy
LocationUS Core Location
EncounterUS Core Encounter
CareTeamUS Core CareTeam
ConditionUS Core ConditionUsed the share information about a condition a person has or has had.
DeviceUS Core DeviceUsed to share information about the human readable form (HRF) representation of the barcode string as printed on the packaging of the device
DeviceFHIR CoreUsed to share information about a medical device or medical equipment that a patient has had implanted or uses.
CarePlanUS Core CarePlanUsed to share information about a care plan that exists for a patient.
DiagnosticReportUS Core DiagnosticReportUsed to share information about diagnostic testing a patient has had performed.
GoalUS Core GoalUsed to share information about a goal that exists or has existed for a patient.
ImmunizationUS Core ImmunizationUsed to share information about an immunization a patient has received.
MedicationStatementUS Core MedicationStatementUsed to share information about a medication a patient takes or has taken.
Medication
US Core Medication
Used to share information about a specific type of medication.
ProcedureUS Core ProcedureUsed to share information about a procedure that has been performed on a patient.
ObservationUS Core ResultsUsed to share information about the result associated with a particular type of test a patient has had performed.
ObservationUS Core Smoking StatusUsed to share information about a person's smoking status at a point in time.
ObservationFHIR Core Vital SignUsed to share vital sign information that has been collected for a patient.
DocumentReferenceUS Core DocumentReferenceUsed to record information about registered documents or other data collections of a particular type.
Bundle CDex Document BundleUsed to share a persisted document, i.e. clinical note.
BundleCDex Collection BundleUsed to share a collection of data.
BinaryFHIR Core BinaryUsed to share a "blob" of information encoded in a specified format, i.e. Base64
CompositionC-CDA on FHIR CompositionUsed to share a clinical note in a structured format (standardized human readable sections with associated machine readable data). The composition includes
ProvenanceFHIR Core ProvenanceUsed to share information about the originator of a an information artifact.
CommunicationRequestCDex CommunicationRequestUsed to share a request for information.
CommunicationCDex CommunicationUsed to share information about information being shared.
TaskHRex TaskUsed to share information that is relevant to orchestrating the workflow of the information exchange between disparate systems.


Scenario #1 - Support Quality Measurement During HEDIS Hybrid Measure Period

The payer is in the HEDIS Hybrid measure period. In order to support their needs to maximize performance on Quality Measures, the payer seeks information to determine if identified care gaps can be closed.

Pull (GET) Interaction

Scenario #1 Step 1 Query for List of Available Clinical Notes

Action: Payer System (Information Client) queries the Provider System (Information Source) for document references for a specific patient in a given time period for clinical notes. Applicable DocumentReference Resources are returned

Precondition: Clinical Notes are indexed into the DocumentReference Resource on the Provider System, and the Payer System has been authorized to have access to query the Provider System for members' Clinical Notes. 

Success Criteria: DocumentReference resources are returned to the Provider System for the requested patient in the request time range. A list of the available Clinical Notes is presented to the user.

Bonus point: The interaction is only permitted when the patient being queried is a member of the health plan doing the query.

Scenario #1 Step 2 Query for Needed Clinical Notes

Action: Payer System (Information Client) queries the Provider System (Information Source) for specific clinical notes (Binary, Composition, DiagnosticReport, or CarePlan resources with referenced resources). The applicable Binary Resource, or Bundle (of type Document or Collection) is returned. 

Precondition: The Information Client system has already queried the Information Source for a list of available Clinical Notes. Each clinical note resource can be requested using the previously fetched information.

Success Criteria: The requested Clinical Note resource(s) are returned to the Provider System.

Bonus point: 

Scenario #1 Step 3 Query for Desired Data Element

Action: Payer System (Information Client) queries the Provider System (Information Source) for specific patient for the most recent test result (DiagnosticReport with a referenced observation that is an A1C test).  

Precondition: The Provider System has authorized the Payer's System to access their FHIR API, and access to this patient is allowed because they are a member of the Payer's health plan.

Success Criteria: The requested DiagnosticReport resource is returned to the Provider System.

Bonus point: 

Scenario #1 Post Condition

The information returned to the Payer System is organized by Patient and is accessible by users of the Payer System.  When selected, the information is rendered in a way the assists the reviewer to understand and use the returned information.


Scenario #2 - Auditing of a Paid Claim for Compliance with Medical Necessity Requirements

A claim has been submitted for a patient visit. In auditing the claim, the Payer determines that additional clinical information is needed to confirm medical necessity. The Payer requests the needed clinical information from the Provider.

Request (Solicited) Interaction - (without task-based workflow)

 

Scenario #2 (No Task) Step 1 Request the the needed Clinical Documentation.

Action: Payer System (Information Request Sender) posts an actionable CommunicationRequest on the Provider System (Information Request Recipient) certain types of documents for a specific patient in a given time period. The request is actionable and includes a period of time within which to respond.

Precondition: Clinical Notes are indexed into the DocumentReference Resource on the Provider System, and the Payer System has been authorized to place Communication Requests. 

Success Criteria: The CommunicationRequest resource is accepted by the Provider System. The Payer System includes a request review mechanism that allows a user to review incoming requests.

Bonus point: 

Scenario #2 (No Task) Step 2 Respond to Request for Clinical Documentation.

Action: A user on the Provider System (Information Request Sender) reviews the incoming Communication Request and takes action to respond with the requested information (Information Request Recipient). The user attaches the requested types of documents  for the indicated patient, from the requested time period, and replies/forwards the requested information to the indicated Information Recipients. The Provider system (Information Sender) sends a Communication Resource which includes the identifier of the original CommunicationRequest, and the requested type of documents to the Provider System (Information Recipient(s)).

Precondition: Clinical Notes are indexed into the DocumentReference Resource on the Provider System, and the Payer System has been authorized to place Communication Requests. 

Success Criteria: Documents of the requested type resources are returned to the Provider System for the requested patient in the request time range.

Bonus point:   The User on the Provider System is aided by a query mechanism that allows the User to query for the requested documents and then select with documents to attach and return. The User at the Payer System has a queue that can be reviewed to see what information has been returned. 

Scenario #2  (No Task) Step 3 Request Specific Data Element(s)

Action: Payer System (Information Request Sender) sends a communication request to the Provider System (Information Request Recipient) for specific data elements. 

Precondition: The Payer System has a user interface that allows the user to select a specific data element such as weight or height or blood pressure and if the last n, or more recent is needed. 

Success Criteria: The Provider System receives the request and enables a User to review the request.

Bonus point: 

Scenario #2  (No Task) Step 4 Respond to Request for Specific Data Element(s)

Action: Provider System (Information Sender) queries for specific patient for the requested data elements.  

Precondition: The Provider System has a user interface that makes it possible to query for access to data elements requested by a Payer. Access to this patient's information is allowed because they are a member of the Payer's health plan.

Success Criteria: The requested data elements are included in a Communication and sent (Information Sender) to the information recipient (Information Recipient). 

Bonus point:  The Information Recipient system provides a way to view the incoming Communications and the associated information.  The information can be attached to the associated patient.

Scenario #2 (No Task) Post Condition

The information returned to the Payer System is organized by Patient and is accessible by users of the Payer System.  When selected, the information is rendered in a way the assists the reviewer to understand and use the returned information. At the Payer System, a dashboard or report can be produced showing which communication requests were sent, how many of them were returned and how long it took to respond to the requests.

For Scenario #2 (With Task), See Scenario #4

Scenario #3 - Support Provider-to-Provider Communication of Clinical Information

PCP shares clinical information with treating specialist (Endocrinologist) or home health service provider (home health agency providing home nursing services for wound care and assessment of activities of daily living).

Push (POST) Interaction  and Push (Unsolicited Communication)

    


Scenario #3 Push (POST/PUT) Step 1 Name

Action: Provider System (Information Sender) posts the document and document reference information to the Payer's System (Information Recipient).

Precondition: The Provider System has been authorized to have access to post documents and document references the Payer's System. 

Success Criteria: DocumentReference resources are populated on the Payer System and they point to the appropriate document resources.

Bonus point: The interaction is only permitted when the information being posted is for a member of the health plan who is the recipient of the information.

Note, this information exchange mechanism can be used for individual data resources as well, in which case the document reference resource does not need to be posted.

Scenario #3 Push (Unsolicited Communication without task) See Scenario #2 - the Communication part.



Scenario #3 Push (Unsolicited Communication with task) See Scenario #4 - the Communication part.


Scenario #4 - Build Accurate Risk Profiles

During a cycle of updating risk profiles for members, the Payer seeks confirmation of a member's diagnoses.

Request (Solicited Communication with task) Interaction

 

Scenario #4 Push (Solicited Communication with task) Step 1 Name

Action: The Information Request Sender posts a Solicited Communication Task to the Information Request Recipient's system.  The Information Request Recipient decides if they will execute the task.  In this case, they decide to perform the task. 

Precondition: The Information Request Recipient system knows how to process a Solicited Communication Task. 

Success Criteria: The Information Request Recipient receives and processes the Solicited Communication Task.

Scenario #4 Push (Solicited Communication with task) Step 3 (optional) Name

Action: The Information Request Sender gets the Communication Request Task resource from the Information Request Recipient in order to check on the status of the task.

Precondition: The Information Request Recipient system has a task workflow defined for the Solicited Communication Task. 

Success Criteria: The Information Request Sender receives has visibility into the state of the solicited communication task.

Scenario #4 Push (Solicited Communication with task) Step  (optional) Name

Action: The Information Request Recipient gets the CommunicationRequest resource indicated in the CommunicationRequest task from the Information Request Sender. The system then processes the Communication Request, gathering a readying the requested information and populating the corresponding Communication to be returned to the Information Request Sender.

Precondition: The Information Request Recipient system has a task workflow defined for the Solicited Communication Task. 

Success Criteria: The Information Request Recipient receives and processes the Solicited Communication Task.

Bonus point:

TestScript(s)

The supporting TestScripts and corresponding fixtures have been committed to the FHIR documents Github repository at:

Security and Privacy Considerations

We are considering Security and Privacy topics out of scope for Connectathon. These issues are discussed in the Health Record Exchange (HRex) implementation guide.


Proposed Track Lead

 Track leads must be registered users on http://chat.fhir.org

Christol Green Christol.green@anthem.com

Durwin Day Dayd@BCBSIL.com

Expected participants

HCSC, ANTHEM INC., BCBSAL, BCBSTN, Palmetto GBA

WPS Health Solutions, Availity, Cambia, HSPC

Track Orientation

A webinar will be hosted on date at time to share further participation information about this track.

Attachments 

Below are some sample resources we can use during the Connectathon. Most of these will need to be linked to the CommunicationRequest and Communication resources you will create.

Example resources below. Use “GET” command

Claim =http://fhirtest.uhn.ca/baseR4/Claim/144265

Patient =http://fhirtest.uhn.ca/baseR4/Patient/144179

Practitioner=http://fhirtest.uhn.ca/baseR4/Practitioner/144180

Organization Clearinghouse = http://fhirtest.uhn.ca/baseR4/Organization/144178

Organization Payer = http://fhirtest.uhn.ca/baseR4/Organization/144176

Organization Prov Facility = http://fhirtest.uhn.ca/baseR4/Organization/144177

CommunicationRequest = https://fhirtest.uhn.ca/baseR4/CommunicationRequest/161259

Communication = http://fhirtest.uhn.ca/baseDstu3/Communication/1901282


Extension (for attachment type)

   <extension url="http://hl7.org/fhir/us/attachments/StructureDefinition/attachment-type">
       <valueCodeableConcept>
           <coding>
               <system value="http://loinc.org"/>
               <code value="34133-1"/>
               <display value="Summarization of Episode Note"/>
           </coding>
       </valueCodeableConcept>
   </extension>


Types of attachments allowed:

* PDF attachment

* Unstructured C-CDA attachment

* Structured C-CDA attachment

* C-CDA on FHIR attachment


Roles

Payer

Plays the role of a payer who may request and receive attachments. This is loosely analogous to the "FHIR Client - Claims Attachment Requestor" and "FHIR Client - Claims Attachment Processor" roles in the Financial Management track, but with a focus on content instead of process.

Provider

Plays the role of a provider who may receive requests for attachments and send attachments (solicited or unsolicited). This is loosely analogous to the FHIR Client - Claims Attachment Submitter role in the Financial Management track, but with a focus on content instead of process.

Clearinghouse

Serves as an intermediary/aggregator between multiple parties (usually payers and providers), and thus needs to play both submitter and processor roles. The clearinghouse will need to change the sender/receiver information in the Communication and CommunicationRequest resources appropriately (i.e. when forwarding a request from a Payer to a Provider, the sender should be changed from the Payer to the Organization resource for the clearinghouse.

Basic Scenarios

Solicited

Action: Payor sends an attachment request to the provider. Onus is on the payer to create the staple between the request and the attachment. Provider must return the payer's electronic staple (i.e. ID) with the attachment.

Precondition: None

Success Criteria: Provider receives the request, responds with the attachment, payer receives the attachment and is able to view it in their system.Bonus point: Send to an adjudication engine in the Financial track.

Basic script for payer:

  • Step 1: Payer crafts a communication request (example "a" above).
  • Step 2: Provider uses the content of the request to craft a communication resource as the response (example "b" above)
  • Step 3: Provider creates an attachment (PDF, CDA, C-CDA on FHIR)
  • Step 4: Provider POSTs the Communication resource and attachment to FHIR server.
  • Step 5: Payer GETs the Communication resource and attachment and manually verifies the content matches the request.

Basic script for provider:

  • Step 1: Assume payer has sent provider a communication request example: "a"
  • Step 2: Provider uses the content of the request to craft a communication resource as the response example: "b"
  • Step 3: Provider creates an attachment (PDF, CDA, C-CDA on FHIR)
  • Step 4: Provider POSTs the Communication resource and attachment to FHIR server.
  • Step 5: Payer GETs the Communication resource and attachment and manually verifies the content.

Unsolicited

Action: Provider sends an attachment to the payer in support of a claim without a request. Onus on the provider to create the electronic staple (i.e. matching IDs) between the claim and the attachment



  • No labels