Difference between revisions of "FHIR Infrastructure Minutes WGM 201709"
Josh mandel (talk | contribs) (→Thu Q2) |
|||
(6 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: [ | + | 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 51: | Line 51: | ||
Adjornment 5:04 | Adjornment 5:04 | ||
− | == | + | ==Wed Q2== |
− | Chair: | + | Chair: Grahame Grieve |
− | Scribe: | + | 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 [https://drive.google.com/open?id=165BU5ZmUyuwxz4kg2dtjRWkNM7o4u2PrdcIKSxP94Ts 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. [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. | ||
+ | ==Thu Q2== | ||
+ | Chair: Josh Mandel | ||
+ | Scribe: Josh Mandel | ||
− | == | + | ===SMART Ballot Theme: offline_access=== |
− | Chair: | + | Discussion of the use cases for "online_access" and "offline_access" scopes, both of which are intended to |
− | Scribe: ? | + | 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
Contents
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