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

Chair:  Robert Dieterle

Scribe: Michele Galioto 


NOTE: This attendance applies if you are present at the related meeting/call, regardless if you have signed a different attendance for your WG. 

Attendees 

Present

Name

Affiliation


Enablecare

POCP

Alex KonturONC

Chetan JainOptum

Bruce SchreiberMedAllies

Cooper ThompsonEpic

Greg Meyer

Cerner

StephanieCigna/Evernorth

Jeff BrownMITRE

Liz SheffieldCigna/Evernorth

Cigna/Evernorth

Sonja ZieglerOptum

Senthil

Optum

Brianna MathiowetzMITRE

MaxMD

Matt Carroll

Alex MuggeCMS

Open City Labs

Stephen Konya ONC

Project Unify

Ron Urwongse 

CAQH



Jaffer Traish

Kevin Van Aucker

Dan ChaputIndependent

MITRE

Seth Blumenthal AMA

Jamie SmithIQVIA

Abigail Watson MITRE

Booz Allen

Douglas DeShazo Seneca Global

CommonWell



Onyx

Serafina Versaggi 

AEGIS

Lenel James BCBSA

MITRE

Rachel E. Foerster Rachel Foerster & Associates

Alberto S. Llanes FEHRM

ONC

Jim HaleyArkansas Blue Cross

Nancy Lush Patient Centric Solutions

Anthem

Justin EdelmanCAQH

Sorin DavisCAQH

HCSC



Smile Digital Health

Lauree Tu  

Erin Clements 



Mark WholeyPatient Centric Solutions

Mel Combs-Dyer Mettle Solutions

UC Davis Health

Liz Turi ONC

Shaumik AshrafMITRE

Elevance Health

Lantana

Lantana

Momeena Ali

CVS Health/ Aetna

Joseph Shook 

Surescripts

Dave Vaillancourt

Mahesh Patil



Rick Lisseveld AEGIS

Rosaline Shaw

Flexion

Elevance Health

Independent Health

POCP

Thomas Zhou AH

Steve AtwoodAthena

James Derrickson

Jackie HemenwayUPMC

Daniel LilavoisAetna/CVS Health

Crystal KallemPOCP / FAST PMO


Minutes Approved as Presented 

x

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)
ManagementHL7 Antitrust StatementProfessional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

HL7 Code of Conducthttps://www.hl7.org/legal/code-of-conduct.cfm

Meeting Minute Approval

2023-01-09 National Directory Meeting

Approved by unanimous consent

Project Links

Project Page: National Healthcare Directory

Project Scope Statement: National Healthcare Directory PSS

Implementation Guides:

Connectathon: 2023- 01 FAST National Directory of Healthcare & Da Vinci Plan Net

Zulip Channel: https://chat.fhir.org/#narrow/stream/283066-united-states.2Fnational.20directory

Predecessor work that this effort builds upon:



Milestones

Sept 2022 Ballot Cycle Milestones

Milestone
Ballot VotingComplete
Ballot ReconciliationIn Progress

Tentative: May 2023 Ballot Cycle Milestones

Milestone
Notice of Intent to Ballot (NIB)February 19, 2023
Sept 2022 Ballot Reconciliation CompleteMarch 13, 2023




Announcements

January HL7 Working Group Meeting & Connectathon

  • Connectathon: January 14-15, 2023 (2023 - 01 Connectathon 32)
  • Work Group Meeting: January 16-20, 2023
  • Location: Hilton Lake Las Vegas Resort and Spa, Henderson, NV (In-Person)

  • Registration now open! 
  • Find FAST for Connectathon breakout sessions and at the WGM: FAST Calendar



CMS Advancing Interoperability and Improving Prior Authorization Processes Proposed Rule (CMS-0057-P)

This proposed regulation cover areas like Patient Access API, Payer to Payer Exchange, Handling Prior Authorization, etc.

Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard Proposed Rule (CMS-0053-P)

This is the long awaited attachments rule from the Division of National Standards. It contains follow on requirements in the Accountable Care Act that mandated that CMS establish a standard for exchange of attachments compatible with HIPAA transactions. 


Agenda




TIN

Review Evernorth ballot comments

    • FHIR-38301 – require TIN
      • MB - social care providers largely don't have NPIs - would be wise to have identifier like a Tax ID that every org will have
      • BD - must support or require?
        • Require - you have to have it
        • Must support - if you have it, you have to include it in the transaction; have a method for capturing and storing
      • KGWEYB - can get contracted TIN but not corporate TIN in some cases; must support makes sense
      • From thomas.zhou (AH) to Everyone 11:11 AM - Is the TIN a must to comply with HIPAA?
        • BD - HIPAA related transactions may require TIN, but nothing in HIPAA requires TIN
        • TZ - if there's no requirement/ policy in HIPAA, there's lack of evidence for must support
        • BD - this info probably goes in the base profiles - making it required says every organization that ever participates in the National Directory would have to have a TIN and that's not necessarily true
        • TZ - if it's optional, it should stay as optional - must support is attribute level constraint - sometimes confuses implementer downstream
        • TL - if organization has that data, your implementation has to save it and retrieve it, but not every org has to have the field/ value
        • TZ - mandatory for organization to provide it from business perspective?
        • BD - some orgs that participate will not have or provide a TIN, but we have to have ability to capture it and populate the transaction if we have ability to
        • TZ - optional is good enough - no need to use must support
        • BD - must support says you have to have ability to do that as part of the implementation
          • Already have must support requirements as part of US Core
        • TZ - must support brings conversation/ debate
        • TL - combination of must support and cardinality that turns it from required to optional; maybe share that with your developers - done that way for all FHIR IGs
      • MD - if TIN shouldn't be revealed, any capability to constrain it?
        • BD - yes, with restriction resource
        • MD - use the usage restriction to constrain if TIN shouldn't be shared?
        • BD - TINs in NPPES?
        • MD - yes - guidance to providers not to enter your TIN - NPPES trying to not reveal to public; but for organizations not sure re: privacy concern
        • BD - creating vehicle to restrict if needed, and implementer of directory decides if needs to be restricted or not
        • From thomas.zhou (AH) to Everyone 11:27 AM - I second the PIA
          • TZ - encourage to provide their TIN; but discretion if privacy issues
          • BD - implementer of the directory will make those decisions, not the IG - the IG is about exchange, not policy decisions
          • TZ - prefer to start with less constraint, and then down the road can add must support, constraints
          • BD - not requiring anyone to have it, but requiring ability to capture it and exchange it
      • Proposed Disposition
        • Persuasive with mod
        • Add slice to base profile for Organization.identifier for TIN and make it 0..1 and must support
        • Since OrganizationAffiliation represents relationships between organization modeled after PractitionerRole there is no need to include TIN in OrganizationAffiliation since it will already be associated with the individual organizations
        • Enhancement - Substantive, Compatible
        • Ready for vote
  •  
  •  
    • FHIR-38303 – require TIN
      • Ticket for Exchange IG
      • BD - location address is new piece for this ticket
      • BD - we're adopting what US Core has done for addresses for organization; requirements come from USCDI
      • Clayton (KGWEYB) - we build tables to map location to US postal service address
      • BD- nothing prevents you from having multiple addresses - one that's 123 Main Street and another that says Corner of 4th and Main - we support the capability
      • MB - meant as an alias? different way of saying same address?
      • KGWEYB - yes
      • BD - organization resource and pull back all the addresses are associated with it
      • TL - as long as it supports more than one address, we're ok?
      • KGWEYB - not a way to necessarily relate them?
      • BD - yes could have US postal service address/ everything populated, and then secondary address that has nothing but line populated
      • CC - organization in this context can have multiple addresses - clinic with 10 different locations - do we need 2 slices - one that's USPS mailing address - 10 mailing addresses, and then different set of slices to have 10 'vanity' slices?
        • Understand need for more human friendly version, but what does that look like?
      • BD - we have all the flexibility in the world to have multiple addresses or multiple representations of one address, or within a single address specify a 4 line string
        • The only requirement is City, State, Postal Code, Country - the actual street address is not enforced in a way
      • TL - could do slicing as well? could we put our own use in there?
      • BD - no, it's required you can't - it's not extensible
        • Ability to do postal or physical or both
      • KGWEYB - enough there to work with
      • RL - Plan Net and NDH - address primarily supposed to be in the Location object as opposed to the Organization?
        • According to relational structure it looked like Location resource is the expectation for physical address of an organization
        • BD - we haven't done anything other than pick up US Core base for that - all the statements would still be true whether you use Organization or Location - could use either
          • Practice location would typically use Location
          • Organization itself would typically use Organization
        • MD - NDH - geolocation is being used but not in US Core
          • BD - right, we have some extensions 
        • RL - are we looking for vanity address for practice location or physical location of the organization
        • BD - applies equally to Location and Organization
        • KGWEYB - right - across any represntation of address
        • From Matt Bishop to Everyone 11:45 AM - (5.0) http://hl7.org/fhir/5.0.0-snapshot3/organization.html and (4.3) http://hl7.org/fhir/2021May/organization.html
      • Proposed disposition
        • Persuasive with mod
        • See FHIR-38301 for disposition regarding TIN
        • Current address complex data type has sufficient flexibility to address vanity addresses - no need to modify either Location or Organization resource
        • Enhancement - compatible, substantive
        • Ready for vote
  •  
    • FHIR-38304 - Examples does not appear to reflect Tiered OAuth
      • Redoing all this in the single combined IG
      • Changed issue type from a technical correction to a change request
      • Proposed Disposition
        • Persuasive with mod
        • Include brief description and reference to Tiered OAuth in the combined implementation guide
        • Clarification - non-substantive
        • Ready for vote
  •  
    • FHIR-38305 - Org Type Value Set Flexibility
      • TL - discrepancies between 3 IGs
      • BD - should have been the one taken out of Plan Net and that had a lot of payer input and terminology group input
      • TL - specific value set for the 3 directory IGs and different from base R4 value set
      • BD - don't think we have rationale for changing the Plan Net work
      • BD - won't have 3 IGs anymore
      • Proposed Disposition
        • Will verify that value set is the same as used in Plan Net 
        • If not will change to reference the same value set
        • Correction - compatible, substantive
        • Ready for vote

ManagementNext Agenda

No meetings during the week of 1/16 for HL7 WGM

Next meeting Monday, 1/23

Future meetings:

  • Request to revisit discussion, resolution re: endpoint use case topic from a week or so ago - better suited to be called purpose, and needed a separate data element that would reflect the workflow
  • Review HSDS revisions to align with our work
  • Reference Implementation link

Henderson Meeting Agenda Items:

  • What will we do with payloadType and payloadMimeType

 Adjournment
Adjourned at 12pm ET

Supporting Documents

Outline Reference

Supporting Document

Presentation



Tasks