FHIR Chat · fhircast-docs / Issue #108 May 2019 Ballot Comment: Provi... · fhircast-github

Stream: fhircast-github

Topic: fhircast-docs / Issue #108 May 2019 Ballot Comment: Provi...

---

Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):

hl7-fhircast-bot opened Issue #108

## May 2019 Ballot Comment: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Submitted by Mitra Rocca; Terrie Reed
Chapter/section: Overall
Url: https://fhircast.hl7.org/
Type: A-S

Summary: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Comment: Since the "hub.topics" are meant to be events, it would be useful to create a hierarchy of events using a BNF grammar similar SMRT clinical context scopes. For instance: "session.*" hub.topic scope would correspond to all session-related events or alterantively an could subscribe to either "Session.close" or "session.change". Similarly the "hub.topic" could be centered on a a FHIR resource - similar to SMART scoes - "patient.selected" , "device.selected". The lesson of CCOW is that standardizeding the "contexts" and creating an extensible grammar/sytax are both needed for adption. Pub/sub topics provide a similar hierarchical approach to "topic" definitons.

---

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

Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):

hl7-fhircast-bot labeled Issue #108

## May 2019 Ballot Comment: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Submitted by Mitra Rocca; Terrie Reed
Chapter/section: Overall
Url: https://fhircast.hl7.org/
Type: A-S

Summary: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Comment: Since the "hub.topics" are meant to be events, it would be useful to create a hierarchy of events using a BNF grammar similar SMRT clinical context scopes. For instance: "session.*" hub.topic scope would correspond to all session-related events or alterantively an could subscribe to either "Session.close" or "session.change". Similarly the "hub.topic" could be centered on a a FHIR resource - similar to SMART scoes - "patient.selected" , "device.selected". The lesson of CCOW is that standardizeding the "contexts" and creating an extensible grammar/sytax are both needed for adption. Pub/sub topics provide a similar hierarchical approach to "topic" definitons.

---

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

Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):

hl7-fhircast-bot edited Issue #108

## May 2019 Ballot Comment: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Submitted by Mitra Rocca; Terrie Reed
Chapter/section: Overall
Url: https://fhircast.hl7.org/
Type: A-S

Summary: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Comment: Since the "hub.topics" are meant to be events, it would be useful to create a hierarchy of events using a BNF grammar similar SMRT clinical context scopes. For instance: "session.*" hub.topic scope would correspond to all session-related events or alterantively an could subscribe to either "Session.close" or "session.change". Similarly the "hub.topic" could be centered on a a FHIR resource - similar to SMART scoes - "patient.selected" , "device.selected". The lesson of CCOW is that standardizeding the "contexts" and creating an extensible grammar/sytax are both needed for adption. Pub/sub topics provide a similar hierarchical approach to "topic" definitons.

---

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

Github Notifications (FHIRcast) (Jul 15 2019 at 22:03):

isaacvetter commented on Issue #108:

This comment proposes a substantive change. The current FHIRcast events are named in the specification and effectively "hardcoded" and aren't otherwise parsable by a machine. The use and creation of new standard events would necessitate updating the spec.

Proposed resolution: Persuasive with Mod
Proposed comment: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification and use it simply as guidance, not specification content.

FHIRcast hub.topic's are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.topic ::= ( fhir-resource ) '.' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.topic and by the FHIR Patient resource, if the workflow related event is related to a single patient.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('.'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #142, #128, ...

Github Notifications (FHIRcast) (Jul 15 2019 at 22:04):

isaacvetter labeled Issue #108:

## May 2019 Ballot Comment: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Submitted by Mitra Rocca; Terrie Reed
Chapter/section: Overall
Url: https://fhircast.hl7.org/
Type: A-S

Summary: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Comment: Since the "hub.topics" are meant to be events, it would be useful to create a hierarchy of events using a BNF grammar similar SMRT clinical context scopes. For instance: "session.*" hub.topic scope would correspond to all session-related events or alterantively an could subscribe to either "Session.close" or "session.change". Similarly the "hub.topic" could be centered on a a FHIR resource - similar to SMART scoes - "patient.selected" , "device.selected". The lesson of CCOW is that standardizeding the "contexts" and creating an extensible grammar/sytax are both needed for adption. Pub/sub topics provide a similar hierarchical approach to "topic" definitons.

---

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

Github Notifications (FHIRcast) (Jul 16 2019 at 11:52):

isaacvetter edited a comment on Issue #108:

This comment proposes a substantive change. The current FHIRcast events are named in the specification and effectively "hardcoded" and aren't otherwise parsable by a machine. The use and creation of new standard events would necessitate updating the spec.

Proposed resolution: Persuasive with Mod
Proposed comment: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification and use it simply as guidance, not specification content.

FHIRcast hub.topic's are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.topic ::= ( fhir-resource ) '.' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.topic and by the FHIR Patient resource, if the workflow related event is related to a single patient.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
1) Syntax: How does this proposed syntax impact our proposed OAuth scopes in #127 (and #105)? If a hub.topic looks like: Patient.open, would the scope look like: fhircast/Patient.open.read ? The re-use of the period in the topic stomps on SMART's existing use of the period and potentially complicates parsing of the scope syntax.

2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('.'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #142, #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 12:15):

isaacvetter commented on Issue #108:

Considerations on hub.events syntax for compatibility with SMART scopes

SMART uses a right slash (/) and period (.) to demarcate computable pieces of a scope:

This comment proposes turning our each event in hub.events into a two-part computable string. Other comments (#127, #105) suggest exposing these events and the ability to receive or send them as OAuth2 scopes.

What event syntax would be easy for developers, future-proof against SMART scope syntax changes and elegant?

Some possibilities:

• hub.events=Patient|open with a corresponding scope of fhircast/Patient|open.read?
• fhircast/Patient$open.read
• fhircast/Patient,open.read
• fhircast/Patient~open.read
• fhircast/Patient:open.read (Let's assume that SMART will use a colon in the future).
• fhircast/Patient_open.read
• fhircast/Patient+open.read
• fhircast/Patient-open.read

Here's an excellent overview of (surprisingly non-standard) OAuth scope syntaxes across the internet.

Here's the most relevant part of RFC 6749:

The value of the scope parameter is expressed as a list of space-
delimited, case-sensitive strings. The strings are defined by the
authorization server. If the value contains multiple space-delimited
strings, their order does not matter, and each string adds an
additional access range to the requested scope.

scope       = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

Github Notifications (FHIRcast) (Jul 16 2019 at 12:16):

isaacvetter edited a comment on Issue #108:

This comment proposes a substantive change. The current FHIRcast events are named in the specification and effectively "hardcoded" and aren't otherwise parsable by a machine. The use and creation of new standard events would necessitate updating the spec.

Proposed resolution: Persuasive with Mod
Proposed comment: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification and use it simply as guidance, not specification content.

FHIRcast events (as communicated in hub.events) are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.events ::= ( fhir-resource ) '.' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.events and by the FHIR Patient resource, if the workflow related event is related to a single patient.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
1) Syntax: How does this proposed syntax impact our proposed OAuth scopes in #127 (and #105)? If a hub.events looks like: Patient.open, would the scope look like: fhircast/Patient.open.read ? The re-use of the period in the topic stomps on SMART's existing use of the period and potentially complicates parsing of the scope syntax.

2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('.'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #142, #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 12:17):

isaacvetter edited a comment on Issue #108:

This comment proposes a substantive change. The current FHIRcast events are named in the specification and effectively "hardcoded" and aren't otherwise parsable by a machine. The use and creation of new standard events would necessitate updating the spec.

Proposed resolution: Persuasive with Mod
Proposed comment: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification and use it simply as guidance, not specification content.

FHIRcast events are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.events ::= ( fhir-resource ) '.' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.events and by the FHIR Patient resource, if the workflow related event is related to a single patient.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
1) Syntax: How does this proposed syntax impact our proposed OAuth scopes in #127 (and #105)? If a hub.events looks like: Patient.open, would the scope look like: fhircast/Patient.open.read ? The re-use of the period in the topic stomps on SMART's existing use of the period and potentially complicates parsing of the scope syntax.

2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('.'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #142, #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 12:34):

isaacvetter edited a comment on Issue #108:

# Considerations on hub.events syntax for compatibility with SMART scopes

SMART uses a right slash (/) and period (.) to demarcate computable pieces of a scope:

This comment proposes turning our each event in hub.events into a two-part computable string. Other comments (#127, #105) suggest exposing these events and the ability to receive or send them as OAuth2 scopes.

What event syntax would be easy for developers, future-proof against SMART scope syntax changes and elegant?

Some possibilities:

• hub.events=Patient|open with a corresponding scope of fhircast/Patient|open.read?
• fhircast/Patient$open.read
• fhircast/Patient,open.read We're already using a comma to separate events in hub.events.
• fhircast/Patient~open.read
• fhircast/Patient:open.read (Let's assume that SMART will use a colon in the future).
• fhircast/Patient_open.read
• fhircast/Patient+open.read
• fhircast/Patient-open.read

Here's an excellent overview of (surprisingly non-standard) OAuth scope syntaxes across the internet.

Here's the most relevant part of RFC 6749:

The value of the scope parameter is expressed as a list of space-
delimited, case-sensitive strings. The strings are defined by the
authorization server. If the value contains multiple space-delimited
strings, their order does not matter, and each string adds an
additional access range to the requested scope.

scope       = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

## Where and how does a FHIRcast implementer use these events?

hub.events is a comma-delimited list of events communicated as a form parameter in a POST (and therefore url-encoded) during:

• Subscription Request
• Unsubscribe

hub.events is a comma-delimited list of events communicated as a querystring parameter in a GET (and therefore url-encoded) during:

• Subscription Denial
• Intent Verification Request

hub.event is a json element communicated in an HTTP Post as part of the:

• Event Notification
• Request Context Change
• Query for Current Context

## Conclusion
A simple dash is elegant, already in use by our legacy scope names, doesn't conflict with SMART, compatible with url encoding. We'll just need to change the name of our "meta" sync-error event to use the dash as part of our computable syntax --

Github Notifications (FHIRcast) (Jul 16 2019 at 12:35):

isaacvetter edited a comment on Issue #108:

This comment proposes a substantive change. The current FHIRcast events are named in the specification and effectively "hardcoded" and aren't otherwise parsable by a machine. The use and creation of new standard events would necessitate updating the spec.

Proposed resolution: Persuasive with Mod
Proposed comment: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification and use it simply as guidance, not specification content. sync-error will be renamed to syncerror.

FHIRcast events are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.events ::= ( fhir-resource ) '-' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.events and by the FHIR Patient resource, if the workflow related event is related to a single patient.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
1) Syntax: How does this proposed syntax impact our proposed OAuth scopes in #127 (and #105)? If a hub.events looks like: Patient.open, would the scope look like: fhircast/Patient.open.read ? The re-use of the period in the topic stomps on SMART's existing use of the period and potentially complicates parsing of the scope syntax.

2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('.'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #142, #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 12:37):

isaacvetter edited a comment on Issue #108:

This comment proposes a substantive change. The current FHIRcast events are named in the specification and effectively "hardcoded" and aren't otherwise parsable by a machine. The use and creation of new standard events would necessitate updating the spec.

Proposed resolution: Persuasive with Mod
Proposed comment: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification and use it simply as guidance, not specification content. sync-error will be renamed to syncerror.

FHIRcast events are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.events ::= ( fhir-resource ) '-' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.events and by the FHIR Patient resource, if the workflow related event is related to a single patient.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
1) Syntax: How does this proposed syntax impact our proposed OAuth scopes in #127 (and #105)? If a hub.events looks like: Patient.open, would the scope look like: fhircast/Patient.open.read ? The re-use of the period in the topic stomps on SMART's existing use of the period and potentially complicates parsing of the scope syntax.

2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('-'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #142, #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 12:39):

isaacvetter commented on Issue #108:

Proposed resolution: Persuasive with Mod
Proposed comment: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification and use it simply as guidance, not specification content. sync-error will be renamed to syncerror.

FHIRcast events are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.events ::= ( fhir-resource ) '-' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.events and by the FHIR Patient resource, if the workflow related event is related to a single patient.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('-'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #142, #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 12:39):

isaacvetter edited a comment on Issue #108:

This comment proposes a substantive change. The current FHIRcast events are named in the specification and effectively "hardcoded" and aren't otherwise parsable by a machine. The use and creation of new standard events would necessitate updating the spec.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
1) Syntax: How does this proposed syntax impact our proposed OAuth scopes in #127 (and #105)? If a hub.events looks like: Patient.open, would the scope look like: fhircast/Patient.open.read ? The re-use of the period in the topic stomps on SMART's existing use of the period and potentially complicates parsing of the scope syntax.

2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('-'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #142, #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 13:20):

isaacvetter edited a comment on Issue #108:

This comment proposes a substantive change. The current FHIRcast events are named in the specification and effectively "hardcoded" and aren't otherwise parsable by a machine. The use and creation of new standard events would necessitate updating the spec.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
1) Syntax: How does this proposed syntax impact our proposed OAuth scopes in #127 (and #105)? If a hub.events looks like: Patient.open, would the scope look like: fhircast/Patient.open.read ? The re-use of the period in the topic stomps on SMART's existing use of the period and potentially complicates parsing of the scope syntax.

2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('-'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 13:20):

isaacvetter edited a comment on Issue #108:

Proposed resolution: Persuasive with Mod
Proposed comment: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification and use it simply as guidance, not specification content. sync-error will be renamed to syncerror.

FHIRcast events are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.events ::= ( fhir-resource ) '-' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.events and by the FHIR Patient resource, if the workflow related event is related to a single patient.

_Outstanding Questions_
1) Can sync-error be made to fit into this syntactical model?
2) Is the guidance to SHALL send Patient if there's a single patient appropriate?

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('-'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #128, ...

Github Notifications (FHIRcast) (Jul 16 2019 at 16:29):

ElliotSilver commented on Issue #108:

That's a great syntax for things that map directly to a single FHIR resource. What is the plan for things that don't map so closely, "open image" being the obvious one. How about "worklist in focus"?

Github Notifications (FHIRcast) (Jul 17 2019 at 13:44):

gkustas commented on Issue #108:

Comment: Since the "hub.topics" are meant to be events,

I must be missing something. This is a syntax for event naming, not topics right? The hub.topic is the session identifier, that is, the user. Not events, correct?

Github Notifications (FHIRcast) (Jul 17 2019 at 14:35):

isaacvetter commented on Issue #108:

Wg discussion:

• We could modify the open|close to include an "update" (or CRUD) action.
• Ultimately, we should preserve the ability to create new events as needed, outside of the FHIR data model.
• Note that the syncerror event does include OperationOutcome.
• the "open" and "close" events mustn't modify data to enable stable implementations.
• Why should the Patient resource be required on an ImagingStudy event, but not the ImagingStudy on a ... Observation event?

Github Notifications (FHIRcast) (Jul 17 2019 at 14:40):

isaacvetter commented on Issue #108:

## :telephone_receiver: II Working Group Vote (6-16-2019)

Meeting notes: https://confluence.hl7.org/display/IMIN/Teleconferences

@NiklasSvenzen moved the following disposition, seconded by @gkustas

Disposition: : Persuasive with Mod
Disposition Comment:: We will create a simple syntax for FHIRcast events modeled after SMART's scope syntax and based upon FHIR resources. Except for the "meta" sync-error event, we will move the Event Catalog out of the specification. sync-error will be renamed to syncerror. Per other comments, we will also define a process for the publishing of new events within the Event Catalog.

FHIRcast events are an extensible syntax based upon FHIR resources, following the SMART on FHIR scope syntax.

Expressed in EBNF notation, the FHIRcast syntax for workflow related events is:

hub.events ::= ( fhir-resource ) '-' ( 'open' | 'close' )


The event notification or request for context change message SHALL be accompanied by the fhir-resource named in the hub.events. Further, the Event Catalog may define additional resources to be included within the event.

Disposition: 
Disposition Comment:

:+1: For: 14
:expressionless: Abstain: 0
:-1: Against: 0

:tada: The motion passed! :tada:

---

• svg generated from railroad diagrams%2C%0A%20%20Choice(0%2CNonTerminal('-'))%2C%0A%20%20Choice(0%2CNonTerminal('open')%2CNonTerminal('close')%20%20)%2C%0A)%0A)
• relevant to: #128, ...

Github Notifications (FHIRcast) (Jul 17 2019 at 14:40):

wmaethner labeled Issue #108:

## May 2019 Ballot Comment: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Submitted by Mitra Rocca; Terrie Reed
Chapter/section: Overall
Url: https://fhircast.hl7.org/
Type: A-S

Summary: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Comment: Since the "hub.topics" are meant to be events, it would be useful to create a hierarchy of events using a BNF grammar similar SMRT clinical context scopes. For instance: "session.*" hub.topic scope would correspond to all session-related events or alterantively an could subscribe to either "Session.close" or "session.change". Similarly the "hub.topic" could be centered on a a FHIR resource - similar to SMART scoes - "patient.selected" , "device.selected". The lesson of CCOW is that standardizeding the "contexts" and creating an extensible grammar/sytax are both needed for adption. Pub/sub topics provide a similar hierarchical approach to "topic" definitons.

---

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

Github Notifications (FHIRcast) (Sep 11 2019 at 20:50):

wmaethner closed Issue #108:

May 2019 Ballot Comment: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Submitted by Mitra Rocca; Terrie Reed
Chapter/section: Overall
Url: https://fhircast.hl7.org/
Type: A-S

Summary: Provide etensible syntax for "hub.topic" scopes similar to SMART scopes and consistent with Pub/Sub event processing best-practices. This grammar could be used ot create an extensible event catalog.

Comment: Since the "hub.topics" are meant to be events, it would be useful to create a hierarchy of events using a BNF grammar similar SMRT clinical context scopes. For instance: "session.*" hub.topic scope would correspond to all session-related events or alterantively an could subscribe to either "Session.close" or "session.change". Similarly the "hub.topic" could be centered on a a FHIR resource - similar to SMART scoes - "patient.selected" , "device.selected". The lesson of CCOW is that standardizeding the "contexts" and creating an extensible grammar/sytax are both needed for adption. Pub/sub topics provide a similar hierarchical approach to "topic" definitons.

---

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

---

Last updated: Apr 12 2022 at 19:14 UTC