From e4793409a53baca512f91152c74739647d499c63 Mon Sep 17 00:00:00 2001 From: Isaac Vetter Date: Wed, 8 Oct 2025 10:31:16 -0500 Subject: [PATCH 1/7] FHIR ID handling --- input/pagecontent/2-6-SendEventNotification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/input/pagecontent/2-6-SendEventNotification.md b/input/pagecontent/2-6-SendEventNotification.md index 32b609b5..a2b187a5 100644 --- a/input/pagecontent/2-6-SendEventNotification.md +++ b/input/pagecontent/2-6-SendEventNotification.md @@ -4,7 +4,7 @@ The Subscriber MAY request a context change, content change, or `select` event b The Subscriber MAY request context changes with an HTTP POST to the `hub.url`. The Hub SHALL either accept this context change by responding with any successful HTTP status or reject it by responding with any 4xx or 5xx HTTP status. Similar to event notifications, described above, the Hub MAY also respond with a 202 (Accepted) status, process the request, and then later, instead of broadcasting the context change, responds with a `SyncError` event in order to reject the request. In this specific case in which the context change is rejected by the Hub and not broadcasted, the `SyncError` would only be sent to the requesting Subscriber. The Subscriber SHALL be capable of gracefully handling a rejected context request. -Once a requested context change is accepted, the Hub SHALL broadcast the context notification to all Subscribers, including the original requesting Subscriber. The requesting Subscriber can use the broadcasted notification as confirmation of their request. The Hub reusing the request's `id` is further confirmation to the requesting Subscriber that the event is a result of their request. +Once a requested context change is accepted, the Hub SHALL broadcast the context notification to all Subscribers, including the original requesting Subscriber. The requesting Subscriber can use the broadcasted notification as confirmation of their request. The Hub reusing the request's event `id` is further confirmation to the requesting Subscriber that the event is a result of their request. Note that a Hub MAY reassign logical FHIR IDs (see [conformance](2-7-Conformance.html) and [individual](3-3-1-Patient-open.html) [resources](3-5-1-ImagingStudy-open.html) [profiles](3-6-1-DiagnosticReport-open.html)).
{% include EventNotificationSequence.svg %} From 2b562f0541fb10ccd6db043a7485b669e9e4fdb3 Mon Sep 17 00:00:00 2001 From: Isaac Vetter Date: Wed, 8 Oct 2025 11:00:03 -0500 Subject: [PATCH 2/7] Update 2-7-Conformance.md --- input/pagecontent/2-7-Conformance.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/input/pagecontent/2-7-Conformance.md b/input/pagecontent/2-7-Conformance.md index fd92843f..59334bf3 100644 --- a/input/pagecontent/2-7-Conformance.md +++ b/input/pagecontent/2-7-Conformance.md @@ -28,6 +28,8 @@ Field | Optionality | Type | Description --------------------------- | ----------- | ----- | --- `supportsGetCurrentContext` | Optional | Boolean | `true` or `false` - indicating support for the "[Get Current Context](2-9-GetCurrentContext.html)" API. `supportsNonCurrentContextUpdates` | Optional | Boolean | `true` or `false` - indicating support for the "[Update Events Outside of Current Context](2-10-ContentSharing.html#experimental-capability--update-events-outside-of-current-context)" +`preservesFhirId` | Optional | Boolean | `true` or `false` - indicating that the Hub preserve the FHIR resources' logical FHIR IDs while broadcasting open events. If false, the Hub assigns a different FHIR ID and populates an additional business identifier with the value of the requesting subscriber's FHIR ID. See [Hub Generated FHIR IDs]([url](2-5-ReceiveEventNotification.html#hub-generated-fhir-ids)). + #### Wellknown endpoint discovery example @@ -70,3 +72,4 @@ FHIRcast defines profiles for various FHIR resource structures used in the speci In the context of FHIRcast, must support (MS) on any data element SHALL be interpreted to mean [FHIR’s MustSupport](https://www.hl7.org/fhir/conformance-rules.html#mustSupport). Generally, implementations are expected to: * if known and possible, populate supported data elements as part of the event notifications as specified by the FHIRcast profiles. * interpret missing, supported data elements within resource instances as data not present in the sending systems (or for which the requestor is unauthorized). + From fd2239fe9f7fd92d75ca9118821177525c4457c1 Mon Sep 17 00:00:00 2001 From: Isaac Vetter Date: Wed, 8 Oct 2025 11:49:58 -0500 Subject: [PATCH 3/7] Update 2-5-ReceiveEventNotification.md --- input/pagecontent/2-5-ReceiveEventNotification.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/input/pagecontent/2-5-ReceiveEventNotification.md b/input/pagecontent/2-5-ReceiveEventNotification.md index f1a70833..28023c5f 100644 --- a/input/pagecontent/2-5-ReceiveEventNotification.md +++ b/input/pagecontent/2-5-ReceiveEventNotification.md @@ -133,3 +133,15 @@ During a normal shutdown of a Subscriber, it SHALL unsubscribe, and provide a We If a Hub grants subscriptions to different sets of `hub.events` to different Subscribers for the same session, the Hub is responsible for generation of implied open events. Close events are typically not generated by the Hub. When distributing a received event, a Hub SHALL ensure open events for the referenced resource types of the received event are also sent to subscribers. Hubs SHOULD either support derived events or require that Subscribers are subscribed to the same context. Hubs SHOULD NOT generate and send duplicative events. + +## Subscriber compares identifiers to local data store + +Upon receiving an open event, a subscriber typically uses information in the FHIR resource to match to its own data. For example, upon receiving a `patient-open` a typical system will execute a patient matching algorithm using business identifiers (such as mrn) and demographics. Specific patient (or other) matching algorithms are out of scope for this IG. + +#### Hub Generated FHIR IDs + +During a FHIRcast session, any participating system could potentially request an open. As part of that open event, the requesting system assigns and sends a FHIRcast event id and for each FHIR resource: a logical FHIR ID and potentially many business identifiers. The event id generated by the requestor is broadcasted to subscribers by the Hub. Similarly, the business identifiers supplied by the requestor are also broadcast. If a Hub modifies the logical FHIR ID that's supplioedby the requestor, the Hub SHALL [advertise this behavior by setting the preservesFhirId capability in its conformance endpoint](2-7-Conformance.html). + + + + From 008536d5873d8ff35ddbcc0df5f1e218b7e28881 Mon Sep 17 00:00:00 2001 From: Isaac Vetter Date: Wed, 8 Oct 2025 14:27:53 -0500 Subject: [PATCH 4/7] Update input/pagecontent/2-5-ReceiveEventNotification.md --- input/pagecontent/2-5-ReceiveEventNotification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/input/pagecontent/2-5-ReceiveEventNotification.md b/input/pagecontent/2-5-ReceiveEventNotification.md index 28023c5f..02d17c14 100644 --- a/input/pagecontent/2-5-ReceiveEventNotification.md +++ b/input/pagecontent/2-5-ReceiveEventNotification.md @@ -140,7 +140,7 @@ Upon receiving an open event, a subscriber typically uses information in the FHI #### Hub Generated FHIR IDs -During a FHIRcast session, any participating system could potentially request an open. As part of that open event, the requesting system assigns and sends a FHIRcast event id and for each FHIR resource: a logical FHIR ID and potentially many business identifiers. The event id generated by the requestor is broadcasted to subscribers by the Hub. Similarly, the business identifiers supplied by the requestor are also broadcast. If a Hub modifies the logical FHIR ID that's supplioedby the requestor, the Hub SHALL [advertise this behavior by setting the preservesFhirId capability in its conformance endpoint](2-7-Conformance.html). +During a FHIRcast session, any participating system could potentially request an open. As part of that open event, the requesting system assigns and sends a FHIRcast event id and for each FHIR resource: a logical FHIR ID and potentially many business identifiers. The event id generated by the requestor is broadcast to subscribers by the Hub. Similarly, the business identifiers supplied by the requestor are also broadcast. If a Hub modifies the logical FHIR ID that's supplied by the requestor, the Hub SHALL [advertise this behavior by setting the `preservesFhirId` capability in its conformance endpoint](2-7-Conformance.html). From aae3c2da61b306e7222582de0efcaefd185b906f Mon Sep 17 00:00:00 2001 From: natan shpringman <55200920+shpringman@users.noreply.github.com> Date: Thu, 9 Oct 2025 12:18:01 -0500 Subject: [PATCH 5/7] Update 2-5-ReceiveEventNotification.md tweak formatting (add backticks to first open, capitalize Subscriber) and rework sentence for clarity --- input/pagecontent/2-5-ReceiveEventNotification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/input/pagecontent/2-5-ReceiveEventNotification.md b/input/pagecontent/2-5-ReceiveEventNotification.md index 02d17c14..ecbb11ba 100644 --- a/input/pagecontent/2-5-ReceiveEventNotification.md +++ b/input/pagecontent/2-5-ReceiveEventNotification.md @@ -140,7 +140,7 @@ Upon receiving an open event, a subscriber typically uses information in the FHI #### Hub Generated FHIR IDs -During a FHIRcast session, any participating system could potentially request an open. As part of that open event, the requesting system assigns and sends a FHIRcast event id and for each FHIR resource: a logical FHIR ID and potentially many business identifiers. The event id generated by the requestor is broadcast to subscribers by the Hub. Similarly, the business identifiers supplied by the requestor are also broadcast. If a Hub modifies the logical FHIR ID that's supplied by the requestor, the Hub SHALL [advertise this behavior by setting the `preservesFhirId` capability in its conformance endpoint](2-7-Conformance.html). +During a FHIRcast session, any participating system could potentially request an `open`. As part of that open event, the requesting system assigns and sends a FHIRcast event id for the overall event and a logical FHIR ID and potentially many business identifiers for each FHIR resource. The event id generated by the requestor is broadcast to Subscribers by the Hub. Similarly, the business identifiers supplied by the requestor are also broadcast. If a Hub modifies the logical FHIR ID that's supplied by the requestor, the Hub SHALL [advertise this behavior by setting the `preservesFhirId` capability in its conformance endpoint](2-7-Conformance.html). From cbfad3f26072852245c4562aac1074c48dbfe007 Mon Sep 17 00:00:00 2001 From: natan shpringman <55200920+shpringman@users.noreply.github.com> Date: Thu, 9 Oct 2025 12:23:11 -0500 Subject: [PATCH 6/7] make preservesFhirId required? From the SHALL phrasing in ReceiveEventNotification, we're saying setting preservesFhirId=`true` is required if you are preserving the FHIR ID. Should we go ahead and make the parameter Required? If not, should we add narrative somewhere to suggest that `preservesFhirId` can be treated as False by default? (maybe something that can be left to the implementer, too) --- input/pagecontent/2-7-Conformance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/input/pagecontent/2-7-Conformance.md b/input/pagecontent/2-7-Conformance.md index 59334bf3..0ead6e60 100644 --- a/input/pagecontent/2-7-Conformance.md +++ b/input/pagecontent/2-7-Conformance.md @@ -28,7 +28,7 @@ Field | Optionality | Type | Description --------------------------- | ----------- | ----- | --- `supportsGetCurrentContext` | Optional | Boolean | `true` or `false` - indicating support for the "[Get Current Context](2-9-GetCurrentContext.html)" API. `supportsNonCurrentContextUpdates` | Optional | Boolean | `true` or `false` - indicating support for the "[Update Events Outside of Current Context](2-10-ContentSharing.html#experimental-capability--update-events-outside-of-current-context)" -`preservesFhirId` | Optional | Boolean | `true` or `false` - indicating that the Hub preserve the FHIR resources' logical FHIR IDs while broadcasting open events. If false, the Hub assigns a different FHIR ID and populates an additional business identifier with the value of the requesting subscriber's FHIR ID. See [Hub Generated FHIR IDs]([url](2-5-ReceiveEventNotification.html#hub-generated-fhir-ids)). +`preservesFhirId` | Required | Boolean | `true` or `false` - indicating that the Hub preserve the FHIR resources' logical FHIR IDs while broadcasting open events. If false, the Hub assigns a different FHIR ID and populates an additional business identifier with the value of the requesting subscriber's FHIR ID. See [Hub Generated FHIR IDs]([url](2-5-ReceiveEventNotification.html#hub-generated-fhir-ids)). #### Wellknown endpoint discovery example From 249ad77cf35c7a7f00bbafbb33cc259c727e35e2 Mon Sep 17 00:00:00 2001 From: natan shpringman <55200920+shpringman@users.noreply.github.com> Date: Thu, 9 Oct 2025 12:34:14 -0500 Subject: [PATCH 7/7] add resource-level info --- input/pagecontent/3-3-1-Patient-open.md | 4 ++++ input/pagecontent/3-5-1-ImagingStudy-open.md | 4 ++++ input/pagecontent/3-6-1-DiagnosticReport-open.md | 4 ++++ 3 files changed, 12 insertions(+) diff --git a/input/pagecontent/3-3-1-Patient-open.md b/input/pagecontent/3-3-1-Patient-open.md index cce13219..80bc6330 100644 --- a/input/pagecontent/3-3-1-Patient-open.md +++ b/input/pagecontent/3-3-1-Patient-open.md @@ -6,6 +6,10 @@ eventMaturity | [3 - Considered](3-1-2-eventmaturitymodel.html) User opened a patient's medical record. The indicated patient is now the current patient in context. +During an `open` event requested by a Subscriber, the Subscriber assigns and sends a logical FHIR ID for the Patient resource. + +A Hub MAY reassign the logical FHIR ID for the Patient resource supplied by the requestor (see [Receive Event Notification](2-5-ReceiveEventNotification.html)). + ### Context {:.grid} diff --git a/input/pagecontent/3-5-1-ImagingStudy-open.md b/input/pagecontent/3-5-1-ImagingStudy-open.md index 326125a9..347aaf33 100644 --- a/input/pagecontent/3-5-1-ImagingStudy-open.md +++ b/input/pagecontent/3-5-1-ImagingStudy-open.md @@ -6,6 +6,10 @@ eventMaturity | [2 - Tested](3-1-2-eventmaturitymodel.html) User opened an imaging study. The newly opened image study is now the current imaging study in context. When the image study's subject is a patient, this patient SHALL be provided in the event. +During an `open` event requested by a Subscriber, the Subscriber assigns and sends a logical FHIR ID for the ImagingStudy resource. + +A Hub MAY reassign the logical FHIR ID for the ImagingStudy resource supplied by the requestor (see [Receive Event Notification](2-5-ReceiveEventNotification.html)). + ### Context {:.grid} diff --git a/input/pagecontent/3-6-1-DiagnosticReport-open.md b/input/pagecontent/3-6-1-DiagnosticReport-open.md index 2ce4ac3b..bc46ca01 100644 --- a/input/pagecontent/3-6-1-DiagnosticReport-open.md +++ b/input/pagecontent/3-6-1-DiagnosticReport-open.md @@ -6,6 +6,10 @@ eventMaturity | [2 - Tested](3-1-2-eventmaturitymodel.html) User opened a diagnostic report. The newly opened diagnostic report is now the current report in context. +During an `open` event requested by a Subscriber, the Subscriber assigns and sends a logical FHIR ID for the DiagnosticReport resource. + +A Hub MAY reassign the logical FHIR ID for the DiagnosticReport resource supplied by the requestor (see [Receive Event Notification](2-5-ReceiveEventNotification.html)). + ### Context {:.grid}