FHIR Infrastructure Minutes WGM 201801

FHIR Infrastructure 2018 January New Orleans WGM Minutes

Return to FHIR Infrastructure Minutes

Agenda

• see FHIR_Agenda_201801_WGM

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

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

Thursday 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

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)

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

Josh Mandel: Pass 4-0-0

Josh Mandel: # 185

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