This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

HL7 FHIR Security 2017-11-07

From HL7Wiki
Jump to navigation Jump to search

Call Logistics

Weekly: Tuesday at 05:00 EST (2 PM PST) 

Web conference desktop and VOIP https://www.freeconferencecall.com/join/security36 
Online Meeting ID: security36
Phone: +1 515-604-9567, Participant Code: 880898
 Please be aware that teleconference meetings are recorded to assist with creating the meeting minutes

Back to HL7 FHIR security topics

Attendees

Member Name Member Name Member Name
x John Moehrke Security Co-Chair x Kathleen Connor Security Co-Chair x Alexander Mense Security Co-chair
. Suzanne Gonzales-Webb CBCC Co-Chair . Johnathan Coleman CBCC Co-Chair . Mike Davis
. Reed Gelzer RM-ES Lead . Glen Marshal x Joe Lamy AEGIS
. Diana Proud-Madruga . Rob Horn . Beth Pumo
. Irina Connelly . Mario Hyland AEGIS [1] x Peter Bachman

Agenda

Future Block

  • 12941 Security+Role+vocabulary+should+include+ISO+21298 (John Moehrke) Persuasive
  • 13571 AuditEvent.entity.identifier+vs+resource+vs+URI+-+explain+why+each+should+be+used (John Moehrke) Not Persuasive
  • 13570 Provenance+-+clarify+when+Provenance.entity.whatUri+and+whatIdentifier+are+to+be+used (John Moehrke) Persuasive with Mod

Current backlog

  • 9167 AuditEvent+needs+to+make+more+obvious+how+to+record+a+break-glass+event (John Moehrke)
  • 10343 Three+additional+Signature.type+codes (Kathleen Connor)
  • 10580 How+should+test+data+be+identified%3F (John Moehrke)
  • 12462 Security%2FPrivacy+Module+page+should+explain+W5+realty+that+provenance+elements+in+other+resources+vs+use+of+Provenance+as+a+resource (John Moehrke)
  • 12463 explain+relationship+between+Provenance+and+AuditEvent.+ (John Moehrke)
  • 10579 New+Security+and+Privacy+%22Module%22+page+needs+content (John Moehrke)
  • 11071 Improve+security+label+guidance+-+2016-09+core+%2390 (Kathleen Connor)
  • 12660 HCS+use+clarification (John Moehrke)
  • 13011 The+value+set+for+security-role-type+is+broken+for+Provenance (Lloyd McKenzie)
  • 13013 Valueset+for+Provenance.activity+is+broken (Lloyd McKenzie)
  • 13014 Provenance.agent.relatedAgentType+doesn%27t+make+sense (Lloyd McKenzie)
  • 13822 S%26P+outlline+when+a+user+includes+query+parameters+they+don%27t+have+access+to++policy+issue (John Moehrke)
  • 13841 Align+AuditEvent+with+Event+pattern (John Moehrke)
  • 13842 Align+Provenance+with+new+Event+pattern (John Moehrke)
  • 14027 enhance+current+disclosure+AuditEvent+so+that+it+explains+what+is+being+recorded+and+why (John Moehrke)
  • 14028 Explain+how+one+might+use+AuditEvent+to+inform+an+Accounting+of+Disclosures (Kathleen Connor)

Minutes

  • John Chaired
  • did not review prior minutes due to late gathering
  • reviewed with new participant our pages http://build.fhir.org/secpriv-module.html
  • Discussion on chat around PurposeOfUse and how it should be conveyed. https://chat.fhir.org/#narrow/stream/implementers/topic/GDPR.20PurposeOfUse
    • The where to put PurposeOfUse is not an obvious thing in an OAuth world. Just like it is not clear where one would put the security ROLE of the user. In neither case would one prompt the user. But, it is not clear. In normal business logic the purpposeOfUse and the user-role come from the context of the interaction. Usually from business relationships (the user is a cardiologist at this organization [static role], and right now is the treating cardiologist [functional role], with the purposeOfUse of treatment), ( the user is a clinical data analysis at blah-organization with the purposeOfUse of treatment quality and timeleness analysis).
    • In IHE-IUA (IHE's OAuth profile), we put these as attributes in the token. http://wiki.ihe.net/index.php/Internet_User_Authorization We however never addressed where they came from (Yes, IUA is a bit too thin to be useful).
    • SMART does not include PurposeOfUse, and are defering changes to scopes
    • I did model purposeOfUse into scope https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html
    • Mike's Cascading OAuth does include PurpoeOfUse, but it isn't documented anywhere
    • HEART does not include PurposeOfUse, but did include Confidentiality and Sensitivity
    • What is important to include in the model is that the declaration of PuposeOfUse must be an assertion of truth that all parties can trust is accurate and will be upheld. (Just like the user, user-role, user-organization, etc...) This is why I put it into the token, rather than into the scope.
    • Lastly, yes we know that the break-glass that is in the spec today is problematic. It exists because it was written, not because it was a consensus decision. However, we don't have a better consensus yet. The results of this PurposeOfUse experiment will inform us.
    • Long discussion on prescription dispensing in USA often results in data being available for data-mining beyond treatment
    • GDPR 'purpose' seems to be an identifier used when asking for access to data that was previously authorized by that purpose. Thus purpose is a token (string). Where Treatment is a specific example that we have vocabulary for. But where in GDPR these purposes are not constrained to a defined standard vocabulary, a string should be sufficient.
    • So where we landed seems to me: ( a ) the mechanism written in the break-glass section seems wrong (http header is not a security layer), ( b ) IHE has purposeOfUse in the OAuth JWT, and ( c ) SMART is deferring this until next revision of SMART. An OpenID Connect token should not be seen as appropriate as that is only about identity of the user, which might include structural-roles, but would not know about functional-roles or purposeOfUse. Experimentation, and experience might put it in various places. In SMART it could go into context, near other stuff that is describing the workflow context. It could go into scope. It could be that we define specific cascade of OAuth where the Nth OAuth authority is responsible for assuring the user is authorized to participate in a specific worflow/dataflow/reason. This might be the same as the consent OAuth authority (UMA), or might be an additional layer... Certainly at the GDPR level, purpose is very specific to authorization of reason for access (consent).
  • 10579 is the CR to bring in Cascading OAuth.
    • Cascading OAuth is today only documented for DSTU2
    • This might not be optimal, but that should not be a limitation.
  • 14028 reviewed, but did not move forward. May discuss with full group next week
  • 13571 and 13570 reviewed
Retrieved from "https://wiki.hl7.org/w/index.php?title=HL7_FHIR_Security_2017-11-07&oldid=149014"