Page History

Liz Sheffield 

Mark Wholey

2023-09-25 National Directory Meeting

Project Page: National Healthcare Directory

Project Scope Statement: National Healthcare Directory PSS

Implementation Guides:

• CI Build: http://build.fhir.org/ig/HL7/fhir-us-ndh/branches/master/index.html
  • Note: 3 IGs have been combined into a single IG
• Balloted Versions:
  • http://hl7.org/fhir/us/directory-query/2022Sep/
  • http://hl7.org/fhir/us/directory-exchange/2022Sep/
  • http://hl7.org/fhir/us/directory-attestation/2022Sep/

Reference Implementation:

• National Directory RI Client: https://ndh-query-client.fast.hl7.org/
• National Directory RI Server - https://national-directory.fast.hl7.org/fhir

Connectathon: 2023 - 09 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:

• • VHDir Implementation Guide
  • ONC Healthcare Directory initiative
  • Da Vinci PDex Plan Net Implementation Guide

September 2023 Ballot Cycle Milestones

Please be sure to update your Zoom by adding your company name to your name. 

• Find your name under "participants" (bottom of your zoom screen)
• Click the ... next to "mute"
• Choose the "rename" option and add your company next to your name and save the change. 

Da Vinci PDex Plan Net discussions will take place on the 2nd Friday of each month during the standing PDex/Formulary/Plan Net Implementer Support meetings (at 1:00 pm ET). Will plan to reconcile Jira tickets that influence/impact ND work. https://www.hl7.org/concalls/CallDetails.cfm?concall=65611

• National Directory meeting details will be modified to use FAST's Zoom account. This means we'll update the HL7 Conference Call Center, Confluence references, and post details to list serv and Zulip. 
• Impact on you:  You'll need to update your own calendar manually or through the HL7 Conference Call Center with new ZOOM meeting details: 

Join Zoom Meeting for October 2023 and beyond for National Directory calls: 
https://hl7-org.zoom.us/j/95314390248?pwd=QUhvNktmTVJiWUk2ZnRHSmdWcHpmdz09

Meeting ID: 953 1439 0248
Passcode: 588636

Dial by your location
• +1 301 715 8592 US (Washington DC)
• +1 312 626 6799 US (Chicago)
• +1 646 558 8656 US (New York)
• +1 253 215 8782 US (Tacoma)
• +1 346 248 7799 US (Houston)
• +1 669 900 9128 US (San Jose)

Meeting ID: 953 1439 0248

Notes: Attendees reminder via verbal update and chat box post. Message sent to FAST Projects list serv and applicable Confluence pages revised to contain new zoom details. 

THO Decision Tree Process for NDH

Code System

• Is Code System in THO
  1. Yes – continue
  2. No
     1. Is Code System used by NDH only
        1. Yes – Local Code System
        2. No – Add to THO

• Is it completed (includes all of the required values for the Value Set)?
  1. Yes – continue
  2. No – can we add the required values for the Value Set

Note: Are there codes that overlap and change the meaning  or restrict the addition of new required codes

1. Yes – need to request additional values
2. No – consider value set that is combination of the THO Code System and a Code System local to the iG

Value Set

• Is value set in THO
  1. Yes – use Value Set (need to consider the impact of the Value Set binding)
  2. No – is value set local to IG only
     1. Yes – local Value Set
     2. No – build in THO (submit to THO)

NOTES: 

FHIR-42248: 

Image Added

Discussion of Consent and related National Directory (ND) restrictions: 

• We only have 1 value - DRC. Challenge with patient vs. directory centric context.
• Ming and Bob suggested that we put code in THO and create our own value set OR we could create consent restriction resource with all the codes that relate to the NDH restrictions with a separate code set.

Image Added

• Bob spoke to local code approach and it being akin to other IG approaches.
• Rick asked if this is the only consent code? Any other codes out there that talks about restricting access to information.
• Bob indicated the problem we have is the existing binding to consent resource for this particular system - it is extensible. Not aware of other code systems and want to not complicate the process for implementers.
• Rick suggested we create NDH code systems with unique values that are relevant for ND and then create value sets from that code system.
• Bob agreed with Rick. Intent would be single code system for NDH and its broader than consent philosophical question.
• Ming said we need to run this by THO.
• Bob agreed noting the need for a related note in the tracker/ticket, then once we process all tickets we can double check our logic as we bundle up discussion items with THO.
• Ming asked Joe about IHE and their code system for connection type. There is a ticket on this and she is encountering an error.

Image Added

• Dave recommended adding the error into Zulip stream to prompt discussion with Grahame and THO because code system is not yet loaded and could take up to a year to be addressed.

Image Added

FHIR-42661: 

• Bob presented the metadata lastupdate related ticket.  One of the issues is the ND server ability to support the "get" which would have mandated the metadata lastupdate be supported as well as "put/post" functions. However, it’s being created internally so the question becomes rather than making resource.net a cardinality of 1...*, we make it 0…* with a must support. This change would make it workable in the various scenarios. Attendees asked if any concerns; none presented. 
• Bob clarified this is only for exchange profiles and how to use in search parameters with it being updated to must support.
• Rick asked: If it is must support in exchange, why wouldn’t it remain in distributed? 
• Bob indicated there is no control over downstream directories or internal structure. Just because we use FHIR and exchange profiles to provide data doesn’t mean it is stored that way at all in the downstream systems. We have no knowledge if they support concept of lastupdate; this is why we stayed away from it. We focused on the ND query only. Remember – downstream queries are optional; offered in IG in case folks wish to do them. Bob acknowledged Rick’s conformance interplay concern.

Image AddedImage Added

Image Added

Discussion pivoted to Search parameters tickets –

FHIR-42132

• Rick asked if we could get list of trackers we’ll cover with call so he can be prepared.
• Rick explained the issue in ticket related to new patient and new patient from network – both keyed off same extension. The new patient from network is the result of the search parameter that returns ‘network’ which is populated but not necessarily providing info that is being sought.
• Ming noted that the context of location helps infer if it’s a new patient or new patient in a network (insurance coverage aspect).
• Rick clarified concern as tying back to list of networks that exist within this extension; without use of both search parameters nothing about the value of accepting new patients is returned. How does one know if new patients are being accepted or not?
• Ming shared the cardinality of both stating network is optional. So if you want to search new patient flag is required; Interplay with hierarchy relationship.  
• Rick posted: https://hl7.org/fhir/us/ndh/2023Sep/ValueSet-AcceptingPatientsVS.html 
• Rick talked through a few aspects to help find path forward offering: If the idea is I can pass the network one used in conjunction with accepting new patients, then thinking we’d express that expectation and filter the results; he would remove search parameter for network and search on 4 values because you’d have the networks already.
• Bob noted concern as it would eliminate the opportunity to search for doctor and plan. 
• Tanya indicated concern with Bob’s scenario of searching for new primary care doctor in a given plan that query should be using the payers (issuers) directory. Otherwise, this could add burden.
• Jack said that operationally it does then impact all providers because once people start using and do not get reliable info returned they will stop using it. 
• Tanya stated that the directory should not have insurance networks in initial NDH. 
• Bob noted that the point was to make it available through ND and no one said it should not be managed by payers.
• Tanya offered the issuer/payer is the source of the data on who is in or out of network.
• Bob - agreed / confirmed the primary source indicating network is optional, they don’t have to say if they are accepting new patients by network. They are permitting it to be added, but not required. Accepting new patients is required, not the network aspect. He spoke to 4 values being used which were provided by the payer community. Goal is to be flexible, not comprehensibly restrictive.
• Tanya noted the query should come from payer/issuer in the first place, not ND. 
• Bob shared the initial intent of use if for government health plans. As for commercial use, not aware of any decision if or when commercial will be in the directory.
• Tanya thought she heard CMS OBRHI not putting networks into NDH at a HIMSS presentation this year. 
• Bob noted that if you look at CMS ND RFI and related presentations it shows inclusion of network info. 
• Tanya thought focus was on provider side.
• Bob clarified intent is ND, not a particular focus – rather broader – anyone involved in provision/delivery of healthcare/ - excludes patients and their unlicensed caregivers (mom/dad/child in contrast to the social service providers). Need to have lots of ability and someone else needs to decide how to leverage ND IG. 
• Bob clarified in exchange standard directory must support – but you aren’t required to supply the data as a data submitter.
• Will complete ticket on next call and continue working Search parameters trackers/tickets.