Skip to end of metadata
Go to start of metadata

FHIR-I WGM Agenda 2020-09

Attendance: FHIR-I Attendance_ bit.ly_fhiri - Attendance.pdf

Monday Q4 (4-6 PM ET)

Joint Session with CG and II

Chair (Lloyd McKenzie)

Scribe (Yunwei Wang)

FHIR-I Release Scheduling

  • R4B
    • Happy Path: Ballot Jan-2021, publish Q2-2021
    • Not happy Path May-2021
  • R5
    • Comment Ballot (scope and readiness)  May-2021
    • Ballot (normative/stu) Sept-2021
    • Another normative ballot Nov/Dec-2021
    • Publish: Q1/Q2-2022

Any plan for R4B/R5

  • CG
    • Trying to get examples and extensions from OO
    • Will pull R5 and test
  • II
    • Nothing on the critical path

Any resource ready for normative or maturity update for R5?

  • CG: Sequence
    • Not normative candidate for R5
    • May bump maturity level up from M2 to M3
  • II:
    • ImagingStudy:
      • Could be normative candidate but still in bubble

Implementation Guide (new IG, new release)

  • CG
    • Another round of ballot for STU2 release Genomic Reporting IG
  • II
    • Modeling Radiology workflow
      • may result in an IG
    • extracting radiology reporting from DICOM to FHIR
      • may result in an IG
    • Both in early stage. There is no time line
      • Not in January,

Recent or upcoming FHIR changes

  • FMG is working on clarify MustSupport
    • Will provide more direction and tooling for IG be more specific about what MustSupport is
  • FHIR is using UTG now
    • Any terminology update will go through UTG process


  • How to deal with resource derived from multiple IGs
    • there is no mechanism to support multiple inheritance (multiple parents) for profile
    • You have to pick one as base profile and add the other as invariant.
    • Will address the compare feature in the ig publisher/validator
  • Process for requesting new resources
  • Guidance for moving away from spreadsheet
    • Spreadsheet is still available
    • Some projects are moving to using FSH
    • Some uses JSON StructureDefinition directly
    • There is no timeline to disable Excel spreadsheet at this time.
    • There is tooling to convert StructureDefinition to FSH (in early stage)
  • Can Forge be used?
    • For daily job: HL7 has fixed number of license available
    • It is free for learning or training

JSON comments in JSON 5

  • Support JSON comments in IG publisher
  • No normative JSON syntax nor commitment
  • Start zulip discussion

R4B vs R5

  • R4B
    • Medication definition
    • Evidence-based-medicine
  • If a resource does not use any of these resources above, resource can be claimed to conformed to R4B if it is conformed to R4
  • The desire is to make R4B tiny and out of door fast.
    • Regulator in US and EU are eager to see R5 equivalent medication definition resources
  • R4B is not the official name
  • Final naming and version number will be decided after more discussion

FHIR-27761 - Getting issue details... STATUS

  • The problem is OeprationDefinition is normative
  • Possible solution
    • Create a profile
    • add a not-required element
    • create a new resource
  • Another issue is the output parameter
    • since parameter name has to be unique
    • you cannot have a bundle for type operation and valueset (eg) for instance operation
  • Add parameter.scope 0..* with code type
  • Missing means the same as current R4 usage: same as OperationDefinition scope unless specified
  • Will also update existing OperationDefinition
  • Josh Mandel/Gina Canessa: 26-0-2

Monday Q5 (6-8 PM ET)

Chair (Lloyd McKenzie)

Scribe (Yunwei Wang)

CapabilityStatement (presented by Grahame Grieve)

  • Many backbone elements are TU
  • Grahame created CapabilityStatement2 for exploring options (as draft)
  • (0..*)
    • code/value pair
    • example:
    • Feature query:
      • GET base/metadata?feature=resource:Codesystem
    • Feature Negotiation:
      • Use in HTTP header for featre assertion
      • x-Mandatory-Feature: rest:server.resource:AdverseEvent.readHistory;true
    • Challenge:
      • Is this a good syntax?
      • could feature have more than one value?
    • Reduced the designed size of CS
      • Full "expanded" CS with all features is larger than regular CS w/o features
  • When goes /metadata, which resource will be returned?
    • the intent is there is only one
    • or can use metadata?mode=... (will create a temporary mode to distinguish CS and CS2)
  • How to interpret 501
    • No such feature Or feature is not implemented?
    • No such feature is 404
  • feature vs extensions in CS
    • Not sure the boundary
    • extension is to amend system's existing behavior
  • value is code?
    • back and forth several times but now settled on code.
    • could be expand to other data type if required
  • will existing feature be specified twice
    • existing feature flag will be removed
  • reduce size
    • by default, there is no feature returned.
  • tooling need
    • IG publisher, graphic rendering, validator
    • connectathon in January
  • current syntax vs canonical url
    • the focus is to make the logic correct.
    • syntax is not the focus
  • Connectathon proposal
    • using multiple CS as example
    • converter between featured-CS and regular CS
    • some people/companies express interests to participate
  • How much does it buy us for new client
    • clarify the http code in case not support

Tuesday Q4 (4-5:30 PM ET)

Chair (Lloyd McKenzie)

Scribe (Rick Geimer)

  • Lloyd reviewed general messaging from FMG
    • Ballot plans for FHIR R5 and R4b. 
      • Current plan is to do an interim release (R4b)
        • Will be doing tooling changes (spreadsheets don't merge well in git, etc. ) R4b will be a test of that process
        • Everything not changed in R4b will be as it was in R4 technical correction
        • Timeline for R4b: ballot in Jan 2021 cycle, publication around Q2 2021. Dates could slip if funding for tooling not available or scope changes. 
        • Medication Definition resources and those for Evidence-Based Medicine definitely in scope for R4b and of interest to BR&R and Pharm WGs
      • R5
        • Timeline: for comment ballot in May 2021, Sept 2021 normative ballot, End of 2021 2nd normative ballot. Publish Q2 2022. Timeline also subject to change. 
        • Comment ballot for verifying readiness and community acceptance of Normative scope for R5
  • General discussion and questions
    • Lloyd will send details on the above to the announce stream on Zulip
    • Noted that US Core will likely ignore R4b
    • Smita Hastak noted that BR&R requested some reference changes in some CDS resources, and Peter Bomberg noted the same for Procedure and related resources, so this might impact scope. 
    • Lloyd said they need to send the full list of resources that need changes than cannot be done with workarounds (i.e. extensions). But we will try hard to avoid such changes. 
    • Lloyd said CodeableResource will not be in R4b, Grahame questioned this. It could be introduced, but only in changed resources (i.e. not introduced globally)
    • BR&R is requesting AdverseEvent to be added to scope as well. They need to provided good justification for why it needs to change and why workarounds are not possible. 
    • Scope could also include removing misleading examples
    • BR&R: No new normative resources likely for R5, but would like to push ResearchStudy and ResearchSubject up the maturity level. Seems the only change would be to the maturity level (i.e. the paperwork is wrong). FMG has some wiggle room there, so worth discussion changes to maturity level that don't change any resource content. 
    • Pharmacy: MedicationRequest will move to normative, Medication, MedicationDispense, MedicationUsage, and MedicationAdministration will move to 5 but not normative. Unclear about Medication (should probably be normative, but Pharmacy needs to discuss further). Immunization is currently maturity level 3, may need further discussion about advancing. ImmunizationEvaluation is 0 and should move to 1 if possible. 
    • Briefly discussed IGs coming from the Vulcan accelerator ( 
    • Will be various tooling changes next year (publishing changes, moving to Jira for balloting, etc.)
    • Discussed changes to CapabilityStatement (i.e. "feature" support). 
    • Discussed removing status from MedicationUsage. Noted that this will likely mean changing status to adherence and using different codes. 
    • Discussion about how compartments are defined (i.e. why reverse lookups were removed). Grahame noted there was a todo to revisit reverse lookups, etc., but has not happened yet. Requested Bas to submit a tracker item for reviewing compartment definitions. 

Tuesday Q5 (6-7:30 PM ET)

Chair (Lloyd McKenzie)

Scribe (Rick Geimer)

  • Future of GraphDefinition
    • Grahame provided an overview of the existing GraphDefinition functionality
    • Rene created a tutorial on GraphDefinition, and in doing so reviewed against various graphing languages (GraphML, etc.)
    • Open questions:
      • Can we restructure GraphDefinition around nodes and edges so that it is more recursive. 
      • Can we allow multiple start nodes (current GraphDefinition only allows a single entry point)
      • How much should we support rules about value consistency
    • Various questions and discussion on the use case for GraphDefinition 
    • Discussed the value of cannonical graph defs (i.e. us core defines one that conforming servers must support)
    • Servers that support GraphDefinition:,
    • Reviewed Keith Boone's post and using FluentQuery for FHIRPath:
    • Discussed adding parameters to a graph definition (i.e. pass in a LOINC code so you don't have to create separate graph defs for each code)
    • Grahame has enough feedback to propose something on Zulip once he has time to prepare it...specifically one day when he is bored (smile)
  • Takeaways from joint meeting with Conformance this morning
    • Discussed how to express that something must not be null (clear in V2 and V3, not so much in FHIR)
    • Discussed nuances of must-support
    • A lot more people familiar with V2 starting to use FHIR, how to explain/document the pain points better
    • Grahame demonstrated some of the rendering features possible if people create constraints properly

Wednesday Q5 (6-7:30 PM ET)

Chair (Lloyd McKenzie)

Scribe (Yunwei Wang)

Topic: Patterns

  • Patterns tab may be move to somewhere else
  • Two types of Patterns
    • Design Pattern (4)
    • Interface Pattern
  • What tooling improvement?
    • We can map, but
    • We don't have good mechanism to capture the rational when there is difference between pattern and Resource,
      • such as pattern has 0..* while resource has 1..1, what is the reason behind that
      • another example is an element in pattern is not presented in resource at all.
  • How we differentiate underlying Framework vs Pattern
    • Esp issue for (R5) code generation
    • To be discussed in a different topic
  • Where is Task pattern?
    • similar: Group, Location, Medication
    • Looks like the generator/publish is not work correctly
  • Is this page manually created or calculated
    • It is generated
  • Pattern and Resource implementation may not have the same type for element
  • Interface Pattern is a little bit tighter
    • More observational
    • Better for code generation
  • Pattern Candidate
    • Resource can be used in which Location with what Pattern
  • Point of Pattern work
    • better drive design consistency amount resources
    • consistency in CDA can be migrated into FHIR
  • How much benefit when the element types are difference among resources
    • There are some mapping work to do
    • Example: complex type Name to string
    • It is not that useful when involve details, such as how to map from string to Name
    • Maybe indicate the mapping is one directional trip
    • In principal, we cannot guaranty by directional but may be possible in some cases.
  • Procedure.subject cannot be RelatedPerson
    • Usecase for infant may require the related person to be subject
    • It is not for Pattern to address this
    • But Pattern does bring it to the surface
    • There is no semantic reasoning for why something is removed from pattern (compare to resource definition)
    • Lloyd suggest to clean the table before moving to R5 normative
    • Grahame: It would be great if someone could step up to bring this inconsistence between pattern and resource definition to community to address.
      • The problem is there are so many edge cases and how many time the community would like to spend to address those edge cases
    • Confusing about 80% rule with Pattern
      • What choice of an element should be (such as RelatedPerson for Procedure.subject), vs
      • If an element should be exist
      • Lloyd will bring the discussion to MM
  • Technical question from Ewout: 
    • Frameworks are embedded as inheritance in code generation
      • for example: ValueSet resource inherits from from DomainResource and implements CanonicalResource interface
      • class should not increase the cardinality defined in interface/pattern
      • CanonicalResource interface could be generated as classes
        • CanonicalResource is defined as interface for temporary reason. Should be change to class later.
      • FHIR-27839 for the disconnect on baseDefinition
      • Some other tiny discrepancy on using CanonicalResource
        • Grahame knows those and will fix in R5
    • Ewout suggest to use ... to append short description to base class's 

Thursday Q4 (4-5:30 PM ET)

Chair (Yunwei Wang)

Scribe (Rick Geimer)

  • Reviewed R4b/R5 plans
    • R4b
      • No changes anticipated from OO, PE, or CBCP for R4b
    • R5
      • CBCP: Wants to move the Consent resource to normative. Unsure how to discover where it is in use, have asked people and they have not come forward. Grahame is willing to follow up. There will be discussions in Security about a Permission resource, need to review to see are conflicts or overlaps with Consent. They mentioned that advance directives have been dropped from the scope of the Consent resource, and CBCP and PE will be having discussions about how to represent advance directives. 
      • PE: They own no resources at this point, so no changes
      • OO: Want to deprecate some observation-genetics profiles ( Grahame: discussed this in FMG, they will likely not remove them in R4b, but ok adding a note to readers pointing them to the genetics IG. OO looking at moving DiagnosticReport and Device to FMM5 by May, maybe advance Specimen as well. 
  • Patient Empowerment (PE) project proposal (presented by Debi Willis)
    • Patient Corrections IG to support a patient request for corrections to their chart. 
    • Want a Connectathon track in January 2021, ballot in May 2021. 
    • Gave an overview of the laws addressing this.
      • HIPAA 45 CFR & 164.526
      • GDPR Chapter III, section 3 ...
    • PE is following the HIPAA workflow
    • Will be authored by patients, then changes reviewed and implemented (or denied) by clinical staff
    • Largely unstructured narrative data
    • There is a lot of back and forth especially when changes are denied
    • Potential resources: Communication, Task, ServiceRequest
      • Rick Geimer: Suggested Composition (aka a FHIR Document).
      • Grahame agreed regarding Composition if this is something that a patient will sign. Concerned about the multiple changes, rejections, etc., may be good to consider multiple Task resources for each change. Also concerned about how to identify the clinician of record for any discrete data element. Provenance likely useful here. Grahame then discussed how the workflow gets problematic when data moves from system to system and the original source may not be preserved at every step. Suggested bringing Josh Mandel in to discuss further. 
      • Discussed various examples of data that needs changing, who can be contacted for specific changes, etc. 
      • Suggested breaking this into 2 parts: capturing the data that needs changing, and the workflow needed to process the changes. 
      • Isaac suggested a different workflow based on changes via USCDI. RG: USCDI does not cover the entire medical record. Debi(?): the patient needs to request changes in as simple a way as possible, it's clinicians who make the change. 
      • Abigal Watson: For a structured post/put update for something like smoking status, will EHRs support write access? Answer: goal is not to give patients write access. This would be a clinician operation. 
      • Grahame: POST/PUT is accept/reject occurs immediately. There is not opportunity for discussion/workflow, etc. So that needs to happen separately. 

Thursday Q5 (6-7:30 PM ET)

Chair (Josh Mandel)

Scribe (Rick Geimer)

  • Subscription discussion
    • Gino gave an overview of the new Subscription model
      • Main build:
      • Staging (Argonaut):
      • Sept 2020 Connectathon Track: 2020-09 Subscriptions Track
      • Discussed changes such as Subscription, SubscripitonTopic, SubscriptionStatus, and the new Bundle type of subscription. 
      • Will back port a limited version of R5 subscriptions to R4, primarily using extensions
      • Discussed about using GraphDefintion as a filter
      • Discussed using the FHIR registry for storing SubscriptionTopic instances that could then be shared with other. 
      • Can also include SubscriptionTopic in implementation guides
      • Discussed subscription notification issues: heartbeats, unsolicited notifications, what metadata is sent with the notification, etc. 
      • Discussed web-sockets. Did at a prior connectathon but got no feedback on the results. Notes issues with security, disconnects, etc. 
  • Tracker item discussions. No votes taken, just introducing the issues. Will revisit on a future FHIR-I call. 
    •   FHIR-28489 - Getting issue details... STATUS
      • Discussion on how previous and current criteria work with null fields. 
    • FHIR-28490 - Getting issue details... STATUS
      • It's not clear today between Subscription and SubscriptionTopic which criterias or filters apply to which qualifying resources. We need to reorganize the fields to make this more clear.

      • Proposal:

        • Add resourceType to Subscription.filterBy to be able to associate filters with resource to which it applies. Change resourceType to 0..1
        • Move canFilterBy under SubscriptionTopic.resourceTrigger, make resourceTrigger 0..*
    • FHIR-28491 - Getting issue details... STATUS
      • The Subscription.topic reference should be canonical

        • Update field definition
        • Add documentation for clients that if they need the SubscriptionTopic, they can search the server via SubscriptionTopic and/or try to resolve the canonical.  It MAY not be possible to retrieve the SubscriptionTopic directly.

Friday Q4 (4-5:30 PM ET)

Chair (Lloyd McKenzie)

Scribe (Yunwei Wang)

  • Topic: SANER Project (Keith Boone)
    • FHIR-28557 - Getting issue details... STATUS
      • Need an extension for StuctureDefintiion to specify invariant for some validation criteria for Measure
      • Lloyd suggests to look RequestGroup or PlanDefinition
        • RequestGroup does not support FHIRPath invariant at this time. 
        • RequestGroup is in instance space with PlanDefinition is in definition space
      • Keith noticed that it is also doable by using
      • If we wan for standard workflow, FHIR-I could create an extension for Definition pattern (except OperatonDefinition)
      • FHIR-I will discuss on Monday to create such extension
    • FHIR-28447 - Getting issue details... STATUS
      • Will move to ITS
    • FHIRPath questions:
      • throws errors on comments, memberOf, date +/- quantity
      • feature request: location of error in parsing
      • Keith will create change requests for specific FHIRPath implementation
  • Topic: FHIR Planning
    • Subscription:
      • MOTION: we will not make changes of R4 Subscription resource other than include reference to the back port Subscription IG. We will not add SubscriptionStatus to R4: Rick Geimer /  Gino Canessa (42-0-0)
        • Discussion about what backport covers. Concerns about back porting SubscriptionTopic and SubscriptionStatus to R4 
        • Focus is on back porting SubscriptionTopic 
      • Will discuss on Monday if any Subscription change would be included in R4B
    • Target for Normative or ML level up?
      • Basic:
        • Gino, Rick used in connectathon
        • Target to ML 3
      • CompartmentDefinition
        • Used in product but not shared
        • HAPI use CompartmentDefinition
        • Bryn used in CQL
        • Target to ML 3/4
      • ExampleSenario
        • Target to ML 1/2
      • GraphDefinition
        • Target to ML 2/3
      • Group
        • Used by some IG 
        • Target to ML 3
      • ImplementationGuide
        • At least implemented at 5 systems 
        • Target to ML 5
      • List
        • List is used in build.
        • Structure changes to List would be a high risk
        • Target to ML 4
      • Namingsystem
        • Target to ML 4
        • will transfer to Vocab
      • Questionnaire / QuestionnaireResponse
        • Target to ML 5
      • SeachParameter
        • Target to Normative
      • StructureMap
        • Target to ML 3
      • Subscription / SubscriptionTopic / SubscriptionStatus
        • Target to ML 3
      • TestReport
        • Support by TouchStone
        • but no one else
        • Target to ML 1/2
      • TestScript
        • Used in connectathon but not the focus
        • May have testing track in Jan connectathon 
        • Target to ML 3
    • Changes to Normative Resources
      • CapabilityStatement
      • OperationDefinition ?
    • Documentation Page:
      • Data Type:
        • CodeableReference
        • Int64/long
      • Workflow
        • exchange approach
      • Add Subscription page (already listed under Exchange Resources)
      • JSON 5 ?
      • Retire Turtle ?
      • Add OMOP to data base page
      • Combine FHIR ... Standard under ANSI Documentation 
        • too early to have serious discussion
    • MOTION: Move NamingSystem to vocab WG: Reuben Daniels / Rick Geimer : (36-0-1)
  • Will have conference call on this coming Monday