1. Da Vinci Working Session - NPAG
Gulf Shores, AL
August 25, 2019

2. ANSI Antitrust Policy
ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification bodies under programs requiring adherence to principles of openness, voluntariness, due process and non-discrimination. ANSI, therefore, brings significant, procompetitive benefits to the standards and conformity assessment community.
ANSI nevertheless recognizes that it must not be a vehicle for individuals or organizations to reach unlawful agreements regarding prices, terms of sale, customers, or markets or engage in other aspects of anti-competitive behavior. ANSI’s policy, therefore, is to take all appropriate measures to comply with U.S. antitrust laws and foreign competition laws and ANSI expects the same from its members and volunteers when acting on behalf of ANSI.
Approved by the ANSI Board of Directors May 22, 2014
Note: always clear/include antitrust statement in a public meeting.

3. Session Goals Introductions Program Structure and Membership
Use Case Overview and Implementation Guide (IG) and Reference Implementation (RI) Process
Example Use Case - Payer to Provider Data Exchange
Da Vinci Deep Dive - NPRM and Payer Focused Use Cases
Example Demonstration - Florida Blue, Edifecs, Pulse8 (a Veradigm Allscripts unit)
Disclaimer

4. By providing FHIR based solutions for provider to payer
Da Vinci Project Challenge
To ensure the success of the industry’s shift to Value Based Care
By providing FHIR based solutions for provider to payer
and provider to provider exchanges
Da Vinci simply is an group of industry payers, providers and HIT partners that understand how critical it is to develop common, ideally eventual standard ways for providers and payers to exchange the critical data required for value base case to work.
Pre-Collaboration / Controlled Chaos:
Develop rapid multi-stakeholder process to identify, exercise and implement initial use cases.
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.

5. HL7 Da Vinci Project: An Overview
To ensure the success of the industry’s shift to Value Based Care, Da Vinci established a rapid multi-stakeholder process to identify, exercise and implement initial use cases between payers and provider organizations.
The objective is to minimize the development and deployment of unique solutions with focus on reference architectures that will promote industry wide standards and adoption.
Provider Members:
Dallas Children's Health, MultiCare, OHSU, Providence St. Joseph Health, Rush University Medical Center, Sutter Health, Texas Health Resources, Weil Cornel Medicine
Project Process
Define requirements (clinical, business, technical and testing
Create Implementation Guide (IG)
Create and test Reference Implementation (RI) (prove the IG works)
Pilot the solution
Deploy the Solution
Payer Members:
Anthem, BCBSA, BCBSAL, BCBSM, BCBST, BC Idaho, Cambia Health, Cigna, CMS, GuideWell, HCSC, Humana, Independence, United Healthcare
Vendor Members:
Allscripts, Athenahealth/Virence(aka GE Centricity), Casenet, Cerner, Cognosante, eCW, Edifecs, Epic, HealthLX, InterSystems, Juxly, Optum, Surescripts, ZeOmega
Partners:
HIMSS, NCQA

6. Use Case Focus Areas Quality Improvement Member Access
Clinical Data Exchange
Data Exchange for Quality Measures
Clinical Data
Exchange
Payer Data
Exchange
Payer Data
Exchange
Gaps in Care & Information
Payer Data Exchange: Formulary
Payer Data Exchange: Directory
Clinical Data
Exchange
Process Improvement
Payer Coverage Decision Exchange
Patient Cost Transparency
Alerts / Notifications
Coverage / Burden Reduction
Coverage Requirements Discovery
Risk Based Contract Member Identification
Chronic Illness Documentation for
Risk Adjustment
Patient Data Exchange
Documentation Templates and Rules
Documentation Templates and Rules
Prior-Authorization Support
Performing Laboratory Reporting
May ballot STU and for comment
In early September ballot (July) as STU
September ballot as STU
Currently targeted for early or regular January 2020 ballot
Use cases in discovery (some may be balloted in January 2020)
Use Case Status 6

7. 2019 2020 Ballots and Connectathons
EARLY SEPTEMBER BALLOT (June 21 – July 21)
STU Health Record Exchange (HRex)
STU Payer Data Exchange (PDex)
STU PDex Formulary
STU Clinical Data Exchange (CDex)
MAY BALLOT (Mar 29 – Apr 29)
STU Data Exchange for Quality Measures (DEQM)
STU Coverage Requirements Discovery (CRD)
Comment Documentation Templates & Rules (DTR)
Early January ballot (Oct 15 – Nov 15)
STU PDex Payer Directory
STU Alerts / Notifications
ONC Annual Meeting
Da Vinci Meeting & Connectathon
HL7 Connectathon
2019
2020
MAR
APR
MAY
JUN
JUL
AUG
SEP
OCT
NOV
DEC
JAN
FEB
MAR
Da Vinci
Connectathon &
Working Session
JANUARY BALLOT (Dec 27 – Jan 26)
STU Gaps in Care
STU STU Patient Cost Transparency
STU RBC Member ID and Bulk Data
SEPTEMBER BALLOT (Aug 9 - Sept 9)
STU Documentation Templates and Rules (DTR)
STU Payer Coverage Decision Exchange
STU Prior Authorization Support (Prior Auth)
HL7 Connectathon
HL7 Connectathon

8. Governance Structure STEERING COMMITTEE OPERATING COMMITTEE
Payers -3
Providers - 2
IT Vendors- 2
CMS - 1
HL7 - 1
Sagran Moodley*
United
Kirk Anderson
Cambia Health
Mike Funk
Humana
Dr. Shafiq Rab, Rush Medical
Dr. Steven Lane
Sutter Health
Hans Buitendjik**
Cerner
Peter DeVault
Epic
Melanie Combs-Dyer
CMS Fee for Service
Dr. Ed Hammond/ Dr. Chuck Jaffe
Program Manager & Technical Director
Jocelyn Keegan Dr. Viet Nguyen
OPERATING COMMITTEE
STEERING COMMITTEE
Senior level executive, can make decisions and commit organization resources
Driving interoperability strategy within home organization and responsible for coordination with industry
Technology and business ownership to drive “business case” approval
OPERATING COMMITTEE
Budget planning and approval for “in kind” and project fees
Leader and/or influencer across home organization
Work closely/aligned with senior leadership at home organization, can queue up commitment and decisions and drive to conclusion
Understands and will own HL7 standards relationship, commitments
Roll up sleeve and problem solve use case development and inventory, priorities, details
Identify and gain access/time for “in kind” resources for priority use case work
Use Case 1 Project Lead
Use Case 2 Project Lead
Use Case n+ Project Lead
DEPLOYMENT COMMITTEE
Disclaimer
*Chair **Co-Chair

9. Sample Project Timeline
Represents 4 weeks
2 - 4 sprints
IG Development
Specify profiles, …
IG Framework
Create Draft IG
Revise and Finalize IG
FHIR Gap Analysis
Assemble Team
Requirements
RI Tech Approach
Project start
RI Development
Build Initial RI
Test RI
Update Final RI
Build Data Set
Build Test Set
Week
Work with appropriate HL7 workgroup for IG sponsorship and input

10. Follow Progress, Test, Implement
FIND
Background Collateral
Implementation Guide(s)
Reference Implementation
HL7 Connectathon Links
Publicly Available
RESOURCES
HL7 Da Vinci Wiki & Listserv signup -
HL7 Confluence Site -
Where to find Da Vinci in Industry - nci+2019+Calendar
Use Case Summary and Links to Call In & Artifacts - nci+Use+Cases
Reference Implementation Code Repository -

11. Highlight:
Spaces (top left)
Watch (top right)
Page Tree (left side)
Program status (center)
- Key items (center)

12. Blues Member Perspective
Disclaimer

13. Health Record Exchange Simplified
BCBSA
Co-lead
Health Record Exchange Framework
Interactions & Profiles
Provider can receive relevant Payer Sourced Data about a patient
Payer to Provider Data Exchange (PDex)
Provider can access Plan Network Directory information
Payer to Provider/ Member Data Exchange (PDex): Directory
Patient can access Plan Network Directory information
Payer to Provider/ Member Data Exchange (PDex): Formulary
Provider can access Plan Formulary information
Patient can access Plan Formulary information
Provider can share relevant Provider Sourced Data to Payer and/or other Providers
Provider to Payer Exchange (CDex)
PROVIDER
PAYER
PATIENT/ MEMBER

14. PDex Use Case Overview Overview Builds on HRex Framework
Exchange between providers and payers of USCDI to help improve are coordination
Also allows for Payer to Payer exchange to satisfy NPRM Requirements
As with all Da Vinici IG’s, developed rapidly; with requirements gathering in February and IG balloted in July
BCBSAL Journey
Core team consists of 2 business and 3 developers but others are identified as needed
Support from Sr. leadership historically in Standards development with X12 and HL7. FHIR and Da Vinci are no different
Knowledge gained from participating is invaluable. Typically 1-2 hours per week for calls per use case
Community driven process allows for collaboration with peers from other organizations
Note: always clear/include antitrust statement in a public meeting.

15. Use Case Deep Dive
Disclaimer

16. Information Exchanges Supported by Da Vinci IGs
[10] Provider Data
[12] Alerts/Notifications
Quality Measures and Gaps
[1] Data Exchange for Quality Measures
[2] Gaps in Care and Information
Member Directed Exchange (CMS NPRM)
[3] Payer Data Exchange
[4] Payer Data Exchange: Directory
[5] Payer Data Exchange: Formulary
[6] Payer Coverage Decisions (Treatment)
Coverage/Documentation Requirements
[7] Coverage Requirements Discovery
[8] Documentation Templates and Rule
[9] Prior-Authorization Support
Patient Data Exchange
[10] Clinical Data Exchange (Provider Data)
[11] Payer Data Exchange (Payer Data)
[12] Alerts/Notification
Patient Cost Transparency (in discovery)
Provider
Provider
[9] Prior-Authorization
[12] Alerts/Notifications
[2] Gaps in Care
[7] Coverage Requirements
[8] Documentation Rules
[11] Payer Data
[1] Quality Data
[10] Provider Data
[3] USCDI
[6] Continuity of Treatment
Payer
Payer
[2] Aggregated Quality Measure Reporting
[3] USCDI
[4] Directory
[5] Formulary
[3] USCDI
[4] Directory
[5] Formulary
Patient
Member authorization
Consumer
Application

17. CMS NPRM Information Exchanges Supported by Da Vinci IGs
[10] Provider Data
[12] Alerts/Notifications
Quality Measures and Gaps
[1] Data Exchange for Quality Measures
[2] Gaps in Care and Information
Member Directed Exchange (CMS NPRM)
[3] Payer Data Exchange
[4] Payer Data Exchange: Directory
[5] Payer Data Exchange: Formulary
[6] Payer Coverage Decisions (Treatment)
Coverage/Documentation Requirements
[7] Coverage Requirements Discovery
[8] Documentation Templates and Rule
[9] Prior-Authorization Support
Patient Data Exchange
[10] Clinical Data Exchange (Provider Data)
[11] Payer Data Exchange (Payer Data)
[12] Alerts/Notification
Patient Cost Transparency (in discovery)
Provider
Provider
[9] Prior-Authorization
[12] Alerts/Notifications
[2] Gaps in Care
[7] Coverage Requirements
[8] Documentation Rules
[11] Payer Data
[1] Quality Data
[10] Provider Data
[3] USCDI
[6] Continuity of Treatment
Payer
Payer
[2] Aggregated Quality Measure Reporting
[3] USCDI
[4] Directory
[5] Formulary
[3] USCDI
[4] Directory
[5] Formulary
Patient
Member authorization
Consumer
Application

18. Work Breakdown to Support CMS NPRM

19. Activities by the Numbers Activities by the Numbers
UNLOCKING PAYER INFORMATION TO IMPROVE CARE
HIMSS19 Demonstration
Activities by the Numbers
Stats
Total practice runs 3
Total public runs 23
Filming runs 1
Total variations 14
Total roles 96
Total role system issues 7
Role availability
92.7%
Activities by the Numbers
Stats
AEGIS Touchstone available
100%
Total MCs 6
Total EHRs 2
Total Payer/Partner 4
Total Payer only 5
Total Sponsors 16
Number of visitors (approx.)
500
Percent that left during vignette
< 10 %
Patient 1 2 3 4
PCP
Schedule Appt with Payer
Admitted for Angioplasty
Discharged with O2 Therapy
Cardiologist
Hospital
Payer
Med Rec
Patient Data
CLINICAL SUMMARY
Da Vinci is demonstrating the ability to exchange information between payers and providers using HL7® FHIR® and CDS Hooks® as part of the Interoperability Showcase.
The vignette describes a clinical encounter for 78-year-old Asian women named Dara that starts with her primary care physician, proceeds to a cardiologist who admits Dara to the hospital for an angiogram and observation where it is determined that her chronic obstructive pulmonary disease has progressed to the point that she needs supplemental oxygen.
As Dara returns to her primary care physician, her previous medications are reconciled with those prescribed at discharge, the PCP reports the medication reconciliation, in support of a quality measure the Medicare Advantage program is following for its members.
The visual describes the interactions demonstrated at HIMSS Interoperability Showcase, direction of each exchange, the FHIR standards used, the setting where the interaction is occurring and the participants.
Each step represents a provider – payer exchange using FHIR IG

20. Subscribe for Measure Data
Quality Data Quality Measures
Submit Measure Data
Use 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 quality
Additional Scenarios underway to expand measure patterns in framework
1. Submit
OperationOutcome
Payer
Aggregator
Collect Measure Data
2. Collect
Return Measure Data
Provider
Payer
Subscribe for Measure Data
3. Subscribe
OperationOutcome
Aggregator
Provider

21. Emerging DEQM Patterns
Measure
Pattern
Status
30 Day Medication Reconciliation
Attestation
STU
Colorectal Cancer Screening
Screening
May Ballot
Venous Thromboembolism Prophylaxis
Process
Initial example of how Da Vinci funding expandable framework
Multiple groups providing resources to build out measures beyond Da Vinci
Evaluating missing components to expand types of measures that could leverage framework i.e., public health

22. CMS NPRM Member Access

23. CMS NPRM for Payer Data Exchange – to Member
1) Must implement and maintain an open API that permits third-party applications to retrieve, with the approval and at the direction of an individual MA enrollee, data specified below through the use of common technologies and without special effort from the enrollee.
a) Accessible content – all plans
i) Standardized data concerning adjudicated claims, including claims …
ii) Standardized encounter data, …
iii) Provider directory data on the MA organization’s network of contracted providers, including names, addresses, phone numbers, and specialties, … and
iv) Clinical data, including laboratory results, if the MA organization manages any such data …
b) Accessible content – for plans that offer an MA-PD plans
i) Standardized data concerning adjudicated claims for covered Part D drugs …
ii) Pharmacy directory data …, and
Formulary data that includes covered Part D drugs, and any tiered formulary structure or utilization management procedure which pertains to those drugs.
Notes: a) applies to other plans covered by the CMS NPRM – see specific language for each
b) applies in part to some other covered plans – see specific language for each

24. CMS NPRM for Payer Data Exchange – to Payer
2) Coordination among payers.
a) MA organizations must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the regulations regarding the content standard adopted at 45 CFR (USCDI). Such information received by an MA organization must be incorporated into the MA organization’s records about the enrollee. At the request of an enrollee, the MA organization must:
i) Receive such data from any other health care plan that has provided coverage to the enrollee within the preceding 5 years;
ii) At any time an enrollee is currently enrolled in the MA plan and up to 5 years after disenrollment, send such data to any other health care plan that currently covers the enrollee;
Notes: a) applies to other plans covered by the CMS NPRM – see specific language for each

25. Use Case Focus Areas Quality Improvement Member Access
Clinical Data Exchange
Data Exchange for Quality Measures
Clinical Data
Exchange
Payer Data
Exchange
Payer Data
Exchange
Gaps in Care & Information
Payer Data Exchange: Formulary
Payer Data Exchange: Directory
Clinical Data
Exchange
Process Improvement
Payer Coverage Decision Exchange
Patient Cost Transparency
Alerts / Notifications
Coverage / Prior Authorization
Coverage Requirements Discovery
Risk Based Contract Member Identification
(Bulk Data)
Chronic Illness Documentation for
Risk Adjustment
Patient Data Exchange
Documentation Templates and Rules
Prior-Authorization Support
Performing Laboratory Reporting
May ballot STU and for comment
In early September Ballot (July) all STU
September ballot as STU
Currently targeted for early or regular January 2020 ballot
Use cases in discovery (some may be balloted in January 2020)
Use Case Status 25

26. CMS NPRM Information Exchanges Supported by Da Vinci IGs
[10] Provider Data
[12] Alerts/Notifications
Quality Measures and Gaps
[1] Data Exchange for Quality Measures
[2] Gaps in Care and Information
Member Directed Exchange (CMS NPRM)
[3] Payer Data Exchange
[4] Payer Data Exchange: Directory
[5] Payer Data Exchange: Formulary
[6] Payer Coverage Decisions (Treatment)
Coverage/Documentation Requirements
[7] Coverage Requirements Discovery
[8] Documentation Templates and Rule
[9] Prior-Authorization Support
Patient Data Exchange
[10] Clinical Data Exchange (Provider Data)
[11] Payer Data Exchange (Payer Data)
[12] Alerts/Notification
Patient Cost Transparency (in discovery)
Provider
Provider
[9] Prior-Authorization
[12] Alerts/Notifications
[2] Gaps in Care
[7] Coverage Requirements
[8] Documentation Rules
[11] Payer Data
[1] Quality Data
[10] Provider Data
[3] USCDI
[6] Continuity of Treatment
Payer
Payer
[2] Aggregated Quality Measure Reporting
[3] USCDI
[4] Directory
[5] Formulary
[3] USCDI
[4] Directory
[5] Formulary
Patient
Member authorization
Consumer
Application

27. MEMBER DIRECTED APPLICATION
CMS NPRM Member Access for Covered Payers
MEMBER DIRECTED APPLICATION 1 1 1
Blue Button CARIN 2 2 2
USCDI* -- Da Vinci PDex 3 3 3
Directory: Da Vinci Payer Network 4 4 4
Formulary: Da Vinci Formulary
PAYER 1
PAYER 2
Member Direction
*Supports bulk data exchange for USCDI

28. Examples of Payer Data Sources
USCDI – US Core Profiles on FHIR R4

29. Continuity of Care
Payer – Payer Exchange

30. CMS NPRM Requirement for Covered Payers2
USCDI* -- Da Vinci PDex 5
Continuity: Da Vinci PCD
PAYER 1
Member Direction
PAYER 2 2
*Supports bulk data exchange for USCDI 5

31. Payer Coverage Decision Exchange
Goal: To address the portability of care/treatment as a member moves from one covered plan to another
Regulatory: CMS NPRM for member directed payer to payer exchange of USCDI data
Immediate Requirement: Support for information regarding ongoing treatment
Relevant diagnoses
Current treatments (including start date, end date (if any), …)
Guidelines for prior-authorization (e.g. specific Milliman guideline)
Current prior-authorizations (service, duration, remaining)
Clinical information that went into the decision for treatment coverage

32. CMS NPRM Care Team Alerts

33. CMS NPRM Information Exchanges Supported by Da Vinci IGs
[10] Provider Data
[12] Alerts/Notifications
Quality Measures and Gaps
[1] Data Exchange for Quality Measures
[2] Gaps in Care and Information
Member Directed Exchange (CMS NPRM)
[3] Payer Data Exchange
[4] Payer Data Exchange: Directory
[5] Payer Data Exchange: Formulary
[6] Payer Coverage Decisions (Treatment)
Coverage/Documentation Requirements
[7] Coverage Requirements Discovery
[8] Documentation Templates and Rule
[9] Prior-Authorization Support
Patient Data Exchange
[10] Clinical Data Exchange (Provider Data)
[11] Payer Data Exchange (Payer Data)
[12] Alerts/Notification
Patient Cost Transparency (in discovery)
Provider
Provider
[9] Prior-Authorization
[12] Alerts/Notifications
[2] Gaps in Care
[7] Coverage Requirements
[8] Documentation Rules
[11] Payer Data
[1] Quality Data
[10] Provider Data
[3] USCDI
[6] Continuity of Treatment
Payer
Payer
[2] Aggregated Quality Measure Reporting
[3] USCDI
[4] Directory
[5] Formulary
[3] USCDI
[4] Directory
[5] Formulary
Patient
Member authorization
Consumer
Application

34. Site of where notifiable event occurred
Alerts/Notification
HIE / HIN
Primary Care
Any care team member can be connected directly or via an intermediary (e.g. HIE)
Site of where notifiable event occurred
Specialty Care
Inpatient Services
Payer
Potential Interactions:
Subscribe to event directly (no intermediary)
Subscribe to event via intermediary
Push to “registered” member (perhaps via payer care team information)
Push to intermediary

35. Prior Authorization Support

36. Electronic Transactions
Current Prior-Authorization Environment
Fax
PA Request
Telephone
Payers
Portals
Providers
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

37. Virtual (within same CH)
Current HIPAA / Anticipated Attachment Approach
Must be ASC X12N 278 (PA request) / 275 (attachment with CDA)
May be any method (including ASC X12N)
Virtual (within same CH)
Any Method
ASC X12N 278/275
Any Method 1a 1b
Payer 1
ASC X12N 278/275
Any Method 2 BA
ASC X12N 278/275
Payer 2
Per the reqs (i.e. § Requirements for covered entities), if the Clearinghouse services both payer 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

38. Virtual (within same CH)
Future FHIR Enabled Solution
Must 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
ASC X12N 278/275
Any Method 1a 1b
Any Method
ASC X12N 278/275
Payer 1
FHIR 2
Any Method
FHIR
ASC X12N 278/275
FHIR
Payer 2

39. Use Case Focus Areas Quality Improvement Member Access
Clinical Data Exchange
Data Exchange for Quality Measures
Clinical Data
Exchange
Payer Data
Exchange
Payer Data
Exchange
Gaps in Care & Information
Payer Data Exchange: Formulary
Payer Data Exchange: Directory
Clinical Data
Exchange
Process Improvement
Payer Coverage Decision Exchange
Patient Cost Transparency
Alerts / Notifications
Coverage / Burden Reduction
Coverage Requirements Discovery
Risk Based Contract Member Identification
Chronic Illness Documentation for
Risk Adjustment
Patient Data Exchange
Documentation Templates and Rules
Documentation Templates and Rules
Prior-Authorization Support
Performing Laboratory Reporting
May ballot STU and for comment
In early September ballot (July) as STU
September ballot as STU
Currently targeted for early or regular January 2020 ballot
Use cases in discovery (some may be balloted in January 2020)
Use Case Status 39

40. Prior Authorization Workflow (X12 processing at Health Plan)

41. FHIR Prior Authorization Endpoint Interactions
FHIR PA endpoint requirements
Receive and process PA bundle
Respond in <15 seconds
Receive and process Subscription request for “PENDED” PA
Reply on change in PA status
Receive and reply to PA status query
Receive and process cancel
Receive and process update
Support Status, Cancel, Update from both ordering and performing provider
Disclaimer

42. FHIR Prior Authorization Components
FHIR Implementation Guides define content, code systems / value sets, exchange protocols, security, operational behavior (e.g. response time) and exchange conformance , etc.

43. Summary
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 efficiencies
We can substantially reduce provider burden by
Acquiring critical patient information while the patient is available
Obtain prior-authorizations in real-time for certain common services
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. 43

44. Payer Coverage Decision Exchange
Goal: To address the portability of care/treatment as a member moves from one covered plan to another
Regulatory: CMS NPRM for member directed payer to payer exchange of USCDI data
Immediate Requirement: Support for information regarding ongoing treatment
Relevant diagnoses
Current treatments (including start date, end date (if any), …)
Guidelines for prior-authorization (e.g. specific Milliman guideline)
Current prior-authorizations (service, duration, remaining)
Clinical information that went into the decision for treatment coverage

45. Bulk Data Access

46. Pipelines can support many scenarios
Large volume of data for one patient:
EHR
Encryption Transformation
RESTful
Exchange
EHR
Bulk Data API
Bulk Data API
Population based Data
EHR
Encryption Transformation
RESTful Exchange
Pop Health
Bulk Data API
Bulk Data API
Files represent LCD to connect distinct processes together

47. Design Goals
Focus on enabling automated communication between backend services and EHRs/clinical systems
Use mature, stable technologies wherever possible
Small API surface area
Limit number of query parameters
Limit number of serialization formats
Reuse as much of existing FHIR semantics as possible
Data models
API format and data types
Implementation guide structure
Use existing standards based authentication and authorization
Base on widely used OAuth (SMART) standard
Structure for efficiently generating and loading large datasets
Asynchronous operation
One data type per file
Streaming data

48. Security Flow (SMART Backend Services)
Backend Service Admin
Bulk
Data
Server
Configure Public Key and other OAuth settings
OAuth Client Id
Bulk Data Client
Signed Token Request
Presumes registration process (could use dynamic client reg or a self-management dashboard to make it hands off)
Asymmetric keys through oauth
Optimized for server to server communication with no user action after setup
Short Lived Access Token

49. File Request Bulk Data Client (destination) Kickoff Request Bulk Data
Server
(source)
Content Location
GET Content Location
File Generation Status (e.g. 20% complete)
GET Content Location
File Links
GET File (eg Observation.ndjson)
FHIR Resources File

50. CMS Blue Button 2.0 BB 2.0 FHIR Server OAuth Token Weekly Load
Integrated Data Repository
Chronic Condition Data Warehouse
Store
Submitted
Claims
Adjudicated Claims
Claims 1
OAuth
Token
BB 2.0 FHIR Server
Blue Button 2.0 API
Blue Button 2.0 Data Repository
Beneficiary
Application
Weekly Load
ACO Attribution List
BB 2.0
Based on FHIR STU 3.0
Large number of Custom Extension
Resources
Patient
Coverage
EOB (8)
DPC Roster
Authentication Process
Data At Point of Care
Application
ACO
Application
ACO processing
ACO processing
Authentication Process
Bulk Data Access
Bulk Data Access

51. Use Case Focus Areas Quality Improvement Member Access
Clinical Data Exchange
Data Exchange for Quality Measures
Clinical Data
Exchange
Payer Data
Exchange
Payer Data
Exchange
Gaps in Care & Information
Payer Data Exchange: Formulary
Payer Data Exchange: Directory
Clinical Data
Exchange
Process Improvement
Payer Coverage Decision Exchange
Patient Cost Transparency
Alerts / Notifications
Coverage / Prior Authorization
Coverage Requirements Discovery
Risk Based Contract Member Identification
(Bulk Data)
Chronic Illness Documentation for
Risk Adjustment
Patient Data Exchange
Documentation Templates and Rules
Prior-Authorization Support
Performing Laboratory Reporting
May ballot STU and for comment
In early September Ballot (July) all STU
September ballot as STU
Currently targeted for early or regular January 2020 ballot
Use cases in discovery (some may be balloted in January 2020)
Use Case Status 51

52. Florida Blue Demo
Disclaimer

53. Da Vinci Program Manager: Jocelyn Keegan, Point of Care Partners
Da Vinci Technical Lead:
Dr. Viet Nguyen, Stratametrics LLC
Da Vinci Program Team:
Bob Dieterle, enablecare