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

Difference between revisions of "HL7 WGM Atlanta October 2015"

From HL7Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by 2 users not shown)
Line 36: Line 36:
 
** ANSI INCITS (US TAG for ISO JTC1 SC27). Next Generation Access Control (NGAC) - (very) technical specification   
 
** ANSI INCITS (US TAG for ISO JTC1 SC27). Next Generation Access Control (NGAC) - (very) technical specification   
 
** IHE (John) - Entering phase for new proposals.  Working to align IUA profile with the SMART and HEART work. New consent profile to support codeable consents as opposed to BPPC.
 
** IHE (John) - Entering phase for new proposals.  Working to align IUA profile with the SMART and HEART work. New consent profile to support codeable consents as opposed to BPPC.
 +
* Mike discussed a paper VHA is participating on regarding Relationship Based Access Control (ReBAC)
 +
** http://gforge.hl7.org/gf/project/security/docman/Security%20White%20Papers/ReBAC%20Information/
  
 
= Tuesday Q2 =
 
= Tuesday Q2 =
Line 205: Line 207:
 
'''FHIR Consent Resource / Profile / Questionnaire Work Session'''
 
'''FHIR Consent Resource / Profile / Questionnaire Work Session'''
  
Notes by John
+
==Notes by John==
 
* Consent as a resource vs as profiles on contract
 
* Consent as a resource vs as profiles on contract
 
** Grahame -- need diagrams in the consent profiles that explain the relationships
 
** Grahame -- need diagrams in the consent profiles that explain the relationships
Line 239: Line 241:
 
*** Could add an invariant that forces binding to always be false, when legal attachment is not agreed to.
 
*** Could add an invariant that forces binding to always be false, when legal attachment is not agreed to.
  
Notes by Diana:
+
==Notes by Diana:==
 +
There are a number of CPs that need to be resolved in FHIR, specifically in Consent.
 +
Currently Consent is currently a profile under Contract. No everyone agrees.
 +
 +
There was a diagram that showed relationships of consent and contract in an ISO doc but it seems to have disappeared. Kathleen contends that there are other diagrams that will work as well.
 +
 +
Mike has agreed to create the first draft of a similar diagram that the group can kick around.
 +
 +
Use Cases:
 +
Kathleen has started working on work cases/profiles and will work with Paul Knapp to complete.
 +
 +
Graham:
 +
 +
K: There has to be some binding document that is presented to the patient. I have multiple  examples in the consent resource.
 +
 +
G: Are there examples of agreements that are in computable form? How is it done? I'm being told that you can't do that in FHIR.
 +
 +
K: You can do it in FHIR.
 +
 +
G: Use Case: National EHR Patients consent to no sharing or partial sharing or by specific policies. We would like a template that the patients can choose from…
 +
K: that's the questionnaire. The questionnaire is the template.
 +
 +
Paul: The templates/questionnaires are pre-contract which allow for the compilation of the choices that are computable and can be inputted into a contract format.
 +
 +
Binding is the legal signature. Right now binding is 1…1 in consent but there is an argument that binding should be 0…1. Suggestion: we have more than one consent profile, one where there is a binding (Privacy Consent Directive) and one which doesn't have the binding (Privacy Consent)?
 +
 +
Alex: in Austria - They use an Opt-out model. Binding would point to evidence. (Note: I'm still not clear how binding would be dealt with in this model. What would constitute "evidence." Would the evidence be that the notification was sent to the person?)
 +
 +
John: There is still some objections to using the word "consent."
 +
 +
K: OCR uses "consent" in a way that supports authorization and consent. This includes negative (do not share) type of consent/authorization.
 +
 +
Need to clarify definitions of "binding," "legal," and "patient friendly" to ensure no ambiguity.
 +
 +
"legal" - Is the actual legal wording of the contract.
 +
 +
"binding" - is the "signature."
 +
 
 +
"friendly" - is the non-legal wording
 +
 +
* Suggestion from Paul Knapp: Another possible way is to include a "binding" flag that can be added to the legally binding copy within the profile, whether it's on the legal, friendly, or rule. Note: This would then negate the need for a separate "binding" section. (no real response to this suggestion from the group.)
 +
 +
* G: Sometimes that binding may not be on the legal, it may be on the rule.
 +
 +
* John: suggestion to collapse legal, friendly, and rule into one with flags that differentiate between them and then a boolean flag to identify which one is signed and binding.
 +
 +
* Proposal from John (what is in red were adjustments suggested by Kathleen that were not really discussed or accepted.)
 +
 +
*** Contract.attachment 0..*
 +
****Contract.attachment.content -- Attachment
 +
****Contract.attachment.type -- code (Friendly, Legal, Rule, Policy)
 +
****Contract.attachment.binding -- boolean (not available for Policy)
 +
****Contract.attachment.signature  -- (suggestion and discussion on the possibility of replacing binding with signature or linking the binding boolean to specific binding types.)
 +
 +
* Mike asked if there is a notary type. Could not find it on first glance. Kathleen thinks that there should be a notary type already there. John will create a CP to ensure that notary is added if it's not already there.
 +
 +
* None of the proposed changes were agreed to or voted on.
  
 
= Thursday Q2 =
 
= Thursday Q2 =
Line 257: Line 315:
 
Opportunity to change it to an access control standard - incorporating different types of access control, including normative standards e.g. RBAC, ABAC, and new relationship access control. Discussion on if this could be incorporated into RBAC.  
 
Opportunity to change it to an access control standard - incorporating different types of access control, including normative standards e.g. RBAC, ABAC, and new relationship access control. Discussion on if this could be incorporated into RBAC.  
 
Choice: 1. Reaffirming ballot as it is or 2. add a normative table of vocabulary that would support attribute based.  
 
Choice: 1. Reaffirming ballot as it is or 2. add a normative table of vocabulary that would support attribute based.  
RAC and ABAC tables would be separate but in the same document.  
+
RBAC and ABAC tables would be separate but in the same document.  
Hideyuki suggested that the relationship based access control could be implemented using ABAC. Mike questioned if you needed classified data in relationship BAC. Alex agreed with Hideyuki. All agreed that we should put the standards together.  
+
Hideyuki suggested that the relationship based access control could be implemented using ABAC. Mike questioned if you needed classified data in relationship BAC. Alex agreed with Hideyuki. Consensus that the access control standards should be colated in one standard. Given that a reaffirmation ballot the changes cannot be substantive.
 +
Proposal to have a new ballot with have previous RBAC and add new tables for ABAC and relationship. ABAC is already in the normative vocabulary.  
  
For a reaffirmation ballot the changes cannot be substantive.
+
'''Motion:''' Not proceeding with the re-affirmation ballot of the current RBAC Permission Catalog.   
Proposal to have a new ballot with have previous RBAC and add new tables for ABAC and relationship. ABAC is already in the normative vocabulary.
 
Motion: Not proceeding with the re-affirmation ballot of the current RBAC Permission Catalog.   
 
 
Proposer Mike, Seconded - Alex.MOtion carried 6/0/0.
 
Proposer Mike, Seconded - Alex.MOtion carried 6/0/0.
  
Motion: To create a new PSS and standard that will include RBAC and ABAC.  
+
'''Motion:''' To create a new PSS and standard that will include RBAC and ABAC.  
 
Proposed - Mike, Seconded  - Alex. Motion carried 6/0/0.
 
Proposed - Mike, Seconded  - Alex. Motion carried 6/0/0.
 
Suzanne to create PSS for new project 'Healthcare Access Control Catalog'.   
 
Suzanne to create PSS for new project 'Healthcare Access Control Catalog'.   
Line 274: Line 331:
  
 
'''* Future security tutorials (free or paid) future planning'''  
 
'''* Future security tutorials (free or paid) future planning'''  
 +
Previous attendance was good to free Wednesday afternoon tutorials.
 +
Suitable topic would be how security labelling fits in with FHIR, including a demo - Q4. 
 +
Mike to send Trish a summary of proposed session  - so that it can be included in the January WGM brochure.
  
'''* Workgroup Health
+
'''* Workgroup Health'''
Decision making, Liaisons'''
+
The WG Health report indicates we did note vote in TSC election, however, Mike Davis did vote - will query will HL7.
 
+
Room bookings same as this meeting with addition of Free tutorial.
= Thursday Q3 =
 
*''' Attendees'''
 
** Chaired by
 
 
 
* Not scheduled, no room assigned TBD - EHR/Vocab alignment sub-group * TENTATIVE *
 

Latest revision as of 18:23, 13 October 2015

Minutes from Security WG

Tuesday Q1

Opening Security WG Meeting Introductions

  • Attendees
    • Chaired by Mike Davis - Co-Chair
    • Princess Trish Williams - Co-Chair
    • Alex Mense - Co-Chair
    • John Moehrke - Co-Chair
    • Hideyuki Miyohara
    • Johnathan Coleman
    • Duane De Couteau
    • Suzanne Gonzales-Webb
    • Kathleen Connor
    • Diana Proud-Madruga

Approval of agenda

Approval of Previous WGM Minutes

  • Minutes Reviewed HL7 WGM May 2015 - Paris, France - Security WG - Minutes
    • Moved - Trish, Seconded - Kathleen Connor, Approved 10/0/0
      • Discussion on Wed Q4 session and separation of consent from contract in minutes. It was requested to have a computable method to provide evidence that consent was obtained. It was relayed that all except two items are optional in the profile for consent. Nothing was decided at this meeting - just a consensus reached but contingent on CBCC approval. Subsequently CBCC did not give approval.

International Report outs

  • Japan (Hideyuki) is commencing Social Security number. Intention to create Japanese Medical Association want to define a new healthcare number for medical treatment. Want to introduce in 2018. Currently, each hospital has a separate number and therefore it is difficult to share information using patient number.
  • Austria (Alex): ELGA will start in Dec 2015. Next step will be implementing tele-health and then to provide an infrastructure for tele-monitoring. Timeframe about 3 years.
    • Europe projects looking at cross country sharing - refer to International Council presentations.
    • In June Europe agreed on 'Right to Forget' - next step will be working out details to be completed by end of 2015. Possibly become law in 2018.
  • Australia (Trish) PCEHR being renamed at MyHealthRecord. Push for more clinical engagement with the national system. Revision of governance for development organisation (replacing NEHTA).
  • Other SDO update
    • ISO (Hideyuki) No updates since May, Next meeting in Bern in Nov 2015.
    • OASIS Trust Elevation (Diana) working on 4th deliverable - protocols for trust elevation. Looking at different models for implementation. They are seeking input and comments. Possible need for harmonisation. Diana will pass on to distribute to HL7 Sec WG.
    • OASIS XSPA (Mike) working with Sequoia - working on information to convey consent. Also updating to include move to Vocabs to HL7.
    • ANSI INCITS (US TAG for ISO JTC1 SC27). Next Generation Access Control (NGAC) - (very) technical specification
    • IHE (John) - Entering phase for new proposals. Working to align IUA profile with the SMART and HEART work. New consent profile to support codeable consents as opposed to BPPC.
  • Mike discussed a paper VHA is participating on regarding Relationship Based Access Control (ReBAC)

Tuesday Q2

PASS AC ballot reconciliation (Security,CBCC,SOA)

  • Attendees
    • Chaired by Mike Davis - Co-Chair
    • Princess Trish Williams - Co-Chair
    • Alex Mense - Co-Chair
    • John Moehrke - Co-Chair
    • Hideyuki Miyohara
    • Duane De Couteau
    • Kathleen Connor
    • Diana Proud-Madruga
    • Don Jorgensen (SOA)
    • Ken Rubin (SOA)
    • Vadim Polyakov vpolyakov@ikovaloa.com (SOA)


Tuesday Q3

Security WG Project Meeting: Data Provenance (w/Harry), review for final publication

Tuesday Q4

Security WG Project Meeting FHIR Security and Privacy (announcement to be made) - TENTATIVE Entire Quarter

  • Attendees
    • Chaired by John Moehrke - Co-Chair
    • Trish Williams - Co-Chair
    • Alex Mense - Co-Chair
    • John Davies - Co-Chair
    • Hideyuki Miyohara
    • Duane De Couteau
    • Kathleen Connor
    • Elliot Silver (elliot.silver@mckesson.com)
    • Michael Donnelly (michael.donnelly@epic.com)
    • Kevin Shekleton (kshekleton@cerner.com)
    • Grahame Grieve (arrived 4.35pm)

Discussion on consent policies to gain consensus on what SEC WG would like represented in FHIR IG. Suite of resources on consent rather than segments only in the FHIR implementation guide. The FHIR team think it should be simpler. The concerns have been overstated to date. Suggested that specific use case be considered in exchanging consent with a third party allowed to collect consent.

The WG agree that we should remain with using 'contract' as the resource name, and we will need to create a set of profiles that will be structured under an IG.

Wednesday Q1

Joint w/ EHR, CBCC, SOA Security - EHR Hosting


Wednesday Q2

Joint w/ SOA PSS SOA Security Existing project - PASS Access Control


Wednesday Q3

Hosting FHIR

Attendee:

  • John Moehrke (Chair)
  • Mike Davis
  • Trish Williams (aka Princess Kitty)
  • Dennis Patterson (Cerner)
  • Hideyaki Miyohara (HL7 Japan)
  • Kathleen-Connor
  • Josh Mandel
  • Janet Campbell
  • Michael Donnally
  • Marcis Di Cesere
  • Simone Heckmann
  • Reuben Daniels
  • Gunther Meyar
  • Joe Lamy
  • Dmytro Rud
  • Dave Shaver
  • Gary Dickinson

Authentication and Authorization

  • FHIR Specification and Security WG are emphasizing that FHIR should be agnostic to the security implementation.
  • HTTP is commonly secured via OAuth, although other models will work.
  • HEART Group working on healthcare usecases and how they could use OpenID Connect, OAuth, and UMA
    • Participation from many including IHE, HL7, ONC, OpenID Connect, OAuth, and UMA
    • More information at https://openid.net/wg/heart/
    • The result will need to live somewhere, that somewhere should be a healthcare standards organization. Some of their results may need HL7 standards, most of what they produce will be profiles that would best live in IHE.


AuditEvent and Provenance FHIR Resources:


Kathleen view on big needs on audit and provenance

  • understanding the relationship between provenance and audit
  • synching audit and provenance
  • defining better who should record them and when
  • lifecycle/w5
  • improve examples that show relationship between audit and provenance
  • use-cases of enterprise vs cross-enterprise
  • provenance as a subset of audit – thus why duplicate?
  • transform of a resource cause provenance? Reversible vs not- reversible.
  • use-case driven for all these issues
  • better vocabulary

Gary:

  • Vocabulary, action metadata vs record entry metadata,

Discussion: Combination of Audit and Provenance:

  • Mike – concerned with the issue of overlap. This overlap is intended, is driven by use-case and intended use.
  • * The fact that it appears that audit and provenance are gathering the same data is only a partial view. The auditable events are more than the provenance events.
    • Audit is conditionally recorded, controlled by security. Audit may be purged after a shorter time.
  • others agree.
  • Gary – understandable to keep them separate,

Motion: Kathleen moves that we keep audit and provenance independent because of the use-case and intended use with the expectation that we align them as best we can while explaining them better, Second Mike; Passes 13/0/5

  • Audit needs to be more flexible because it is recording what is actually happen. For example it must record auditable events on objects that are not defined by an interoperability standard (such as a database-entry, proprietary resource definition,

Discussion: Why do we need an Audit interoperability standard

  • Radiology – system of systems, where the systems didn’t want to take on all the requirements of audit log management/reporting

Note:

  • Aligning the element names should be done when they are indeed speaking of the same thing.

Discussion: cleanup use of purposeOfUse

  • Either explain why duplication is needed or eliminate.
    • I don’t think this is duplication.
      • Element, Participant, object, object-policy

Discussion: there a specification for minimum elements that must be filled out?

  • No, expectation is that you fill out the audit schema as best as you can. It is more important to record the event, than to fill out the schema
  • Where specific use-case analysis has been done there are constrained (profiled) audit events.
  • * IHE profiles explain the minimum requirements for the transactions they define
    • ISO 27789 has some for EHR tasks
    • DICOM has some for DICOM tasks
  • Should we expose these in HL7 FHIR? Should we re-do this work?

Wednesday Q4

Attendees:

  • Chaired by Mike Davis - Co-Chair
  • Princess Trish Williams - Co-Chair
  • Alex Mense - Co-Chair
  • John Moehrke - Co-Chair
  • Hideyuki Miyohara

No identified business, so adjourned

Thursday Q1

Security WG Project Meeting: Hosting FHIR Informal joint with CBCC

  • Attendees
    • Chaired by John
  • Duane DeCouteau ddecouteau@edmondsci.com
  • Kathleen Connor Kathleen.connor@comcast.net
  • Diana Proud-Madruga
  • Dennis Patterson dennis.patterson@cerner.com
  • Michael Donnelly michael.donnelly@epic.com
  • Kevin Riley kevin.riley@infor.com
  • Prareen Ekkati Praveen.Ekkati@infor.com
  • Hideyuki Miyohara miyohara.hideyuki@ap.mitsubishi-electric.co.jp
  • Mike Davis mike.davis@va.gov
  • Suzanne Gonzales-Webb suzanne.gonzales-webb@va.gov
  • Alexander Mense alexander.mense@hl7.at
  • Joshua Mendel childlens.harvard.edu
  • Graham Grieve grahame@healthintersections.com.au
  • Paul Knapp Pknapp@Pknapp.com
  • Nancy Orvis nancy.j.orvis.civ@mail.mil


Agenda: FHIR Consent Resource / Profile / Questionnaire Work Session

Notes by John

  • Consent as a resource vs as profiles on contract
    • Grahame -- need diagrams in the consent profiles that explain the relationships
      • Mike will build the diagram and develop text
      • Kathleen suggests that the diagram can be also used for FM uses.
  • Use-cases are not well understood
    • Kathleen will work on use-cases
    • Kathleen will work on an IG
  • Grahame ? on contract
    • consent allows the description of the set of rules. Is there a way to share the base set of rules?
      • Kathleen, yes there is a way
      • John, yes there are many ways
      • Grahame emphasizes the question on if there is a way to reference
    • Need to cleanup the consent directive
      • Consent that 'binding' is forced to 1..1. This is not appropriate in all places.
        • consentDirective -- could be the one with binding 1..1
        • consent -- could be with out this mandatory binding
  • Discussion on .binding vs .legal
    • John: Not clear why there is two things to hold the same thing. There is no distinction.
    • Kathleen: legal would only point at laws
    • Paul: legal would hold boilerplate, binding would hold the signed individual copy
    • Paul: since legal is multivalued it could hold both
    • Grahame: PHR usecase offers a set of OAuth scopes to pick and choose from using OAuth infrastructure. What gets recorded?
      • Unclear the legal basis of this exchange.
      • John: If we ignore the legal basis, we still need to address the functional need.
        • The scopes could be saved in computable, where there is no need for binding
    • Collapse binding, legal, friendly, rule into one with type and binding flag, so that binding could be applied to any form of the three different types.
      • Contract.attachment 0..*
        • Contract.attachment.content -- Attachment
        • Contract.attachment.type -- code (Friendly, Legal, Rule)
        • Contract.attachment.binding -- Boolean
        • Contract.attachment.signature -- Signature
      • Could add an invariant that forces binding to always be false, when legal attachment is not agreed to.

Notes by Diana:

There are a number of CPs that need to be resolved in FHIR, specifically in Consent. Currently Consent is currently a profile under Contract. No everyone agrees.

There was a diagram that showed relationships of consent and contract in an ISO doc but it seems to have disappeared. Kathleen contends that there are other diagrams that will work as well.

Mike has agreed to create the first draft of a similar diagram that the group can kick around.

Use Cases: Kathleen has started working on work cases/profiles and will work with Paul Knapp to complete.

Graham:

K: There has to be some binding document that is presented to the patient. I have multiple examples in the consent resource.

G: Are there examples of agreements that are in computable form? How is it done? I'm being told that you can't do that in FHIR.

K: You can do it in FHIR.

G: Use Case: National EHR Patients consent to no sharing or partial sharing or by specific policies. We would like a template that the patients can choose from… K: that's the questionnaire. The questionnaire is the template.

Paul: The templates/questionnaires are pre-contract which allow for the compilation of the choices that are computable and can be inputted into a contract format.

Binding is the legal signature. Right now binding is 1…1 in consent but there is an argument that binding should be 0…1. Suggestion: we have more than one consent profile, one where there is a binding (Privacy Consent Directive) and one which doesn't have the binding (Privacy Consent)?

Alex: in Austria - They use an Opt-out model. Binding would point to evidence. (Note: I'm still not clear how binding would be dealt with in this model. What would constitute "evidence." Would the evidence be that the notification was sent to the person?)

John: There is still some objections to using the word "consent."

K: OCR uses "consent" in a way that supports authorization and consent. This includes negative (do not share) type of consent/authorization.

Need to clarify definitions of "binding," "legal," and "patient friendly" to ensure no ambiguity.

"legal" - Is the actual legal wording of the contract.

"binding" - is the "signature."

"friendly" - is the non-legal wording

  • Suggestion from Paul Knapp: Another possible way is to include a "binding" flag that can be added to the legally binding copy within the profile, whether it's on the legal, friendly, or rule. Note: This would then negate the need for a separate "binding" section. (no real response to this suggestion from the group.)
  • G: Sometimes that binding may not be on the legal, it may be on the rule.
  • John: suggestion to collapse legal, friendly, and rule into one with flags that differentiate between them and then a boolean flag to identify which one is signed and binding.
  • Proposal from John (what is in red were adjustments suggested by Kathleen that were not really discussed or accepted.)
      • Contract.attachment 0..*
        • Contract.attachment.content -- Attachment
        • Contract.attachment.type -- code (Friendly, Legal, Rule, Policy)
        • Contract.attachment.binding -- boolean (not available for Policy)
        • Contract.attachment.signature -- (suggestion and discussion on the possibility of replacing binding with signature or linking the binding boolean to specific binding types.)
  • Mike asked if there is a notary type. Could not find it on first glance. Kathleen thinks that there should be a notary type already there. John will create a CP to ensure that notary is added if it's not already there.
  • None of the proposed changes were agreed to or voted on.

Thursday Q2

Security WG Project Meeting

  • Attendees
    • Chaired by Princess Trish Williams - Co-Chair
    • Mike Davis - Co-Chair
    • Alex Mense - Co-Chair
    • Suzanne Gonzales-Webb
    • Hideyuki Miyohara
    • Duane De Couteau
    • Diana Proud-Madruga

Role-Based Access Control (RBAC)Permissions Catalog

- Project Scope for reaffirmation required before end of October 2015.  

Opportunity to change it to an access control standard - incorporating different types of access control, including normative standards e.g. RBAC, ABAC, and new relationship access control. Discussion on if this could be incorporated into RBAC. Choice: 1. Reaffirming ballot as it is or 2. add a normative table of vocabulary that would support attribute based. RBAC and ABAC tables would be separate but in the same document. Hideyuki suggested that the relationship based access control could be implemented using ABAC. Mike questioned if you needed classified data in relationship BAC. Alex agreed with Hideyuki. Consensus that the access control standards should be colated in one standard. Given that a reaffirmation ballot the changes cannot be substantive. Proposal to have a new ballot with have previous RBAC and add new tables for ABAC and relationship. ABAC is already in the normative vocabulary.

Motion: Not proceeding with the re-affirmation ballot of the current RBAC Permission Catalog. Proposer Mike, Seconded - Alex.MOtion carried 6/0/0.

Motion: To create a new PSS and standard that will include RBAC and ABAC. Proposed - Mike, Seconded - Alex. Motion carried 6/0/0. Suzanne to create PSS for new project 'Healthcare Access Control Catalog'. Ballot this for January is needed.

Diana circulated three papers from the VA on relationship access control as the basis for consideration and discussion. at future meetings.


* Future security tutorials (free or paid) future planning Previous attendance was good to free Wednesday afternoon tutorials. Suitable topic would be how security labelling fits in with FHIR, including a demo - Q4. Mike to send Trish a summary of proposed session - so that it can be included in the January WGM brochure.

* Workgroup Health The WG Health report indicates we did note vote in TSC election, however, Mike Davis did vote - will query will HL7. Room bookings same as this meeting with addition of Free tutorial.