Attendees: 


Monday

Mon Q1 - Intro to FHIR, tracker items

Chair: Lloyd McKenzie

Script: Yunwei Wang


Lloyd walks through this week's FHIR-I Agenda

Lloyd introduces FHIR-I work group and FHIR-I projects


Tracker:

FHIR-24691 - Getting issue details... STATUS

  • Postpone to Monday Q3

FHIR-25627 - Getting issue details... STATUS

  • This does not affect any existing implementation. The validator enforce the rule correctly.
  • eld-19 has the regular expression for 64 characters
  • Will move "64 characters" to eld-19
  • Technical correction

FHIR-28467 - Getting issue details... STATUS

  • Move to PA which owns Endpoint resource

FHIR-29562 - Getting issue details... STATUS

  • Need discussion between FHIRPath and Library
  • Move to CDS which owns Library resource

FHIR-29715 - Getting issue details... STATUS

  • jasonpatch/test is not presented in "xml pach"
  • We should document a 422 in general http patch
  • Persuasive
    • Grahame Grieve / Michael Donnelly: 29-0-1

FHIR-29954 - Getting issue details... STATUS

  • We can fix the hyper link
  • Will change wording to "specification" from "document"
  • Persuasive
    • Grahame Grieve / Rick Geimer: 30-0-0

FHIR-30008 - Getting issue details... STATUS

  • Move to ITS

FHIR-30379 - Getting issue details... STATUS

  • Will discuss at Subscription projects

FHIR-30891 - Getting issue details... STATUS

  • It is correct that originalText is type of string only
  • The question is what is the original intention for originalText
  • The difference between originalText and narrativeLink is vague
    • The originalText is narrower than narrativeLink. 
  • Will expand origialText to support both string and url
  • Persuasive
    • Rick Geimer / Richard Ettema: 29-0-2

FHIR-31054 - Getting issue details... STATUS

  • If changes, it is "SHOULD" be less than or equals to m
    • Ex: base profile has 2..5 and child profile having a slicing with minimum 3 is valid but confusing
  • Will clarify that the sum of slicing minimum and element cardinality are separate constraints and validation shall evaluate both constraints
    • Ex: base profile has patient.name 0..* and child profile slice the name with officialName 1..1.
      • What this means is that if patient has a name, the name must contain an officialName
      • It is also valid if patient does NOT have any name
      • This is why such slicing is confusing.
  • Persuasive
    • Grahame Grieve / Ward Weistra: 30-0-0

FHIR-31348 - Getting issue details... STATUS

  • Technical speaking, valueAttachment is not part of path
  • Normal way is to following the path of sliced discriminator
  • If the a polymorphic type in R5 can convert to R4, then it is an error to use this extension
    • Ex: Observation.subject in R5 allows Substance which is not part of R4
      • It is fine to use this extension for Substance reference
      • It is not fine to use this extension for Patient reference
  • Persuasive
    • Alexander Henket / Grahame Grieve: 23-0-0

Mon Q2 - R4B tracker items

FHIR-32111 - Getting issue details... STATUS

  • Technical correction. Tooling issue, auto-approved, assigned to Grahame. 

FHIR-32110 - Getting issue details... STATUS

  • Technical correction. Tooling issue, auto-approved, assigned to Grahame. 

FHIR-32110 - Getting issue details... STATUS

  • Grahame will turn validation back on once WGs fix their examples. Technical correction, auto-approved. 

FHIR-32108 - Getting issue details... STATUS

  • Technical correction, auto-approved. 

FHIR-32107 - Getting issue details... STATUS

  • Technical correction. Tooling issue, auto-approved, assigned to Grahame.

FHIR-32106 - Getting issue details... STATUS

  • Will remove this extension and takes steps to prevent this in the future
  • Persuasive with Mod
  • Motion: Grahame Grieve/Ewout Kramer: 18-0-4

FHIR-32105 - Getting issue details... STATUS

  • Will correct extension definition to be uri vs. url. 
  • Persuasive with mod
  • Motion: Ewout Kramer/Michael Donnelly: 22-0-1
  • Motion to Reopen: Grahame Grieve/Ewout Kramer: 22-0-0
  • While this SHOULD be a URI, changing now would break a lot of tooling. 
  • Persuasive
  • Motion: Grahame Grieve/Ewout Kramer: 23-0-0

FHIR-32104 - Getting issue details... STATUS

  • Technical correction, auto-approved. 

FHIR-32103 - Getting issue details... STATUS

  • Technical correction, auto-approved. 

FHIR-31715 - Getting issue details... STATUS

  • Possible duplicate of FHIR-32680
  • Persuasive
  • Motion: Rick Geimer/Alexander Zautke: 23-0-0

Moved on to regular tracker items

FHIR-31700 - Getting issue details... STATUS

  • Won't maintain page but will migrate to history
  • Persuasive with Mod
  • Motion: Grahame Grieve/Rick Geimer: 23-0-0

FHIR-31702 - Getting issue details... STATUS

  • Persuasive
  • Motion: Michael Donnelly/Alexander Henket: 21-0-0

FHIR-31703 - Getting issue details... STATUS

  • Not Persuasive with Mod
  • Motion: Michael Donnelly/Alexander Henket: 21-0-0

FHIR-31704 - Getting issue details... STATUS

  • Not Persuasive with Mod
  • Motion: Alexander Henket/Grahame Grieve: 21-0-0

FHIR-31705 - Getting issue details... STATUS

  • Persuasive with Mod
  • Motion: Rick Geimer/Alexander Henket: 21-0-0

Mon Q3 - Capability Statement

Chair: Lloyd McKenzie

Script: Yunwei Wang


Grahame Grieve demos CapabilityStatement2

  • CS1 has the structure rest → resources
    • This is not productive.
    • Too many TUs
  • CS2
    • Replace TUs with "feature" capabilities
    • feature uses code-value pair as representation
    • Both code and value have required bindings
  • The initial R5 ballot has a bare bone draft list of feature codes
  • The improvement starts when communication through API
  • Demo: http://test.fhir.org/r5/metadata?mode=capabilities2
    • returns CS2
  • feathers can be at both system level and resource level
  • Demo: http://test.fhir.org/r5/$features
    • returns list of features as parameters in a Parameters resource
  • Demo: http://test.fhir.org/r5/$features?feature=rest:server.resource:Account
    • returns list of features on Account resource
  • Feature Negotiation
    • examples in CS2 resource page
  • EK: This create a chance for sever searching capabilities. There are questions on the current syntax
    • GG: current syntax is (context[:value].)* = value
  • LM: Are we going to stick with Parameters response?
    • GG: This is up for discussion
  • JM: Should the feature keep at root system level or push down as further as possible
    • GG: It is up to the implementer to put it in its natural logical place
  • EK: how to say server not support a feature?
    • GG: not now.
    • rest:server.resource:Account = false?
  • GC: With more features added, will client query feature directly instead of using CS?
    • GG: question is how many features we are willing to put into CS.
  • YW: Get a "clean" set of CS w/o features?
    • GG: current implementation on test can prevent certain features to be returned.
    • But we could add a enhancement to reduce the returned to only certain features
      • ex: using qualifiers = xxx
  • GC: It feels like we are talking about two separate resources, CS and Features
    • GG: it is possible to separate them.
  • GC: Clients asks for 10 features but server supports only 9 of them, should server returns OperationOutcom along with Parameters?
    • GG: The server returns 501? with the Parameters contains 9 features
  • EK: The feature list could evolve independently from CS
    • GG: It is possible
  • JM/EK: If we started pushing implementer to use features, it would be hard later to convert feature into regular resource
    • Alternative way is to use FHIRPath query a subsection of whole CS.
    • GG: current feature syntax support filtering naturally. Using FHIRPath could be very complicated
    • EK: will consider use cases for FHIRPath.
  • Let's aim to create a draft and connectathon at September
    • if Vocab does not do new ConceptMap
    • GG will create server
    • Need someone on client side, GC?
  • Is possible for IG to create feature requirement?
    • GC may try that at Subscription
  • The feature code binding is required now but may be extensible in the future.
  • Maye FHIR-I should be the central issuer to guaranty the feature name is unique
    • Central registry just like extensions?
    • Is it possible to use full url instead of qualified name?
  • rest.Codesystem:http://loinc.org = CLASS:equals is confusing because of mulitple : and .
    • urlencode?
    • using bracket?
      • rest.Codesystem[http://loinc.org] = CLASS:equals
      • rest[server].resource[Account] = false

Mon Q4 - FMG update - II, CDS, CQI, CG

Chair: Lloyd McKenzie

Scribe: Yunwei Wang


Hosting II, CDS, CQI, CG


  1. How's your WG doing on the core progress?
  2. Do you have a regular process for both updating & applying changes?
  3. Do you need assistance applying changes?
  4. Are you on track to have your candidate resources ready for normative and target maturities?
  5. Any FMG discussion resoruces for R5 normative?
  6. Near-term IG plans?
  7. Other topics?


R5 normative candidate cut off date: this summer

R5 balloting: Jan-2022


II:

  • Candidate Normative: ImagingStudy
    • Will have conneectathon in September

CDS:

  • Focused on IGs. Will update core spec using the knowledge learned from IGs.
  • Targeting FMM4 for most of FMM3 resources
  • Targeting some other low FMM level resource to next level
  • No normative candidate for R5 yet
    • May try Measure depending on implementer's feedback
    • LM: You can bring core resource to Normative with some attributes marked as STU
    • Library is another candidate.
  • New IGs?
    • EBM on FHIR
  • Other topics?
    • Interest in IG registration project
      • Will discussion the project on FHIR-I Wed Q1 and FMG Thur Q4
    • RelatedArtifact as a DataType

CG:

  • Proposals to create 1 or 2 new resources
    • Could submit proposal in confluence
      • Confluence → FHIR → Designers → Resource Proposal
    • Using Definition Pattern
      • Depends on the fields the definition would apply
  • New IGs?
    • Consolidating comments for current IG: Genomic Reporting


FHIR-32373 - Getting issue details... STATUS

  • Could rename dateFilter to valueFilter?
  • The intention is limiting to these types that can be easily translated to indexing.
  • Will remove SampleData
  • There is an extension defined in R4

FHIR-31739 - Getting issue details... STATUS

  • It is not recommended to have open ended RelatedArtifact.type
  • Move to MM

Tuesday

Tue Q2 - FMG update - PH

Chair: Lloyd McKenzie

Script: Yunwei Wang


Hosting: PH

Creating US public health library (IG?)

  • Based on US Core

Discussion about moving Immunization to normative

  • Portion of WG are not familiar with Immunization area
  • Lack of feedback
  • Consider alternatively bump up to FMM4

Consider bumping up FMM level for ImmunizationEvaluation, ImmunizationRecommendation

Support from FMG

  • Reach out to community about usage of Immunization resource
    • To quality for normative, need at least 5 systems in at least 2 countries
    • Epic, Cerner, and VA are reported/mentioned using Immunization

ImmunizationRecommendation is used by an IG in switzerland

In IG, how describe a bundle used for reporting exchanging

  • Narrative section in IG, or Composition with different sections
  • This is like story telling
  • Bundle vs Query
    • If the system support strong querying interaction, then it is not necessary to wrap everything in a Bundle
  • If use Bundle, Messaging is better
    • "Please process this report"
    • Another idea is using Subscription workflow
  • It is necessary to define a scope what data are included (either through querying or wrapper in a package)
    • Ex: Birth defect may include mother's previous pregnancy but not mother's cholesterol level
      • It is necessary to have cholesterol level now but may be found valueable in the future
    • IG should define two things: a minimum set of data and how such data are exchanged.
  • Has Subscription talked about followup queries?
    • Not yet
    • Have a traceability that this access of part of reporting process would be helpful

Some use cases have many observations. IG creates many Observation profiles to match the real world use cases. But those profiles have only different LOINC code etc. Is there way to create computable different observations?

  • Yes. Use ObservationDefinition which is introduced in R4
  • Usage of ObservationDefinition in IG is similar as using Questionnaire in IG


FHIR-27927 - Getting issue details... STATUS

  • This is a tooling issue

FHIR-28128 - Getting issue details... STATUS

  • We cannot change "publish" language but will update "on demand"
  • Persuasive
    • Grahame Grieve / Richard Ettema: 20-0-5

FHIR-32757 - Getting issue details... STATUS

  • The sentence "The SUBSETTED Security Label can be used to flag data that has had information removed. " is not correct
  • Also noticed that links to valueset in R4B were broken. Need to fix those.
  • Persuasive with Mod

Tue Q3 - Must Support

Chair: Lloyd

Scribe: Rick

Lloyd introducted the topic: mustSupport. Part of the FHIR spec for a long time. Lots of angst/confusion about it. Reviewed the definition from the spec. 

Issues:

  • impedes reuse of profiles
  • should be more fine-grained (X for client, Y for server)
  • what does it mean on choice or complex types (i.e. mustSupport on value[x], complex types like HumanName, etc.)
  • conditional mustSupport (this OR that)
  • what does mustSupport mean in an 'implementation' CapabilityStatement?

Any changes will not impact R4, would be for R5. But may decide to backport via extensions if deemed necessary. 

Inheritance issue (impedes reuse of profiles)

  • Possibilities
    • move to CapabilityStatement2
    • create a different "layering" of profiles that separates mustSupport. 
    • leave mustSupport flag but add mustSupportDetails extension pointing to cap statement

Went over CapabilityStatement instantiates and imports features. 

Lots of discussion on different use cases for must support, how inheritance can help/hinder those cases, etc. 

Discussed difference between implementing a profile with mustSupport vs. extracting data from instances that conform to such a profile (an extracting system might reply on the cardinalities, but not implement the mustSupport requirements). 

Candidate proposal: add a flag that tells the snapshot generator not to propagate must support and methodology to say when you should/should-not use that flag. Will likely be an extension. 

MnM needs to clarify how mustSupport and cardinality behave at root. FHIR-I still needs to discuss fine grained support. 

Tue Q4 - Rolling up our sleeves

Chair: Lloyd McKenzie

Script: Yunwei Wang


Link to dashboard: https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=12005


The biggest problem is too many resolved tickets are not applied. (692, 58%)


Working on Technical Correction (108) first

Calling volunteers for applying changes and reviewing changes


  1. Pre-requisit
    1. Need to know basic git operations and have a git client installed
    2. MS Excel installed (for editing extensions)
    3. JVM or JDK installed to build locally
      1. Could use Docker as alternative build method
    4. HL7 JIRA trusted user
    5. FHIR github committer
    6. Review HL7 operator manual Chapter 9
  2. Assign JIRA ticket to yourself
    1. Need to be HL7 trusted user
    2. Contact Lloyd McKenzie if you are not
  3. ./fhir/source folder
    1. ./profiles folder has the shared content: extensions etc
      1. Only support editing in Excel
      2. More details at Confluence → FHIR → Designers → FHIR Spreadsheet Authoring
    2. ./[resource] folder (ex ./observation for Observation resource)
      1. Use either (reousrce)-spreadsheet.xlsx or structiondefinition-(observation).xml
    3. ./datatypes folder has list of FHIR DateTypes
    4. ./terminologies folder has list of value sets
    5. all html pages are under source folder
  4. process
    1. Need to be a committer (ask Lloyd or Josh)
    2. clone repo
    3. create branch
    4. no naming convention for branch name other than no slash in the name
    5. no requirement for one Jira per branch nor one Jira per commit
    6. fix the ticket
    7. run local build
    8. push changes
    9. create pull request (targeting "master" branch)
    10. add comment with pull request link in original JIRA ticket
    11. change Jira ticket to "Applied" after merged

Wednesday

Wed Q1 - IG Tooling

Host: Lloyd

Scribe: Rick

  • PSS
  • Expectations around documentation
    • If committing a change to tooling, ensure there is a corresponding pull request with documentation
    • Perhaps a summary of the documentation locations in IG Guidance
      • Consolidate and reference?
    • There are challenges with the current process
    • Need guidelines for where documentation lives
    • Perhaps a summary page with links to all the IG Guidance out there. Consolidate where possible, reference where not. Examples:
  • IG template testing
    • Implement features in the sample IG and build with template before committing
    • In the future, discuss Grahame's multi-IG publishing process
  • Current template proposals
    • Propogating status and FMM
    • Renaming/moving the "Text Summary" tab
      • Keep required, but move to last tab. 
      • Rename to "Stats and References"
    • Tabs for constraint, terminology, data dictionary
    • IG guidance
    • Multi-lingual IGs

Wed Q2 - Tooling tracker items

Chair: Lloyd McKenzie

Scribe: Yunwei Wang


128 JIRA tickets are related to tooling with status "Resolved - change required"

  • Issues SHOULD only be raised in Jira if they appear in the specification (core or IG) otherwise they should be in Git. Issues shouldn’t be both places.  If you’re not sure, put it in Jira and we’ll triage it.
  • Move anything that shouldn’t be in Jira to Git and close the Jira issue as ‘No change’ as it’s not specification related and provide a link to the Git issue created
    • Comment on the close should include a link to the Git issue and indication that if you want to follow the progress of the Git issue, you’ll need to watch the issue in Git.

Tooling priority order is: validator, then IG publisher, then core publisher, then templates

Create tooling dashboard for JIRA tickets for Mark/Grahame

  1. Ensure sufficiently described so that “what is to be done” is clear
    1. Validator fixes need test cases
      1. Get validator to spit out what packages were used in results
      2. Include instance that triggered issue in on-line validator, or package of resources needed to reproduce the problem
    2. For IG, core publisher & tooling bug reports, provide a branch that includes the issue or zip up the IG
  • Pull requests are welcome
  1. Create a confluence page that describes what’s needed to report a tooling issue that we can point submitters at if their submission is not ‘complete’
    1. Include pointer to tooling source documentation for people who are motivated to debug/fix/pull request themselves.
  2. Apply Jira or Git rule
  3. Is this categorized as the right ‘tool type’

Create a confluence page indicating "requirement/recommendation" when creating a tooling ticket


FHIR-32757 - Getting issue details... STATUS

  • Second use case (resource already exists)
    • Should the response code be 201 or 200?
    • Is the same as "conditional create"
      • Conditional create is that client specifies the matching rules
    • The existing language does say that client cannot do create and update at the same time.
    • It is problem to respond to a "create" request with existing resource
    • According to https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.3
      • It is possible to send 303 if resource already exists
      • Question is if any server/client handle that code
      • It may confuse the implementer that "equivalent instance" is not the "identical instance"
    • Client may stuck if client think it is difference instance while the server think it is.
    • Another external discussion: https://stackoverflow.com/questions/3825990/http-response-code-for-post-when-resource-already-exists
    • Does 303 also update the existing resource (or indicate the existing resource updated)
      • LM: No
      • GG: Yes
    • The server MAY also send 422
      • The location header can be used to point to existing resource
    • Difference between 303 and 422
      • 303: equivalence record already exist
      • 422: unique index conflict

Wed Q3 - FMG update - BR&R, Pharm

Chair: Josh Mandel
Minutes:  Rick Geimer

Agenda: Review R5 and IG planning with hosted workgroup

Sign in at: https://bit.ly/fhiri

  1. Planning for R5

    1. Do you have FFM targets for all resources in R5?

      1. R5 Timeframe is still being refined
        1. planning for R5 ballot in Jan (open during December), meaning content done by end of October
      2. Notional deadline for establishing FMM targets is "a few weeks from now"

    2. Anything targeting normative, and has FMG reviewed?

      1. BR&R: None
      2. Pharmacy: targeting Medication and MedicationRequest; already discussed in FMG

  2. Progress toward R5

    1. Overview

      1. How’s your WG doing on FHIR core resources?

      2. Do you have a regular process for both updating & applying changes?

      3. Do you need assistance applying changes?

      4. Are you on track for candidate resources to meet target maturities?

    2. BR&R
      1. Pace is picking up on ResearchSubject and ResearchStudy (structural changes, broader focus, strong contribution in meetings); still need to build out examples. In a good place here.
      2. Medication Definition resources: strong push for R4B, currently resolving (will apply in parallel to R5). Good ballot feedback; all FMM1 in R4B, and may target FMM2 for some in R5 (which will require example valuesets, an outstanding TODO for this summer).
      3. General issue about terminology: previously every group had a terminology facilitator; this has changed with UTG, but we're not clear today about how to manage terminology. Formal UTG role is too big
        1. e.g., when we're defining a resource we need to create (at least!) an example valueset. Doing this properly can require review of a business process, understanding requirements, reviewing existing terminologies to see if any apply, using them and/or augmenting them. This is a lot of work, so in practice we just sprinkle in a few example values and call it a day; then implementers come by and use them as though they were a proper vocab. Challenges with licensing, too.
        2. Example valuesets (and even a few accidental casualties like status valuesets) were taken out of FHIR Core and moved to UTG which is unwieldy to manage even for valuesets. Can't even run the UTG build process on a Mac. From Zulip: tentative agreement (or at least no objectives) to move example valuesets back into core build. Melva plans to re-create example valuesets for Pharmacy and put them back into the build.
        3. Getting beyond "example" bindings in the core spec is very challenging across the board; to get to "preferred" or "extensible" requires jurisdictional or use-case specific inputs. Still, our "example" bindings could be better; implementers aren't expert enough to discern "just a placeholder example valueset" from "a really nicely crafted example valueset". They don't know what they don't know. Possible solutions:
          1. → make  examples really great so they're suitable for implementation directly
          2. → make the examples LOUDLY UNSUITABLE for production use" e.g., https://github.com/facebook/react/blob/80bff5397bf854750dbe7c286f61654ea58938c5/src/umd/ReactUMDEntry.js#L20-L2
        4. We see implementers in two classes 1) ones who need guidance to understand they shouldn't use examples in prod, 2) implementers with an existing working system that has its own codes already worked out, and just need to know where in the model to include them.
        5. Are vocab facilitators really "no more"? Rachel notes she's performing this role in Patient Empowerment. (Melva: active discussion for TSC; in FHIR we haven't done a good job of breaking out or relying on this role the way it was used in V2. Many workgroups don't have anyone in this role today.)
          1. Broad / industry-wide issues (terminology, licensing, management, etc)
          2. HL7 process issues (harmonization, tooling, maturity, etc)
    3. Pharmacy
      1. Keeping up with trackers on Medication and MedicationRequest
      2. Other resources will be moving up in maturity
      3. QA issues are a perpetual challenge, often right at the end
      4. Spreadsheet with other requirements we're expected to fill in as part of the maturity process
        1. For maturity: who is using resources, and are they using through the full scope? It's hard to really know but we can make decent guesses. We don't have implementers participating in our weekly calls. Yes at WGMs and connectathons but they're too busy for our weekly calls. (They used to be, but they've dropped off over the past few years. Hugh notes similar participation challenges in BR&R; we often learn late about implementer uptake. But participation increasing with Vulcan.)
        2. Particularly for resources that have been implemented in DSTU2 and have changed in R4 and R5, how does (or how should) the DSTU2 experience "count"? For example, US Core implementers (FYI Brett Marquard are interested in seeing MedicationStatement progress.
          • TODO(Josh Mandel) – find a link to this spreadsheet and understand whether this is gating/blocking
          • What is  the right bar for usage? Is it a "gut feeling", or are there hard criteria? And if there are hard criteria, how do you explain "full scope of use" (which elements? read vs write, which kinds of users/roles, etc)
          • TODO(Brett Marquard) can Argonaut provide a way to feed evidence of usage back to Pharmacy and other workgroups? This is a painpoint for WG co-chairs that are trying to work up the FMM. Implementer that want to see FMM increases can 1) implement, 2) share details about their implementations, 3) show evidence of maturity.

  3. Near-term IG plans?

    1. Pharmacy is working on a "medication list guidance FHIR IG"; FMG approved; it's an "odd duck" for being not directly implementable, but we often have folks looking to create an "active meds list" in some particular context of use. We wanted to put together best practice guidance to help other IG authors get these patterns right. We're now thinking that this work might better fit in FHIR Core rather than in an IG. ("The list of meds the pt should be taking" vs "the list of meds the patient is taking", etc – you need to know a context of use to get consistent implementation.)
    2. BR&R: looking out over next 12 months, targeting 1 IG in September (CodeX trial matching, already with PSS), and 2 or 3 more by summer 2022 (plan for adverse events; pharmaceutical quality chemistry manufacturing and controls for FDA; possibly one more).

  4. Other topics?

    1. Discussion on ownership of med definition resources (some overlap in scope with knowledge resources; some attributes in Med Knowledge that aren't definitional, so they're technically distinct but there's significant overlap). Formally a resource is owned by just 1 WG, but talked about defining a process for joint control, so Jira issuers on these resources would be visible to a set of workgroups, to make it easier to have a shared understanding.
      1. Resources: MedicinalProductDefinition (MPD), PackagedProductDefinition (PPD), AdministratableProductDefinition (APD), ManufacturedItemDefinition (MID), ClinicalParticulars (CP), Ingredient MedicationKnowledge (MK), Medication
      2. WGs: BR&R, Pharmacy

Thursday

Thur Q1 - FMG update - OO, Dev

Chair: Yunwei Wang

Scribe: Rick Geimer

Joint session with DEV, OO

FMG Update: R5 postponed to Jan 2022

  1. How's your WG doing on the core progress?
    1. DEV: No large backlog of JIRA trackers. 
    2. OO:  Highest number of JIRA trackers of any WG, barely beating FHIR-I (smile). Rob H.: we know it's a big backlog, but we will try to get it addressed. 
  2. Do you have a regular process for both updating & applying changes?
  3. Do you need assistance applying changes?
  4. Are you on track to have your candidate resources ready for normative and target maturities?
  5. Any FMG discussion resources for R5 normative?
    1. DEV 
      1. DeviceMetric should move up the FMM levels (probably FMM2)
      2. Would like to add a new DeviceAert resource
        DeviceAlert FHIR Resource Proposal - FHIR - Confluence (hl7.org)
    2. OO
      1. No new normative candidates
      2. Several resources for FMM updates
        1. Device
        2. ObservationDefinition
        3. Specimen
        4. DiagnosticReport
        5. Will remove CatalogEntry
        6. Potentially other resources (Rob did not have the full list on hand)
  6. Near-term IG plans?
    1. DEV plans updates for the following:
      1. Personal Health Device IG:
        1. Needs help publishing the IG. Issues with getting system URIs (getting errors using a non-resolvable URL in the IG Publisher). 
        2. Grahame will have a look
      2. Point of Care Device IG
    2. OO plans to update
      1. Catalog IG
      2. LIVD IG (LOINC invitro diagnostics)
  7. Other topics?
    1. DEV
      1. IEEE nomenclature still not easily usable in FHIR IGs (MDC codes). Grahame will support in the next release of the tooling. 
    2. OO
      1. Will discuss in Q2
      2. Hans B. asked about FHIR Subscription issues. Rob. M. agrees more communication needed around Subscription. 


Tracker Items

FHIR-31356 - Getting issue details... STATUS

  • Is a nice to have, but Grahame is ok with trying it out. Motion to approve pending feasibility.
  • Persuasive
  • Motion: Michael Donnelley/Ward Weistra: 26-0-1

FHIR-31385 - Getting issue details... STATUS

  • Persuasive
  • Motion: Rick Geimer/Alexander Henket: 26-0-2

FHIR-31400 - Getting issue details... STATUS

  • Will move eld-1 from ElementDefinition to StructureDefinition.snapshot, but this is normative so need to consider exactly how to do this in a compliant way
  • If we do this, will need to consider relaxing our rules about relaxing constraints in normative artifacts (versions.html, search for "Value Constraints")
  • Persuasive with Mod
  • Motion: Rick Geimer/Lloyd McKenzie: 20-0-4


Friday

Fri Q4 - Carry-over

Chair: Lloyd McKenzie

Scribe: Rick Geimer

Tracker Items

FHIR-32757 - Getting issue details... STATUS

  • Discussion about how to handle a situation where you have a transaction bundle but want it to succeed if a specific resource (or set of resources) fail. Could handle with some sort of flag on Bundle.entry in R5. 
  • Clarified which response codes are allowed for entries in order for the transaction to return 200 OK
  • Persuasive with Mod
  • Motion: Joe Lamy/Michael Donnelly: 15-0-0

FHIR-32800 - Getting issue details... STATUS

  • Will add language that serializers and parsers MAY retain, escape, or strip unescaped non-supported unicode characters. Will document differences between XML and JSON regarding leading/training whitespace, training zeros, etc.. 
  • Persuasive with Mod
  • Motion: Grahame Grieve/Gino Canessa: 15-0-1

FHIR-31401 - Getting issue details... STATUS

  • Change to "Servers SHALL NOT return more resources in a single page than requested..."
  • Persuasive
  • Motion: Grahame Grieve/Richard Ettema: 15-0-0