May 2019 Ballot Comment: Is there a pre-defined syntax available for "hub.topics" and does it support a hierarachy of topics?

[hl7-fhircast-bot]

May 2019 Ballot Comment: Is there a pre-defined syntax available for "hub.topics" and does it support a hierarachy of topics?

Submitted by Greg Staudenmaier on behalf of @IoanaSingureanu ([email protected] )
Chapter/section:
Url:
Type: A-S
In Person requested: Yes 👤

Summary: Is there a pre-defined syntax available for "hub.topics" and does it support a hierarachy of topics?

Comment: It would be useful to have predifined syntax to allow subscribers to to wildcard experssions (e.g. patient/, session/ to specify events related to patietn or session changes)

---

This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet.

[wmaethner]

Hey @IoanaSingureanu

During conversation at the Montreal, May 2019 working group meeting, @wdvr, @isaacvetter , @NiklasSvenzen and myself talked through this issue.

A couple of points:

1. the hub.topic is the unique "session identifier", which the spec currently describes as a "unique, opaque identifier of the current user's session".
2. We think that you actually meant, hub.events in this comment, not hub.topic.

We are planning on defining a hub.topic syntax as well as guidance for the community to define and propose new events as mentioned in issue #213. This will follow a similar pattern to CDS hooks.

Proposed resolution: We will update how we create and define events. As for wildcarding, we expect the number of events to be relatively small so wildcards wouldn't add too much benefit. Also we prefer subscribers to explicitly state the events they want to prevent the chance of the subscribers receiving events they don't understand because the wildcard resulted in more than they expected.

Would be interested in yours and everyone else's thoughts.

[isaacvetter]

@IoanaSingureanu made the point in conversation at the WGM that events should be based upon FHIR resources.

[isaacvetter]

Consider how the SMART launch context parameters should continue into FHIRcast events. Ex: DeviceDefinition as context in the SMART scope, and therefore extended into FHIRcast events.

Proposed resolution: Persuasive with Mod.
Create a syntax and process for proposing and defining new events. Remove existing event catalog from base specification.

Ioana agrees that this is a duplicate of #165.

Resolved.