This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Infrastructure Minutes WGM 201709"

From HL7Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
[[:Category:2017 FHIR Infrastructure Minutes|Return to FHIR Infrastructure Minutes]]
 
[[:Category:2017 FHIR Infrastructure Minutes|Return to FHIR Infrastructure Minutes]]
  
Attendance sheet: [http://bit.ly/fhiri http://bit.ly/fhiri]
+
Attendance sheet: [[File:2017-09 FHIR-I Attendees Sheet.pdf]]
  
 
==Agenda==
 
==Agenda==
Line 27: Line 27:
  
 
===Overview===
 
===Overview===
Lloyd provided an overview of the workflow spec, introducing the ideas of workflow patterns and workflow interoperability architectures and briefly described the work that has happened to date.
+
Lloyd provided an overview ([[File:FHIR_Workflow_Update_201709.pptx]]) of the workflow spec, introducing the ideas of workflow patterns and workflow interoperability architectures and briefly described the work that has happened to date.
  
 
===Pattern changes===
 
===Pattern changes===
Line 52: Line 52:
  
 
==Wed Q2==
 
==Wed Q2==
Chair: ???
+
Chair: Grahame Grieve
Scribe: ???
+
Scribe: Ewout Kramer
  
==Thur Q2==
+
===Item 1 - PSS for II context synchronization===
Chair: ???
+
Isaac Vetter runs us through the PSS, which he likes FHIR-I to sponsor.  The text of the PSS can be found [https://drive.google.com/open?id=165BU5ZmUyuwxz4kg2dtjRWkNM7o4u2PrdcIKSxP94Ts here].  We vote to sponsor, Grahame Grieve/Corey Spears: 21/0/1
Scribe: ???
 
  
 +
===Item 2 - Support for data registries in FHIR===
 +
Tom informs the group about a usecase in the dutch LSP where a type of Resource is needed that can convey
 +
information about what is available in the registry (aspects include type of information, endpoint to retrieve
 +
the information, the practitioner involved).  Tom suggests a list of canidates but is not convinced any of
 +
those are applicable. After some deliberation, we settle on DocumentManifest. Unfortunately, this resource
 +
has a required set of references to either a document or resource. This is not applicable to this usecase
 +
since there is no reference to actual instances, just information about kinds of information in the
 +
registry. Tom will contact SD to talk about relaxing this cardinality. We also suspect that this will lead
 +
to a discussion about renaming the resource to e.g. "ContentManifest".
 +
 +
===Item 3 - Versioning of endpoints and instances===
 +
A continuation of our discussion in Madrid.
  
 +
Jenny, Kevin and Lenel put forward that some kind of versioning indication seems useful. Agree to have Grahame finish the whitepaper on versioning AND pilot some approaches (amongst which the mime-type based one, akin to GitHub) during the January connectathon.  Lots of interest during the meeting. [https://www.linkedin.com/pulse/fhir-nuts-bolts-versioning-chris-grenz Chris Grenz' blog about this subject] highlights another aspect of versioning, that we did not get into.
  
==Thur Q3==
+
==Thu Q2==
Chair: ???
+
Chair: Josh Mandel
Scribe: ???
+
Scribe: Josh Mandel
 +
 
 +
===SMART Ballot Theme: offline_access===
 +
Discussion of the use cases for "online_access" and "offline_access" scopes, both of which are intended to
 +
convey a request for a refresh token. We discussed that offline_access is intended to result in a refresh
 +
token that lasts for an indefinite period of time; while online_access is intended to result in a refresh
 +
token that lasts for less time -- just enough to support the current user session, where the mechanism
 +
for determining exactly how to accomplish this is up to the EHR (e.g. it could be based on session
 +
activity, or continued use of an access token, or clock time, etc).
 +
 
 +
Vote recorded in [https://docs.google.com/spreadsheets/d/1j-Dp6B3VetJ_dMseTl6F9qu4GIZr5b9HFRB4iURfSLw/edit#gid=569200369 spreadsheet]:
 +
Dennis Patterson / Michael Donnelly 10/0/2
 +
 
 +
 
 +
===SMART Ballot Theme: Extension URL Space===
 +
We discussed the use of the "smarthealthit.org" domain in extension URLs for the SMART app launch specification. We decided not to change these to "hl7.org", with the goal of maintaining backward compatibility -- but we decided to deprecate these extensions from the CapabilityStatement (by moving them to a .well-known discovery document) and to ensure that in the meantime we can publish proper StructureDefinitions describing these extensions. We also discussed the format of the new discovery document.
 +
 
 +
Vote recorded in [https://docs.google.com/spreadsheets/d/1j-Dp6B3VetJ_dMseTl6F9qu4GIZr5b9HFRB4iURfSLw/edit#gid=569200369 spreadsheet]:
 +
2017-09-14 Isaac Vetter / Reuben Daniels 11-0-1
 +
 
 +
 
 +
 
 +
===SMART Ballot Theme: Where can Confidential clients run===
 +
We began a discussion about relaxing our advice about confidential clients to include the possibility that confidential clients may be able to run on mobile devices in appropriate circumstance.s
 +
 
 +
==Thu Q3==
 +
Chair: Josh Mandel
 +
Scribe: Josh Mandel
 +
 
 +
===Block Vote===
 +
We completed the September Block Vote (as submitted to the FHIR-I mailing list on 2017-09-04).
 +
 
 +
Ewout Kramer / Richard Ettema 7-0-3
 +
 
 +
 
 +
 
 +
===SMART Ballot Theme: Where can confidential apps run?===
 +
We completed a discussion about where confidential apps can run, with a vote to incorporate updated language indicating that, with appropriate conditions, confidential apps can run on a mobile device.
 +
 
 +
Vote recorded in [https://docs.google.com/spreadsheets/d/1j-Dp6B3VetJ_dMseTl6F9qu4GIZr5b9HFRB4iURfSLw/edit#gid=569200369 spreadsheet]:
 +
Christiaan Knaap / Isaac Vetter 10-0-1
 +
 
 +
 
 +
===SMART Ballot Theme: Person in OIDC===
 +
We discussed the use of the Person resource in conveying details about the signed-in user who launches an app.
 +
 
 +
Vote recorded in [https://docs.google.com/spreadsheets/d/1j-Dp6B3VetJ_dMseTl6F9qu4GIZr5b9HFRB4iURfSLw/edit#gid=569200369 spreadsheet]:
 +
 
 +
Dennis Patterson / Reuben Daniels 8-0-3
 +
 
 +
 
 +
 
 +
===SMART Ballot Theme: "issuer" discovery===
 +
We discussed the process for discovering the "issuer" associated with a SMART EHR. "Follow the OIDC protocol. We noted that information about the token URI, authorize URI, registration URI, and OIDC Issuer URI are available in the ${FHIR Base}/.well-known/smart-configuration as well as ${Issuer}/.well-known/openid-configuration .
 +
 
 +
Vote recorded in [https://docs.google.com/spreadsheets/d/1j-Dp6B3VetJ_dMseTl6F9qu4GIZr5b9HFRB4iURfSLw/edit#gid=569200369 spreadsheet]:
 +
 
 +
Isaac Vetter / Dennis Patterson 10-0-2
 +
 
 +
 
 +
 
 +
===SMART Ballot Theme: OIDC Requirements===
 +
We discussed the specific subset of OpenID Connect that is necessary for SMART support. We agreed on a set of clarifications to include in the specification.
 +
 
 +
Vote recorded in [https://docs.google.com/spreadsheets/d/1j-Dp6B3VetJ_dMseTl6F9qu4GIZr5b9HFRB4iURfSLw/edit#gid=569200369 spreadsheet]:
 +
 
 +
Michael Donnelly / Ewout Kramer 7-0-5

Latest revision as of 18:52, 30 September 2017

FHIR Infrastructure 2017 Sept San Diego WGM Minutes

Return to FHIR Infrastructure Minutes

Attendance sheet: File:2017-09 FHIR-I Attendees Sheet.pdf

Agenda

Mon Q3 - FHIR Core

Chair: Ewout Kramer Scribe: Lloyd McKenzie


Introduction

Ewout Provided a quick overview of the work group, how we meet and the agenda for the week

Tracker Items:

  • 13561 OperationDefinition.parameter is largely redundant with ElementDefinition - Persuasive w/ Mod
  • 13376 Settle on a single markdown specification - will solicit feedback on adopting Github markdown spec

Adjourned at 3:07pm

Mon Q4 - FHIR Workflow

Chair: Lloyd McKenzie Scribe: Lloyd McKenzie

Overview

Lloyd provided an overview (File:FHIR Workflow Update 201709.pptx) of the workflow spec, introducing the ideas of workflow patterns and workflow interoperability architectures and briefly described the work that has happened to date.

Pattern changes

Lloyd shared a [[ |presentation]] showing the changes that are being applied to the Event, Request and Definition patterns. The group discussed the difference between "function" codes and "role" codes. There may be a need for function codes in some resources - particularly Procedure. Such resources will be able to still use a nested structure if they need to.

There was discussion of the proposed change to add insurance information to Request. Paul and Lloyd will discuss further before bringing it to the work group for a vote

WorkflowExample

Lloyd provided an overview of the WorkflowExample resource and its purpose and how it would be rendered.

Question about whether the resource could be used to simply show evolution of a resource over time. At the moment, the resource requires identifying sender and receiver

Discussion about changing name of resource. Straw poll conducted. Strong preference for ExampleScenario instead of WorkflowExample as it encompasses the broader scope of the resource

Change Requests

Reviewed [11217]. Discussion about the difference between orders and prescriptions/authorizations. Also discussion about whether DeviceRequest could be exteneded to incorporate VisionPrescription

Outcomes:

  • OO will consider changing the "order" intent code (and specializations) to use "authorization" in their names instead. (The actual ordering is a request for fulfillment which is separate from the Request resource.)
  • Lloyd will try modeling the Vision resources using an adjusted version of DeviceRequest
  • The request resource will be updated to have language about an authorization that defines characteristics of what's wanted vs. an authorization that fully describes what's needed

Adjornment 5:04

Wed Q2

Chair: Grahame Grieve Scribe: Ewout Kramer

Item 1 - PSS for II context synchronization

Isaac Vetter runs us through the PSS, which he likes FHIR-I to sponsor. The text of the PSS can be found here. We vote to sponsor, Grahame Grieve/Corey Spears: 21/0/1

Item 2 - Support for data registries in FHIR

Tom informs the group about a usecase in the dutch LSP where a type of Resource is needed that can convey information about what is available in the registry (aspects include type of information, endpoint to retrieve the information, the practitioner involved). Tom suggests a list of canidates but is not convinced any of those are applicable. After some deliberation, we settle on DocumentManifest. Unfortunately, this resource has a required set of references to either a document or resource. This is not applicable to this usecase since there is no reference to actual instances, just information about kinds of information in the registry. Tom will contact SD to talk about relaxing this cardinality. We also suspect that this will lead to a discussion about renaming the resource to e.g. "ContentManifest".

Item 3 - Versioning of endpoints and instances

A continuation of our discussion in Madrid.

Jenny, Kevin and Lenel put forward that some kind of versioning indication seems useful. Agree to have Grahame finish the whitepaper on versioning AND pilot some approaches (amongst which the mime-type based one, akin to GitHub) during the January connectathon. Lots of interest during the meeting. Chris Grenz' blog about this subject highlights another aspect of versioning, that we did not get into.

Thu Q2

Chair: Josh Mandel Scribe: Josh Mandel

SMART Ballot Theme: offline_access

Discussion of the use cases for "online_access" and "offline_access" scopes, both of which are intended to convey a request for a refresh token. We discussed that offline_access is intended to result in a refresh token that lasts for an indefinite period of time; while online_access is intended to result in a refresh token that lasts for less time -- just enough to support the current user session, where the mechanism for determining exactly how to accomplish this is up to the EHR (e.g. it could be based on session activity, or continued use of an access token, or clock time, etc).

Vote recorded in spreadsheet: Dennis Patterson / Michael Donnelly 10/0/2


SMART Ballot Theme: Extension URL Space

We discussed the use of the "smarthealthit.org" domain in extension URLs for the SMART app launch specification. We decided not to change these to "hl7.org", with the goal of maintaining backward compatibility -- but we decided to deprecate these extensions from the CapabilityStatement (by moving them to a .well-known discovery document) and to ensure that in the meantime we can publish proper StructureDefinitions describing these extensions. We also discussed the format of the new discovery document.

Vote recorded in spreadsheet: 2017-09-14 Isaac Vetter / Reuben Daniels 11-0-1


SMART Ballot Theme: Where can Confidential clients run

We began a discussion about relaxing our advice about confidential clients to include the possibility that confidential clients may be able to run on mobile devices in appropriate circumstance.s

Thu Q3

Chair: Josh Mandel Scribe: Josh Mandel

Block Vote

We completed the September Block Vote (as submitted to the FHIR-I mailing list on 2017-09-04).

Ewout Kramer / Richard Ettema 7-0-3


SMART Ballot Theme: Where can confidential apps run?

We completed a discussion about where confidential apps can run, with a vote to incorporate updated language indicating that, with appropriate conditions, confidential apps can run on a mobile device.

Vote recorded in spreadsheet: Christiaan Knaap / Isaac Vetter 10-0-1


SMART Ballot Theme: Person in OIDC

We discussed the use of the Person resource in conveying details about the signed-in user who launches an app.

Vote recorded in spreadsheet:

Dennis Patterson / Reuben Daniels 8-0-3


SMART Ballot Theme: "issuer" discovery

We discussed the process for discovering the "issuer" associated with a SMART EHR. "Follow the OIDC protocol. We noted that information about the token URI, authorize URI, registration URI, and OIDC Issuer URI are available in the ${FHIR Base}/.well-known/smart-configuration as well as ${Issuer}/.well-known/openid-configuration .

Vote recorded in spreadsheet:

Isaac Vetter / Dennis Patterson 10-0-2


SMART Ballot Theme: OIDC Requirements

We discussed the specific subset of OpenID Connect that is necessary for SMART support. We agreed on a set of clarifications to include in the specification.

Vote recorded in spreadsheet:

Michael Donnelly / Ewout Kramer 7-0-5