Skip to content

Conversation

@bvdh
Copy link
Collaborator

@bvdh bvdh commented Mar 28, 2023

Reformat event definition section and added specifiaction language on the names of keys in context-change events.

@bvdh bvdh requested review from EricOnFHIR and isaacvetter March 28, 2023 15:06
Copy link
Collaborator

@EricOnFHIR EricOnFHIR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some non-trivial questions we should discuss.


FHIRcast supports all events that follow this format. The most common events definitions have been provided in the [event catalog](3_Events.html).

#### Infrastructure events
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should UserHubernate and UserLogout events be here?

Upon communicating a `SyncError` resulting from an unresponsive Subscriber, the Hub SHALL unsubscribe the Subscriber.

The Hub SHALL NOT generate [`SyncError`](3-2-1-SyncError.html) events in the following situations:
The Hub SHALL NOT generate [`syncerror`](3-2-1-SyncError.html) events in the following situation:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be "SyncError" to be consistent with the sentences immediately above?

* Does a Hub send an `SyncError` for each Subscriber that cannot be reached or refused, or is the Hub allowed to combine them in one.
* When the Hub/Subscriber resends an context change event, is the `Heartbeat.html` still needed?
* Should a Subscriber get all syncerror's or only those related to events to which it subscribed?
* Does a Hub send an `syncerror` for each Subscriber that cannot be reached or refused, or is the Hub allowed to combine them in one.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confused about which we are going for: "SyncError" or "syncerror".

In 2.5.5, most of the occurrences are SyncError; however, here it seems like it was consciously changed to syncerror.

**Anchor Context** | a context that is used as a container for shared content, typical anchor contexts are FHIR resources such as `ImagingStudy` and `DiagnosticReport`

**Anchor Context** | a context that is used as a container for shared content, typical anchor contexts are FHIR resources such as Patient, Encounter, ImagingStudy, and DiagnosticReport
**Anchor resource** | a FHIR resource that is used as a container for shared content, typical anchor resource are resources such as Patient, Encounter, ImagingStudy, and DiagnosticReport
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there an Anchor resource? I thought throughout the spec we were using Anchor Context and it was fine. For what is Anchor resource used?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants