Page History

2023-09-18 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 – this week – 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

THO Decision Tree Process for NDH

Bob presented a decision tree for processing code system and value set terminology (THO) tickets which is alignment with recent discussions, including feedback from Grahame Grieve. By the end of fall we need to have processed each of the THO tickets having decided whether to keep as a local code system/value set and related reasoning or to have code set/value system be "owned"/managed by THO. 

Finished up ticket 41771 41772

• Rick requested an refresher on why a practitioner may have a direct address that has nothing to do with an organization and to include consideration of the Thursday WGM discussion on the practitioner resource. Rick noted there seem to be ways to identify those end-users that don’t necessarily a definitive role by indicating which trust network they belong to and to jump from their over to the endpoint. 
• Bob indicated one could make that argument for any endpoint we have - service, insurance plan, network. The intent was to represent endpoint based on the resource that is most critical to what you are interested in, rather than go through a hierarchy (like org not orgaffiliation). Trust networks are part of the endpoint resource and not understanding why we need another structure to represent trust framework.  
• Rick clarified it is not about adding another structure, rather its about providing an easier way to use the structures to navigate the trust framework and identify it rather than a code set to enumerate the relationship. 
• Bob perceives this discussion as forcing structure that doesn't exist. 
• Ming acknowledged Rick's question as pulling into the view the issue of how to navigate relationships from the directory point of view when the provider attests into the National Directory (ND and may or may not have the endpoint information. 
• Rick sees it differently in that the practitioner ma be stand alone and not part of a trust network. He questioned what use case we are trying to address because leaving it at practitioner role is where they'll go find the health care services. 
• Bob indicated that would be endpoint in context of a relationship with the other organization, services, location, network. Not a standalone, you wouldn't have that in a personal Direct address. 
• Rick noted that if you have a Direct address, then there is a trust framework and not trying to reach them pointedly. 
• Bob noted that if you have a Direct address under a HISP (health information service provider) not sure what practitioner role adds or how it helps. 

• Rick shared the idea is beyond not adding to practitioner – it’s a construct perspective – the practitioner is an individual and when they start to function as a practitioner we go to the role to figure out the mapping on what they offer, how, when for services.

• Bob provided a concierge doctor example that brings no overheads like that and would be inappropriate to create role that has nothing to do with the individual. He called the question asking others on the call to offer their input.

• Joe Lamy – echoes Rick sentiments because the comment came from modeling he is suggested. Simply trying to say – as shown on ticket link - Modeling trust framework.

• Bob clarified it’s about an Direct address, not trust framework. You can have Direct address that doesn’t say anything beyond Direct conformance.

• Joe acknowledged the point clarifying the link ticket is to explain how trust framework modeling in 2 ways: extension on endpoint or exposing relationship between orgs.

• Bob stated modeled endpoint a different way and asked for input beyond Aegis representatives to which there was none. 

• Images shown during the discussion: 

Ticket 42241: 

• Recommended by THO, Ming added comment about code system that doesn’t exist. 42277 is another/related ticket. 
• Bob – the link exists. But the code system is retired.
• Ming – has 42657 – it is the correct code system we should use.

• Ming commented that this one makes sense and the other two tickets do not so let's go with this one. Correct code system and we used value from code system. Ming showed: 

• Bob asked if there as a current value set in THO, Ming said NO. Bob then asked if we needed the same value set in PlanNet / both using MIMETYPE for non-FHIR use
• Ming navigated the IG (images below) resulting in confirming the binding is extensible which lead into discussion around base referring to FHIR and extensions for Non-FHIR. If we don't want to use the THO value set, then we have to create our own. 
• Bob asked for background on how this got created to which Ming indicated it was effort by Lisa Nelson/Direct Trust. Bob also asked if we've accounted for IHE to which Ming said 'yes' that promoted back and forth on needing neutral transport reason to support xml, json. Further consideration was given to PlanNET IG usage that would mean (per the decision tree logic) that we move value set to THO. PlanNet already has non-FHIR endpoint and is expected to be updated once ND is updated. Ming asked if we could point to the value set version going to THO as PlanNet is a subset of ND which could effectively keep it as a local value set. 
• Bob asked for feedback, none offered. Next step is for Ming to use the discussion/input and bring back the ticket on Thursday's call for completion.  

Ticket 41913:

• Ming shared that the underlying issue is that an error was made by including in the capability statement as reverse include which now needs to be corrected/removed.