Content-sharing clarifications

1. Delete action: should implementing clients consider a delete as an "undo", or a removal of the key/value entirely.
   1. E.g. in the case when an app has an existing value, which is then updated interoperably, then deleted interoperably, should the app revert to the existing value or delete the value entirely?
   2. Note this jira: [FHIR-36910] persistent, pre-existing findings across systems ? - Jira (hl7.org)
   3. Kamal: individual apps with pre-existing finalized findings should probably reject modifuication to those findings (perhaps except statuses of amending). We don't want FHIRcast to dicate this behavior, because we think they're business rules of the application. 

Logout valueset issue - 

• New valueset for logout reason is here: Reasons for sending a logout event. - FHIRcast v3.0.0
• Can we add:
  • system-initiated vs user-initiated is meaningful because applications should consider user-initiated logouts as stronger guidance to close the session, than system initiated. Further, some system initiated logout reasons reasonably indicate distinct application behavior. Specifically:   
    • system-timeout:
      • Definition: System initiated logout. Implies that system will reasonably be available in the near future.
      • Display: "Automated logout due to user inactivity"
    • system-downtime:  
      • Definition:System initiated logout. Implies that additional processing of messages will likely fail.
      • Display:"Temporarily unavailable due to system maintenance"
    • system-error:
      • Definition: System initiated logout.Implies that additional processing of messages will fail.
      • Display: "System encountered error resulting logging out the user. System is unavailable.
• And change system-initiated
  • Definition to: The application in active use by the user, or the Hub has initiated the logout.