- Chair: @Christopher Shawn
Scribe: @Suzanne Gonzales-Webb
Weekly calls Tuesdays 3PM ET
FreeConferenceCall Online Meeting Link https://www.freeconferencecall.com/join/security36
Dial-in Number (United States): (515) 604-9567 Access Code: 880898#
| Minutes Approval|
2019-08-06 Security WG Agenda/Minutes
Motion to Approve with amendment to update # of approval 8/6 Minutes : Moved: Mike / Second Kathleen
Objections: 0 Abstentions: 0; Approve: 6
|Share with Protections|
Updates- Mike Davis
- see Walk Though of Share with Protections (graphic shown)
- 'we are in the world of DS4P'
- Inability to read the tabs is a problem
- the agreement to use the security tags is a policy statement. "I will honor and use your security labels...' that is a trust contract/TF4FA
- JohnM is trying to separate out - you cannot include in the protections tabs things that you do not have some confidence. the recipient can or will enforce. if you have no reason to believe that your trading partner has the ability to encrypt data at rest, to simply throw a tag on, you have no reason to believe that the ode will magically create the functionality seconds before–that's why I’m asking before
- that the crux of the issue - trying to set up a system, where the senders …
- I see this as part of the agreement. the DURSA is being updated to include the requirements for CUI. The way they've done it they've made a technical adjustment. Those signing the DURSA must sign the OP&P, and must implement CUI Marking requirements and comply with NIST SP 800-171. In Sequoia, everyone agreed to the OP&P 13. Mike is using this agreement as a model for Sharing with Protections. If trading partners can't agree to the DURSA, then the Senders have a problem. Wrt to CUI, if the Sender's Mission requires sharing the information, then a Federal Agency could decide to send the CUI anyway knowing that the Recipient cannot or will not comply. Wrt to other privacy and security policies, under the ONC CURES NPRM, the Sender must document privacy/security policies that prohibit sharing in order to meet the information blocking exemption/safeharbor.
- this is imp documentation for info blocking, for sending information where the DURSE cannot...
- the entire effort is to get us to a point to significantly reduce blocking of information - hence sharing w protections
- appendix E: The meaning of 'consent'
- three issues (in progress)
- issue 1 - In today's world, if information identified in a HIPAA authorization is 'protected information" then how is it protected upon disclosure?
- Issue 2 - a patient authorization is not provided with or referred to as an attribute of disclosure
- ignorance of the law is not an excuse; it is the data holder's responsibility to not disclose...
- issue 3 - originator lacks assurance that Recipient will continue to properly control 'sensitive' information
- what would the product be for the PSS - the paper? (Mike)
- suggest associating the information with DS4P (Kathleen), publish as part of the FHIR IG
- currently the paper is written as a practical use of the abstract; giving stepping stones beyond DURSA only
- next week's meeting has been cancelled 8/20/2019 (John will be at ONC event)
Follow up on CARIN BlueButton FHIR IG "self-attestation" to privacy and security requirements, and seek collaboration on attestation criteria. Note that "Consent Federation" is a project on CARIN roadmap. Suggest that we invite the IG author, Amol Vyas, Cambria Health, to WG call.
See Carin Alliance WEDi.pdf and https://build.fhir.org/ig/HL7/carin-bb/toc.html
|Recent ISA updates|
HL7 PAC is soliciting WG input on The Interoperability Standards Advisory (ISA) for HL7 comments. See ONC ISA 2019 for focus areas
Kathleen is coordinating comments (please review document and send to Kathleen) for incorporation/submittal for ISA Review
|Adjournment||Meeting adjourned at 1258 Arizona Time|
Temporary Meeting Recording: https://fccdl.in/cSEzyr3YGI
Be the first to like this