interoperability: apis and fhir heat up · 2020. 5. 8. · virtual (within samech) per the reqs...

Copyright 2020 CONFIDENTIAL – PROPRIETARY – RESTRICTED

Interoperability: APIs and FHIR Heat Up

INTEROPATHON | 2020 | Hosted by:

Webinar 2: Accelerator Overviews (Da Vinci, Gravity, and CARIN)

Today’s Agenda

02

03

01 Welcome

Da Vinci Overview Use case and implementation

guides for CDex, DEQM, and Prior Auth

Gravity (SDOH) OverviewOverview of use case and implementation guide

05

04CARIN BlueButton OverviewOverview of use case and

implementation guide

Q & A

https://interoperabilityinstitute.org/virtual-interopathon/


May 7, 2020

HL7 DA VINCI PROJECT OVERVIEW AND USE CASE DEEP DIVE

MIHIN


Project Challenge

To ensure the success of the industry’s shift to Value Based Care

Transform out of Controlled Chaos: Develop rapid multi-stakeholder process to identify, exercise and

implement initial use cases.

4

Collaboration:Minimize the development and

deployment of unique solutions. Promote industry wide standards

and adoption.

Success Measures:Use of FHIR®, implementation

guides and pilot projects.


VENDORS

Da Vinci 2020 Multi-Stakeholder Membership

PROVIDERS EHRs PAYERS

DEPLOYMENT

INDUSTRY PARTNERS

For current membership: http://www.hl7.org/about/davinci/members.cfm

*

*

**

*

*

* *

* * *

* **

*

* *

**Indicates a founding member of the Da Vinci Project.

Organization shown in primary Da Vinci role, Many members participate across categories.

* * *

5

http://www.hl7.org/about/davinci/members.cfm


Data Exchange forQuality Measures

Gaps in Care & Information

Risk Based ContractMember Identification

4

Patient Cost Transparency

Chronic Illness Documentation for

Risk Adjustment

Payer Data Exchange

Use Case Focus Areas

Payer Coverage Decision Exchange

Clinical Data Exchange

Payer Data Exchange: Directory

Payer Data Exchange: Formulary

Quality

Improvem

ent

Clinical D

ataExchange

Coverage / Burden

Reduction

Process Improvement

Mem

berAccess

Payer Data Exchange


Notifications

Patient Data Exchange

Performing Laboratory Reporting

Coverage Requirements

Discovery

DocumentationTemplates and Rules

Prior-Authorization Support Use Case

HL7 StandardsProgress

Published

Balloting

Build Future

Aligned with specific ONC or CMS rule


Use Case Maturity

Clinical Data ExchangeMember Access

Coverage/Burden Reduction

Quality Improvement

Data Exchange for Quality Measures


Risk Adjustment for ChronicIllness Documentation

Risk Based Contract Member Identification


Discovery

Documentation Templates and

Rules

Prior-Authorization Support


DirectoryPayer Data Exchange

Formulary Coverage Decision Exchange


Notifications


Payer DataExchange

Patient DataExchange

Process Improvement

Price Cost Transparency

Standard Phase Future BuildBa

l

lot Published

Connectathon <1 2-4 5+

Live <1 1-3 >4

Progress

Aligned with specific ONC or CMS rule

6

Da Vinci Demonstration Lara’s Patient Journey

Lara

PCPHospital

ER Cardiologist

Payer APayer B

Booth Activities StatsNumber of Members 46

Members Demonstrating 22+

Number of Demos 30+

Panel Discussions 5

Use Cases in Flight 14

https://confluence.hl7.org/display/DVP/Da+Vinci+2020+Calendar

Benefits of Implementing Da Vinci

Create transparency and reduce burden for patients, providers and payers across all sets of patient experienceSaves money and time by minimizing the development ofone-off solutionsLeverage the collective expertise and efforts of industry experts and HL7 FHIRReduce burden and waste by focusing on knownhighvolume, manual activities that can be automated,Allow efficient, effective real-time data exchange to effect patient outcomes and support VBC

https://confluence.hl7.org/display/DVP/Da%2BVinci%2B2020%2BCalendar

Da Vinci Implementation Guides

IG Status # TimesTested

Quality Improvement

Data Exchange for Quality Measures (DEQM) STU 2 Ballot 1 based on FHIR R4 7

Gaps in Care Active Development N/A

Coverage/ Burden Reduction

Coverage Requirements Discovery (CRD) STU 1 Ballot 2 based on FHIR R4 7

Documentation Templates & Rules (DTR) STU 1 Ballot 2 based on FHIR R4 6

Prior Authorization Support (PAS) STU 1 Ballot 1 based on FHIR R4 4

Member Access

Health Record Exchange Framework (HRex) STU 1 Ballot 1 based on FHIR R4 N/A

Clinical Data Exchange (CDex) STU 1 Ballot 1 based on FHIR R4 5

Payer Data Exchange (PDex) STU 1 Ballot 1 based on FHIR R4 5

Payer Data Exchange (PDex): Formulary STU 1 Ballot 1 based on FHIR R4 4

IG Status # TimesTested

Payer Data Exchange (PDex): Plan Network Directory STU 1 Ballot 1 based on FHIR R4 4

Payer-Payer Coverage Decision Exchange STU 1 Ballot 1 based on FHIR R4 4

Patient Cost Transparency Planning N/A


Notifications STU 1 Ballot 1 based on FHIR R4 4

Patient Data Exchange Planning N/A

Performing Laboratory Reporting Planning N/A

Process Improvement

Risk Based Contract Member Identification STU 1 Ballot 1 based on FHIR R4 2

Chronic Illness Documentation Risk Adjustment Planning N/A

http://hl7.org/fhir/us/davinci-deqm/2020FEB/index.html

http://hl7.org/fhir/us/davinci-crd/2019May/

http://hl7.org/fhir/us/davinci-dtr/2019Sep/

http://hl7.org/fhir/us/davinci-pas/2019Sep/

http://hl7.org/fhir/us/davinci-hrex/2019Jun/

http://hl7.org/fhir/us/davinci-cdex/2019Jun/

http://hl7.org/fhir/us/davinci-pdex/2019Jun/

http://hl7.org/fhir/us/Davinci-drug-formulary/Jun2019/

http://hl7.org/fhir/us/davinci-pdex-plan-net/2020Feb/

http://hl7.org/fhir/us/davinci-pcde/2019Sep/

http://hl7.org/fhir/us/davinci-alerts/2020FEB/index.html

http://hl7.org/fhir/us/davinci-atr/2020FEB/index.html


Data Exchange forQuality Measures


Risk Based ContractMember Identification

8

Patient Cost Transparency

Chronic Illness Documentation for

Risk Adjustment

Payer Data Exchange

FOCUS FOR MIHIN CONNECTATHON

Payer Coverage Decision Exchange


Payer Data Exchange: Directory

Payer Data Exchange: Formulary

Quality

Improvem

ent

Clinical D

ataExchange

Coverage / Burden

Reduction

Process Improvement

Mem

berAccess

Payer Data Exchange


Notifications

Patient Data Exchange



Discovery

DocumentationTemplates and Rules

Prior-Authorization Support Use Case

HL7 StandardsProgress

Published

Balloting

Build Future

Implementation Guides for MIHIN Connectathon

Current Prior-Authorization Environment

Payers

Providers

Telephone

Portals

PA Request

Medical Records

Electronic Transactions

Currently providers and payer exchange prior authorization requests and supporting medical records using a number of methods: telephone, fax, portals, and electronic transactions

Fax

11

Current HIPAA / Anticipated AttachmentApproach

Must be ASC X12N 278 (PA request) / 275 (attachment with CDA)

May be any method (including ASC X12N)

B A

Any Method

ASC X12N 278/275

Any Method1a

2

1bASC X12N 278/275 Any Method

Virtual (within same CH)

Per the reqs (i.e. §162.923 Requirements for covered entities), if the Clearinghouse services bothpayer and provider, they must act as two virtual clearinghouses and must provide the transaction as a HIPAA compliant standard transaction internally – not currently enforced by CMS

Payer 1

12

Payer 2

Any Method

ASC X12N 278/275

Any Method1a

2

1bASC X12N 278/275

Any Method

Payer 1

Payer 2

FHIR FHIR

FHIR

Future FHIR Enabled SolutionMust be ASC X12N 278 (PA request) / 275 (attachment with CDA)

May be any method (including ASC X12N)

HL7 FHIR

Virtual (within same CH)

FHIR FHIR

ASC X12N 278/275

13


Power to Reduce, Inform and Delegate Prior Authorization Support

CDS Hooks

FHIRAPIs

Coverage Requirements Discovery

Coverage RequirementsDiscovery

Documentation Templatesand Coverage Rules

Documentation Templates and Coverage Rules

Prior Authorization Support Prior AuthorizationSupport

Improve transparency

Reduce effort for prior authorization

Leverage available clinical content and increase automation

PAYE

REH

R/PR

OVID

ERBAC

K O

FFICE

SYSTEMS

Transformatio

n LayerO

ptionalTr

ansf

orm

atio

n L

ayer

14

X12 278

X12 275if required



SUMMARYProviders need to easily discover which payer covered services ordevices have

15

– Specific documentation requirements,– Rules for determining need for specific treatments/services– Requirement for Prior Authorization (PA) or otherapprovals– Specific guidance.

With a FHIR based API, providers can discover in real-time specific payer requirements that may affect the ability to have certain services or devices covered by the responsible payer.The discovery may be based on

– Plan conditions only (e.g. no need for PHI)– Member identification (PHI) in the event the specific plan isnot

known at the time of requestResponse may be

– The answer to the discover request– A list of services, templates, documents, rules– URI to retrieve specific items (e.g. template)

Stage Ballot Reconciliation &Connectathons

Implementation Guide

CRD FHIR IG (v0.3.0:STU1 ballot 2) basedon FHIR R4

Reference Implementation

CRD GitHub Repository

ConfluenceArtifacts

Coverage Requirements Discovery (CRD)

STATUS




https://github.com/HL7-DaVinci/CRD

https://confluence.hl7.org/pages/viewpage.action?pageId=21857602



Providers need to easily discover which payer covered services or devices have

– Specific documentation requirements,– Rules for determining need for specific treatments/services– Requirement for Prior Authorization (PA) or other approvals– Specific guidance.

With a FHIR based API, providers can discover in real-time specific payer requirements that may affect the ability to have certain services or devices covered by the responsible payer. The discovery may be based on

– Plan conditions only (e.g. no need for PHI)– Member identification (PHI) in the event the specific plan is not

known at the time of requestResponse may be

– The answer to the discovery request– A list of services, templates, documents, rules– URL to retrieve specific items (e.g. template)

Provider

Order Procedure, Lab or Referral

Discover Any Requirements

Payer

16



1. Based on a specific clinical workflow event:scheduling,start of encounter, planning treatment, ordering, dischargeProviders send FHIR based request, with appropriate clinical context to the responsible payer

2. Payer may request additional information from the provider EHR using existing FHIR APIs3. Payer responds to the EHR with any specific requirements that may impact the clinical decisions or coverage

PayerProvider

Provider requests coverage requirements from payer

Optional: request additional information

Payer responds to the request

Provider utilizes this information to make treatment decisions while considering specific payer coverage requirements.

17


Documentation Templates & Coverage Rules (DTR)

SUMMARYProviders are challenged to deal with the diversity of administrative and clinical requirements that impact documenting the need for treatment and selecting the appropriate best path for care. The current environment is made more complex by the large number of payer based requirements that must be met to document that covered services and devices are medically necessary and appropriate.The goal of this use case is to reduce provider burden and simplifyprocess by establishing electronic versions of administrative and clinical requirements that can become part of the providers daily workflow. An exemplar for this use case is to follow the approach taken to incorporate formulary requirements interactively into the medication selection process. Proposal includes the ability to inject payer coverage criteria into provider workflows akin to clinical decision support (CDS Hooks), to expose rules prospectively while providers are making care decisions. A limited reference implementation on a limited use case (e.g. Home Oxygen Therapy)

18

– Address coverage requirements, documentation compliance, and detect misuse/ abuse

– Provide value based care requirements at point of service– Collect, in real-time, patient information to alert provider or care team

StageMay Ballot Reconciliation & Sept STU Ballot


DTR FHIR IG (v0.1.0:Ballot for Comment) based on FHIR R3


DTR GitHub Repository

Confluence Artifacts

Documentation Templates and Payer Rules (DTR)

STATUS

http://hl7.org/fhir/us/davinci-dtr/2019May/

http://hl7.org/fhir/us/davinci-dtr/2019May/

https://github.com/HL7-DaVinci/dtr



CRD and Document Templates & Rules

DME Ordered “order-review” hook triggers query

CDS Service searches repository leveraging FHIR data

Invokes service & sends pre-fetch FHIR data

including order informationLibrary of coverage

rules/templatesSMART on FHIR App

Send CDS Hooks Response with link to SMART on FHIR App

PAYE

R

EHR

/PRO

VIDER

BACK

OFFIC

ESYSTEM

S

Displays Gaps/Template/Rule Collects Missing Data and Store

as Part of Medical Record

Retrieve rules, if necessary. Parse rule from CQL, identify

gaps in data available in EHR and populate template

19


Documentation Templates and Payer Rules (DTR)

Providers need to easily incorporate payer requirements into their clinical workflow

– Specific documentation requirements,– Rules for determining need for specific

treatments/services– Requirement for Prior Authorization (PA) or

other approvals– Specific guidance.

Use a FHIR based standard for representingpayer “rules” to communicate, in real-time, payer medical necessity and best clinical practice requirements that may affect the ability to have certain services or devices covered by the responsible payer.

The template/rules may (examples, not complete list)

– Specify provider documentation requirements for coverage, medical necessity

– Provide guidance / documentation requirements regarding social determinates that are antecedents for specific care

– Collect information for some purpose (e.g.authorizations)

– Indicate clinical requirements including appropriate use

– Collect specific documentation for Quality Measures

– Respond with specific information asrequested/documented in the template/rules

DTR/Order Flow

21


SUMMARYA FHIR-based B2B process to allow implementers to use existingIT infrastructure resources for exchanging prior authorization. Existing business agreements can also be reused.This use case assumes that the goal is define API services toenable provider, at point of service, to request authorization (including all necessary clinical information to support the request) and receive immediate authorization.The assumption is that this use case will leverage the ASC X12N 278 and275 for compliance with HIPAA.Clearinghouses can continue to route and translate data as appropriate. Investigate ability to enable translation layer to convert FHIR resourcesto HIPAA format.

22

Stage September STU Ballot


Prior Authorization Support – CI Build

ReferenceImplementation

Prior Auth SupportGitHub Repository


Prior Authorization Support


STATUS

http://build.fhir.org/ig/HL7/davinci-pas/index.html

https://github.com/HL7-DaVinci/prior-auth

https://github.com/HL7-DaVinci/prior-auth

https://confluence.hl7.org/display/DVP/Prior%2BAuthorization%2BSupport


Prior Authorization Support Abstraction/Transform for HIPAA

Compliance

X12 278

X12 275

EHR OR PROVIDERSYSTEM

PAYER SYSTEMCLEARINGHOUSE ORINTEGRATION LAYER

Clearinghouse or Integration Required to Meet HIPAA Regulations


Support Authorization

Support

Transformatio

n Layer

Tran

sfor

mat

ion

Lay

er

23


Power to Reduce, Inform and Delegate Prior Authorization Support

CDS Hooks

FHIRAPIs


Coverage RequirementsDiscovery

Documentation Templatesand Coverage Rules

Documentation Templates and Coverage Rules

Prior Authorization Support Prior AuthorizationSupport

Improve transparency

Reduce effort for prior authorization

Leverage available clinical content and increase automation

PAYE

REH

R/PR

OVID

ERBAC

K O

FFICE

SYSTEMS

Transformatio

n LayerO

ptionalTr

ansf

orm

atio

n L

ayer

24

X12 278

X12 275if required


Prior Authorization Workflow (X12 processing at Health Plan)

Integrating FHIR and X121) Create FHIR bundle with required

X12 information and supporting clinical documentation

2) Convert FHIR bundle to X12 278,X12 275 and X12 278 I

3) Process by payers as X12 278 with unsolicited attachments

4) Convert X12 278 response o FHIRbundle

5) Present results to provider

25


Disclaimer 24

FHIR Prior Authorization Endpoint Interactions

Provider System Prior-Authorization Black Box (any valid combination of application, BA, clearinghouse and health plan)

(8))Receive and process

request

(2)Receive and process

Bundle

(1)Assemble

information for PA request

(5)Present result of PA

response to providerin workflow

(3)Manage anyHIPAA

transaction requirements

FHIR bundle including Information for 278/275

FHIR bundle

Response (FHIR bundle) within 15 seconds May be error(s), answer or PEND

(7)Request Status (if PEND, orany

reason)

(9)Present result of PA

response to providerin workflow

(5)Event notification on change in PA status

(6)Receive status change

notification

(4)Process PA request and

associated documentation and return result

Response to subscription

Subscribe to delayed response

FHIR bundle

(10)Request canceland/

or update)

Follows same path as original request and with original PA ID

FHIR PA endpoint requirements1) Receive and process PAbundle

• Respond in <15 seconds2) Receive and process Subscription request

for “PENDED” PA• Reply on change in PAstatus

3) Receive and reply to PA status query

4) Receive and process cancel

5) Receive and process update6) Support Status, Cancel, Update from

both ordering and performing provider


25

FHIR Prior Authorization Components

P r o v id e r H e a l t h P l a nD i r e c t c o n n e c t i o n o r v i a e x c h a n g e( e . g . C l e a r i n g h o u s e )

( 2 )H e a l t h P l a n

r e c e i v e s r e q u e s ta n d e v a l u a t e s

( 4 )R e s p o n s e w i t h d o c u m e n t a t io n r e q u i r e m e n t s i f

a p p r o p r i a t e

C D S C A R D S

( 1 )P r o v i d e r o r d e r s o r

p l a n s t r e a t m e n tC D S H o o k s r e q u e s t t o p a y e r

( 6 )E H R / S M A R T A p p

c o l l e c t s a t t e s t a t i o n s , c l i n i c a l d a t a ( f r o m

p a t i e n t r e c o r d w h e r e p o s s i b l e ) ,

( 5 )P r o v i d e r r e c e i v e s a n s w e r

( 9 )H e a l t h P l a n R e c e i v e s P A r e q u e s t a n d a t t a c h m e n t s ,

p r o c e s s r e q u e s t a n d p r o v i d e s r e s p o n s e

( 8 )C o n v e r t F H I R t o / f r o m

X 1 2 i f n o t d o n e b y p r o v i d e r a p p l i c a t i o n

( 7 )G a t h e r s a l l i n f o r m a t i o n f o r P A a n d a t t a c h m e n t a n d s e n d s i t d i r e c t l y o r

v i a i n t e r m e d i a r y t o p a y e r- - r e t u r n s P A N , P e n d ,

D e n y

F H IR A S C X 1 2 N

C o v e r a g e Requirements D i s c o v e r y

Documentation T e m p l a t e s a n d

R u l e s

P r i o r Authorization S u p p o r t

C o n v e r s i o n t o m e e t H I P A A

( 3 a )C o v e r a g e r u l e s /

t e m p l a t e s

A S C X 1 2 N

Y e s( 3 ) I s P A

r e q u i r e d ?

N o

P A

C Q L / S M A R T A p p

N o t e : i f P e n d e d , p r o v i d e r s u b s c r i b e s t o P A r e q u e s t a n d r e t r i e v e s r e s p o n s e w h e n s t a t u s c h a n g e s

Coverage Requirements1) Initiates process

using CDS hooks2) As if PA is requiredTemplates and Rules1) If PA is required start

SMART app and retrieve Payer Rules and Template

2) Prepopulate3) Solicit missing infoPASupport1) Package clinical data

and request/response2) Manage exchanges

with payer

Summary

26

Using new technologies (FHIR , CDS Hooks, SMART on FHIR, CQL) it is possible to integrate previously time intensive tasks into the clinical workflow to achieve significant efficienciesWe can substantially reduce provider burden by

1. Acquiring critical patient information while the patient is available2. Obtain prior-authorizations in real-time for certain common services3. Minimize rework by “getting it right the first time”

One critical impact of improving the prior-authorization workflow is the improvement on patient care and experience.

Quality Improvement


Data Exchange for Quality Measures (DEQM)

SUMMARYUse case creates a common framework for quality data exchange Enables the exchange of raw quality measure data between quality measurement Teams and Care teams that provide patient care Timely exchange of key data is critical to evaluate and capture qualityEmerging DEQM patterns

30

– 30 Day Medication Reconciliation (AttestationPattern)– Colorectal Cancer Screening (ScreeningPattern)– Venous Thromboembolism Prophylaxis (Process Pattern)

Initial example of how Da Vinci funding expandable framework Multiple groups providing resources to build out measures beyond Da VinciEvaluating missing components to expand types of measures/patterns that could leverage framework (i.e., public health)

Stage Ballot Reconciliation & Connectathons


DEQM FHIR IG (v0.2.0:STU1 Ballot 2) based onFHIR R3

30 Day Medication Reconciliation Reference Implementation

MRP-Reference-App

MRP-Payer-App

MRP-Operation-Submit-Example

MRP-Sample-Patients

Colorectal Cancer Screening Reference Implementation

COL-CollectData-App

COL-Submit-App

Confluence Artifacts Data Exchange for Quality Measures (DEQM)

STATUS

http://hl7.org/fhir/us/davinci-deqm/2019May/STU3/



https://github.com/HL7-DaVinci/MRP-Reference-App

https://github.com/HL7-DaVinci/MRP-Payer-App

https://github.com/HL7-DaVinci/MRP-Operation-Submit-Example

https://github.com/HL7-DaVinci/MRP-Operation-Submit-Example

https://github.com/HL7-DaVinci/MRP-Sample-Patients

https://github.com/HL7-DaVinci/COL-CollectData-App

https://github.com/HL7-DaVinci/COL-Submit-App



Data Exchange for Quality Measures

Use case creates a common framework for quality data exchangeEnables the exchange of raw quality measure data between quality measurement Teams and Care teams that provide patient careTimely exchange of key data is critical to evaluate and capture qualityAdditional Scenarios underway to expand measure patterns in framework

1. Submit

3. Subscribe

2. Collect

Payer Aggregator

Submit Measure Data

OperationOutcome

Provider

Collect Measure Data

Return Measure DataPayer

Aggregator

Subscribe for Measure Data

OperationOutcomeProvider

31


Emerging DEQM Patterns

32

Initial example of how Da Vinci funding expandable frameworkMultiple groups providing resources to build out measures beyond Da VinciEvaluating missing components to expand types of measures that could leverage framework i.e.,public health

Measure Pattern Status

30 Day Medication Reconciliation Process

STU1 – Ballot ReconciliationColorectal Cancer Screening Screening

Venous Thromboembolism Prophylaxis

Process

Controlling Blood Pressure Outcome Discovery

Clinical Data Exchange/Member Access


Health Record Exchange Simplified

Payer to Provider Data Exchange (PDex)

Provider to Payer Exchange (CDex)

PAYERPROVIDER

Health Record Exchange Framework

Interactions & Profiles

Provider can receive relevant Payer Sourced Data about a patient

Provider can share relevant Provider Sourced Data to Payer and/or other Providers

Payer to Provider/ Member Data Exchange (PDex):

DirectoryPayer to Provider/ Member

Data Exchange (PDex): Formulary

PATIENT/ MEMBER

Provider can access Plan Network Directory information

Provider can access Plan Formulary information

Patient can access Plan Network Directory information

Patient can accessPlanFormulary information

32


HRexHealth Record exchange

Framework/Library

Interactions and Profiles

PDexPayer Data exchange

DEQMData Exchange for Quality

Measures

Framework

MRPMedication Reconciliation

Post-discharge

Additional Measures for DEQM IG

CDexClinical Data exchange

Health Record Exchange


SUMMARYThe Da Vinci Payer Health Record Exchange (HRex) Framework/Library specifies the FHIR elements used in multiple Da Vinci implementation guides. This includes FHIR profiles, functions, operations, and constraints on other specifications such as CDS-Hooks and other aspects of Da Vinci Use Cases that are common acrossmore than a single use case.Da Vinci HRex Implementation Guide (IG) will make use of US Core profiles that are based on the FHIR R4 specification wherever practical. The HRex IG will use the HL7 FHIR Release 4/US Core STU3 specification as its base.The HRex profiles documented in this IG will be used to exchange databetween providers systems (e.g. EHRs) and other providers, payers, and third-party applications were appropriate. In addition, exchanges from payer systems to providers, other payers, and third-party applications are supported by the HRex profiles and operations.HRex may define new extensions, profiles, value sets, constraints/extension toother specification (e.g. specific CDS-Hooks) that are specific Da Vinci requirements.Where appropriate these Da Vinci specific artifacts will be promoted for incorporation into the future versions of existing standards (e.g. R4 US Core profiles) and deprecated in this guide on publication in the updatedstandard.

36

Stage Early September STUBallot Reconciliation

ImplementationGuide

Da Vinci Health Record Exchange (v0.1.0: STU 1 Ballot 1) based on FHIR R4

Reference Implementation N/A

ConfluenceArtifacts

Health Record Exchange Framework (HRex)

STATUS

Health Record Exchange:Health Record Exchange Framework/Library

http://hl7.org/fhir/us/davinci-hrex/2019Jun/



Health Record Exchange:Clinical Data Exchange (CDex)

37

SUMMARYProviders and Payers need to exchange information regarding prior and current healthcare services planned for or received by the patient/member to more effectively manage the patients care. Currently, no FHIR implementation guides exist to standardize the method of exchange (push, pull, triggers, subscription, etc.) and the formal representation (e.g. Documents, Bundles, Profiles and Vocabulary) for the range of exchanges between providers and providers or providers and payers of current and emerging interest to the involvedparties.The focus is on the exchange of provider and payer originated informationto improve patient care and reduce provider and payerburden.This use case will define combinations of exchange methods (push, pull, subscribe, CDS Hooks, …), specific payloads (Documents, Bundles, and Individual Resources), search criteria, conformance, provenance, and other relevant requirements to support specific exchanges of clinical information between: 1) providers, 2) a provider and a payer, 3) a payer and providers, and/or a provider and any third party involved in value based care (e.g. aquality management organization).This project will reference, where possible, the prior work from Argonaut,USCore and QI Core effort for FHIR DSTU2, STU3,



Da Vinci CDex (v0.1.0: STU 1 Ballot 1) based on FHIR R4


CDex Communication Response App

CDex CommunicationRequest App


Clinical Data Exchange (CDex)

STATUS

http://hl7.org/fhir/us/davinci-cdex/2019Jun/

https://github.com/HL7-DaVinci/CDex-CommRes-App

https://github.com/HL7-DaVinci/CDex-CommReq-App

https://github.com/HL7-DaVinci/CDex-CommReq-App



Health Record Exchange:Payer Data Exchange (PDex)

38

SUMMARYProviders need access to payer information regarding current and priorhealthcare services received by the patient/member to more effectively manage the patients care.It is important to standardize the method of exchange (push, pull, triggers, subscription, etc.) or the formal representation (e.g. Bundles, Profiles and Vocabulary) for specific elements of payer information of interest to providers.The value is to provide a standard for adoption by both payers and providers for the exchange of payer information.Where possible the 'standards' defined by the electronic Health Record exchange (eHRx) Framework Implementation Guide which in turn will utilize prior work from Argonaut, US Core and QI Core effort for FHIR DSTU2, STU3, and R4. The goal is to support the exchange of payer data on specific patients/members for better patient care with providers using technology that support FHIR DSTU2, STU3, and R4 releases of the FHIR standard.Will support the use of other interoperability 'standards' (e.g. CDS Hooks and SMART on FHIR) to effectively exchange payer information regarding the currentor previous care, including the provenance of the data, of one or more specific patients/members with a provider responsible for evaluating/specifying/ordering/delivering care for the patient.



Da Vinci PDex (v0.1.0STU 1 Ballot 1) basedon FHIR R4


PDex GitHub Repository

ConfluenceArtifacts

Payer Data Exchange(PDex)

STATUS

http://hl7.org/fhir/us/davinci-pdex/2019Jun/

https://github.com/HL7-DaVinci/PDex-Patient-Import-App




PDex: Provider-Health Plan Exchange via CDS-Hook/SMART-on-FHIR

R4PayerEMR

R4Call Hook

SMART APP

Appointment-book

CARD

Review

Member Query Summary

Review > Select > Write• Get EMR Metadata

• Write constrained by write options in EMR• Write documentReference (Optional – complete or selected DocumentBundle + PDF)

• Provide Access Token with US Core Scopes• Provide URL Link to Smart App• FHIR Entrypoint• Make CapabilityStatement available• Human Readable result of Member Query

• No data found• Unable to match individual• N records returned

• UserId• PatientId• EncounterId• Appointments• (subscriberId)• JWT for access

• Query Payer using Access Token• Default Parameters from Provider constrain search• Present US Core Records for Provider selection

• Query EMR for Patient Record• Query EMR for Coverage• Search by SubscriberId• Search by Patient Demographics


PDex: Member-Authorized Health Plan Exchange (OAuth2.0)

3838

R4Old Health Plan

R4New Health Plan

3rd Party App

1 Member LoginNew Health Plan

2 Member AuthenticationOld Health Plan

API Handoff

3 Member Access Authorization

1 Member Login3rd Party App

Authenticated

Access Token Returned4

5 API Query with Access Token

Eg. URL/Patient/12345/$everything


See Progress, Test, Implement

FIND

• Listserv Sign Up• Background collateral• Active Use Case content• Implementation Guides• Reference

Implementations• Calendar of Activities &

Updates

KEY RESOURCES

HL7 Confluence Site -https://confluence.hl7.org/display/D VP/

Where to find Da Vinci in Industry -https://confluence.hl7.org/display/DVP/Da+Vinci+2020+Calendar

Use Case Summary and Links to Call In & Artifacts -https://confluence.hl7.org/display/D VP/Da+Vinci+Use+Cases

Reference Implementation Code Repository - https://github.com/HL7-DaVinci

VIEW

• Live Demos• Member Panels• End to End Clinical

Scenario

View Full Schedulehl7.me/davincinews

https://confluence.hl7.org/display/DVP/

https://confluence.hl7.org/display/DVP/Da%2BVinci%2B2020%2BCalendar

https://confluence.hl7.org/display/DVP/Da%2BVinci%2BUse%2BCases

https://github.com/HL7-DaVinci


HL7 Da Vinci Project: Confluence

Once credentials are approved, log in for full access and editing capabilities.

42


Click on Spaces to access Directory to find Da Vinci space.

Select “watch”, on each page of interest, to receive email when updates occur.

De-select “watching” to stop email updates.

43


Self-register for Da Vinci’s Public Listserv on Welcome page.

44


Use Case scope / overview slide deck.

Summary of use case call schedule and meeting details.(scroll down on Confluence page)

45


Each use case has its own landing page with overview details.

Subpages are broken into meeting documentation and supporting materials.

Add calls to your calendar manually or through HL7’s Conference Call Center.

46

Questions?

Robert Dieterle CEO, EnableCare LLC Senior Advisor for Vinci Program

[email protected]

mailto:[email protected]

MiHIN InterOpathonLisa Nelson, Gravity Technical DirectorMay 7, 2020

The Gravity Project: Consensus-driven Standards on Social Determinants of Health

Develop consensus-driven data standards to support use and exchange of social determinants of health (SDOH) data within the health care sectors and between the health care sector and other sectors.

Gravity Project Goal

Graphic from: https://hitconsultant.net/2019/03/18/social-determinants-of-health-sdoh-collection/#.XoQWNHJ7ncs

https://hitconsultant.net/2019/03/18/social-determinants-of-health-sdoh-collection/#.XoQWNHJ7ncs

There is broad consensus that SDOH information improves whole person care and lowers cost. Unmet social needs negatively impact health outcomes.

Arons A, DeSilvey S, Fichtenberg C, Gottlieb L. Documenting social determinants of health-related clinical activities using standardized medical vocabularies. JAMIA Open. 2018;2(1):81-88. (http://sirenetwork.ucsf.edu/tools-resources/mmi/compendium-medical-terminology-codes-social-risk-factors)

Business DriversOne of the biggest barriers to addressing social risk and social needs in clinical settings is the limited standards available to represent the data. We need standards to promote the:• Collection and use of the data; • Facilitate the sharing of the data across clinical and

non-clinical organizations; and• Facilitate payment for social risk data collection

and intervention activities

• Food insecurity correlates to higher levels of diabetes, hypertension, and heart failure.

• Housing instability factors into lower treatment adherence.

• Transportation barriers result in missed appointments, delayed care, and lower medication compliance

Key Learning: Despite increased interest around identifying and addressing SDOH in context of US health care settings, existing medical coding vocabularies and health information exchange standards are poorly equipped to capture related activities.

http://sirenetwork.ucsf.edu/tools-resources/resources/documenting-social-determinants-health-related-clinical-activities-using

http://sirenetwork.ucsf.edu/tools-resources/mmi/compendium-medical-terminology-codes-social-risk-factors

Call to Action: In May 2019, the Gravity Project was launched as a multi-stakeholder public collaborative with the goal to develop, test, and validate standardized SDOH data for use in patient care, care coordination between health and human services sectors, population health management, public health, value-based payment, and clinical research.

Gravity Project Scope: Develop data standards to represent patient level SDOH data documented across four clinical activities: screening, assessment/diagnosis, goal setting, and treatment/interventions.

https://confluence.hl7.org/display/GRAV/The+Gravity+Project

Deliverables:• Use Cases (includes Personas and Patient Story)• Common data elements and associated concept domains

(Food Insecurity, Housing Instability, and Transportation Access)• Coded data element capture and grouping recommendations • HL7® FHIR® Implementation Guide(s)• Reference Implementation(s) and Pilots

Project Scope & Deliverables

1. Document SDOH data in conjunction with the Patient encounter.

2. Document and track SDOH related interventions to completion.

3. Gather and aggregate SDOH data for uses beyond the point of care (e.g. population health, quality reporting, risk adjustment)*

USE CASES

* Use Case 3 out of scope for Sept 2020 FHIR IG ballot



https://confluence.hl7.org/display/GRAV/Gravity+Use+Case+Package

https://confluence.hl7.org/display/GRAV/Food+Insecurity+Domain

https://confluence.hl7.org/display/GRAV/Housing+Instability+and+Homelessness+Domain

https://confluence.hl7.org/display/GRAV/Gravity+FHIR+IG

HL7 FHIR Accelerator: In August 2019, Gravity officially joined the HL7 FHIR Accelerator Program and is on target to ballot an HL7 SDOH FHIR Implementation Guide for Sept. 2020.Public Collaboration: Gravity has convened over 1000 participants from across the health and human services ecosystem from clinical provider groups, community-based organizations, standards development organizations, federal and state government, payers, and technology vendors.Industry Considerations: • Regulatory Trends. Incorporation of Gravity data sets into VSAC, ONC ISA, USCDI.• Payment Reform. CMS, MA, and MCO payments for medically or home delivered meals, housing, and transportation

services.• Tech Innovations. Growth of community referral systems, community information exchanges, and SDOH data analytics

platforms.

SDOH Interoperability Glide Path

Accelerating Adoption: Reuse & Innovation

6

Reuse• US Core; Structured Data Capture (SDC); Da Vinci Clinical Data Exchange (CDex); Bidirectional Service

Request (BSeR); C-CDA on FHIR

New FHIR R4 Profiles for SDOH Content• Screening Data: SDC Questionnaire, SDC QuestionnaireResponse, SDOHCC Consent, SDOHCC List• Encounter Data: SDOHCC Observation, SDOHCC Condition, SDOHCC Goal, SDOHCC Procedure• Referral Data: SDOHCC ServiceRequest

SDOHCC Task PatientScreeningSDOHCC CommunicationRequestSDC Questionnaire FoodInsecuritySDOHCC List PatientScreening

SDOHCC CommunicationSDC QuestionnaireResponse FoodInsecuritySDOHCC Consent FoodInsecurity

SDOHCC Task PatientScreeningSDOHCC CommunicationRequestSDC Questionnaire FoodInsecuritySDOHCC List PatientScreening

SDOHCC CommunicationSDC QuestionnaireResponseSDOHCC Consent

SDOHCC Observation FoodInsecuritySDOHCC Condition FoodInsecuritySDOHCC Goal FoodInsecuritySDOHCC Procedure FoodInsecuritySDOHCC ServiceRequest FoodInsecurityBSer Task PatientReferral

CDex CommunicationRequestCDex Communication

SDOHCC Observation FoodInsecuritySDOHCC Condition FoodInsecuritySDOHCC Goal FoodInsecuritySDOHCC Procedure FoodInsecurity

Use Case 1US Core PatientUS Core PractitionerUS Core OrganizationUS Core PractitionerRoleUS Core LocationOrganizationAffiliation

CCDAF CompositionCCDAF DocumentReference

Key Resources

Location of the IG• http://build.fhir.org/ig/HL7/sdoh-cc/

Location of the Zulip Channel• https://chat.fhir.org/#narrow/stream/233957-Gravity-sdoh-cc

Prep Session Recordings from HL7 Connectathon• https://confluence.hl7.org/display/GRAV/Gravity+SDOH+FHIR+Connectathon

+Participant+Meetings

Gravity Confluence site• https://confluence.hl7.org/display/GRAV/The+Gravity+Project

8

http://build.fhir.org/ig/HL7/sdoh-cc/

https://chat.fhir.org/#narrow/stream/233957-Gravity-sdoh-cc

https://confluence.hl7.org/display/GRAV/Gravity+SDOH+FHIR+Connectathon+Participant+Meetings


Questions?

9

Evelyn [email protected]: @egallegoLinkedin: linkedin.com/in/egallego

Lisa Nelson [email protected]: @PHRLisa

Linkedin: linkedin.com/in/lisa-nelson-987b577



https://www.linkedin.com/in/lisa-nelson-987b577?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BOOytBhqPSHeov69wgvN%2BhQ%3D%3D

CARIN Blue Button Framework and Common Payer Consumer Data SetEMPOWERING CONSUMERS WITH THEIR HEALTH PLAN DATA

Amol VyasChief Architect – InteroperabilityCambia Health SolutionsEmail: [email protected]: @mister_pdx


Our Template : The Argonaut ProjectBackground: The Argonaut Project was formed in December 2014 as an implementation community comprising leading technology vendors and provider organizations to accelerate the use of FHIR and OAuth in health care information exchange. The Argonaut project is private-sector initiated and funded and works collaboratively with other FHIR initiatives to create open industry Implementation Guides in high priority use cases of importance to patients, providers and the industry as a whole. Deliverables: Focused on the ONC’s 2015 Edition Common Clinical Data Set (CCDS) to co-develop the SMART App Application Guide using the OAuth 2.0 profile for authorizing apps to access FHIR data and the Argonaut Data Query Implementation Guide (FHIR DSTU2). Timeline: As of October 2018:IG Publication – Mid 2016 (1 ½ years) 82% of all Hospitals using FHIR DSTU2Full Implementation – 2016 to 2019 (3 years) 64% of all Physicians using FHIR DSTU2


CARIN Blue Button Framework

• Leverage the Argonaut Project as a best practice approach• Common Payer Consumer Data Set (CPCDS)

• Includes key health data that should be accessible and available for exchange.• Data must conform with specified vocabulary standards and code sets.• CPCDS data elements can be stored and queried as profiled FHIR resources.

• Data Query Profiles• Based on CPCDS, define the minimum mandatory elements, extensions and terminology requirements

that must be present in the FHIR resource.

• Data Query Implementation Guide• Collection of security specifications, profile definitions and supporting documentation.• The guide satisfies use cases for member access to health plan data, ensuring the CPCDS elements are

included and modeled in a standard format.

• Mapping From CPCDS To FHIR Resource Profiles• Intermediate Extract-Transform-Load (ETL) Extract Format Specification

Representing CPCDS Data Elements (TBD)


Argonaut Project & CARIN Blue Button Framework

Argonaut Project CARIN Blue Button Framework

Logical Data Specification Common Clinical Data Set (CCDS) Common Payer Consumer Data Set (CPCDS)

Physical Data Specification Using FHIR (Data Query)

FHIR Resource Profiles Representing CCDS Data Elements

FHIR Resource Profiles Representing CPCDS Data Elements

Physical Data Specification Using Flat Files (ETL)

None Intermediate ETL Extract Format Specification Representing CPCDS Data Elements (TBD)

Document Query DocumentReference Profile Exposing Patient’s Existing Clinical Document

None

Logical Data Specification to FHIR Translation

Mapping From CCDS To FHIR Resource Profiles

Mapping From CPCDS To FHIR Resource Profiles

Authorization SMART on FHIR/OAuth2/OpenID Connect

SMART on FHIR/OAuth2/OpenID Connect


CARIN Blue Button API Using CARIN Blue Button FrameworkHow can Plans leverage the CARIN Blue Button Framework?

1. Map Claims System of Record (SOR) directly to FHIR Profiles• Leverage CPCDS to FHIR Mapping as a crosswalk to map the Claims SOR data to CARIN Blue Button

Profiled Resources.

2. Map Claims SOR to FHIR Profiles using ETL extracts as an intermediate step• Generate Flat File extracts containing CPCDS elements from the Claims SOR using existing mature

enterprise-grade ETL tools and processes.• Leverage CPCDS to FHIR Mapping to map the intermediate ETL extracts to CARIN Blue Button Profiled

Resources.

• Maintenance and reuse of direct mappings for some Claims SORs in option 1 may be challenging due to the varying versions, configurations or hosting implementations of the SORs.

• The intermediate step in option 2 introduces additional process & governance. However, it can help decouple the FHIR Profiles from the one/many Claims SOR(s), and also enhance the maintainability and reusability of the FHIR mapping.


CARIN Blue Button Framework

FHIR Server

Key

Health Plan A

Health Plan B

FHIR Profiles

CARIN Blue Button Framework with CPCDS

CMS Medicare

Health Plan Covered Entities/BAs

App A

App B

CPCDS – Common Payer Consumer Data Set (Claims, Eligibility, Benefits)

HIPAA IndividualRight of Access API

Consumer Apps

App Z

CCW RIF FHIR

Health Plan CClaims SOR2

Facets v4

Claims SOR1

CPCDS

FHIR Extensions, Profiles &

Implementation Guides

Mappings & Terminologies

Health Plan DFacets

v3Claims SOR3

SOR – System of Record

Mapping

Custom CSV

Covered Entity/BA

Data Hub A

Multi-plan Data Warehouse

Health Plan ZClaims SOR4

Intermediate Format

(optional)


Provider B CARIN Blue Button Framework

FHIR Server

Health Plan A

CARIN Blue Button IG (FHIR

Profiles)

EDI X12 and CPCDS

Covered Entities/BAs

Health Plan BClaims SOR1 (EOB)

Facets v4 (EOB)

CPCDS

Health Plan CFacets v3

(EOB)Claims SOR2 (EOB)

Data Hub A

Multi-plan Data Warehouse (EOB)

Health Plan DClaims SOR3 (EOB)

837-I/CMS1450/UB04

999277CA

835

Provider A

270271

EDI C

lear

ingh

ouse

837-P/CMS1500

Key

835 Electronic Remittance Advice Mappings

SOR System of RecordEDI X12 TransactionsCovered

Entity/BA

270 Eligibility & Benefits Inquiry

277CA Individual Claim Acknowledgement999 Claims Submission Acknowledgement

270 Eligibility & Benefits Response837 Claims Submission


Exceeds

Common Payer Consumer Data Set (CPCDS) v1.0

Meets

CPCDS v1.0

CMS Medicare

Blue Button 2.0 API

Health Plan #3

Health Plan #2

Health Plan #1

In March 2018, CMS launched Blue Button 2.0, whichprovides secure beneficiary-directed data transport in astructured Fast Healthcare Interoperability Resources(FHIR) format that is developer-friendly. This will enablebeneficiaries to connect their data to applications,services, and research programs they trust. Blue Button2.0 uses open source code that is available for all plansat https://bluebutton.cms.gov/developers/.

In February 2019, CMS issued the Interoperability andPatient Access Proposed Rule. Under this proposal, thescope and volume of the information to be provided ormade accessible through the open API would include:adjudicated claims (including cost); encounters withcapitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results(where available)

Data

Ele

men

t Con

sens

us

https://bluebutton.cms.gov/developers/

Proposed Common Payer Consumer Data Set (CPCDS) v1.0 – Draft


Claim

# CPCDS Element Reference CMS Medicare BB 2.0 Element

Description

1 Claim service start date CLM_FROM_DT

[institutional] The first day on the billing statement covering services rendered to the beneficiary (i.e. 'Statement Covers From Date’).[non-institutional] Earliest of any of the line-item level dates. It is almost always the same as Claim Service End Date except for DME claims - where some services are billed in advance.

2 Claim service end date CLM_THRU_DT

[institutional] The last day on the billing statement covering services rendered to the beneficiary (i.e. 'Statement Covers Thru Date’)[non-institutional] The latest of any of the line-item level dates


Description

3 Claim paid date PD_DT

4 Claim received date NCH_WKLY_PROC_DT

5 Member admission date CLM_ADMSN_DT

[inpatient] The date corresponding with admission of the beneficiary to a facility and the onset of services. May precede the Claim Service Start Date if this claim is for a beneficiary who has been continuously under care.

6 Member discharge date NCH_BENE_DSCHRG_DT

[inpatient] Date the beneficiary was discharged from the facility, or died. Matches the Claim Service End Date. When there is a discharge date, the Patient Discharge Status Code indicates the final disposition of the patient after discharge.Date EOB was created or updated. [Discuss the 2 P i l i


Claim


Description

7 Patient account number

Provider submitted information that can be included on the claim

8 Medical record number

9 Claim unique identifier CLM_ID

10 Claim adjusted from identifier

prior [describe mutable/immutable EOB scenarios here]

11 Claim adjusted to identifier

replaced [describe mutable/immutable EOB scenarios here]

12 Claim diagnosis related group CLM_DRG_CD [inpatient]

13Claim inpatient source admission code CLM_SRC_IP_ADMSN_CD

[inpatient] UB-04 Source of Admission code (FL-15)

14Claim inpatient admission type code CLM_IP_ADMSN_TYPE_CD

[inpatient] UB-04 Type of Admission/Visit (FL-14)

15 Claim bill facility type code CLM_FAC_TYPE_CD

UB-04 Type of Bill (FL-4) structure – Type of facility

16Claim service classification type code

CLM_SRVC_CLSFCTN_TYPE_CD

UB-04 Type of Bill (FL-4) structure – Type of care

UB-04 Type of Bill (FL-4) structure – Sequence in


Description

18 Claim processing status code active, cancelled

19 Claim type code NCH_CLM_TYPE_CD Medical, vision, oral, etc

20 Patient discharge status code PTNT_DSCHRG_STUS_CD

[facility] The patient’s status as of the “Through” date of the billing period. UB04 (FL-17)

21 Claim payment denial code

CARR_CLM_PMT_DNL_CD / CLM_MDCR_NON_PMT_RSN_CD

The code on a non-institutional claim indicating to whom payment was made or if the claim was denied / The reason that no payment is made for services on an institutional claim. (CARC/RARC, excddisallowed code)

22 Claim primary payer identifier NCH_PRMRY_PYR_CD

23 Claim payee type codeRecipient of benefits payable

24 Claim payee Recipient reference

25 Claim payment status codepaid, denied, partially-paid


Claim# CPCDS Element Reference CMS

Medicare BB 2.0 Element

Description

Drug

1 Days supply DAYS_SUPLY_NUM

Number of days' supply of medication dispensed by the pharmacy

2 RX service reference number RX_SRVC_RFRNC_NUM

Assigned by the pharmacy at the time the prescription is filled

3 DAW product selection code DAW_PROD_SLCTN_CD

Prescriber's instruction regarding substitution of generic equivalents or order to dispense the specific prescribed medication

4 Refill number FILL_NUM

The number fill of the current dispensed supply (0, 1, 2, etc)

5 Prescription origin code RX_ORGN_CD

Whether the prescription was transmitted as an electronic prescription, by phone, by fax, or as a written paper copy


Description

6Plan reported brand-generic code BRND_GNRC_CD

Whether the plan adjudicated the claim as a brand or generic drug

7 Pharmacy service type code PHRMCY_SRVC_TYPE_CD

Type of pharmacy that dispensed the prescription

8 Patient residence code PTNT_RSDNC_CD

Where the beneficiary lived when the prescription was filled




Description

11 Claim prescribing provider NPI Prescribing provider

12Claim prescribing provider network status

contracted | non-contracted

13 Claim PCP NPI


Description

Provider

1 Claim billing provider NPI CARR_CLM_BLG_NPI_NUM

2Claim billing provider network status


3 Claim attending provider NPI AT_PHYSN_NPI

Physician who has overall responsibility for the beneficiary's care and treatment [institutional]

4Claim attending provider network status


5 Claim site of service NPICARR_CLM_SOS_NPI_NUM, SRVC_LOC_NPI_NUM

The service location NPI will not be on the claim if it is the same as the billing provider NPI

6Claim site of service network status


6 Claim referring provider NPICARR_CLM_RFRNG_PIN_NUM

8Claim referring provider network status


9 Claim performing provider NPI

PRF_PHYSN_NPI, OP_PHYSN_NPI, RNDRNG_PHYSN_NPI

Rendering/servicing/operating/prescribing providerpharmacist

Claim performing provider

contracted | non-




Description

Amounts

1 Claim total submitted amount CLM_TOT_CHRG_AMTSubmitted charge amount

2 Claim total allowed amountNCH_CARR_CLM_ALOWD_AMT

3 Amount paid by patient PTNT_PAY_AMT

Includes all copayments, coinsurance, deductible, or other patient payment amounts [pharmacy]

4 Claim amount paid to providerCARR_CLM_PRMRY_PYR_PD_AMT

5 Member reimbursement NCH_CLM_BENE_PMT_AMT

6 Claim payment amount CLM_PMT_AMT By Payer

7 Claim disallowed amount NCH_IP_NCVRD_CHRG_AMT

8 Member paid deductible NCH_BENE_IP_DDCTBL_AMT

9 Co-insurance liability amountNCH_BENE_PTA_COINSRNC_LBLTY_AMT

10 Copay amount


Description

11 Member liabilityE.g. Non-contracted provider

12Claim primary payer paid amount

NCH_PRMRY_PYR_CLM_PD_AMT


Claim Line# CPCDS Element Reference CMS


Description

Line Service Details

1 Service (from) date LINE_1ST_EXPNS_DT Dispense/fill date (Rx)

2 Line number LINE_NUM

3 Service to date LINE_LAST_EXPNS_DT

4 Type of service LINE_CMS_TYPE_SRVC_CD

5 Place of service code LINE_PLACE_OF_SRVC_CD

6 Revenue center code REV_CNTR

The provider-assigned revenue code for each cost center for which a separate charge is billed (type of accommodation or ancillary) UB-04 Revenue Code (FL-42), Revenue Description (FL-43)

7 Number of units REV_CNTR_UNIT_CNT

Num of times service or procedure performed. UB-04 Units of Service (FL-46)


Description

8 Allowed number of unitsMaximum allowed number of units

9 National drug code LINE_NDC_CD

10 Compound code CMPND_CD

Whether or not the dispensed drug was compounded or mixed

11 Quantity dispensedREV_CNTR_NDC_QTY, QTY_DSPNSD_NUM

Quantity dispensed for the drug

12 Quantity qualifier codeREV_CNTR_NDC_QTY_QLFR_CD

The unit of measurement for the drug. (gram, ml, etc)

13Line network indicator benefit payment status

in-network, out-of-network, other

14Line claim payment denial code



Description

6 Line amount paid to provider LINE_PRVDR_PMT_AMT

Actual payment made by Payer to the provider for the line item service on the noninstitutional claim. Additional payments may have been made to the provider -including beneficiary deductible and coinsurance amounts and/or other primary payer amounts

7 Line patient deductibleLINE_BENE_PTB_DDCTBL_AMT

8Line primary payer paid amount

LINE_BENE_PRMRY_PYR_PD_AMT

9 Line coinsurance amount LINE_COINSRNC_AMT

10 Line submitted amount LINE_SBMTD_CHRG_AMT

Provider submitted charges for the line item service on the non-institutional claim



Description

Line Amount Details

1Line disallowed charged amount

REV_CNTR_NCVRD_CHRG_AMT

Amount related to a revenue center code for services that are not covered

2 Line member reimbursement LINE_BENE_PMT_AMT

Payment (reimbursement) made to the beneficiary related to the line item service on the non-institutional claim

3 Line amount paid by patientREV_CNTR_PTNT_RSPNSBLTY_PMT

Amount paid by the beneficiary to the provider for the line item service (outpatient)

4 Drug cost TOT_RX_CST_AMTPrice paid for the drug excluding mfr discounts

5 Line payment amount LINE_NCH_PMT_AMT

Amount that Payer is responsible for reimbursing for the line item on the non-institutional claim




Description

11 Line allowed amount LINE_ALOWD_CHRG_AMT

Allowed charges for the line item service on the noninstitutional claim. This charge is used to compute pay to providers or reimbursement to beneficiaries. The amount includes both the line-item Payer and beneficiary-paid amounts (i.e. deductible and coinsurance)

12 Line member liabilityE.g. Non-contracted provider

13 Line copay amount

14 Line discounted rate


Diagnoses & Procedures# CPCDS Element Reference CMS


Description

Diagnosis (0-n)

1 Diagnosis codePRNCPAL_DGNS_CD, ICD_DGNS_CD(1-25)

2 Diagnosis description

3 Present on admission CLM_POA_IND_SW(1-25)

4 Diagnosis code type ICD_DGNS_VRSN_CD(1-25) ICD 9 or ICD 10

5 Diagnosis type Primary, 1-25primary, secondary, discharge, etc.

6 Is E code ICD_DGNS_E_CD1

External cause of injury code. For hospital and emergency department visits, E-codes are used in addition to the diagnostic codes. They can be used as “other diagnosis”.


Description

Procedure (0-n)

1 Procedure code ICD_PRCDR_CD(1-25)

2 Procedure description

3 Procedure date PRCDR_DT(1-25)

4 Procedure code type CPT/HCPCS/ICD-PCS

5 Procedure typeprimary, secondary, discharge, etc.

6 Modifier Code -1 HCPCS_1ST_MDFR_CD

7 Modifier Code -2 HCPCS_2ND_MDFR_CD

8 Modifier Code -3 HCPCS_3RD_MDFR_CD

9 Modifier Code -4 HCPCS_4TH_MDFR_CD


Member# CPCDS Element Reference CMS


Description

1 Member id BENE_IDUnique identifier to member

2 Date of birth DOB_DT

3 Date of death

4 Deceased boolean

5 County BENE_COUNTY_CD

6 State BENE_STATE_CD

7 Country

8 Race code BENE_RACE_CD

9 Ethnicity

10 Gender code GNDR_CD

11 Name

12 Zip code BENE_MLG_CNTCT_ZIP_CD

13 Relationship to subscriber


Coverage# CPCDS Element Reference CMS


Description

1 Subscriber id

2 Coverage type

3 Coverage status

4 Start date

5 End date

6 Group id

7 Group name

8 Plan

9 Payer

References


Consumer Directed Payer Data Exchange IG (aka CARIN Blue Button IG)

• CMS Interoperability and Patient Access Final Rule• https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index

• HL7 Balloted version (STU1)• http://hl7.org/fhir/us/carin-bb/2020Feb

• HL7 Ballot Comments in Jira• project = "FHIR Specification Feedback" AND Specification = "US CARIN Blue Button (FHIR) [FHIR-us-carin-bb]"

• CARIN Alliance on HL7 Confluence• https://confluence.hl7.org/display/CAR/CARIN+Alliance

• CARIN Track at HL7 Virtual Connectathon (13-15 May)• https://confluence.hl7.org/pages/viewpage.action?pageId=80119564

• CARIN Track at MiHIN Virtual InterOpathon (28-29 May)• https://confluence.hl7.org/pages/viewpage.action?pageId=76160714

https://jira.hl7.org/issues/?jql=project%20%3D%20%22FHIR%20Specification%20Feedback%22%20AND%20Specification%20%3D%20%22US%20CARIN%20Blue%20Button%20(FHIR)%20%5BFHIR-us-carin-bb%5D%22%20ORDER%20BY%20key%20ASC

Thank You

Questions?

Thank you!Please join us for next week’s webinar on Interoperability Land™

(IOL) and use case data representation!

Thursday, May 14th from 12-1:30 PM EST


For help please contact [email protected]
