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

Chair:  Robert DieterleViet NguyenAnupam Goel

Scribe: Dana Marcelonis
 

Attendees

Present

Name

Affiliation

  •  
Enablecare
  •  
Stratametrics
  •  
Point of Care Partners
  •  
BCBSAL
  •  

Emily Calvert

CMS
  •  

Erica Ross

CMS
  •  
Heather McComasAMA
  •  
Optum
  •  

Kelly Anderson

BCBSAL
  •  
InterSystems
  •  

Mark Mundt

InterSystems
  •  
Megan SoccorsoCigna
  •  

Mike Funk

Humana
  •  
Nancy SpectorAMA
  •  
Terry CunninghamAMA
  •  
Tori WillowsWellcare
  •  
BCBSFL
  •  
Aim/ Anthem
  •  

Marci Maisano

Cigna
  •  
Edifecs
  •  
Edifecs
  •  
United Healthcare
  •  
Anthem
  •  
Christy Dodson
  •  
BCBSAL
  •  
Laura Hoffman
  •  
WPS Health Solutions
  •  
Optum
  •  
Edifecs
  •  
CMS
  •  

  •  
CAQH
  •  
Raj
  •  
Ray WilkersonScope Info Tech
  •  
BCBST
  •  
Taha AnjarwallaCAQH
  •  
Tom
  •  
Sonja Ziegler
  •  
Intersystems
  •  
Nandini GangulyEMDI/ Scope Info Tech
  •  
BCBSM
  •  
Kasi
  •  
EMDI Team
  •  
Anthem
  •  
Bart CarlsonAzuba
  •  
Cambia
  •  
Duane WalkerBCBSM
  •  
InterSystems
  •  
Tibco
  •  
Louis BedorCognosante
  •  
Anthem
  •  
CMS
  •  
CMS
  •  
IBC
  •  
Anthem
  •  
Rian
  •  
Palmetto gba
  •  
Sandeep
  •  
Sreekanth PuramMettle Solutions
  •  
Allscripts
  •  
James Gallagher Jr.Premera
  •  
Joseph Figueroa
  •  
Tony LittleOptum
  •  
Pallavi TalekarEMDI/ Scope Info Tech
  •  
Thomas KesslerCMS
  •  
Todd Omundson
  •  
ZeOmega
  •  
Emily TenEyckCAQH
  •  
Mark Taylor
  •  
Julia SkapikCognitive Medicine
  •  
Michael BrodyCME Online
  •  
Michelle ZuttermanHumana
  •  
Surescripts
  •  
Laurie DarstMayo
  •  
Marianna SinghCAQH
  •  
Labcorp
  •  

  •  
Mariana SinghCAQH
  •  
Madhuri
  •  

  •  
Bob THompson
  •  
Ben LangleyMITRE
  •  
Michelle PriestAllscripts
  •  
Michael Hurley
  •  
Cedars-Sinai
  •  
Roland Gamache
  •  
Dave HCRT INC
  •  
Barbara WoodPNC
  •  

  •  
Padma KondaveetiMettles
  •  
Unknown User (meryl_bloomrosen)Premier
  •  
Cambia
  •  
Judy Williamson

Present

Name

Affiliation

  •  
Anthem
  •  
Rachel GoldsteinCAQH
  •  
Ralph Saint-PhardHealow
  •  
Susan LestinaAHA
  •  
Briana BarnesScope Info Tech
  •  
Cerner
  •  
Cassandra Bell
  •  
Deepthi ReddyMettle Solutions
  •  
Cognosante
  •  
Humana
  •  
Prashanth Golconda
  •  
Rajesh GodavarthiMCG
  •  
Rim Cothren
  •  
Scott LawrenceCMS
  •  
Chris JonesHumana
  •  
Christina BorgLumeris
  •  
Julie MaasEMR Direct
  •  
Kathleen Connor
  •  
Matt ReidAMA
  •  
Mike BerkmanCoverMyMeds
  •  
Monse SerenilHumad
  •  
Rian RaineyCoverMyMeds
  •  
Sandra StuartKP
  •  
Sheryl TurneyAnthem
  •  
Wanda Govan-JenkinsHHS
  •  
Chris HutchinsonCoverMyMeds
  •  
Anna MeisheidCMS
  •  
Cyrus PeyrovianFastAuth
  •  
Janice BakosAetna
  •  
SureScripts
  •  
Gevity
  •  
Melanie JonesCMS
  •  
eClinicalWorks
  •  
Tammy SchreinerWPS Health Solutions
  •  
Amy PetersonHumana
  •  
Dave Trotter, MD
  •  
BCBSIL
  •  
Renee FullerIBX
  •  
Helina Gebremariam
  •  
Cambia
  •  
Intepro
  •  
Carradora
  •  

  •  

  •  
MaxMD
  •  
Cindy Monarch BCBSM
  •  
Dawn PerreaultBCBSM
  •  
Cognizant
  •  
Mitre
  •  

  •  
Missy BoserSurescripts
  •  
CAQH
  •  
Phranil MehtaeClinicalWorks
  •  
Dylan TuggleBCBST
  •  
JPSys
  •  
Mario JarrinChange Healthcare
  •  
Jim AdamsonArkansas Blue Cross
  •  
Brian PoteetBCBST
  •  
Tony LaurieNoridian
  •  
Optum
  •  
Bonnie SirottZeOmega
  •  
MCG
  •  
ESAC
  •  
Geeta KrishnanEdifecs
  •  
Katherine LuskChildrens
  •  
Michael NovalesBCBSIL
  •  
Tracey McCutcheonKPMG
  •  
Anupam ThakurBCBS FL
  •  
Cathy PlattnerKP
  •  
Srinivasarao EadaraesMD
  •  
Availity
  •  
ZeOmega
  •  
Dennis ZanettiNantHealth
  •  
Haris BegCambia
  •  
Kishore MetlaMettle Solutions
  •  
Sunitha Godavarthi
  •  

  •  
C-HIT
  •  
SriniesMD
  •  
Anthem
  •  
Kumar SourabhGRSI
  •  
Julia ChanCW Global Consult
  •  
Ric LightHumana
  •  
UHC
  •  
Anil VezendlaMCG
  •  
Ken LordBook Zurman
  •  

  •  
Christopher GraconIndependent Health
  •  
Gary GryanMitre
  •  
Mitre
  •  
Marty StaszakVoluware
  •  
Stephen ReckfordGRSI
  •  
Joe HamiltonUnity Point
  •  

  •  
Dave Foster
  •  
Betty SullivanAllscripts
  •  
Cigna
  •  
Juzer KhorakiwallaUHC
  •  
Unknown User (patricekuppe)Surescripts
  •  
Express-Scripts
  •  
Celine LefebvreAMA
  •  
Eshaa DhalleClinicalWorks
  •  

  •  
Aakash DeliwalaeClinicalWorks
  •  
Chris JohnsonBCBSAL
  •  
Megan RileyMITRE


Agenda Topics

Agenda Outline

Agenda Item

Meeting Minutes from Discussion

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



Milestones
LloydBallot Comment Review

#24166

  • Last week the group agreed that we'd adjust the diagram in the CRD, DTR, PAS IGs to show how they intersect - this comment seems related
  • In order to use DTR, do you need to use CRD?
    • You can use DTR independently
    • DTR involves launching a SMART app to gather a set of information
    • CRD acts as a prompt to launch the SMART app
    • DTR SMART app could be launched at any time, don't necessarily need to wait for the prompt - though it wouldn't be launched in workflow context

#24174

  • Claim acts as a packaging bundle, but items can be processed independently
  • From within EHR system, they'll start accumulating items that they will eventually submit as part of a Claim before the Claim comes together
    • They'll package them up based on timeframe or workflow
  • Payer processing and state management happens at line item level, not overall Claim level 
  • Claim is a logical grouping of line items - from a Prior Authorization or Claim perspective we can operate on individual line items within the overall construct
  • We'll still have the package because there's tracking that's done at the Claim level
  • Processes exist to allow adding items to a Claim after it's been submitted, removing items from a Claim after it's been submitted - this leans towards Claim item being its own resource
  • Internal business processing rules differ from entity to entity
  • If we were to split Claim item as an independently manageable resource, it wouldn't stop anyone from treating the Claim as a cohesive unit, and it would allow for flexibility in processing individual line items independently
  • WEDI Prior Auth sub-workgroup have had similar discussions - Prior Auth request with multiple items in it - there are differences in how payers handle it
    • Wheelchair and accessories example - if accessories are approved but not wheelchair, there's no reason for the accessories. May be a reason to hold until everything is complete
    • Different unrelated services on the same request when you want to move forward on some things without holding everything up
    • Sub-group talked about creating some guidelines around relatedness, but how do you define what's related
  • Resources should enable the range of business processes that exist

#24263

  • CRD uses CDS Hooks, and CDS Hooks only allows JSON
  • PAS mandates XML and JSON
  • General recommendation in FHIR is to support multiple syntaxes when possible
  • What happens if one party in exchange doesn't support the syntax coming to them?
    • PAS mandates that payers have to support both XML and JSON

#24271

  • Providers would be exposing a web hook endpoint, not a FHIR endpoint - a place to post a notification saying there's new data available
    • EHRs have indicated strong interest in supporting this
  • Deferred until Paul Knappis available for discussion

#24292

  • Other tracker items already addressed to add a blurb to clarify how the CRD, DTR, PAS IGs intersect

#24322

  • PAS profiles are not derived from US Core profiles
  • Stayed away from US Core profiles because general X12 guideline to not share information you don't need to
    • X12 278 does carry some clinical information (e.g., diagnosis code) - low industry adoption because it doesn't include specific clinical data payer needs to make medical necessity determination
      • What we're transmitting is 2 sets of information:
        • Claim resource - maps directly into the 278
        • Bits and pieces of Practitioner, Encounter, Patient, Procedure, etc. that expose bits of information that are part of the 278 - focused on what does the 278 require
        • Also allow transmission of full-blown US Core instances of Observation, Encounter, Procedure, MedicationRequest, etc. - those are sent using 275/attachment
        • We're sending same resources twice in the same request with different amounts of information - addressing differences between 278 and 275
      • Data in 275 is put in a binary segment as binary data - not specific data elements - could be PDF, CCDA, any type of document or image
  • Are we comfortable with the PAS profiles standing alone, or do we want to derive from US Core?
    • Originally didn't plan to align PAS profiles with US Core profiles, because we're focused on mapping to 278
    • Concern re: focusing only on 278; US Core is intended to be broader
      • If we inherit elements we don't need, we can't constrain them out
      • If we bring US Core in, we inherit all the 'must supports' for stuff we don't want to be supported
      • EHR vendors are going to implement US Core for the most part
        • We're already adding elements to support 278
    • Group discussion was split between the 2 options
    • Need to continue the discussion next week


Next agenda

Ballot comment review continued


 Adjournment

Adjourned at 4:04pm ET


Supporting Documents

Outline Reference

Supporting Document

Minute Approval
Connectathon Kick-Off Presentation and recording
Prior Authorization Support Draft Implementation Guidehttp://build.fhir.org/ig/HL7/davinci-pas/index.html


Tasks

  •