Attendees

See  FHIR-I Attendance_ bit.ly_fhiri - 201905.pdf

Agenda for WGM

http://wiki.hl7.org/index.php?title=FHIR_Agenda_201905_WGM

Monday Q1

Monday Q2

Monday Q3

Agenda: Tracker Items

20688: Does Resource.meta.source point to a system, or a full resource URI, or something else?

20332: Create a $restore operation


20947: Clarification on which operations can be included in a batch/transaction request

Monday Q4

FHIR-I w/CDS, II, MnM, OO

Agenda: FHIR Workflow, Objective FHIR

Notes:

Tuesday Q4

SDC Tracker items

19530: Document how to access variables created by the "variable" and "questionnaire-context"

20396: Move choice/open-choice out of Questionnaire.item.type, and add Coding

SIRB Project

SDC Ballot Rec

21376: Should disabled data be visible? - SDC #65

21377: Should non-enabled answers be removed? - SDC #66

Adjournment

Wednesday Q1

Co-chair: Josh Mandel

Minutes: Michael Donnelly

Pain points from the HL7 FHIR Connectathon this weekend:

Most real-world systems are broken down into topics and subscriptions; we want clear separation between those.
One topic can have multiple subscriptions.
Topics have been handled thus far as a Subscription linked to an EventDefinition

Good syntax and a framework will be better for R5 than what we have today.

Josh has a proposal to refactor FHIR subscriptions and test it out at the HL7 FHIR Connectathon before this fall's WGM.
https://docs.google.com/document/d/1rjOI49M-PBVDT7DpLT9LolV4e3qNU1jZbBKdxTwtRE8/edit

This won't use lots of extensions because there's a "developer ergonomics bias" against complicated structures like that.

We're looking at examples of subscription mechanisms that have topics with filters.

A trigger has:

A topic has a list of properties on which that topic can be filtered. These canFilterBy properties will be FHIR search criteria; but not all FHIR search criteria will filterable properties.

Once you create a topic, nothing happens until there's a subscription to that topic.

Topics can be server specific. If there are widely defined topics, a server will specify which of those it will support.

:checkbox: PARKING LOT: how do we align topics from server to server?

When a client wants to subscribe, it creates a subscription on the server. Much of this is like what we have today. Differences:

instead of search criteria, the client specifies the topic to which it wants to subscribe
it supplies a list of criteria for any filters defined in the topic
Topic has "canFilterBy" and Subscription has "filterBy"

(filterBy syntax can look a lot like FHIR search syntax)

How does a provider get notifications about patients he or she cares about?

Today you might be able to do something like "Encounter?patient:_has:Group:patient:_id=my-group"

With this proposal, you'd filterBy "matchType": "memberOfGroup" with "value": ["Group/my-high-risk-patients"]

:white_medium_square: PARKING LOT: Filter syntax
:checkbox: PARKING LOT: Scheduling use case

Previously, there was no clear way to learn about something falling out of your search set.

In the current system, when you have a REST hook channel, you specify a URL that the server treats as a FHIR base.

In this proposal, the server posts a bundle to that URL.

A FHIR server can parse the Bundle and use it. Other clients will know it'll get everything to the same place.

If a server only wants tobatch up notifications (e.g. twice a minute), it can put more things in the Bundle.

Bundles can handle deletes.

A client can say they only want the IDs and not the full resources.

Some clients want nothing - jsut getting pinged on the endpoint with an empty payload will let them know something happened.

The last case could be useful if the message is going through somewhere unsecure.

How does a Bundle do a delete?
Bundle.entry.request.method=DELETE

This Bundle is the server telling the client, "This is what you should execute to look like me."

But many clients don't want to look like the server.

Should this be a transaction bundle or a history bundle?

A transaction Bundle only allows you to send the request part.

So history is probably what we want. (Josh updated his Google doc)

How can a server detect deletes?

Before: Practitioner.org = 123
After: Practitioner.org:not=123

But the latter won't work because there's nothing to evaluate.

There's no resource to reason about.

Even with an implied search criterion of _id being the current context, nothing will ever be true (in FHIRpath) for it.

Maybe After: "$not-found"

?

Looks like in addition to Before and After with FHIRpath, we need boolean's of isDeletion and isCreation.

:star: For later follow up: we need syntax to address detection of deletion and creation in native FHIR servers.

Scheduling use case

A client wants to know about schedule slots - when it can schedule appointments

They're looking at Slots as a proxy for time periods that a Practitioner is available.

Subscribe to Slot where Practitioner=123

They get an update when the Slot changes

The client does a couple of queries.

The problem is that there's no Practitioner on Slot.

Idea: instead of subscribing to Slot, the client could subscribe to changes in Schedule for Practitioner, but when there's a change the client would requery for Slots for that Practitioner.

Canonical references

Josh would like an Argonaut IG to be able  point to topics out there somewhere.

url - server declares its own canonical url
instantiatesUrl - declare alignment with an official topic

Should a Subscription.topic be to a shared URL or one specific to the server?

:star: This remains an open question.

Filter Syntax

Should we have filters split out into separate JSON elements or combined into comma separated lists?

Arbitrary. The group has a weak preference for JSON, and we'll try that out first, but we're open to considering the other way in the future.

Motion: @Eric Haas moved/Michael Donnelly seconded:

Vote: 13/0/0


Considering Michele's alternate proposal


Details at https://github.com/CareEvolution/Public/blob/master/Subscriptions.md

Use a List for subscriptions.

Entries are added to or removed from the List by the server. (The mechanism for this is up to the server.)

> Michele Mottini: I have an alternative proposal: https://github.com/CareEvolution/Public/blob/master/Subscriptions.md (that is backward compatible, so it can be used in existing servers)

There could be a list of "Admissions in the last 24 hours"

Josh: Since the items in the list are patients, the list should be called "Patients who were admitted in the last 24 hours".

A client can subscribe to the List and get notification of changes to it.

In the example of "patients admitted in the last 24 hours", the list would be updated when a new patient is admitted or when a patient on that list has been admitted for more than 24 hours.

Josh: In my opinion, this doesn't address the core concerns we have including scalability.

JM: the list could get longer and longer over time.

Michele Mottini: It works for us - and we have some fairly large deployments

Michele Mottini: (fairly large = tens of million patients, billion of data points)

Q1 ended.

Wednesday Q2

Chair: Josh Mandel

Minutes: Ewout Kramer


Wednesday Q4

Chair: Josh Mandel

Minutes: Michael Donnelly

How should JWK Set caching work?
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=21751

How should JWK Set caching work?

Michael Donnelly moved and @Nick Robison seconded that we will add:

Passed 6/0/2

Optionality of security layer weakens interoperability
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=21695&start=0

There are some implementations that use creative mechanisms to download the bulk data files once they're generated. The SMART Backend Services guide was developed with this use case in mind.

Currently we're only recommending this. If SMART Backend Services doesn't meet a systems needs, we should improve that guide.

CMS doesn't have a way currently to do Bulk FHIR with OAuth 2 that meets their security and engineering goals.

Would CMS provide a different security layer in addition to OAuth 2. 0 or instead of it?

Instead.

Can CMS comment on the guide to try to enhance it to get it to meet their needs too?

Yes, that's why Nick is here this week.

Is Bulk Data different from the rest of FHIR? Is this more important here?

It's not more important, but this is an IG, so we need to get into more detail than the base spec needs.

Can we make a profile for the IG, where the profile defines the requirement to use OAuth 2.0 instead of the base IG?

Maybe? Seems confusing.

Could we say that servers either have to do OAuth 2.0 or CMS's delegated authorization scheme? And clients have to do whatever the server they're connecting to does?

What's CMS's issue? 
The ACOs they work with aren't downloading the data directly; third parties are doing it for them, so they need a way to say who's allowed to get the data for them.

Could we say that Bulk FHIR requires SMART Backend Services, and later CMS can incorporate delegated authorization into SMART Backend Services?

People seem to feel okay about that.

CMS could come back later to change either Bulk FHIR or SMART.

Healthy discussion about how much this should be locked down.

ONC could specify a requirement to use the Bulk Data IG and the SMART Backend Services Guide.

In practice, the security layer will be negotiated between parties.

There was a motion to require SMART Backend Services that died for lack of a second.

@Nick Robison moved to find the ballot comment not persuasive, @Javier Espina seconded. 
The motion passed with 3 votes for, 2 against, and 4 abstaining.

From Robert's Rules Of Order Newly Revised In Brief by Henry M. III Robert, William J. Evans, Daniel H. Honemann & Thomas J. Balch:

Do abstention votes count?

The phrase “abstention votes” is an oxymoron, an abstention being a refusal to vote. To abstain means to refrain from voting, and, as a consequence, there can be no such thing as an “abstention vote".

In the usual situation, where either a majority vote or a two-thirds vote is required, abstentions have absolutely no effect on the outcome of the vote since what is required is either a majority or two thirds of the votes cast. On the other hand, if the vote required is a majority or two thirds of the members present, or a majority or two thirds of the entire membership, an abstention will have the same effect as a “no” vote. Even in such a case, however, an abstention is not a vote.

Support encryption in bulk data
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=21051

CMS is working on per-client payload encryption.

Nobody else has had an issue with this yet; encryption in motion (TLS) is necessary but encryption at rest hasn't been needed for any other use cases.

Does FHIR support indicating that data are encrypted in the base FHIR spec?

No.

Should that be part of the Bulk FHIR spec?

That wouldn't drive implementers toward compatibility with the specification.

One thing that's tempting (but maybe not a good idea) would be to have an optional keyMap in the file to point at a descriptor about how to decrypt the file (e.g. a decryption algorithm and params).

CMS is happy to have conversation with the community about how to do this.

What was the threat assessment about this?
If someone gained access to the file system, unencrypted files could expose PHI.

If we're going to encrypt these files, we should have the opportunity to compress them first.

@Isaac Vetter moved to find the comment non-persuasive with mod and to revisit the topic when CMS brings back a proposal. @Chris Grenz seconded. The motion passed with 7 votes for, 0 against, and 2 abstaining.

Reconcile $export vs $everything
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=21050&start=0

$export is more specific than $everything (kind of)

$export means

$everything means

One view: $everything is for replicating a FHIR server. Converting from one system to another.

Does $everything set an inaccurate expectation for clients? Would they be disappointed if they asked for "everything" and just got USCDI?

Michael moved to find this non-persuasive. @Adam Culbertson seconded.
The motion passed with 4 votes for, 1 against, and 4 abstaining.

We will keep the $export name. Although the target data set is similar, the group sees different use cases for the operations.
Over time, $everything has adopted aspects of the $export operation. In the future, PA may want to more fully reconcile the $everything operations with $export.

Q4 ended. 

Thursday Q2

Chair: Ewout Kramer (until 11:54) then Lloyd McKenzie

Notes: Rick Geimer (until 11:50) then Ewout Kramer

Agenda: Bulk Data Ballot Rec


Combine group export overlap with the async workflow in R4 - BULKDATA #116
Combine patient export overlap with the async workflow in R4 - BULKDATA #115
Combine export overlap with the async workflow in R4 - BULKDATA #114


Clarify the scope of the authorization components and how it differs from the existing standard - BULKDATA #112

How do you specify the FHIR version to be used? - BULKDATA #58 

Incorrect input (IN) parameters are labeled as output (OUT) - BULKDATA #7

Clarify what date/time the _since flag uses. - BULKDATA #56

Can individual clinical provider credentials be used to initiate a bulk data export on all patients? - BULKDATA #55



A client is assigned an identifier. - BULKDATA #33

Healthcare orgs are already aware of their responsibility to protect PHI. Suggesting otherwise is silly. - BULKDATA #17

Transition to US Core FHIR IG - BULKDATA #51


Need to put actual ballot content into the ballot for github content - BULKDATA #50


IG should mandate that jku endpoint requires HTTPS, but not authnz. - BULKDATA #40


Why is OAuth2 / mutual TLS required authorization - BULKDATA #96

Bookmark to fine-grained permissions discussion

Add fine grained requests and permissions for the _typeFilter - BULKDATA   #85
Provide an example request with _typeFilter - BULKDATA #102
Does the inability to filter data potentially violate HIPAA's Minimum Necessary requirement? - BULKDATA #57
Provide an example request with _typeFilter - BULKDATA #102
Does _typeFilter support ALL FHIR query capabilities?
Suggest discussions with vendors trying to implement this feature and narrowing this down to what is viable prior to inclusion in IG. - BULKDATA #13
Drop _typeFilter parameter

Thursday Q3

Combine the async R4 details with this proposal due to mismatched parts of the specification - BULKDATA #97


Requesting dateTime instead of instant type for _since parameter - BULKDATA #4


Clarify if the use cases are using one or more specifications - BULKDATA #91


Required access token lifetime is inconsistent in IG. - BULKDATA #36


Include an example of an extension in the example. - BULKDATA #111


Use a table format to specify content, type, optionality and description of the result body like CDS Hooks. - BULKDATA #107


Is it mandatory behavior to support the bulk data files? - BULKDATA #106


How do you know what subset of fhir resources are returned - BULKDATA #101


Include the mime type application/fhir+json - BULKDATA #105


When a 200 OK is returned can the Response error be empty? - BULKDATA #104



Clarify if it is a "client-to-server" or "client-to-client" certificate - BULKDATA #47
Also: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=21739