FHIR Chat · Sept Connectathon track · subscriptions

Stream: subscriptions

Topic: Sept Connectathon track

Isaac Vetter (May 30 2017 at 20:00):

@Brian Postlethwaite (new) , @Alexander Henket , @Christiaan Knaap, @Danielle Friend, @Ewout Kramer - We talked about starting a connectathon track for FHIR subscriptions in Sept. Connectathon tracks should be submitted by next Wednesday. The rough proposal below limits us to only creating the resource and only sending/receiving a full FHIR resource (instead of a ping).

What do you think? Are you still interested / available in working on this? Who else would be interested?

Expected Participants:

• Brian Postlethwaite
• Alexander Henket
• Christiaan Knapp
• Ewout Kramer?
• ?

Roles:

• FHIR Subscriptions server
  ** The FHIR Server supports the Subscription resource and pushing relevant FHIR resources to client.

• FHIR Subscribing client
  ** Subscribes to FHIR server and gets updates.

Scenarios:

• Create FHIR Subscription
  ** Action: Support Subscription resource writes.
  ** Precondition: n/a
  ** Success Criteria: Client POSTs new subscription resource to FHIR server. FHIR server persists active subscription resource.
  ** Bonus Point: FHIR server support searching and reading Subscription resources.

• REST Hook with payload of "payload": "application/fhir+json"
  ** Action: Support pushing FHIR resources.
  ** Precondition: n/a
  ** Success Criteria: FHIR server pushes FHIR payload of relevant resource using REST Hook.
  ** Bonus point: n/a

Grahame Grieve (May 31 2017 at 01:13):

I am an expected participant.

Grahame Grieve (May 31 2017 at 01:13):

thanks.

Grahame Grieve (May 31 2017 at 01:28):

however this is just purely testing existing functionality, right?

Grahame Grieve (May 31 2017 at 01:29):

I'd like to test event based subscriptions, rather than the current search based subscription

Christiaan Knaap (May 31 2017 at 14:10):

Thanks for the mention. I intend to have Vonk do this as well. @Grahame Grieve : what do you mean by event based subscriptions? Are you referring to the Messaging part of Subscription (http://www.hl7.org/implement/standards/fhir/subscription.html#2.46.6.4) ?

Christiaan Knaap (May 31 2017 at 14:13):

I am also interested to see whether longer running subscriptions are useful without means of communicating that a resource has 'left' the criteria because it was deleted or updated in a way that it no longer matches the criteria. I bring this up because adding this to the handling of subscriptions might complicate the implementation. Is anyone interested in trying to make this work (not sure we have enough time to do so).

Grahame Grieve (May 31 2017 at 20:30):

in Madrid, we spoke about changing the way the criteria from 'when a search set changes' - which has the problem you just identified, and other implementation issues, to an event based approach where you write some criteria (fhirpath, probably) against previous + current in order to define which events you want to know about

Grahame Grieve (May 31 2017 at 20:30):

I'd like to implement that, using an extension on the Subscription resource

Grahame Grieve (Jun 07 2017 at 20:28):

@Isaac Vetter @Christiaan Knaap @Brian Postlethwaite @Danielle Friend @Alexander Henket @Bryn Rhodes any one has any specific proposals for connectathon scenarios?

Isaac Vetter (Jun 07 2017 at 21:55):

Grahame - I'm working on somenow now (at the last minute).

An extension to the Subscription resource that supports events/topics could look like this:

"criteria": "Patient/123",
"extension": {[
"url": "http://hl7.org/fhir/subscription/topics",
"valueCode": {
"value": "admit",
"display": "patient admitted",
"system" : "https://www.hl7.org/fhir/subscriptions/topics"
}
]
}

Isaac Vetter (Jun 07 2017 at 21:58):

I think that it would be important for the FHIR server to inform the subscribing client of the event/topic that occurred, so I'm not sure that an empty POST message would be enough. The full payload method would be straightforward, though.

Grahame Grieve (Jun 07 2017 at 23:39):

I think it would be a full payload, yes

Grahame Grieve (Jun 07 2017 at 23:40):

but I have no idea what your fragment above does

Danielle Friend (Jun 07 2017 at 23:41):

Grahame, what would your extension look like?
My understanding of Isaac's is that it would allow for servers and clients to subscribe to a known list of discrete events very simply and direct, because it has more structure. Yours would be less structured and would allow for any event/change that you could dream up.
Does that seem like an accurate comparison? In Isaac's example of an event=admit, Grahame, how would you represent such a request to subscribe to patient admissions?

All that to say, this seems like a really interesting track, and a good place to see both approaches in action.

Grahame Grieve (Jun 07 2017 at 23:44):

so the logic is implicit in Isaac's proposal? that has both advantages and disadvantages.

Grahame Grieve (Jun 07 2017 at 23:46):

as far as subscribing to patient admissions, what does that actually mean? Once we have figured out what that actually means, then I would be able to think about how I would represent that.

Grahame Grieve (Jun 07 2017 at 23:46):

does it mean 'let me know about all inpatient episode changes'?

Danielle Friend (Jun 07 2017 at 23:52):

<didn't reply in the right place!>
Sure, I think a maybe more common example would be - let me know when a patient is admitted to this department.
Such as the ED department

Isaac Vetter (Jun 07 2017 at 23:54):

Right. I think that we should make events very discrete and the FHIR server simply describes the list of events that it supports.

Here's the above extension fragment in a full FHIR subscription resource:

Example subscription resource with proposed extension:
{
"resourceType": "Subscription",
"criteria": "Patient/123",
"extension": {[
"url": "http://hl7.org/fhir/subscription/topics",
"valueCode": {
"value": "admit",
"display": "patient admitted",
"system" : "https://www.hl7.org/fhir/subscriptions/topics"
}
]
}
"channel": {
"type": "rest-hook",
"endpoint": "https://biliwatch.com/customers/mount-auburn-miu/on-result",
"payload": "application/fhir+json"
}
}

Grahame Grieve (Jun 07 2017 at 23:58):

well, here's the explicit version:

Grahame Grieve (Jun 07 2017 at 23:58):

{
  "resourceType": "Subscription",
  "id": "example",
  "status": "requested",
  "reason": "Monitor all admissions to Emergency",
  "criteria": "Encounter?",
  "extension" : [{
    "url" : "http://healthintersections.com.au/fhir/subscription-event-filter",
    "valueString" : "(current | previous).location.where(location = "Location/emergency" and status in ['active', 'completed'] ).exists()"
  }]
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://biliwatch.com/customers/mount-auburn-miu/on-result",
    "payload": "application/fhir+json",
    "header": [
      "Authorization: Bearer secret-token-abc-123"
    ]
  }
}

Grahame Grieve (Jun 07 2017 at 23:59):

making the events very discrete, so the server can limit what it offers makes for less work on the server, but restricts the client's capabilities greatly

Grahame Grieve (Jun 08 2017 at 00:07):

@Bryn Rhodes does CQL have a suitable resource for defining a set of event triggers so that we can have our cake and eat it too? or do we need an EventDefinition resource?

Isaac Vetter (Jun 08 2017 at 00:37):

Hey Grahame, your FHIRPath extension seems to be modeling a search criteria more than an event. I think that an event is a name for a thing that happens in the world, or at least in a user's workflow.

The FHIRPath approach is, at best, a language for modeling events.

No doubt you're right that not giving the client a flexible language for defining eventsrestricts their abilities, but it's too large of a burden on the server. In practice, we'd have to severely limit the FHIRPath that we supported to map to a set of pre-defined clinical events. Exposing the actual events, in a standard way is more transparent to the client.

Grahame Grieve (Jun 08 2017 at 00:39):

'more transparent'? how?

Grahame Grieve (Jun 08 2017 at 00:39):

though I agree with the impact on the server. Except that for me, the FHIRPath way is easier ;-)

Grahame Grieve (Jun 08 2017 at 00:41):

and no, my approach is not a search criteria - it's something that fires on changes to encounter, and evaluates before and after

Isaac Vetter (Jun 08 2017 at 00:45):

Except that for me, the FHIRPath way is easier ;-)

Yeah, I caught that. :)

An ED admit (or transfer or discharge) is an important thing that happens in the real world. Is this:

"valueString" : "(current | previous).location.where(location = "Location/emergency" and status in ['active', 'completed'] ).exists()"

how we should model this well known event?

Grahame Grieve (Jun 08 2017 at 00:46):

well strictly, this is 'notify me of changes to encounter where the location is or was emergency, and the encounter is a real encounter (e.g. not just a plan)'

Isaac Vetter (Jun 08 2017 at 00:46):

Also, I think that your approach, assumes that a clinical system is a database of FHIR resources, which isn't the case outside of middle-ware, reference implementations and other specialized HIT software.

Grahame Grieve (Jun 08 2017 at 00:47):

I don't think my approach assumes that, just that there's a translation layer somewhere.

Grahame Grieve (Jun 08 2017 at 00:47):

the middle ground, that there's a formal definition you can refer to, allows that translation layer to be a human

Grahame Grieve (Jun 08 2017 at 00:48):

the classic v2 approach is to use hand-wavy narrative like 'An ED admit (or transfer or discharge)' and then let all the systems interpret that slightly differently, so that implementations are actually all unsafe

Isaac Vetter (Jun 08 2017 at 00:50):

That's kind of compelling, but doesn't make it easy for me at all.

Do you think that the same point applies to this: https://github.com/cds-hooks/docs/wiki/Proposed-Hooks ?

Grahame Grieve (Jun 08 2017 at 00:51):

well, I think they need formal definitions. but it's possibly less important there because there's a human in the picture, and they are believed to be able to check the system. Back end subscriptions, you don't have chance to find out what you don't know

Grahame Grieve (Jun 08 2017 at 00:52):

but inasmuch as that isn't a characteristic of many users ('the system is god') then more formal definitions will be necessary

Isaac Vetter (Jun 08 2017 at 00:52):

I guess I'd say that we've spend a bunch of time refining our definitions of the hand-wavy industry events for all kinds of reasons (including the support of HL7v2) and now have a pretty decent implementation.

Grahame Grieve (Jun 08 2017 at 00:53):

you do. But your business rules probably differ from anyone else

Grahame Grieve (Jun 08 2017 at 00:53):

looking at the hook definitions, most the -view stuff is pretty straight forward. The change ones are much more challenging

Isaac Vetter (Jun 08 2017 at 00:55):

I was thinking that one of the use-cases for subscriptions might be "application synchronization", such that an event could be defined, similar to cds hooks, but on the backend. I think that a FHIRPath approach would preclude that.

Grahame Grieve (Jun 08 2017 at 00:56):

why would it preclude that?

Isaac Vetter (Jun 08 2017 at 00:58):

Using FHIRPath assumes that the FHIR server's resources are accurately modeling the events that the FHIR subscription server is pushing to clients. For "workflow" type events (e.g. user opens a patient's chart), I don't see how a FHIR client could learn that such an event happened by simply performing reads against the server.

Grahame Grieve (Jun 08 2017 at 00:58):

AuditEvent. If you surface that, that is

Grahame Grieve (Jun 08 2017 at 01:00):

but what I am proposing specifically is that we have a list of events, back them with a formal definition, an d then servers are free to use the formal definition directly if they can, else they implement, but conformance would be tested against the formal definition

Isaac Vetter (Jun 08 2017 at 01:01):

Okay.

What does the FHIR client specify when creating the subscription?

Grahame Grieve (Jun 08 2017 at 01:03):

reference to the definition, or maybe include the definition as a contained resource? Need to talk to Bryn to see if there is already something existing? but I don't think there is. Just some infrastructure. That would mean creating an EventDefinition resource to refer to, and then we could consider doing formal definitions for the cds-hooks events as well

Isaac Vetter (Jun 08 2017 at 01:05):

Alright. I can eventually implement that.

What are the next steps for a connectathon track? I'd like to keep the goals as simple and pragmatic as possible.

Grahame Grieve (Jun 08 2017 at 01:06):

and for the connectation, you'd have:

{
  "resourceType": "Subscription",
  "criteria": "n/a",
  "extension": {[
    "url": "http://hl7.org/fhir/StructureDefinition/subscription-event",
    "valueUri": "http://hl7.org/fhir/EventDefinition/admit"
  }],
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://biliwatch.com/customers/mount-auburn-miu/on-result",
    "payload": "application/fhir+json"
  }
}

Grahame Grieve (Jun 08 2017 at 01:07):

if we liked it after the connectathon, I'd propose making event a normal property of Subscription.

Isaac Vetter (Jun 08 2017 at 01:07):

Yes, definitely.

Grahame Grieve (Jun 08 2017 at 01:08):

let's see what I come up with Bryn before we decide which way to go

Grahame Grieve (Jun 08 2017 at 01:08):

though the formal deadline for connectathon proposals was today, we only had about half of them so we extended

Isaac Vetter (Jun 08 2017 at 01:08):

Oh good.

Isaac Vetter (Jun 08 2017 at 01:08):

Till when?

Grahame Grieve (Jun 08 2017 at 01:09):

forget. Another week? not sure

Isaac Vetter (Jun 08 2017 at 01:10):

I talk to Bryn fairly often, I can ask him about his thoughts on an EventDefinition resource, modify the track proposal and post it here by ... Monday.

Grahame Grieve (Jun 08 2017 at 01:10):

ok great

Isaac Vetter (Jun 08 2017 at 01:10):

thanks, Grahame.

Grahame Grieve (Jun 08 2017 at 01:11):

I think it would find wider use - from MessageDefinition, from CapabilityStatement, for cds-hooks, and in the security stuff maybe. Unless all those are pushed into Subscription

Isaac Vetter (Jun 08 2017 at 01:13):

I see subscriptions as FHIR's backend pub sub model and CDS Hooks as limited and very targeted remote, user-facing, real-time, cds.

Grahame Grieve (Jun 08 2017 at 01:14):

it might not possible to use the same language to describe the front end hooks. but I suspect some formal language will be required

Isaac Vetter (Jun 08 2017 at 01:16):

mapping the ad-hoc, CDS Hooks defined hooks into an EventDefinition resource would be a elegant way to formalize the definitions of these hooks for systems/people that needed/wanted that formalization if it didn't impact the straightforward usabilility of the CDS Hooks spec.

Grahame Grieve (Jun 08 2017 at 01:17):

we certainly don't want to impact that. But getting the hook definitions and implementation consistent will inevitably be a tax on the implementers, in that they will actually have to get it right.

Grahame Grieve (Jun 08 2017 at 01:18):

this is the sort of thing that the spec can't drive, though - it can make it possible to correctly know what implementing a hook correctly means, but only the market can make it worth while actually getting it right

Isaac Vetter (Jun 08 2017 at 01:19):

Yeah, i think this issue is making your point about consistency and accuracy: https://github.com/cds-hooks/docs/issues/39

Grahame Grieve (Jun 08 2017 at 01:23):

y

Bryn Rhodes (Jun 08 2017 at 02:15):

We used to have a TriggerDefinition data type, but we only used it one place (in PlanDefinition), so we collapsed back to just an element there. But I've often thought that the Subscription could make use of the same information.

Bryn Rhodes (Jun 08 2017 at 02:16):

It would be pretty easy to take the TriggerDefinition components and turn that into a datatype and then a resource that could use it.

Grahame Grieve (Jun 08 2017 at 02:17):

it's already a data type

Grahame Grieve (Jun 08 2017 at 02:17):

but the definition is very weak. we'd have to beef it up considerably

Grahame Grieve (Jun 08 2017 at 02:17):

the event timin part - is that relevant for a subscription?

Grahame Grieve (Jun 08 2017 at 02:18):

and you can only filer by codes or date?

Bryn Rhodes (Jun 08 2017 at 02:18):

Yes, it's intentionally restricted to simplify implementation.

Bryn Rhodes (Jun 08 2017 at 02:18):

It basically maps to a B-Tree for codes and dates.

Bryn Rhodes (Jun 08 2017 at 02:19):

You can express anything you need to on top of that with a query, but by restricting the requirement to that, you simplify the implementation.

Bryn Rhodes (Jun 08 2017 at 02:19):

That's the data access layer for a CQL engine.

Grahame Grieve (Jun 08 2017 at 02:20):

that simplification doesn't work for subscription, though

Bryn Rhodes (Jun 08 2017 at 02:20):

Not sure about the timing part, it'd be cool, I guess, you could effectively turn any FHIR server into a scheduling service :)

Bryn Rhodes (Jun 08 2017 at 02:22):

I agree it doesn't give you as formal a description as your wanting for the events (in terms of detecting a change), you'd have to provide that in addition, or maybe as another kind of trigger?

Grahame Grieve (Jun 08 2017 at 02:22):

anyway, where we stand is, there isn't an existing resource for the task, but there is an existing data type that is useful, but not complete for the prupose

Bryn Rhodes (Jun 08 2017 at 02:27):

So should I put together an EventDefinition resource proposal that covers the current plus this more complete use case (fully formal description of the event)?

Grahame Grieve (Jun 08 2017 at 02:33):

sure, why not? we can argue about that...

Christiaan Knaap (Jun 12 2017 at 12:20):

Not sure how many '...Definition' resource types we should create. And that made me think about what we actually want to reuse.
As for DataRequirement: Would it be possible to capture the dateFilter and codeFilter of DataRequirement in fhirpath as well?
And if so, I was thinking of a way to do reuse with fhirpath expressions, that can have a name (or probably a uri).

These named fhirpath expressions could then be used for:
- defining triggers
- maybe defining _elements, or parts of a GraphDefinition
- expressing support for events in a CapabilityStatement (e.g. Isaac will support the event with the fhirpath named 'patient admittance')
- optimizing implementation (e.g. for triggers or searches that happen very often)

Generic fhir servers like Grahame's, HAPI and Vonk will probably use the expression that goes with the name, but fhir interfaces on specific systems could just use the name and implement it 'hard coded' based on the meaning (that is still defined by the expression).

Isaac Vetter (Jun 12 2017 at 15:13):

Not sure how many '...Definition' resource types we should create. And that made me think about what we actually want to reuse.

Hey @Christiaan Knaap , Totally agree that there are a number of uses for eventdefinitions.

Isaac Vetter (Jun 12 2017 at 15:13):

How are they created?
1) For heavily prototyped use-cases, we should publish implementation guides around standardly named events and standardly defined fhirpath statements.

2) A subscription client should be able to create a new EventDefinition on the server (if the server supports that) and then subscribe to that recently defined event.

3) A subscriptions FHIR server should publish the EventDefinitions that it supports.

Isaac Vetter (Jun 12 2017 at 17:44):

Hey @Grahame Grieve , All,

Given an EventDefinition resource as discussed by Bryn and Grahame, here's a sample Subscription resource with an extension that points to an event:

Example subscription resource with proposed extension:
{
"resourceType": "Subscription",
"criteria": "Patient/123",
"extension": {[
"url": "http://hl7.org/fhir/subscription/topics",
"valueReference": {
"reference": "https://example.com/EventDefinition/123",
"display": "patient admitted",
}
]
}
"channel": {
"type": "rest-hook",
"endpoint": "https://biliwatch.com/customers/mount-auburn-miu/on-result",
"payload": "application/fhir+json"
}
}

Isaac Vetter (Jun 12 2017 at 17:44):

And a connectrathon track proposal:

Submitting WG/Project/Implementor Group
• FHIR-I

Justification
The current FHIR Subscriptions spec is based around the idea that a clinical system uses FHIR resources as its native database format and executes subscribed FHIR queries against every resource as it's created or modified. This would work well for custom built middleware and FHIR reference implementations, but generally not for systems that implement clinical workflow.

I think that most clinical systems, mine included, are event-based. An implementable subscription criteria would rather be based on an event and then narrowed to specific attributes/criteria.

The subscription pub/sub pattern enables FHIR clients to retrieve data from a server without performing a more expensive periodic polling queries. This model also enables workflow event-based notifications that could keep two applications data in sync, but also synchronize their context. There's no lightweight, widely implemented CCOW-type application synchronization standards available to developers. There's some interest within the RIS/PACS community to identify a common standard.

This track will attempt to prototype this event-based concept on top of the existing FHIR Subscription REST hook and criteria element. Further, as a stretch goal, this connectathon will attempt to prototype this workflow synchronization using FHIR Subscriptions.

Expected Participants:

• Brian Postlethwaite
• Alexander Henket
• Christiaan Knapp
• Grahame Grieve
• Will Maethner
• TBD PACS developers

Roles:
1) FHIR Subscriptions server
a. The FHIR Server supports the Subscription resource and pushing relevant FHIR resources to client.
2) FHIR Subscribing client
a. Subscribes to FHIR server and gets updates.

Scenarios:
1) Create FHIR Subscription
a. Action: Support Subscription resource writes using the topic extension, as illustrated, below.
b. Precondition: n/a
c. Success Criteria: Client POSTs new subscription resource to FHIR server. FHIR server persists active subscription resource.
d. Bonus Point: FHIR server support searching and reading Subscription resources.

2) REST Hook with payload of "payload": "application/fhir+json"
a. Action: Support pushing FHIR resources.
b. Precondition: n/a
c. Success Criteria: FHIR server pushes FHIR payload of relevant resource using REST Hook when the subscribed event occurs in the FHIR server.
d. Bonus point: n/a

3) Subscribe to a REST Hook of "patientchartopen"
a. Action: Subscribing app creates Subscription with an extended topic that means that a patient chart was opened in the EHR FHIR server in a specific Location. FHIR Server notifies app of the patient chart that was opened.
b. Precondition: Subscription resource support.
c. Success Criteria: Subscribing app is notified of the event.
d. Bonus point: FHIR server has a prototyped EventDefinition resource that defines a patient chart being opened.

Grahame Grieve (Jun 13 2017 at 03:30):

I don't follow the CCOW reference - how's that relevant?

Grahame Grieve (Jun 13 2017 at 03:31):

my server is also event based even though it's natively FHIR internally btw

Grahame Grieve (Jun 13 2017 at 03:31):

I'm good with the rest of the stream description - can we move it to the wiki?

Grahame Grieve (Jun 13 2017 at 03:32):

and thanks

Grahame Grieve (Jun 13 2017 at 03:32):

@Christiaan Knaap - FHIRPath is a nice way to say some things, but it's really hard to reverse engineer into 'do this to produce the right stuff' - so we should not use it where we can avoid it

Christiaan Knaap (Jun 13 2017 at 08:10):

@Grahame Grieve - OK, so we settle for EventDefinition for now, without FHIRPath.
Track proposal looks good. Only thing I don't know is how I would recognize that 'a patient chart was opened in the EHR' in a generic FHIR server. Does that result in an AuditEvent? In other words: on what criteria would I then send a notification? Or should I ignore this one, since Vonk is not an EHR?

Christiaan Knaap (Jun 13 2017 at 08:18):

As for CCOW: that was designed for tracking and syncing state, whereas I see subscription being designed for tracking and syncing data. Track part 3) seems also to be about syncing state. It may turn out to be confusing to have these two concepts supported by one solution (Subscriptions), if we even manage to make it work.

Bryn Rhodes (Jun 13 2017 at 20:11):

Actually, we were thinking of an EventDefinition that used FHIRPath, just not exclusively. So a named event, but that has an expression as a FHIRPath change detection.

Bryn Rhodes (Jun 13 2017 at 20:12):

At least, that's the EventDefinition I'm currently building.

Grahame Grieve (Jun 13 2017 at 22:47):

I think that makes sense. Say what you can say in a structured form, and say the rest using an expression

Grahame Grieve (Jun 13 2017 at 22:47):

that's my preference.

Isaac Vetter (Jun 14 2017 at 21:55):

Hey @Christiaan Knaap , yes, we can represent a "openpatientchart" even with an AuditEvent.

Isaac Vetter (Jun 14 2017 at 21:56):

I'll remove the CCOW reference from the justification and try to get it posted on the connectathon wiki page (just asked webmaster@hl7 for a login).

Grahame Grieve (Jun 14 2017 at 22:24):

@Isaac Vetter let me know if there isn't a timely response on thta

Josh Mandel (Jun 15 2017 at 00:27):

This is awesome! Is there a proposed way to say "on chart open for any patient"? Would you just say "criteria: Patient" instead of "criteria: Patient/123"? Also is there an example of what an EventDefiniton would look like? I'm a little lost on that.

Grahame Grieve (Jun 15 2017 at 01:37):

we haven't put that together yet.

Bryn Rhodes (Jun 30 2017 at 00:17):

Here's the above example rendered in a draft EventDefinition resource: http://build.fhir.org/eventdefinition-example.xml.html

Grahame Grieve (Jun 30 2017 at 10:50):

it's not clear to me why the definition of an event has a time period - does the event somehow change outside that period?

Grahame Grieve (Jun 30 2017 at 10:51):

I don't follow why contributers. What would it mean to be a contributer

Grahame Grieve (Jun 30 2017 at 10:52):

I don't follow the use case for relatedArtifact

Grahame Grieve (Jun 30 2017 at 10:54):

I don't understand the interplay between event timing and data requirement date elements

Grahame Grieve (Jun 30 2017 at 10:54):

shouldn't eventCondition.language be a code bound to mime type?

Grahame Grieve (Jun 30 2017 at 10:54):

that's what we've done elsehwere

Grahame Grieve (Jun 30 2017 at 10:56):

what kind of languages do we anticipate here?

Bryn Rhodes (Jun 30 2017 at 21:54):

effectivePeriod, contributors, and relatedArtifacts are because those are common fields for knowledge resources. I questioned whether they would be applicable here or not (there's a TODO on them), but left them in for discussion. It may be that an EventDefinition is a simple enough resource that it would never need/require the types of governance and management typically associated with knowledge management.

Bryn Rhodes (Jun 30 2017 at 21:55):

As far as the interplay between event timing and data requirements, the eventTiming element is only used for Periodic events, and the dataRequirements element is only used for Data-Added/updated/removed events.

Bryn Rhodes (Jun 30 2017 at 21:56):

Yes, eventCondition.language should be bound to a mime type, I'll make that change throughout.

Bryn Rhodes (Jun 30 2017 at 21:57):

As far as language, we currently expect FHIRPath and CQL, but you could probably use XPath too.

Grahame Grieve (Jun 30 2017 at 22:02):

I think there's a little more to say about the language. In particular, there's the idea of the delta between current and previous versions being meaningful in this context

Grahame Grieve (Jun 30 2017 at 22:02):

critical, in fact

Grahame Grieve (Jun 30 2017 at 22:02):

I'm not sure I have my head around periodic events. What's an example of that?

Bryn Rhodes (Jun 30 2017 at 22:21):

Agree on establishing that delta is available, it's effectively a data-updated event, we've just also named it, which makes me question the usefulness of the type discriminator.

Bryn Rhodes (Jun 30 2017 at 22:21):

For periodic events, the idea is to support scheduled items, such as "check this lab result daily"

Grahame Grieve (Jun 30 2017 at 22:34):

I think I'm troubled by the different between the definition of what an event is, and the application of asking for event notifications. this resource seems to mix these things

Bryn Rhodes (Jul 02 2017 at 05:08):

I see the Subscription resource as the one that asks for event notifications, where EventDefinition only describes what an event is. What aspects of EventDefinition are troubling?

Isaac Vetter (Sep 01 2017 at 14:29):

Hi @Grahame Grieve , @Bryn Rhodes , All,

@Niklas Svenzén and team spent some time at Epic, with myself and @Will Maethner , last week to successfully prototype a PACS<-> EHR context synchronization using FHIR Subscriptions. We're continuing this testing next week and at the connectathon.

We started with AuditEvent for modeling context sync events, such as "patient chart opened", but quickly exceeded it. We spec'd out a new resource, UserSession, which defines a user interacting with an application, its status and the primary context for their session. This UserSession resource enables context synchronization within the existing FHIR Subscription specification.

We think that this new resource , used within FHIR Subscriptions, is the best approach for a context synchronization specification in FHIR and there's active interest in making this happen.

Can you guide us on the draft resource, below, and how to move forward, in general?

Isaac Vetter (Sep 01 2017 at 14:30):

pasted-image.png

Jens Villadsen (Sep 06 2017 at 20:58):

To do more CCOW-ish user synchronization you would need a 2-phase commit / accept to change context. Is that something anyone has considered?

Isaac Vetter (Sep 06 2017 at 21:03):

Hey @Jens Villadsen , a strict CCOW context synchronization in FHIR would also require an independent context manager. It seems like a relatively simple post of a changed event fits into the existing subscriptions spec fairly well.

I thought that your description yesterday of how outbound events could be ordered, and I think guaranteed as well applies here. What do you think?

Jens Villadsen (Sep 06 2017 at 21:08):

@Isaac Vetter not sure I'm following ... my desc. from yesterday described a guaranteed ordered event stream from the server to the client which could be used to signal that (in a true CCOW-FHIR-like setup) a client would like to do something about the context

Jens Villadsen (Sep 06 2017 at 21:11):

now following a ccow setup, other clients also subscribing on the usersession would all need to somehow signal to the manager (POSTing) their acceptance and only after all had accepted the context could be changed

Isaac Vetter (Sep 06 2017 at 21:15):

Yeah, you're right. Unlike CCOW, using FHIR Subscriptions for context sync would be a dictatorship instead of democractic model.

The problems with the democratic model is that the entire integration is held back to the performance of the slowest app.

In practice, in our experience at least, CCOW isn't as widely implemented by a large number of similar, proprietary context sync specs. Supporting context sync functionality becaomes a massive task when we have to support many proprietary specs.

We think that there's room for a simple, re-usable context synchronization specification ... perhaps even without all the features of CCOW.

Jens Villadsen (Sep 06 2017 at 21:15):

@Isaac Vetter guaranteed order is not part of the existing subscription resource AFAIK. As the connection from the server to the client using a simple rest-hook is not 'dedicated/reserved/statefull' order is not necessarily guaranteed. Using a web socket or server sent events you are at least guaranteed that there will only be a single channel for you as a client that you need to look into

Jens Villadsen (Sep 06 2017 at 21:18):

@Isaac Vetter right ... dictating instead of democratizing - ... I get it. Its a more simple model which could work in a lot of cases.

Grahame Grieve (Sep 08 2017 at 03:29):

@Isaac Vetter sorry finally getting to this - I've been on the road all week travelling.

Grahame Grieve (Sep 08 2017 at 03:29):

I think it's a very interesting idea, and I think that the requirements are valid

Grahame Grieve (Sep 08 2017 at 03:29):

but I worry that the solution is actually out of scope for FHIR

Grahame Grieve (Sep 08 2017 at 03:35):

how would you use this outside the context of synchronising a session? What's it's relationship with AuditEvent?

Grahame Grieve (Sep 08 2017 at 03:36):

also, user may not correspond to a known FHIR entity. It makes us really need a User resource, which we've always avoided as truly out of scope

Isaac Vetter (Sep 09 2017 at 16:13):

Good Morning Everybody!

The FHIR Subscriptions table is up front, come join us if you're interested.

We're having a breakout session right after general announcements in Palatine A.

Isaac Vetter (Sep 09 2017 at 19:06):

Hey Everybody, you can create a Subscription FHIR resource on Epic's prtotype here: https://connectathon.epic.com/Interconnect-Fhir-Basic/api/FHIR/STU3/Subscription

You need to authenticate with HTTP Basic auth, here's the username: "emp$1685477" and password "epic77", so a successfully HTTP Header, looks like this:

User-Agent: Fiddler
Content-type: application/fhir+json
Host: connectathon.epic.com
Authorization: Basic ZW1wJDE2ODU0Nzc6ZXBpYzc3
Content-Length: 357

Grahame Grieve (Sep 09 2017 at 19:06):

what topics can you use?

Isaac Vetter (Sep 09 2017 at 19:08):

Here's a sample Subscription resource, that's still got some dummy content:

{
"resourceType": "Subscription",
"criteria": "Patient/123",
"channel": {
"type": "rest-hook",
"endpoint": "https://biliwatch.com/customers/mount-auburn-miu/on-result",
"payload": "application/fhir+json"
},
"id": "00000000007C2DCBF35FA1921026459D",
"extension": [{
"valueReference": {
"reference": "https://example.com/EventDefinition/123",
"display": "patient admitted"
},
"url": "http://hl7.org/fhir/subscription/topics"
}]
}

Isaac Vetter (Sep 09 2017 at 19:09):

How about just using https://example.com/EventDefinition/123 as the topic, for now.

Nick Hatt (Sep 09 2017 at 20:43):

Hi all - redox is accepting new subscriptions at POST https://ab6b2d27.ngrok.io/fhir/Subscription/new
not picky about what the topic is
Authentication - add a verification-token header with a value of redox

Nick Hatt (Sep 09 2017 at 22:14):

GET https://ab6b2d27.ngrok.io/fhir/EventDefinition now works too!

Grahame Grieve (Sep 09 2017 at 22:52):

yay, after several hours investigating the wrong problem, I've found the simple misconfiguration issue, and my R4 server is up at http://test.fhir.org/r4

Grahame Grieve (Sep 09 2017 at 22:52):

it does subscriptions completely (I think)

Bill Harty (Sep 10 2017 at 17:09):

it does subscriptions completely (I think)

Having trouble adding a subscription to your server. Getting this error:

"Unable to read Document - starts with "testing" at Row 1 column 8"

Seems like it's expecting XML. I'm POSTing the JSON below, with a header of Content-Type: application/json+fhir

{
"resourceType": "Subscription",
"meta": {
"versionId": "agatha-1",
"lastUpdated": "2017-06-30T14:58:58.041+00:00"
},
"text": {
"status": "generated",
"div": "testing"
},
"criteria": "Patient?family=SMITH",
"reason": "Test subscription for Sept connectathon",
"status": "requested",
"extension": [
{
"url": "http://hl7.org/fhir/subscription/topics",
"valueReference": {
"reference": "https://example.com/EventDefinition/123",
"display": "patient admitted"
}
}
],
"channel": {
"type": "rest-hook",
"endpoint": "http://pinc-fhir.us-east-1.elasticbeanstalk.com/agatha/payload/patient",
"payload": "application/json",
"header": "Authorization: Bearer secret-token-abc-123"
}
}

Bill Harty (Sep 10 2017 at 17:10):

oops, maybe a probelm with my DIV. let me fix that

Christiaan Knaap (Sep 10 2017 at 17:10):

You can test Vonk's subscription feature by POSTing a subscription to http://vonk.furore.com/administration/Subscription. Afterwards, you can send a create/update matching the subscription to the regular FHIR endpoint at http://vonk.furore.com (without the /administration)

Niklas Svenzén (Sep 10 2017 at 17:11):

Hey Will, here is the UserSession I just sent you:

{"resourceType":"UserSession","id":"0000000000F7AE2BF35FA1921026459D","action":"R","recorded":"2017-08-22T19:08:18Z","agent":[{"requestor":"true","network":{"address":"172.17.72.98"}}],"source":{"identifier":{"value":"Epic"}},"entity":[{"identifier":{"value":"6116494"},"type":{"system":"http://hl7.org/fhir/resource-types","code":"Patient"}}]}

Grahame Grieve (Sep 10 2017 at 17:19):

this works:

Grahame Grieve (Sep 10 2017 at 17:19):

{
"resourceType": "Subscription",
"meta": {
"versionId": "agatha-1",
"lastUpdated": "2017-06-30T14:58:58.041+00:00"
},
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">testing</div>"
},
"criteria": "Patient?family=SMITH",
"reason": "Test subscription for Sept connectathon",
"status": "requested",
"extension": [
{
"url": "http://hl7.org/fhir/subscription/topics",
"valueReference": {
"reference": "https://example.com/EventDefinition/123",
"display": "patient admitted"
}
}
],
"channel": {
"type": "rest-hook",
"endpoint": "http://pinc-fhir.us-east-1.elasticbeanstalk.com/agatha/payload/patient",
"payload": "application/json",
"header": ["Authorization: Bearer secret-token-abc-123"]
}
}

Isaac Vetter (Sep 10 2017 at 17:37):

Hey Everybody - I'm putting together our track presentation. If you're not at the table in the front and worked on FHIR Subscriptions -- will you pm me or come talk to me?

Bill Harty (Sep 10 2017 at 18:11):

You can test Vonk's subscription feature by POSTing a subscription to http://vonk.furore.com/administration/Subscription. Afterwards, you can send a create/update matching the subscription to the regular FHIR endpoint at http://vonk.furore.com (without the /administration)

patient id = 015ce2b1-f03d-431e-a0af-473723fdd6c3

Isaac Vetter (Sep 10 2017 at 19:19):

Hey Everybody - you can see our Sept connectathon track presentation here: https://drive.google.com/open?id=0B3gH07JzlFotSDhnM1pHamlRRlU

Great work this weekend!

Last updated: Apr 12 2022 at 19:14 UTC