Skip to end of metadata
Go to start of metadata
HL7 TSC FMG Meeting Minutes 

(voice and screen)

Date: 2020-08-19
Time: 4:00 PM U.S. Eastern
Chair:Note taker(s): Anne W.
Quorum = chair + 4yes/no
Co chairsxDavid Hay
Lloyd McKenzie
Wayne Kubick, CTO
XHans Buitendijk
Brian Postlethwaite
Paul Knapp
AbdulMalik Shakir
xJosh MandelxJohn MoehrkexBrian Pech
xGrahame Grieve

Brian Phinney



  • Community Feedback on FHIR R4B options
    • Grahame looking at build to separate content and make it easier to manage different resources in distinct branches. Mark Iantorno working on build pipeline infrastructure for CI, and the main FHIR repo would slim down to source/temp/publish directories.
    • What would change about day to day process? Today, master definitions are in spreadsheets, edited in excel, on master branch. This doesn't merge well. So Grahame's plan is to flip this around: use spreadsheets to generate resources in a textual format (and regenerate spreadsheet from that until they converge). The logical workflow would be: I'm working on an intermediate release, or a main release, and create a branch based on that. 
    • How would these changes impact our release plan? These changes would make it possible for us to extract r4 definitions as-of r4 publication time and create an r4b branch from those definitions, and current infrastructure. We'd maintain an r4b and r5 "current build" as well as snapshots, releases, etc. HAPI reference implementation would support both branches.
    • Where would the "infrastructure" (i.e., build tool) live? In a separate repository, with the build tool creating a "main build" jar in a github release, as well as core resources like infrastructure templates, supporting images, html framework, etc. So then would download the jar, jar downloads the resources release, and then you run it a local checkout of r4b or r5 or whatever.
    • What about narrative changes outside of resource definitions; how will these be managed or tracked? Careful diffs and merges.