We will update the event-based content sharing non-normative page (this – https://build.fhir.org/ig/HL7/fhircast-docs/4-6-fhircast-event-content-sharing.html) to succinctly and clearly explain the below.  The content that is interacted with during a FHIRcast content-sharing session can be considered a shared, non-persisted "cache" of FHIR data. This "cache" begins the session empty, except for the anchor context. Content is then added using FHIRcast *-update events from the session's subscribers. Upon a *-close event, FHIRcast doesn't place any requirements on persisting the content. From a workflow perspective, each subscriber is responsible for determining if FHIRcast session-created content should persist. Subscribers should provide previously existing content to a FHIRcast session anchored by a relevant diagnostic report (context).      Logically, the content that's interacted with during a FHIRcast content sharing session can be considered a shared, non-persisted "cache" of FHIR data. At the beginning of the session this cache is empty, except for the anchor context and content is added as part of FHIRcast *-update events from the session's Subscribers. At the end of the session (upon a *-close event), FHIRcast doesn't place any requirements on the different Subscribers to persist the content; therefore, the interaction between the resulting content from multiple distinct FHIRcast sessions is also unspecified. Similarly, simultaneous FHIRcast content-sharing sessions changes to the same content are not synchronized. Standardization of behavior for persisting content created during a FHIRcast content sharing session is unspecified in the base FHIRcast spec, but may be dealt with in related "sub-IGs", like IHE's IRA profile.   From a workflow perspective, each subscriber is responsible for determining if FHIRcast-session-created-content should be persisted, and if so, how, when and the relationship between this new content and any previous content. Subscribers should provide previously existing content to a FHIRcast session anchored by a relevant DiagnosticReport (context). Practically, contradictory content should probably be surfaced to the user.