Skip to end of metadata
Go to start of metadata
US Realm Steering Committee Call Agenda/Minutes 


Date: 2020-09-22
Time: 12 PM Eastern
Co-ChairsSteve/BrettNote taker(s)Anne
Quorum: Chair +7


xSteve Posnak (Chair)xIoana Singureanu (Infrastructure SD)
xBrett Marquard (Cochair)xSandy Stuart (Organizational Support SD)

Ed Hammond (Chair Emeritus)xDanielle Friend (Implementer)
xWayne Kubick (HL7 CTO)xJenni Syed (Implementer)
xAustin Kreisler (TSC Chair)xChristol Green (Payer)

Lorraine Constable (ARB)
Laura Conn (Public Health)

Tony Julian (ARB)xChris Shawn (Security/Privacy)
xHans Buitendijk (Administrative SD)xRob McClure (Vocabulary)
xBryn Rhodes (Clinical SD)xRon Parker, International Council Representative

xCatherine Hosage NormanxFran Pivonka
xCatherine HoangxFloyd Eisenberg
xKeith CarlsonxNathan Bunker
xIsaac VetterxYunwei Wang
xJohn BenderxAlex Kontur
xMatt RahnxBrittany Brown
xRob SnelickxChristopher Schaut
xNancy OrvisxRick Geimer
xEmma JonesxSean Muir
xDave ShaverxRyan Argentieri
xAnastasia PerchemxDidi Davis
xAvinash ShanbhagxMaria Michaels
xBrian DouthitxJoseph Bormel
xChristopher SchautxDavid deRoode
xKathy PickeringxKeith Carlson



  • Agenda review

Review Items:

Discussion topics:

  • USCDI Release Cycle
  • Growth Policy for US Core
  • Must support enhancement/extension


Discussion topics:

  • USCDI Release Cycle
    • Reviewed slide deck on release cycle.
    • Timing process was developed to fit in to the ONC's Standards Version Advancement Process. Draft in January, initial publication for testing in July, final publication/approval in December.
    • Where does US core fit in? Current proposal is to do a US FHIR Core ballot in 2021, then an update ballot each January starting in 2022. US FHIR Core would be a year behind USCDI.
    • Ioana suggests outlining expectations for projects based on this schedule. How do we deprecate older versions, what are the direct implications on projects. Need to know what version to use.
    • Rob: Need to think about terminology in the context of versioning. Are we going to test conformance around value sets that can change based on yearly updates? US Core is a trailing artifact in regards to USCDI; US Core should think about if there is value in pre-adopting things. Steve: Part of the USCDI process is that there is evidence of implementation and use. On the regulatory side, we're adopting things that people have experience with. Can inform each other on both sides.
    • Floyd: There are some things that are basically errata in US Core. Even though they're identified in USCDI they should be corrected. Need to be careful that we include necessary things instead of waiting for USCDI.
    • Emma: How does the validation fit into this timeline? Brett: When we release the IG, the FHIR validator can validate against it. Steve discusses how that works in the different editions. Rob asks how Inferno handles terminology updates. Will be discussed offline. inferno needs to rely on US Core or VSAC. Yunwei describes how Inferno is updated. Rob: The value sets might change US Core references - would be good to have a place where people can test against changes that may not be required by regulation but could be adopted or assessed. 
    • Ioana: If you look back you have a choice of versions. Going forward, you have a choice that says this version or later - is that true?
    • Danielle asks about balloting in Sep 2021 instead of Jan 2022? Brett states it would overlap with SVAP if we did. Maybe we need to be clear that continuous draft versions will be published. Ioana: We could start profiling work as soon as we have draft requirements in January.  Brett cautions against creating parallel tracks. Should be done on a case by case basis. Brett: Balloting is not the only way we get feedback - if we have enough feedback to go to ballot in September, we should - but that timeline is likely to be too fast. 
      • MOTION to endorse the proposed release cycle for US Core: Ioana/Rob
      • VOTE: All in favor
      • This will go to Cross Group Projects this week for approval as well.
  • US Realm Profiles vs. US Core
    • Reviewed "Story of US Core" slides
    • Began with US Core Profiles with a subset designated Must Support
    • Then we had overlapping US Core and US Realm profiles with a subset of Must Support
    • Then, included within Must Support, data elements required by regulation were added (Must Support elements)
    • Reviewed scenarios for new profiles
    • If an IG developer is using the FHIR Core profiles as is, then no additional rules apply
    • If an IG developer needs to add on to an existing US FHIR Core Profile, they need to check the registry for existing profiles, constraints, extensions, etc. that may overlap and add a new entry
    • If an IG developer needs to change an existing core profile, they must present deviation to CGP if it is in the rules set - if not, they must present to USRSC
    • If an IG developer needs to do less than an existing US Core profile, they should log a tracker and present deviation to CGP to receive approval
    • Ioana: What about replacing a set of requirements with a new set of requirements? Need to account for that scenario as well. Some things have to change for technical reasons and some for business reasons.
    • Floyd: If someone has to add an extension to US Core or feels that they have to loosen the requirements, that should require a tracker item so CGP knows about it.
    • Ioana: Sometimes in trying to reuse a profile, you run into the issue that it might be too tightly constrained. Creating another profile that can serve as the parent is one way to handle it. We need to develop a number of strategies and decide how we maintain relationships between profiles. 
  • Growth Policy for US Core
    • Rob: Alignment between US Core and USCDI - what things are in one place and not the other
  • Must support enhancement/extension
    • Hans: Attributes marked as Must Support have variations on what that means. Working on improved tooling in the next version to more specifically document it. FMG, FHIR-I, MnM, CPG, etc. are all working on it. Overall sense seems to be that Must Support is not supposed to automatically propogate down. If you have a list of choices they should all be allowed but not required; should be driven by the individual system.
    • Rob: Keep in mind that Must Support has an impact on expansions around the contents of the value set based on the strength of the binding. Has very specific impact. Need to make sure we all agree on what the impacts are.
    • Ioana: Is there a way in which we can look separately at what the APIs are telling us around what data we should expect? We have started to draft an extension stating what data has to be always present/what values can't be omitted. Gives more nuance around what data is supposed to be used and correlates around the terminology bindings. 
  • Adjourned at 1:34 pm Eastern

1 Comment

  1. Team: perhaps we can write some guidance documents on behalf of USRC:  what version of FHIR Core (e.g. 4.0.1) or US Core (HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1 or  FHIR US Core Implementation Guide (IG) STU 3.1.0 as Identified by the Inferno test framework.