FHIR Infrastructure Minutes WGM 201801
Contents
FHIR Infrastructure 2018 January New Orleans WGM Minutes
Return to FHIR Infrastructure Minutes
Agenda
Attendees
A comprehensive list for the WGM can be seen here: File:FHIR-I Attendance Jan 2018.pdf
Monday Q1
Chair: Ewout Kramer
Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)
Block Vote from Jan 16
- Remove Issue 14000
Vote: 42-0-6
Tracker Items
- 13542 - Pagination on Patient/:id/$everything - Persuasive
- 13336 - Add paging and filtering operation to List - Persuasive with Mod
- 13324 - Allow AND in _has query - Not Persuasive
- 14864 - all-types can't be normative when resource names may change - Not Persuasive
Monday Q2
Chair: Ewout Kramer
Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)
Tracker Items
- 13348 - Need guidance on how :missing works with elements that may be present but non-valued or otherwise incomplete - Discussed, in progress
- 13224 - Clarify how default values work in presence of extensions - Discussed, in progress
Monday Q3
Chair: Ewout Kramer
Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)
Tracker Items
- 13543 Standard extension needed to convey the type of the resource in case ogf a logical resource reference - Persuasive with Mod (seeking community review for FMM 5 change)
- 13284 - Cardinality of search parameters in CapabilityStatement - Discussed
- 13455 - Compartment usage for POST/PUT Ask - Discussed
- 13922 - Add asynchronous pattern support to FHIR API - Persuasive
- 13711 - define a limited subset of FHIRPath for re-use in multiple places - Persuasive
Monday Q4
Chair: Lloyd McKenzie
Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)
Workflow Project Overview
- The FHIR Workflow project was established about 2 years ago to (1) provide consistency in FHIR when you want something to be done and to (2) define and make clear what are the different ways you can actually ask for something to be done, providing guidance on the FHIR way of doing it.
Pattern Report
- The workflow module definition page found at http://build.fhir.org/workflow-module.html defines 3 patterns: Definition, Request, Event. These are not real FHIR Resources, but are logical models that are to used as a guide that resources should follow.
- A report of all FHIR resources that are not in alignment with the workflow pattern guidelines has been created as WorkflowIssues.xml. The report has been distributed and for each item in that report, the responsible work group should resolve the warning. FHIR resources do not necessarily have to align in all areas, but need to consider each warning and decide how the warning will be resolved. The warning can be resolved by (1) changing the FHIR resource to follow the pattern or by (2) copying the issue from the WorkflowIssues.xml into the suppressed-workflow-warnings.xml file found in the FHIR source code.
- Items that are added to suppressed-workflow-warnings.xml are reviewed by FHIR-I and for items that are not obvious, clarification will be solicited from the responsible work group.
- Report why something is not applicable to the WG in their patterns, needed different datatype, review added content.
- If FHIR-I changed a name in a pattern have work group review that.
- If pattern doesn't make sense for WG have 2 choices - exclude WG resource from pattern use OR submit change request to fix pattern
- If FHIR-I finds that all work groups are suppressing the same warnings, this will be an indication that the element should probably be removed from the pattern.
Pattern Changes
- The patterns have recently been updated and so each work group should review the patterns again.
- Work groups should raise any additional changes as Tracker Items. This should be done in the next few weeks, since any changes to the patterns affect other workgrups and they will need time to address any warnings that those changes may create.
- Will re-run the error report once all applied changes have been covered before WGs start reviews
Example Scenario
- An ExampleScenario resource has been created that can be used to define a complete workflow example, showing what steps are involved, which parties are invovled, and so forth.
- The ExampleScenario resource is an early draft version and so if there are items that cannot be expressed, please provide feedback so that it can be updated to accommodate those items.
- The ExampleScenario instances will be rendered using diagrams (UML and Sequnce) to give a visual representation of the workflow example.
- Work groups are invited to create ExampleScenario instances that show the scenarios that they would like to exercise.
- In the next couple of months, the build process will be updated to consume these ExampleScenario instances and produce the diagrams and end user consumable content.
- Want to have scenarios available for Sep 2018 ballot
- What is the purpose? To help make IGs more understandable for each of the modules
- Scenario allows for actors to be people - so step can be shown and described, but no resource is created without a system - draft resource, start using and send feedback to FHIR-I
- Plan is to add GUI to make it easier to use - e.g. in clinician on FHIR or for IG writers - also would like to create a tooling that can import just deltas to the base scenario created for an IG use case
- What is difference to the test script in connectathon?
- Main difference is that test script is written as 1. step, 2. Step for the resources but not telling the entire story on the business side - this sets the context
- The path in the scenario can have one or more test scripts for each of these - test scripts are usually only between 2 actors
- In workflow we would like to see 2- 6 examples per module
- Once committee defines the resource and the first scenario - when other working groups create scenarios and a resource changes, do all then have to be updated, even the ones we have NOT created as curating workgroup
- Use the example resources that have already been created = patients and providers not so problematic biggest issue would be service request, observation, medication, condition.
- Will have to create tooling to help with instance creation
- For now work on the flow set up, not the instances
Tracker Items
- 14470 Align workflow with OMG Healthcare Business Process - 2018-Jan Core #110 - Persuasive
- 14476 Consider SOA OrderingService as input to workflow - 2018-Jan Core #116 - Persuasive
May 2018 WGM
- Will keep this same session in May 2018
Tuesday Q4
Chair: Josh Mandel
Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)
SMART on FHIR Ballot Items
Notes in Zulip
Block Vote from Jan 4
Motion: Kevin Shekleton
Second: Michael Donnelly
3 votes for, 0 votes against, 1 abstain
Passes: 3-0-1
fhirUser vs Profile
Motion: Rename profile to fhirUser, but document that the older profile claim remains, but deprecated. Indicate that profile will be removed in a subsequent version of the specification. Note that servers already implementing the profile claim should add fhirUser with the same value, but should preserve the profile claim until the deprecation cycle has been completed. SMART apps should prefer the fhirUser claim over profile.
Mover: Kevin Shekleton Second: Michael Donnelly
Passes: 4-0-0
launchContext (Ballot issue 187)
Motion: Update our "launch context" docs to state that: launch context is a negotiation where a client asks for specific launch context parameters (e.g. "launch/patient"); a server can decide which launch context parameters to provide, using the client's request as an input into the decision process. When granting a patient-level scopes like "patient/*.read", the server MUST provide a "patient" launch context parameter.
Mover: Michael Donnelly Seconder: Christian Knaap
Passes: 4-0-0
read and search (Ballot issue 185)
Motion: Asked and Answered. Add langauge to specification to clarify: Apps that need to read existing data from an EHR (e.g., FHIR `read` and `search` interactions) should ask for `read` scopes. Apps that need to write data to an ehr (e.g., FHIR `create`, `update`, and `delete`) should ask for `write` scopes. EHRs may decide what specific interactions and operations will be enabled by these scopes.
Moved: Michael Donnelly Seconded: Kevin Shekleton
Passes: 4-0-0
Wednesday Q2
Chair: Ewout Kramer
Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)
Tracker Items
- 14154 -Searching a patient by Identifier Type - Persuasive with Mod
- 14237 - Provide example and guidance on use of token for ContactPoint, uri & boolean - Persuasive with Mod
- 13728 - Allow CQL for Subscription.criteria - Not Persuasive
- 14410 - CapabilityStatement.messaging and CapabilityStatement.document Experience - Persuasive
Thursday Q2
Chair: Josh Mandel
Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)
Tracker Items
- 13337 - Persuasive (but no need for action if we eliminate defaults)
- 13224 - Clarify how default values work in presence of extensions - discussed
- 13339 - Clarify how default values work in the presence of subsetted/redacted resources - discussed
- 13348 - Need guidance on how :missing works with elements that may be present but non-valued or otherwise incomplete - - discussed
Ewout Kramer and Christiaan Knaap worked out an overview that Ewout presents.
Comments:
Michael Donnelly: what problem do defaults solve? E.g. should we keep them at all?
A discussion follows on removing the notion of defaults and of meaningWhenMissing from the spec.
The only place where meaningWhenMissing is really useful is Period.end. It may not be worthwile to have a separate concept just for this one case.
Lloyd joins the meeting for his input.
Motion is prepared for next meeting.
Thursday Q3
Chair: Ewout Kramer
Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)
Tracker Items
- 15121 - Grouper issue for Defaults and Meaning When Missing - Persuassive
Motion
- Remove the notion of defaultValue[x] from ElementDefinition.
- Retain support for meaningWhenMissing, but specify that profiles must not create guidelines that change or assert interpretation of missing elements.
Execution Details
- In most cases, the default value for an element can be eliminated by making that element required.
- When an element needs to be optional, a meaningWhenMissing can be provided.
- Workgroups are discouraged from specifying a meaningWhenMissing when that meaning is trivial (e.g. "the item is not known").
- Workgroups are encouraged to create data models in which meaningWhenMissing is not required.
- Update 2.32.0.4.3 Missing Elements to indicate that "missing" should be synonymous with "has no value".
- This implies that "meaning when missing" applies to elements are not present and to elements that have no value. It also implies that searches for Patient?gender:missing=true should return all patients without a gender value (including patients that have extensions but no value on gender).
- Update the examples in 2.32.0.4.3 Missing Elements.
Motivation
- We don't think the advantage of more concise resources is outweighed by the disadvantages of
- inconsistent or more complex processing of the data and
- opportunity for miscommunication ("sender did not know" vs. "have to assume the default")
- Implementing special cases (in which default behavior is used) can introduce implementer mistakes. We strongly suggest committees change any element with a default value to be mandatory.
- The current list of such elements likely to be made mandatory is relatively small.
This motion will require community consultation.
