HL7 · isaacvetter · Oct 8, 2025 · Oct 8, 2025 · Oct 8, 2025 · Oct 8, 2025
diff --git 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 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).
+
+
+
+
diff --git 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)). 
 
 <figure>
   {% include EventNotificationSequence.svg %}

diff --git 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` | 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
 
@@ -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).
+
diff --git 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
@@ -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
@@ -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}