Progress towards publication

• See dashboard: https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=15106
  • Balloted Triaged or Submitted
  • Balloted and undone
• unballoted, undone issues

Balloted triaged: 66

Balloted submitted: 0

Balloted undone: 84

Unballoted, and undone: 71

Add Jira Grouping of "Fit-for-teleconference" (or Scheduling = "NextCall")to put issues in a queue for discussion.

Next steps:

• Read through undone jiras
• Add a proposed resolution to Jira, or even in comments
• Add Jira Grouping of "Fit-for-teleconference" to put issues in a queue for discussion.

Alex – this Hub capability seems super hard --

Processing Update Events and Current Context

A FHIRcast Hub SHALL process a [FHIR resource]-update event even if the anchor context referenced differs from the current context (the anchor context is present in the context attribute in [FHIR resource]-update events). The proposed [FHIR resource]-update event SHALL be processed in scope of the referenced context (not the current context) following the same rules as if the referenced context were the current context. The current context is not changed by a [FHIR resource]-update event that references an anchor context that is not the current context.

Notes previous call:

Kamal: this would result in an error for our Hub. 

Paul: is this a multi-tab scenario?

-->Yes

Kamal: from a clinical safety perspective, it seems important to not update a context that's not in-focus. 

Alex: agreed.

We think that this behavior should definitely not be mandated on Hubs, and should probably not be allowed.

Observation:

• This could only be done for contexts which are open.
• This is a multi-tab behaviour - in the case multi-tab scenario, multiple content context need  to be maintained.
• There is no technical issue preventing sending the update and processing it within the requested context (not the current one.

• What should getCurrentContext return? → current position on this is: current context of all current anchors. It does not the context of open context which are not current.

It should also not be mandatory behavior of the hub. If the hub does not update - something needs to be returned. 

The Hub does not need to wait for updating the content until all events are send and processed → a refusal of client to update content has no effect on the state of the content of the hub. Ergo → why indicate this?

Do other clients care? → Eric: likely not, Bas agrees. → A error return code is not needed.

The main remaining issue is whether this is a safety issue? 

We discussed the proposed wording changes. The group likes the intend but some (Bas) are worried that using *-selectContent might confuse the reader and proposes to rephrase this. E.g to illustrate using an example, something like: "when sending an event DiagnosticReport-select( DR:A, select: D,F,E,) it means that within the context of DR:A, content items D,F,E are slected.

For the resolution of: [FHIR-43040] change logout valueset to better differentiate between system events - Jira (hl7.org)

• Bas van den Heuvel to Update this  value set with these values:
  • system-initiated: The application in active use by the user, or the Hub has initiated the logout.
    • 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.
  • user-initiated: The user initiated the action. 

Review block-vote-5 for scheduling. 

Alex – this Hub capability seems super hard --

Processing Update Events and Current Context

A FHIRcast Hub SHALL process a [FHIR resource]-update event even if the anchor context referenced differs from the current context (the anchor context is present in the context attribute in [FHIR resource]-update events). The proposed [FHIR resource]-update event SHALL be processed in scope of the referenced context (not the current context) following the same rules as if the referenced context were the current context. The current context is not changed by a [FHIR resource]-update event that references an anchor context that is not the current context.

Kamal: this would result in an error for our Hub. 

Paul: is this a multi-tab scenario?

Kamal: from a clinical safety perspective, it seems important to not update a context that's not in-focus. 

Alex: agreed.

We think that this behavior should definitely not be mandated on Hubs, and should probably not be allowed.