2022-10-13 Public Health Work Group Call Minutes

Welcome, agenda review, meeting minute approval 

• Pick a Jan WGM time for FHIR-I
  • Mon Q4, Tue Q2, Wed Q3, Thur Q1 or Fri Q2

• last week's minutes approved as posted; no concerns or corrections raised
• WG's preference for meeting with FHIR-I is earlier in the week
  • Wed. Q3 is the standing joint "Registries" session with CIC
  • will request Mon. Q4 or Tues. Q2
• Erin reminded the WG that Craig had forwarded a notice from HQ / Lynn about NIBs for the Jan. ballot cycle
  • due to 1) a shortened submission window due to waiting until after the extended Sept. balloting period, and 2) access issues due to the on-going migration of HL7's Association Management System, Lynn has "created a simple empty form at https://confluence.hl7.org/display/HL7/2023JAN+NIB+form+template that can be used to submit the NIB information.  Please make a copy of the page to your work group’s Confluence space, fill it in, and send me the page link once completed. I can create the NIB records on the back end without interfering with the AMS migration."

• during the Thurs. Q1 session with FHIR-I at the Sept. WGM, there was some discussion around how to standardize access / security / permissions for Public Health systems connecting to EHR APIs
• there was some follow-up discussion during the 9/28 WG call, where it was noted that the FAST (FHIR At Scale Taskforce) Accelerator may be doing some work in this area, so we invited Brett from FAST to present about that work
• HL7 FAST_HL7 Public Health WG Update_101322_from_brett.pptx
• Initial use cases for FAST were payer / provider exchange
• goal is to align disparate organizations to implement FHIR similarly so that it can be scaled quickly
• active FAST work:
  • national directory exchange
  • endpoint query
  • attestation and validaiton
  • security
  • digital identify and patient matching
  • hybrid / intermediary exchange
• for security, OAuth works well enough for the client app to EHR API use case, but not as well for B2B exchange
  • there could be additional confidentiality considerations for B2B exchange
  • can result in "credential sprawl" for systems (e.g., Public Health) that need to connect to a lot of FHIR servers
• UDAP (Unified Data Access Profiles) Certifications and Endorsements – delegates trust to a 3rd party (e.g., CARIN Alliance for consumer-based apps)
  • Systems can be authorized once then trusted by multiple other systems
• Security IG STU1 published (http://hl7.org/fhir/us/udap-security/STU1/)
  • STU2 in the works

• FMG feedback for Reference Architecture IG publication request (which was approved by the WG on 9/1) – cannot be published as-is; changes are required
  • https://build.fhir.org/ig/HL7/fhir-medmorph/qa.html
  • dependency checks – FMG questionsed why references to US Core and Bulk Data are to older versions of those IGs
    • MedMorph wanted to align with versions named in regulation
  • bigger issue is with the Subscriptions Backport IG
    • MedMorph RA IG referenced a balloted version that was built on R4 (4.0.1)
    • published version of Subscriptions Backport IG is built on R4B (4.3.0), however
    • MedMorph is built on R4 (4.0.1), so this is a version incompatibility
    • a future Subscriptions Backport STU may also include R4 (4.0.1) support, but that would be months out
    • FMG recommends to relax some constraints, update treatment of subscriptions in MedMorph RA IG
• working on some new updates to RA IG – will create new Jira ticket for changes and bring back to the WG for approval (next week)
• Austin asked if any of the new changes will revert other changes previously made due to ballot comments
• Dragon indicated that there were some comments about clarifying subscriptions content, but not about specific content changes
• Austin recommends notifying the ballot pool regardless since the changes being made now are substantive
  • MedMorph team will compose that notification and provide it to the co-chairs to send out via the Ballot Desktop
• After the Jira ticket is approved and changes applied, will send out the final revised content for the WG to review for a week before re-requesting publication

• VRDR FHIR IG STU1 is expiring 10/27, but STU2 has already been published – do we need to withdraw / retire STU1?
• yes; though simpler to wait until after expiration (but right after expiration so the WG doesn't get dinged for health metrics)
• there is no longer a difference between "withdrawn" and "retired" – everything stays on the standards grid now
  • withdrawal form still includes an option, however, which can be confusing – HQ will correct this once the withdrawal form is moved to Jira