Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • 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, final content likely in mid 2021, publication around Q2 20222021. 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. 


  • 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. 
      • Discussion on how previous and current criteria work with null fields. 
    • Jira
      • 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..*
    • Jira
      • 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.