Agenda Overview

 Minutes Approval

Motion to Approve Meeting minutes as written

Moved/Second: Suzanne / Mike

Vote - Approve/Abstain/Oppose :  1 abstain; opposed: none; 3

FHIR Security

Discussion on the topic of use of Digital Signature across the meta.security tags to enable accountability trace to classifier actors.

John - accountability would be far more effective and efficient using Provenance without adding the overhead of Signatures. The Provenance record would be needed even if a digital signature was used to carry the Who, What, Where, When, and Why of the changes. Recommend defining a specific pattern for Provenance record when the change is for data classification. This pattern would be distinguishable from other Provenance use-cases. Thus mandatory carrying of these Provenance in an external communication would be easy.

Is it possible to have a Digital Signature (http://build.fhir.org/datatypes.html#Signature) that just covers the .meta.security – YES. It would require a new canonicalization algorithm that identifies when that canonicalization is used that ONLY the .meta.security element is signed. (see http://build.fhir.org/xml.html#canonical) 

Is it possible to have a Digital Signature that just covers some of the values in .meta.security – possibly with FHIR specific encoding of canonicalization beyond that typical in  XML or JSON signatures. Might leverage FHIR-Path expressions.

Note that Digital Signatures are expensive. The overhead to maintain them, to maintain the certificate authority, the certificate expiration, the certificate purpose, etc. And a digital signature just tells you if the object has or has-not changed.

Trust-Frameworks are more important than the technology. It is far more effective to include in the Trust-Framework requirements around accessibility, upon need, to audit logs. Where the need can be identified as specific events, not general surveillance, for example.

Audit Logs and Provenance are both just as important. Provenance focuses on create/update with a pointed efficient way to prove to a recipient that they should trust the data. Audit Logs prove to data holders that their data are being used appropriately. Yes Audit Logs can carry the functionality of Provenance, but would likely have different accessibility rules and different retention rules. They both are distinct and needed for Trust-Frameworks.

Update: Waiting on a Response from CTO.  Kathleen re-sent request last week.

Review and approve Errata Letter for CTO Consideration

QA of final ANSI publication submittal missed that Volume 3 Provenance DAM did not include the Contributor Table.

We are requesting an errata version.  May not be possible because ANSI has already approved it.

Mike's alternative: wants to claim an author name on HL7 formal letterhead (not to add as an ANSI change)

Document

No comments received–all submitted comments prior to today have been incorporated into latest document.

(Security WG to review and approve on 12/2/2020 call,  Plan is to be submit finalized material on December 13th )

No plan to change current diagrams at this point.  Ioana updated some figures (Mike is reviewing to make sure they fit into current document version)

---

Final walk-through of Logical Data Model during tomorrow's call.

2020-12-02 Privacy and Security Logical Data Model

Plan on voting to recommend that the Security WG approve for submission to 202101 Ballot during 2020-12-8 call.

Dec 13: Final content deadline

Review and approve P&S Logical Model draft NIB submitted without suffix "Cross-Paradigm" after TSC review.

Please review and send Mike comments on V3 Logical Model Draft 1116.docx

• models have updated per comments, including ABAC (new material)
• working on one more model- showing relationship between class model and 
• The majority of the changes are in the ABAC section.
• Mike will walk though the changes at tomorrow's meeting

Meeting scheduled for document and model review

• Calls are on Wednesdays 1 - 2 ET http://www.hl7.org/concalls/CallDetails.aspx?concall=50666

  https://us02web.zoom.us/j/89559883576?pwd=ckd0N2V1L1FybXhhbHhVdElQekg2QT09

  Meeting ID: 895 5988 3576

  Passcode: 258923

  Find your local number: https://zoom.us/u/abruqg5or

HL7 Privacy and Security Information Model PSS

Information model update: The new information model will consolidate and harmonize security models across HL7 standards (Access Control, Audit, TF4FA etc.) and (incomplete) updates from FHIM (Consolidated unresolved models). Also included are direct mappings to Access Control, Audit and Authentication (e.g. Class models)  mapped to Access Control services.

ISD PPS approved 7/7

TSC PSS approval before August 23, 2020

FHIR DS4P IG

KC Most of the vocab errors are because approved codes didn’t make it into FHIR/UTG from V3

From: Grahame Grieve [mailto:grahame@healthintersections.com.au]
Sent: Monday, November 30, 2020 7:36 PM
To: Kathleen Connor
Cc: Mohammad Jafari; Suzanne Webb; Melva Peters; Ted Klein; Jessica Bota; Shawn, Christopher A.
Subject: Re: DS4P FHIR IG for January Ballot

You don't  need to delay a ballot because of QA issues that do not indicate problems in the IG itself. FMG will grant waivers if you can show that the QA issues are problems in the infrastructure. I'm not sure, on the other hand, whether UTG proposals yet to be made will count as grounds for waiver. You might be able to clearly indicate which parts of the ballot are subject to ongoing proposals, and argue to FMG that the ballot should still go ahead that way. But time is very tight - it's late for a discussion like that. Looking at the QA: it's just a set of codes that are not yet approved? If Mohammad sorts out the Jira issue which is purely procedural, then I would support going ahead with ballot with a clear note to balloters explaining what is happening, so they can comment directly or keep it in mind.

Moving comments from spreadsheet into JIRA Tickets - View comments at this link.

Previously approved NIB

Postponed early January ballot until regular January ballot cycle.

Review and approve FHIR DS4P IG Out-of-cycle ballot request for 10/20 opening date.

Carmela A. Couderc block - continue review

Review Reconciliation Spreadsheets and JIRA Ballot Recon

Missed approval of Reconciliation prior to July 5th Sept NIB due date Security WG Admin

Ballot results:

Quorum met - 107 voters, FHIR DS4P IG Ballot Passed

• Affirmative - 26
• Negative - 13
• Abstain - 35

Negatives - missing definitions, which is the result of tooling errors we need to fix, and a general misunderstanding that the FHIR DS4P IG is the basis for profiles for policy specific security label IGs much like the CDA DS4P IG is.  Only the profiles are implementable.

https://www.hl7.org/documentcenter/public/wg/tsc/HL7%20May%202020%20Ballot%20Results.zip

Spreadsheet Spreadsheet

Spreadsheet

Upcoming deadlines:

• FHIR IG must be substantively complete - ???, 2020
• FHIR IG must be complete and handed over to sponsoring WG for QA review - ???
• QA review cycle - ???
• Content QA Change application - ???
• Final content to Lynn for inclusion in Oct Out-of-cycle ballot ???
  
• Submit Ballot Readiness Checklist - before ???

If you have any questions about these dates or the process, you can check out the FHIR IG Process Flow on Confluence

(https://confluence.hl7.org/display/FHIR/B+-+Content+Development+and+Submission)

Request approval to submit to 202101 Ballot

Moved/Seconded (Mohammad / Mike) 

Vote: abstain: none; opposed: none Motion carries : 4

Kathleen will work with Mohammad to get waiver request before FMG

Postponed early January ballot until regular January ballot cycle.

Previously approved NIB already submitted.

JIRA tickets filed for acceptance of new UTG values/data; motion next week when we bring information forward on the value sets.

New CUI Notice 2020-06 RE CUI Marking Waivers with e.g., splash screens, seems to be limited to internal CUI use.

FHIR US Regulatory Security Labels Continuous Build - No update in the build

GitHub repo for the source material:https://github.com/HL7/us-security-label-regs 

John and Mohammad are committers.

US Regulatory Security Label Example Sandbox

Security Labeling Parking Lot

US Regulatory Security Label examples were included in the FHIR DS4P IG.  These will be the starter set for the FHIR US Regulatory Security Label IG

Share with Protections White Paper Project

will need to find time during the January 18 week need time for FHIR (two 2-hour blocks to wrap up ballot reconciliation); recommend two separate days

Worked on ballot recon with Beth for KP comments.  Ready for review.

SwP Ballot Comment Spreadsheet

SwP White Paper

This SOA project is co-sponsored by Security and CBCP. 

2021-01 Consent Management and Enforcement Services Track

Consent Management Service PSS

The project's model has progressed and is impressive.

See Consent Management Service Project

Join Zoom Meeting

https://hl7-org.zoom.us/j/93128162118?pwd=dnZlSzNVOThpeWdpb2hWOHFMU29aQT09

Requesting review provide comment / recommend participants review the information (links below)

High Water Mark on Bundle - https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/Meaning.20of.20Security.20Labels.20on.20Bundles

Consent - https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/Consent.20IG.3F

Scopes for data access - https://chat.fhir.org/login/#narrow/stream/179175-argonaut/topic/Scopes.20for.20data.20access

DS4P IG - https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/DS4P.20IG

Fine-grained Security Policies

Consent Provisions

OCR ruling related to Cost for Right of Access

Grahame Provenance agent.type vs agent.role value sets and element semantics