Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update 2-3-Events.md #605

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update 2-3-Events.md #605

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions input/pagecontent/2-3-Events.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,9 +19,9 @@ Field | Optionality | Type | Description
`versionId` | Conditional| string | A string displaying the context's version ID. `versionId` SHALL be present for *-update events.
`priorVersionId` | Optional | string | A string displaying the context's previous version ID.

The notification's `hub.event` and `context` fields inform the Subscriber of the current state of the user's session. The `hub.event` is a user workflow event, from the [Event Catalog](3_Events.html) (or an organization-specific event in reverse-domain name notation). The `context` is an array of named FHIR resources (similar to [CDS Hooks's context](https://cds-hooks.hl7.org/1.0/#http-request_1) field) that describe the current content of the user's session. Each event in the [Event Catalog](3_Events.html) defines what context is included in the notification. The context contains zero, one, or more FHIR resources. Subscribers SHALL accept a full FHIR resource as defined in the Event Catalog.
The notification's `hub.event` and `context` fields inform the Subscriber of the current state of the user's session. The `hub.event` is a user workflow event, from the [Event Catalog](3_Events.html) (or an organization-specific event in reverse-domain name notation). The `context` is an array of named FHIR resources (similar to [CDS Hooks's context](https://cds-hooks.hl7.org/2.0/#http-request_1) field) that describe the current content of the user's session. Each event in the [Event Catalog](3_Events.html) defines what context is included in the notification. The context contains zero, one, or more FHIR resources. Subscribers SHALL accept a full FHIR resource as defined in the Event Catalog.

The Subscriber requesting a context change SHALL ensure consistency of the FHIR resources in the `context` array. For example, the Hub will not check that the Patient resource in an Encounter-open `context` array is in fact the patient associated with the encounter in the real world.
The Subscriber requesting a context change SHALL ensure consistency of the FHIR resources in the `context` array. For example, the Hub is not required to check that the Patient resource in an Encounter-open `context` array is in fact the patient associated with the encounter in the real world.

### Event name

Expand Down Expand Up @@ -58,17 +58,17 @@ The key used for indicating a context change event's FHIR resource SHALL be the

References to resources other than anchor resources SHALL be named any string which is not a value from the resource type valueset.

In the case in which other events are deriveable from the event in question, additional non-anchor FHIR resources included in the event SHALL be named what they are named in the deriveable event.
In the case in which other events are derivable from the event in question, additional non-anchor FHIR resources included in the event SHALL be named what they are named in the derivable event.

The Hub SHALL only return FHIR resources that the Subscriber is authorized to receive with the existing OAuth 2.0 access_token's granted `fhircast/` scopes.
The Hub SHALL only return FHIR resources that the Subscriber is authorized to receive with the granted OAuth 2.0 access_token's granted `fhircast/` scopes.

### Event types

The FHIRcast specification supports many different events. These events are defined in the [event catalog](3_Events.html). The events can be grouped in different types. The following sections define the characteristics of these different event-types.
The FHIRcast specification supports many different events. These events are defined in the [event catalog](3_Events.html). The events can be grouped into different types. The following sections define the characteristics of these different event-types.

#### Context-change events

FHIRcast context-change events that describe context changes SHALL conform to the following extensible syntax. Patterned after the SMART on FHIR scope syntax and expressed in EBNF notation, the FHIRcast syntax for context-change related event names is:
FHIRcast context-change events that describe context changes SHALL conform to the following extensible syntax. The FHIRcast syntax for context-change related event names is:

```ebnf
ContextChangeEventName ::= ( FHIRresource ) '-' ( 'open' | 'close' )
Expand All @@ -82,7 +82,7 @@ In the case the resource refers to other FHIR resources that represent their own

FHIRcast defines profiles for FHIR resources used in `*-open` and `*-close` events documented in the [`event catalog`](3_Events.html). Each resource used to establish context has a profile for when that resource is used in an `*-open` event and a different profile for when that resource is used in a `*-close` event. The profiles for *-`open` events mandate more attributes than those for `*-close` events since all Subscribers need enough information to identify the appropriate information associated with the context resource(s) in their application enabling them to participate in a common context.

FHIRcast does not mandate that contextual subjects have any FHIR persistance; sufficient information to establish a common context may simply be exchanged using FHIR resources as the structure to hold the necessary information without the resources ever existing in a FHIR server (in fact it may be that there is no FHIR server in the infrastructure associated with any Subscriber synchronizing in a FHIRcast topic). As this is an FHIR R4 implementation guide, all profiles and examples conform to FHIR R4 resource specifications. Where relevant/required, notes have been added to the description of the resource profiles indicating how to use the resources in a FHIRcast session using FHIR R5-based resources.
FHIRcast does not mandate that contextual subjects have any FHIR persistence; sufficient information to establish a common context may simply be exchanged using FHIR resources as the structure to hold the necessary information without the resources ever existing in a FHIR server (in fact it may be that there is no FHIR server in the infrastructure associated with any Subscriber synchronizing in a FHIRcast topic). As this is an FHIR R4 implementation guide, all profiles and examples conform to FHIR R4 resource specifications. Where relevant/required, notes have been added to the description of the resource profiles indicating how to use the resources in a FHIRcast session using FHIR R5-based resources.

__`*-open` Event Resource Profiles:__
* [`Patient`](StructureDefinition-fhircast-patient-open.html)
Expand Down Expand Up @@ -116,7 +116,7 @@ ContentSharingEventName ::= ( FHIRresource ) '-' ( 'update' )

{% include img.html img="ContentSharingEventName.png" caption="Figure: Content sharing event-name specification" %}

`*-update` events provide a mechanism to share content in the context of an `anchor context` (see [`anchor context`](5_glossary.html)). `*-update` events update the content within the specified anchor context; said another way, most `*-update` events are not changing the `anchor context` resource rather creating, modifying, or removing the content within the `anchor context`. A Subscriber shares content related to the anchor context by providing FHIR resource(s) in a `Bundle` contained in the `updates` key of a `*-update` event. See [`Content Sharing`](2-10-ContentSharing.html) for a comprehensive description of `*-update` events. The FHIRresource indicates the anchor context in which content is being shared.
`*-update` events provide a mechanism to share content in the context of an `anchor context` (see [`anchor context`](5_glossary.html)). `*-update` events update the content within the specified anchor context; said another way, `*-update` events are not changing the `anchor context` resource rather creating, modifying, or removing the content within the `anchor context`. A Subscriber shares content related to the anchor context by providing FHIR resource(s) in a `Bundle` contained in the `updates` key of a `*-update` event. See [`Content Sharing`](2-10-ContentSharing.html) for a comprehensive description of `*-update` events. The FHIRresource indicates the anchor context in which content is being shared.

The `context` element in an update event SHALL contain at least two fields. One with the name of the `FHIRresource` which holds the anchor context and one named `updates` holding a single `Bundle` resource with entries holding the content being shared. The `Bundle` resource SHALL conform to the [FHIRcast content update Bundle](StructureDefinition-fhircast-content-update-bundle.html) profile.

Expand Down
Loading