Skip to end of metadata
Go to start of metadata


See  FHIR-I Attendance201909.pdf

Agenda for WGM

See FHIR WGM Agendas 2019-09

Monday Q3 (main)


Current CapabilityStatement aligns with Swagger/OpenAPI. 

CapabilityStatement2 will add some more stuff, but Grahame didn't add it yet, so decided to table the discussion for later. 

Tracker Items

GF 23859: Create a new Bundle type for "subscription notification"

  • Using a Bundle for subscription notifications can allow for notifications of DELETE, etc. However, hard to decide what type to use (history is closest). Need to exchange info about the request and response. But the constraints on Bundle for certain types are problematic. Discussion about whether to create a new Bundle type, or to relax some constraints for history bundles. Decided that sticking with a history bundle is the better approach. Agreed to relax the constraint requiring a request or response to support id only subscriptions. 
  • Persuasive with mod
  • Motion: Josh Mandel/MIchael Donnelly: 15-0-9
  • Note from Tuesday Q3: disposition was not saved, will need to repopulate tracker with stuff above. 

GF 21286: Email delivery options should be more specific

Monday Q3 (questionnaire)

  • Anita and team gave a presentation on the Shared IRB project (See attached)
    • Discussed when it was appropriate/necessary to extract QuestionnaireResponse content into other resources vs. not
  • Lloyd talked about timeline for publication.  We currently have a little over 30 issues remaining to resolve
    • Will start saying "no" to new requirements unless we deem it to be essential to get those changes applied in the next SDC release
    • Realistically, we're looking at publishing at the end of October or some time in November
  • Block votes
    • Motion from Clem, second by Ed to approve both the SDC and PRO block votes (after pulling issues requested by Anita).  Approved 10-0-2
  • Lloyd gave a report on the connectathon
    • Small participation this time
    • Had one new participant from Netherlands.  Hadn't worked w/ SDC before.  He came and was able to get his existing system successfully spitting out SDC-conformant content in one day
    • Have been told to expect significantly more Questionnaire participants in Sydney
    • Had a good demonstration from Paul Lynch on the work he'd done with NLM.  Also had presentation from Brian Postlethwaite on doing Questionnaire population using SDC
    • Spent a session getting requirements for the new "workflow" section in SDC (information on Zulip)
  • Meeting time for Sydney
    • Several participants will be in Sydney.
    • Lloyd will start a Zulip discussion to find a call time that works for Sydney and will book it in the next couple of weeks

Monday Q4

Minutes provided by Riki Merrick

  • Workflow topics
    • Example scenario resource and tooling for example building (draft in R4) – ADD LINK:
      • Includes
        • the scenario itself (clinical use case)
        • Author, context and actors
        • Pre and post conditions
      • Creates diagram for actors and the exchange operations = sequence diagram
      • Showing off FHIR toolkit to pull up the scenario resource:
        • Building the content for an exampleScenario resource
      • Give us feedback on how this works to show workflow examples
        • Think this could be useful, especially the sequence diagram to organize more than 2 actors?
          • Yes
          • Also supports if, then scenario branches
        • Use of this resource for IG development and core?
          • Yes
          • In Rx WG want to string several examples together into a long workflow – need to create that overarching scenario that can reference
          • Where would workflow examples live?
            • Not yet figured out exactly
          • Can we add in the operations into the sequence diagram examples?
            • Not yet done, but good idea
          • Did you look at CMN or ???
            • We define an instance in these scenarios
          • Draft pattern for healthcare product?
            • Will migrate from Jose to the current build soon – ADD LINK here when done
            • Compared attributes among:
              • substance
              • Biologically derived product
              • Specimen??
              • Medication
              • Device
            • Some are universal like code, others only apply to devices, like model number
            • Group attributes that are instance identifying vs those that describe a kind
            • Question about definition of manufacturer?
              • This should be open for adjustment – assume is at organization level
            • What about item resource that was in STU3 – how do we do inventory of generic items that could be either or both at the same time, depending on the jurisdiction it is used in?
              • That is not part of workflow pattern
              • Was decision of the WG we think – may need to do some research of what happened
              • We try hard to not have more than 1 way of representing the same thing
            • Will post to implementers chat on zulip as well as send notice to co-chairs once this has been moved to the current build
          • Pattern difference between resource definitions
            • Looked at 4 resources so far
            • Use the pattern when you design new resource AFTER you have built a draft based on your use case requirements
          • FHIR editor quality
            • GitHub houses the resources
            • Build is automatic AFTER check in
            • OFTEN there is a long list of warnings and errors that comes out
              • Warnings should have FMM0
              • Information messages have FMM3
              • Also some warnings really should be errors, which prevent publication
              • We are in between releases and looking to get these warnings cleaned up
              • Will freeze the current build for those IGs that are going to ballot, so they have something to reference
              • Proposed clean up timeframe November till January – will include list of warnings that will be updated to errors
              • If not fixed after that timeframe, then resource no longer in the current build UNLESS warnings gets fixed
              • 2 issues hard to resolve:
                • RIM mapping is hard to complete (make that informational?)
                • Copyright statements in value sets for HL7 FHIR defined value sets
              • For IGs that are being built against R5 = current build – those will be part of the snapshot
                • not expected in this cycle, but may be concurrent with first R5 ballot in May2020
                • Folks may do this, because they want to use new resources, like subscription
              • Pattern Index in current build – ADD LINK
                • Has a tab even!
                • Interface patterns
                  • patterns of referencing participant
                • Combination patterns
                  • Performer excludes group and location, which makes sense
                  • CommunicationRequest does not include location, but Communication does – why?
                  • PatientCare requested endpoint to be supported in the participant pattern
                  • Communication referenced the pattern name of participant – war rolled back to the actual resources during connectathon (DID I GET THIS RIGHT?)
                • Same session going forward – maybe skip Sydney – will see, but will provide updates for sure then
                • Workflow calls are Mondays 2 PM EDT
                • Adjourned 5:06 PM EDT

Tuesday Q3

Tracker Items

GF 23729: Allow _elements to support dotted paths.

  • Related to 22934, which restricts _elements to root level elements. 
  • Agreed that this is a common use case, is simpler than GraphQL, is easier for server developers, and thus should be supported. 
  • Discussed whether the current guidance around mandatory and modifier elements should be changed. Decided to create a new tracker item for that discussion since it would require community input. 
  • Rick Geimer moved to reopen 22934 since it could conflict (James Agnew 2nd): 7-0-4. Will note that it is superseded by 23729. 
  • Persuasive
  • Motion: Rick Geimer/Yunwei Wang: 9-0-0

GF 23721: NamingSystem is stated to have a .url property

Tuesday Q4

Mark Kramer discussion on FHIR Shorthand (FSH)

  • FSH is a domain specific language to define profiles, extensions, etc. 
  • Combined with a compiler to produce conformance resources that can be consumed by the IG publisher
  • Works well with source control, diffs, etc. compared to StructureDefinition resources or spreadsheets. 
  • Could also generate mind maps, data dictionaries, etc. for the profiles
  • Can also be used to create instances
  • Zulip discussion here:
  • MITRE will likely bring this to FHIR-I as a PSS, at least for experimentation if not standardization yet. 

Tracker Items

GF 22649: Add a note about decimal precision to the safety page

GF 21650: Operation to manage big List and Group resources

  • Lots of discussion about what parts of a resource would qualify. 
  • Would this be specific operations on specific resources (i.e. only on List.entry, StructureDefinition.differential and snapshot, etc.). 
  • Clear need for paging for read, less clear for write and update since we have PATCH. 
  • Would like to use the same paging mechanism for bundles
  • Will likely try out in a future Connectathon. 
  • Need a way to make it very clear that the recipient has not received the whole resource. 
  • Agreed to add a $getpage operation for List.entry and Group.member that will then be tested at the Connectathon. James Agnew will create the draft. 
  • Persuasive
  • Motion: MIchael Donnelley/Josh Mandel: 12-0-1

Wednesday Q1


Wednesday Q2

Tracker Items

GF 22770 - Support "create as search" concept

  • (-) philosophically impure
  • (-) may be differences between the supplied data, or imperfect matches
  • (-) may lose desired changes (... but ignoring some data on POST is generally allowed)
  • (+) a naive client can "just work"

    Current behavior in epic: when a client tries to POST a patient that matches an existing record: acts like it was created (201)

  • Other kinds of special handling for create include for patient-entered data, which might need to be reviewed by a clinician first.

  • Clients might create duplicate records, but the server may have better / more accurate / more consistent logic for matching.

  • Functionally, it's convenient for servers/clients to implement create as "create or get"

  • Cerner has somewhat similar behavior not for Patient, but for Allergies (return a 201 on POST, with a location header pointing to a pre-existing AllergyIntolerance record).

  • Add language to indicating that a server MAY determine that `create` request matches an existing record with high confidence, and MAY return a 201
  • Persuasive: Danielle Friend/Dennis Patterson: 9-0-1

GF 23819 - create a set of common timezones

  • This item asks for a standard valueset of timezones to be used in the existing "tz" extensions.
  • Would be used to mark FHIR data with the timezone a human would prefer to interpret it in.
  • Currently there is a valueset page in the spec, but it has no expansion since it references a non-computable valueset.
  • We have two options: deal with this as we did with languages, which is create a valueset with the most common ones, and leave the binding open enough for others to be used.  Or generate a set that contains all of them
  • We discover that it is not clear which exact timezone "literals" can be used on most platforms (python, java, dotnet, javascript libs), e.g. do these timezones look like "America/New York" or "Afghanistan Central Time". 
  • Ewout and Josh will investigate.

Wednesday Q4

Michael Donnelly: Meeting in M106/M107, Wednesday, September 18, 2019
chair: @Rick Geimer 
scribe: Michael Donnelly

Michael Donnelly: PSS for FHIR Shorthand

Michael Donnelly: @Mark Kramer presenting

Michael Donnelly: FHIR Shorthand is a way to author artifacts for IGs

Michael Donnelly: Objective is to support complex profile development projects

Michael Donnelly: As part of the project, you iterate through many changes

Michael Donnelly: Refactoring after each change is time consuming; per Mark, up to 90%

Michael Donnelly: FHIR Shorthand makes it faster and easier to make these incremental changes

Michael Donnelly: Shorthand, text-based language, so it's easy to diff and merge (vs. spreadsheets)

Michael Donnelly: Also easier than StructureDefinition; ratio of meaningful lines is 200:1

Michael Donnelly: Benefits:

  • agile
  • easy to understand
  • expresses intent of author

Michael Donnelly: MITRE has used this for seven ballots so far

Michael Donnelly: They want to contribute it to the FHIR community

Michael Donnelly: (acronyms, bacronyms, and puns galore)

Michael Donnelly: FHIR Shorthand plays a similar role to CQL

Michael Donnelly: @Mark Kramer explained technical details; see for his Word doc

Michael Donnelly: The biggest thing is getting slices right, so they have abbreviated syntax for that

Michael Donnelly: They've worked with Rick and @Grahame Grieve and @Ewout Kramer on the syntax

Michael Donnelly: They considered using yaml but didn't see a benefit over editing the json directly. They tried out doing US Core Patient in yaml, and it was ~5x the size of FHIR Shorthand.

Michael Donnelly: Mark put together a PSS:

Michael Donnelly: The proposal does not call for migration into this format; people can still use StructureDefinition if they prefer.

Michael Donnelly: Rick: does the proposal include going from StructureDefinition to FHIR Shorthand?
Mark: not yet, but it should; he'll add it

Michael Donnelly: Sponsored by FHIR-I, facilitated by MITRE and Lantana

Michael Donnelly: (Discussion about whether to include "no pun intended" following an intended pun)

Michael Donnelly: Connectathon testing by May 2020 with concurrent comment-only ballot

Michael Donnelly: Rick: Will MITRE assert any copyright over FHIR Shorthand?
Mark: No, I don't believe so.

Michael Donnelly: Rick: there's a push to use FHIR StructureDefinitions for CDA; consider expanding scope to that in the future.

Michael Donnelly: Motion for FHIR-I to sponsor this PSS: @Mark Kramer /Dan Horbatt: 8-0-1

Michael Donnelly: OLD TRACKER TIME

Fragment (SUBSETTED) profile

Michael Donnelly: This (and other trackers @Ewout Kramer wants to discuss) relate to @Chris Grenz's advanced use of StructureDefinition

Michael Donnelly: When originally submitted, FHIR-I didn't know what to do with these.

Thursday Q2

GF 21622: Update eld-11 for CDA coded datatypes like CD, CE, CV, CO, CS

GF 21232: Reusability boundaries for EventDefinition, TriggerDefinition are unclear

GF 22694: Add the ability to list supported language (and locales) in the capabilityStatement

GF 22694: Add the ability to list supported language (and locales) in the capabilityStatement

GF 16519: Bundle -- move signatures to Meta

GF 17278: add element to indicate the source file

GF 20641: Support for :missing combinations

GF 23781: make reverse reference easier to represent

  • GraphDefinition currently has support for reverse references, but it is ugly
  • Won't make the decision without Grahame in the room, but agree that this needs revisiting, maybe after the Da Vinci alerts stuff that will likely use GraphDefinition with messaging

GF 23819: create a set of common timezones

Thursday Q3

GF 23819: create a set of common timezones

GF 18441: Is normalization to single-space problematic? - N-Infra #129

  • This already has a disposition and vote, but Vassil believes it was resolved incorrectly. 
  • The change would conflict with XML digital signatures and the required cannonicalization algorithm for it
  • Motion to reopen: Vassil Peytchev/Rick Geimer 10-0-0)
  • Will not change the algorithm, but will instead add a comment about the security concern. Lloyd considers this to address his comment (it was submitted by Ron on his behalf).
  • Persuasive
    • Vassil Peytchev/Rick Geimer: 10-0-0

GF 24649: Add[x]

GF 19821: List.type - need a type element to differentiate various purposes of Lists

  • No labels