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

HL7 WGM MAY 2017 - Madrid Spain Minutes

From HL7Wiki
Jump to navigation Jump to search

Back to Security Meetings


MINUTES WGM Madrid 6th-12th May 2017

Tuesday Q1

Opening Security WG Meeting

Attendees:

  • John Moehrke John.Moehrke@gmail.com
  • Alexander Mense alexander.mense@hl7.at
  • Princess Trish Williams patricia.williams@flinders.edu.au
  • Kathleen Connor Kathleen.connor@comcast.net
  • Hideyuki Miyohara miyohara.hideyuki@ap.mitsubishi-electric.co.jp
  • Bernd Blobel bernd.blobel@klinik.uni-regensburg.de
  • Kevin Shekleton kshekleton@cerner.com
  • Ashley Duncan a.duncan@furore.com
  • Reinhard Egalkrout reinhard.egelkrout@hl7.at
  • Karl Holzer karl.holzer@cgm.com
  • Introductions
  • Approval of agenda - John/Bernd 10/0/0
  • International Report outs
    • John attended the FHIR connectathon on Sat. Assisted tables, many thinking about security but few had actually integrated it yet.
    • Europe (Bernd & Alex):
      • Security and privacy crucial services for interoperability. Lack of trust is a problem in Germany and the increase in spending on it.
      • Law (not a directive) the EU General Data Protection Regulation (GDPR). The framework is a fixed legal definition. It reflects the new care paradigms, multi domain and multi policies (health and social data) and secondary use for e-business but protecting citizens across Europe. Policy must be written for the end-user (e.g. for a child it must be written so they can understand it). Detailed auditing schema has also been developed.
      • GDPR also right to access their data enforcing data portability to ensure readable electronic format on request.
      • Directive on security networks systems. Mainly focus on critical infrastructure to ensure continuity planning. Trace-ability of data also a requirement.
      • Austria uses opt-out but this may not align with the new GDPR.



    • Australia (Trish): Australia has finally passed mandatory computer security breach reporting laws. Opt-out for MyHealth Record (national health record summary) will now be adopted from 2019.
    • Japan (Hide): Transfer of information from one provider to another requires from patient and uses organizational authorization assertion. Divide healthcare and other networks due to level of threat surface (malware and ransomware). Next year starting whole systems (cross-network) use.

Discussion on Opt-in and Opt-out terminology: Sometimes it describes an event, or a state and this impacts the consent model and its interpretation e.g. implied-consent or explicit-consent. In simple process (share to one) it is acceptable, but in complex systems (secondary use and subsequent sharing).

  • HL7 Policy Advisory Committee update
    • Looking at ONC Standards Advisory and going through and evaluating where HL7 suggestions were amended or ignored. 21st Century Cures Act has impact for security and privacy. In addition to privacy a national trust framework for consumers is required by Cures Act, and the committee is reviewing approaches.
  • Liaison Reports: ISO, IHE, ONC
    • ISO
      • See presentation (Hide)
      • Trends for Standardization of Electronic Signatures -ISO17090-4 CAdes (ISO 14533-1:2012)/XAdES (ISO 14533-2:2012) profiles.
    • IHE
      • The digital signature profile to go to final text (after several years in development).
    • ONC
      • Patient choice for research and comping up with an implementation plan.
  • HL7 Project status and updates (Not completed in Q1):
    • FHIR Security - AuditEvent, Provenance, Security Labels
    • Trust Framework - Ballot Report and WGM Reconciliation Plans, Links to FHIR Security
    • SLS Revisions - WGM Development Plans, Links to FHIR Security
    • SOA Audit - Status, Development Plans, Links to FHIR Security
    • FHIR Privacy and Security Conformance Test Suite Development - Discussions planned for WGM

Tuesday Q2

Attendees:

  • John Moehrke John.Moehrke@gmail.com
  • Alexander Mense alexander.mense@hl7.at
  • Princess Trish Williams patricia.williams@flinders.edu.au
  • Kathleen Connor Kathleen.connor@comcast.net
  • Hideyuki Miyohara miyohara.hideyuki@ap.mitsubishi-electric.co.jp
  • Bernd Blobel bernd.blobel@klinik.uni-regensburg.de


Trust Framework Work Session 

TF4FA R2 Ballot Reconcilation Spreadsheet]

Tuesday Q3

Attendees: CBCC (hosting) FHIR-I Joint on FHIR Consent Resource

Tuesday Q4

Attendees:

  • Alexander Mense alexander.mense@hl7.at
  • Ashley Duncan a.duncan@furore.com
  • Bernd Blobel bernd.blobel@klinik.uni-regensburg.de
  • Hideyuki Miyohara miyohara.hideyuki@ap.mitsubishi-electric.co.jp
  • Kathleen Connor Kathleen.connor@comcast.net
  • Marilyn Harthoorn m.harthoorn@furore.com


Security WG Project Meeting

Wednesday Q1

Attendees: See EHR WG Minutes

Joint w/ EHR, CBCC, FHIR, SOA, Security

  • 1. ISO 21089:2017 Trusted End-to-End Information Flows - approved and preparing for publication.
  • 2. Development of Privacy, Security, Provenance and Digital Ledger Technology Conformance Testing Suite
    • a. Kathleen Connor, John Moehrke
    • b. With Mario Hyland – AEGIS – HL7 Testing Partner
      • i. AEGIS Touchdown Project FHIR testing platform
    • c. Use Case: US VA Cascading OAuth Server
      • i. Expectation is that WGs will bring any test cases [e.g., Cascading OAuth for Patient Right of Access] have been developed or input to test cases
    • d. Use Case: Provenance – e.g., US S&I DPROV System Events
  • 3. FHIR STU-3
    • a. Record Lifecycle Events IG
    • b. Implementer’s Safety Checklist
    • c. W5 Report – Key Metadata Alignment across FHIR Resources
  • 4. EU General Data Protection Regulation (GDPR)
    • a. Presentation by Bernd Blobel on EU Data Protection: Does it hamper or support the Health systems. EU GDPR Slide Presentation
    • b. Paradigm change for health systems – context of adaptable policy design as well as systems design. Including – demographic changes, expectations, fundamental right for equal care, technological developments and so on.
    • c. Intent of a single framework across Europe.

Wednesday Q2

Attendees: See SOA Minutes

Joint w/ SOA

  • PASS Audit topics (joint w Security, CBCC, SOA)
  • Two projects with SEC/SOA
    • Project 914 PASS Audit
      • Front page incorrect 2 Negatives (John / Keith) remaining in ballot from Jan 2017. But only 1 listed on stats http://www.hl7.org/ctl.cfm?action=ballots.tallydetail&ballot_id=1488&ballot_cycle_id=542&ballot_voter_id=8783
      • ACTION: Trish to ask Kathleen for reconciliation in the spreadsheet- clarify status of the -negative and how they need to be resolved. Trish to report back to SOA. RESPONSE: All comments were reconciled and the negative commenters asked to withdraw - however, as it is an informative document there is no necessity to withdraw votes. I expect that this is how it will remain - even though there is a discrepancy between the total (1 negative) and 2 listed in the detail below!
    • Post-ballot comments new version has an extended name, no change to the project number.
    • Project 1264
    • For noting: New project 1316 Integrated Information Models and Tools(IIM&T)
      • Taking EHR system functional model and describing it in CIMI modelling terminology
      • The original model included Security but the new project is not sponsored yet by SEC WG.

Wednesday Q3

Attendees:

  • John Moehrke John.Moehrke@gmail.com
  • Alexander Mense alexander.mense@hl7.at
  • Princess Trish Williams patricia.williams@flinders.edu.au
  • Kathleen Connor Kathleen.connor@comcast.net
  • Hideyuki Miyohara miyohara.hideyuki@ap.mitsubishi-electric.co.jp
  • Bernd Blobel bernd.blobel@klinik.uni-regensburg.de
  • Kevin Shekleton kshekleton@cerner.com
  • Karl Holzer karl.holzer@cgm.com
  • Chris Grenz chris.grenz@analysts.com
  • David Hay david.hay25@gmail.com
  • afarkas@infoway.ca
  • wjones46@dxc.com
  • v.peretokin@furore.com
  • Richard Kavanagh richard.kavanagh@nhs.net
  • Dennis Patterson dennis.patterson@cerner.com
  • Adam Hatherly adam.hatherly@nhs.net
  • Oliver Krauss oliver.krauss@fh-hageberg.at
  • Oliver Egger oliver.egger@ahdis.ch
  • Drew Torres drew.torres@cerner.com
  • isaac@epic.com
  • Josh Mandel Joshua.Mandel@childrens.harvard.edu

Security WG deep FHIR topics

  • SMART on FHIR
    • Scope of SMART in FHIR is intended to be international, and the protocol from SMART App Launch framework – which can be launched from inside or outside the EHR.
    • Data profiles can be specified nationally or internationally.
    • SMART App Launch: design principles
      • Give what is needed for secure interoperability
        • E.g. OAuth (bearer tokens) and OICD
      • Focus on vanilla features of standard frameworks.
    • What is an App Launch?
      • Health data – access token (e.g. FHIR API) and Contextual data (end user identity).
      • OAuth normal flow used.
      • Limiting access approach – OAuth scopes – granular permissions (relates to FHIR resources types)
    • Authorisation Risk Assessment (Argonaut Project) – provides guiding developer facing documentation and worth reading. For example – Residual Risks would include EHR Developer and App Developer Responsibilities, and Public Client support via CORS.
    • bit.ly/smart-app-launch-hl7
  • Introduction to CDS-Hook
    • CDS Hooks: A vendor agnostic remote decision support specification

CDS-Hooks uses SMART on FHIR to specify services to create vendor-independent “substitutable apps” that can be plugged into a variety of EHR and other systems. The services equips a native EHR with an event model, triggering calls to remote CDS services when specific user activities occur (e.g., "prescribe a drug", or "open a patient record"). These CDS Hook services can respond with advice, alternative suggestions, and in-context app launch links that can be presented to the user in accordance with explicit user experience guidelines. The following videos provide excellent presentations on CDS Hooks:

This CDS-Hook services might be an approach for creating “break glass” alerts for e.g., drug-drug interactions where the treating provider did not have clearance to view the entire record – e.g., where a patient has not consented for this provider to access sensitive information. The SLS would provide the CDS with unmasked record while permitting the treating provider to only access the masked record until provider executed break glass based on the CDS alert. 

SMART on FHIR  Deep dive on HOW it does this 
Experience from the field 
Are their known stepping-stones 
Work on how FHIR should address SMART vs HEART vs IUA vs TLS vs others 
Various use-cases  User using browser app 
User using mobile App 
System-to-system (e.g. organization to organization)

Introduction to CDS Hooks Some points that might not be fully clear why I am interested in CDS Hooks. First, the security workgroup knows that we are not experts on medical information. We see the general concept of CDS to be a service that fully understands medical information. Thus we callup the general concept to tell us if there are sensitive health topics. This is what we have encapsulated in the SLS. So, wondering how we can leverage CDS Hooks similarly. I think this is what Grahame was referring to with the point about suggesting security tags to the user. It would be best if the user doesn't need to think about security-tags, although they should be able to change them authoritatively with proper authorization. Adding a layer that can transparently assess the data using current CDS knowledge and expertise to apply proper security-tags. The other point is that to fully protect healthcare data to the very finegrain level that some envision, we need not only security assessment of the data in create/update, or resting, but also during accessing. Today OAuth scopes are very simplistic (i.e. SMART), but eventually they need to get more detailed and multi-layered. Way beyond what OAuth standards support today. The interpretation of the OAuth security token, relative to the query requested, and the results it uncovers; should be done by some security layer that is aware of FHIR, but is not fundamentally changing the baseline concept that is FHIR. --- So I am looking at what you have done with CDS Hooks to see if there is something similar that can be done to advance the capability toward more fine grain authorization enforcement.

Wednesday Q4

Attendees:

  • Alexander Mense alexander.mense@hl7.at
  • Princess Trish Williams patricia.williams@flinders.edu.au
  • Kathleen Connor Kathleen.connor@comcast.net
  • Hideyuki Miyohara miyohara.hideyuki@ap.mitsubishi-electric.co.jp
  • Bernd Blobel bernd.blobel@klinik.uni-regensburg.de

Security WG Project Meeting

  • Continue TF4FA Reconciliation

Spent the majority of the session on Bernd Blobel's comments related to the difference in the information model meaning of the term “composite policy”, which generally has the meaning in HL7 and OASIS of a grouped set of security and privacy policies.  However, the author and supporters of the ISO 22600 Privilege Management Access Control standard, in particular Dr. Bernd Blobel, the author, and Dr. Alex Mense, the chair of HL7 Austria (both graduate level security professors) understood a “Composite Policy” to mean the abstract idea of a “Policy for Composing Policies”. 

ISO 22600 PMAC Policy Model

This is an entirely different meaning from that upon which the HL7 Security and Community and Collaborative Care (CBCC) had been operating, and as defined in the Composite Security and Privacy 2014 DAM.

Composite Security and Privacy Model

Class: CompositePolicy This class is the focal class for electronic privacy policies. It contains a set of basic policies that work together to enforce a privacy policy, organizational standard operating procedure, or a privacy consent directive. Its basic characteristic is that it contains other policies. An instance of a CompositePolicy may include several Authorization, Delegation, Refrain, or Obligation policies. A CompositePolicy is specialization of the abstract Policy class and inherits all its attributes and associations. In addition to the attributes it inherits from its base class ('Policy'), this type of class contains the following association and attribute: Attribute 'CompositePolicy.combiningAlgorithm' of type ' ' with cardinality of [1] This attribute is used to specify the policy combining algorithm that is used to process the contained policies. Association 'CompositePolicy.containedPolicy' of type ' BasicPolicy' with cardinality of [1..*] This association specifies the policies contained in a CompositionPolicy.

This misunderstanding about the key about a very abstract term “Composite Policy” seems to be a translation issue between the original German text and the English translation, which we only came to realize after much gesturing and diagramming on a white board. After much discussion, the HL7 Security Cochairs and Dr. Blobel were find able to a relatively simple mitigation path that will not require major revision of current foundational ISO standards. That is, to understand the meaning of Composite Policy in PMAC as "Composition Policy" and understanding the meaning of the DAM Composite Policy Class as the top level of a nested set of Basic Policies. The DAM definition will need to be revised, and PMAC should have a better definition and description of Composite Policy.

Thursday Q1

Attendees:

  • John Moehrke John.Moehrke@gmail.com
  • Alexander Mense alexander.mense@hl7.at
  • Kathleen Connor Kathleen.connor@comcast.net
  • Hideyuki Miyohara miyohara.hideyuki@ap.mitsubishi-electric.co.jp
  • Kevin Shekleton kshekleton@cerner.com
  • Karl Holzer karl.holzer@cgm.com
  • Andreas Schuler andreas.schuler@fh-hageberg.at
  • Elliot Silver elliot.silver@mekesson.com
  • Dave Pyke david.pyke@readycomputing.com
  • Grahame Grieve grahameg@gmail.com

Security Joint with CBCC,FHIR-I

  • Josh assigned FHIR Core team
  • Continued: FHIR Connectathon Privacy and Security testing scenarios
  • how might GraphDefinition be used with Provenance? How might it be used in an Audit Analysis/Reporting?
  • how might a client that get subsetted/redacted data be enabled to do Update/Patch?
    • Subsetted by _summary
    • Subsetted by some client request (not yet available, is this a FHIR-I work item?)
      • Some mechanism that is based on profiles, where client asks data to be subsetted to the constraints in a profile
    • Subsetted by redaction rules -- where communicating the redaction result
    • So That - when an update happens, the server knows that the client is NOT asking to have the elements missing be removed from the server copy.
    • What might be issues?
  • Can we use a general subsetting type of a profile to enable more complete de-identification algorithms.
  • Vote passed to ass Security WG as a stakeholder on the SMART Application Launch Framework PSS (not yet allocated a Project ID)
  • Introduction to CDS-Hook
    • CDS Hooks: A vendor agnostic remote decision support specification

CDS-Hooks uses SMART on FHIR to specify services to create vendor-independent “substitutable apps” that can be plugged into a variety of EHR and other systems. The services equips a native EHR with an event model, triggering calls to remote CDS services when specific user activities occur (e.g., "prescribe a drug", or "open a patient record"). These CDS Hook services can respond with advice, alternative suggestions, and in-context app launch links that can be presented to the user in accordance with explicit user experience guidelines. The following videos provide excellent presentations on CDS Hooks:

This CDS-Hook services might be an approach for creating “break glass” alerts for e.g., drug-drug interactions where the treating provider did not have clearance to view the entire record – e.g., where a patient has not consented for this provider to access sensitive information. The SLS would provide the CDS with unmasked record while permitting the treating provider to only access the masked record until provider executed break glass based on the CDS alert.

  • John Moehrke's Session Goals from Wed Q3 Security WG Agenda:
  • SMART on FHIR
    • Deep dive on HOW it does this
    • Experience from the field
    • Are their known stepping-stones
    • Work on how FHIR should address SMART vs HEART vs IUA vs TLS vs others
    • Various use-cases
      • User using browser app
      • User using mobile App
      • System-to-system (e.g. organization to organization)
  • Introduction to CDS Hooks
    • Some points that might not be fully clear why I am interested in CDS Hooks. First,
    • the security workgroup knows that we are not experts on medical information. We see the general concept of CDS to be a service that fully understands medical information. Thus we callup the general concept to tell us if there are sensitive health topics. This is what we have encapsulated in the SLS. So, wondering how we can leverage CDS Hooks similarly. I think this is what Grahame was referring to with the point about suggesting security tags to the user. It would be best if the user doesn't need to think about security-tags, although they should be able to change them authoritatively with proper authorization. Adding a layer that can transparently assess the data using current CDS knowledge and expertise to apply proper security-tags.
    • The other point is that to fully protect healthcare data to the very finegrain level that some envision, we need not only security assessment of the data in create/update, or resting, but also during accessing. Today OAuth scopes are very simplistic (i.e. SMART), but eventually they need to get more detailed and multi-layered. Way beyond what OAuth standards support today. The interpretation of the OAuth security token, relative to the query requested, and the results it uncovers; should be done by some security layer that is aware of FHIR, but is not fundamentally changing the baseline concept that is FHIR. --- So I am looking at what you have done with CDS Hooks to see if there is something similar that can be done to advance the capability toward more fine grain authorization enforcement.

Thursday Q2

Attendees:

  • John Moehrke John.Moehrke@gmail.com
  • Alexander Mense alexander.mense@hl7.at
  • Princess Trish Williams patricia.williams@flinders.edu.au
  • Kathleen Connor Kathleen.connor@comcast.net
  • Hideyuki Miyohara miyohara.hideyuki@ap.mitsubishi-electric.co.jp


WorkGroup discussion on directions from TSC

  • Look at Mission and Charter and does the WG name reflect what the SEC WG does.
    • Discussion included consideration of adding Privacy to the WG name. However, we enforce policies on consent and provenance etc, but not defining the Patient Consent interaction with the patient.
    • Also we focus on technical controls. ISO calls WG4 Security, Privacy and Safety.
    • Consensus that the name should remain the same. The mission and charter can articulate the narrative of policy and controls and contribute and enable other standards in HL7.
    • The SCOPE for the WG was discussed and revised. Refer to the new Mission and Charter document. Alex to continue revision and organize vote and post.
    • Decision Making Processes [v6.0] reviewed and reconfirmed. Motion to readopt DMP (Kathleen proposed/John seconded) Passed 4/0/0.
    • SWOT will be discussed at a weekly call.
  • Discussion on meetings for next WGM and liaison with other WGs -for instance Health Care Devices, Mobile Health.
    • For the next WGM, Security WG will email to Co-Chairs to offer a Sec representative to attend a session with them, at their request. This will be offered for Tues Q4 or Wed Q2 (existing Joint with SOA with a Sec Representative will still occur). The first 4 requests will be accepted. This is a trial for the next WGM, and will be reassessed at the next meeting. Trish sent email 11/5/17.
  • Re-instate calls - Alex to do.

Security WG Project Meeting

  • July Harmonization Proposals: Signature Types
    • Addition to FHIR Agent value set
    • POU additions - HTEST, Research Consent POUs
    • Prose Object code system
Retrieved from "https://wiki.hl7.org/w/index.php?title=HL7_WGM_MAY_2017_-_Madrid_Spain_Minutes&oldid=139879"