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

Chair:  Lloyd McKenzieRobert Dieterle

Scribe: Dana Marcelonis
 

Attendees

Present

Name

Affiliation

  •  
IBC
  •  
Lloyd McKenzieGevity
  •  
Enablecare
  •  
Aaron Kohn
  •  
Duane WalkerBCBSM
  •  
Michael CabralCMS
  •  
Susan BellileAvaility
  •  
Susan LangfordBCBST
  •  
Sonja Ziegler
  •  
Peter Muir
  •  
Cambia
  •  
Ann GallagherOptum
  •  
Luis SayagoDacarba
  •  
Ralph Saint-PhardHealow
  •  
Interpro
  •  
Celia Bowen
  •  
Isaac VetterEpic
  •  
Dawn PerreaultBCBSM
  •  
Jeffrey DanfordAllscripts
  •  
Rachel E. Foerster
  •  
Seth ParadisHealow
  •  
Sheryl TurneyAnthem
  •  
Serafina Versaggi
  •  
Rohit ShindeeClinical Works
  •  
Pallavi TalekarScope Info Tech
  •  
Barbara AntunaAIM
  •  
Brandon RaabAnthem
  •  
Chris JohnsonBCBSAL
  •  
Clarissa WinchesterBCBSAL
  •  
Didi DavisSequoia Project

Present

Name

Affiliation

  •  

  •  
JPSys
  •  
Roland GamacheAHRQ/CEPI
  •  
Jeanie SmithBCBSFL
  •  
Jim St. ClairDinocrates Group
  •  
Durwin DayBCBSIL
  •  
Patrick HarenCigna
  •  
Anthem
  •  
Athenahealth
  •  
Katherine LuskChildrens
  •  
Laurie BurckhardtWPS Health Solutions
  •  
Manoj KumarGuidewell
  •  

  •  
Minil Mikkili
  •  
Scott M. RobertsonKP
  •  
David Kates
  •  
Sreenivas MallipeddiMCG
  •  
Thomas J. KesslerCMS
  •  
Eric ThomasIBC
  •  
Tony LittleOptum
  •  
Yolanda VillanovaCMS
  •  
TorQuailla Aultman
  •  
Brian PoteetBCBST
  •  
Brad Prentice
  •  
Heather KennedyBCBST
  •  
Jim TaylorTibco
  •  
Jodie ZellerhoffCambia
  •  
Labcorp
  •  
Nick RadovUHC
  •  
Mary Kay McDanielCognosante
  •  
Joseph QuinnOptum
  •  
Julia Chan
  •  

  •  
BCBSM
  •  
Marianna SinghCAQH
  •  
Neeraja


Minutes Approved as Presented 


This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."


Agenda Topics

Agenda Outline

Agenda Item

Meeting Minutes from Discussion

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



CRD Implementation Guide Link

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



Ballot Comment Triage/Review

#22229

  • Section 4.4 Privacy, Security and Safety
  • Making a claim re: business relationships - this IG is not what defines that client systems take on the responsibility that coverage requirements are met - IG is not capable of mandating that - it's written as if it's a requirement, but the intent was likely background information
  • Revised wording to 'may'
  • Persuasive with mod (since original recommendation was to remove the statement)

#22230

  • Section 4.4.1
  • PHI vs. non-PHI version of the CRD interface
  • How many payers are likely to implement this? ~10?
  • If CMS required it, how many EHRs and PMS systems would implement this? ~12?
  • Many more potential CRD clients than CRD services - doubling implementation work
    • Interoperability would be aided by having a single path
    • By profiling Patient and Coverage to be PHI-less is basically like a new resource - does this make sense in the long-run for the community overall?
  • Slightly more than 50% of all patient encounters don't require PHI to do CRD
  • EHRs would need to support PHI and Non-PHI, but payers would only have to support one
    • EHR would essentially have 2 paths - CMS, State, Medicare Advantage vs. Commercial payers
  • This item will be split out from block vote for individual discussion in the Financial Management workgroup 
  • Chat Comment from Julia Chan: 

    question on earlier discussion> page 19>section 7.3> medicare beneficiary matching rules logic for HET 270/271 uses a combination of HICN or MBI, dob, last name, first name..is HICN or MBI considered as PHI?  reference>https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/HETSHelp/Downloads/R2019Q100HETS270271CompanionGuide.pdf

    • Julia to provide comments in gforge #22230 if she has further quesitons/comments

#22231

  • Provider should not be interrupted unless there's something they need to do
  • It should be up to individual health sytsems/providers and their workflow, as to whether a 'no coverage requirements' card should be presented to the user
  • Payers SHALL provide, is different from EHRs SHALL display it
  • CRD client shouldn't have to parse text intended to be human readable in order to interpret/act upon the message
    • It should come back as structured data/ status flag so that it's machine actionable within the EHR
    • CDS Hooks doesn't support this?
      • Empty JSON object means there is no guidance
  • Change wording to: Payer SHALL respond with an empty JSON object where there is no action to be taken
  • Persuasive 

#22232

  • CRD spec should not include capability for CRD client to 'dyamically configure' the CRD service
  • CRD client is responsible for telling CRD service what guidance the service should provide - violation of separation of concerns, places burden on CRD client - trying to avoid placing burden on the payer software isn't appropriate
  • Defer this issue for Robert Dieterle / Lloyd McKenziereview offline and will bring back to group for discussion
  • Questioning the business requirement and the need to have the technical mechanism

ManagementNext agenda

 Adjournment
Adjourned at 1:01pm ET

Supporting Documents

Outline Reference

Supporting Document

Minute Approval


Action items


Create Decision from template