Note Taker: @
ANSI Anti-Trust Policy:
Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).
Meeting Minutes from Discussion
|Decision Link(if not child)|
|Management||Quorum reached (co-chair + 2) Yes/No|
Progress towards publication
Balloted triaged: 64
Balloted submitted: 0
Balloted undone: 85
Unballoted, and undone: 71
Add Jira Grouping of "Fit-for-teleconference" (or Scheduling = "NextCall")to put issues in a queue for discussion.
- 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.
|Methodology||Eric: FHIR-36910 - [FHIR-36910] persistent, pre-existing findings across systems ? - Jira (hl7.org)|
FHIR-36792Getting issue details...
- Delete action: should implementing clients consider a delete as an "undo", or a removal of the key/value entirely.
- 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?
- Note this jira: [FHIR-36910] persistent, pre-existing findings across systems ? - Jira (hl7.org)
- 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:
- Definition: System initiated logout. Implies that system will reasonably be available in the near future.
- Display: "Automated logout due to user inactivity"
- Definition:System initiated logout. Implies that additional processing of messages will likely fail.
- Display:"Temporarily unavailable due to system maintenance"
- 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.
- Alex to validate need for system-downtime code. (e.g. are you sure an app can send a system-downtime logout while it's down?)
- Update valueset
- Test at some industry testing event.
|Management|| Next agenda|
| Adjournment|| Adjourned at|
|FHIRCast Jira not done|