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

Chair:  Robert DieterleViet Nguyen

Scribe: Dana Marcelonis





Dana Marcelonis Point of Care Partners
Tony Benson BCBSAL

Emily Calvert


Erica Ross

Joseph QuinnOptum

Kelly Anderson

Lynda RoweInterSystems

Mark Mundt

Megan SoccorsoCigna

Mike Funk

Nancy SpectorAMA
Terry CunninghamAMA
Tori WillowsWellcare

Marci Maisano

Lindee ChinEdifecs

Agenda Topics

Agenda Outline

Agenda Item

Meeting Minutes from Discussion

Decision Link(if not child)
ManagementReview ANSI Anti-Trust Policy

Current Environment/ HIPAA Requirements for Prior Auth
  • Targeting May ballot cycle - building upon work that has been going on for almost a year
  • PSS (Project Scope Statement), NIB (Notice of Intent to Ballot), FHIR IG Proposal have been filed

  • Current authorization environment - electronic transactions, phone, portals, etc.
  • Anticipating attachments rule (275) consistent with HIPAA requirement
    • Based on current HIPAA regulations, we have ability to use X12 278 for Prior Auth
    • Portals are allowed for direct data entry
    • Clearinghouse/ payer communication can use any standard or proprietary protocol
    • Exchange between clearinghouses needs to be in HIPAA-mandated format (X12)
    • Business associates have the same requirements as covered entities (provider/ payer)
  • EHRs don't typically support a native transaction to a clearinghouse for prior auth (none support X12 transaction)
    • Communication is typically through practice mgmt system/ patient admin system, and is not usually real-time
  • Goals for this use case
    • Leverage FHIR to support pulling data out of clinical workflow (EHR) to populate X12 transactions
    • Ability to take data from a 278/275 and make it available as a FHIR resource so that real time clinical decision support can be performed
  • Question/ comment re: value in keeping clearinghouses in this workflow (just because this is the way it's done today)
    • Chat comment: even if both provider and payer use FHIR, Clearinghouse might act as routing agency so that provider does not have to connect to every payer.
  • How do we overcome the data limitations of a 278? (and 275 isn't mandated)

Da Vinci Use Case Overview
  • Building Prior Auth Support on top of 3 primary use cases - Coverage Requirements Discovery, Documentation Templates & Rules, Clinical Data Exchange
  • Coverage Requirements Discovery (CRD) - based on certain triggers (ordering something, opening a chart, discharge, etc.) a provider can ask the payer if there's anything they need to know about that action
  • Documentation Templates & Rules (DTR) - ability to inject payer coverage criteria into provider workflows (CDS Hooks) to expose rules while providers are making care decisions
  • Health Record Exchange (HRex) - common set of standards that will be used across use cases

Prior Authorization Support Use Case
  • CRD + DTR + Prior Authorization Support
  • Need to understand how much of the workflow is done manually (by a human) vs. automation
    • Nature of PA request, EHR, how much of info is already structured and identifiable may impact
  • Consolidated CDA could be generated and passed along as part of our work
    • If not, we could generate as CCDA on FHIR or FHIR bundle
    • Could convert back into consolidated CDA
  • This use case covers the request and the documentation
  • SMART on FHIR app - would there have to be a different one for each payer?
    • We might decide to create one app that everyone uses, or we could specify clearly enough that even if there are different ones with different payers, the interaction with the provider is the same interaction
  • FAST initiative - scaling, how do I detect endpoints, how do I deal with versioning

Management Next agenda

 Adjourned at 4pm ET

Supporting Documents

Outline Reference

Supporting Document

Minute Approval