HL7 WGM MAY 2017 - Madrid Spain Minutes

Back to Security Meetings

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.
    • See HL7 WGM Madrid 2017_Blobel_Interoperability Reference Architecture Model and HL7 WGM Madrid 2017 Blobel PMAC - A system-oriented ontology-based and policy-driven approach to interoperability
    • 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

• Review Ballot Comments and proposed dispositions

TF4FA R2 Ballot Reconcilation Spreadsheet]

• TF4FA Ballot Material

Tuesday Q3

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

• Josh assigned Core team assistance
• 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

• Bernd Blobel presented on THEWS Trusted eHealth and eWelfare Space Report on current work: trust calculation and informed trust decisions.
• He began his report on current work: trust calculation and informed trust decisions, by noting that because security and privacy crucial services for interoperability, and the lack of trust is a problem in Germany, there is an increase in spending on enabling trust technologies.
• HL7 WGM Madrid 2017_THEWS Project presentation is of particular interest to the Security WG as it is a pilot project in Finland to establish a run time trust contract between data subjects, e.g., patients, and data collectors, e.g., provider EHRs, HIEs, Apps.  The Finnish pilot epitomizes the type of implementation that the TF4FA specification seeks to enable using HL7 standards for computable security, privacy, consent, and provenance policies encoded as trust contracts between parties in an interoperable information exchange. 
• The impetus is to encourage Finnish citizens to opt-in to sharing their health information, which is the preferred EU GDPR consent scheme for national health information exchange, based on their trust in privacy protections.  Finland provides healthcare to all citizens for free and seeks to achieve ubiquitous healthcare [ubi-health] for all healthcare consumers in order to manage health resources efficiently  and effectively. The core principle is that privacy and trust are interrelated concepts: Data disclosure means loss of privacy, but an increased level of trustworthiness reduces the need for privacy.  Without trust, healthcare consumers will not consent to share their data to achieve an ubi-health ecosystem.

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.
• Bernd's key points were that the GDPR is now the law (not a directive, as it was previously). The framework is a fixed legal definition, and 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 includes;
  • Data subjects’ 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.
  • Data subjects have a “right to be forgotten”, meaning that any digital trace that a  data collector or processor has handled must be permanently removed from digital discoverability/access, which is very difficult for current data collection/analysis business models to achieve without major renovation of their systems.
  • Trace-ability and disclosure of where data has been collected, accessed, used or disclosed is now also a requirement.  
• When the participants registered the implications they raised concerns that the GDPR would impede entrepreneurial healthcare system development, and that data collector and processor would simply refuse to share their data.  Bernd responded that not only were all data collectors and processors required to share all health information in accordance with privacy consents, they are all also required to comply with jurisdictional and patient consent policies by implementing the security labeling and other technologies required for data segmentation and other means for enforcing privacy protections. 

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
    • HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) - Healthcare Audit Services Conceptual Model, Release 1 (PI ID: 1264)
    • http://www.hl7.org/ctl.cfm?action=ballots.tallydetail&ballot_id=768&ballot_cycle_id=542&ballot_voter_id=8783
    • http://wiki.hl7.org/index.php?title=PASS_Healthcare_Audit_Services
    • Negative votes = 23. Have Bernd’s comments been addressed?
    • ACTION: Vince to ask Diana where the ballot sheet is, and the status of the ballot reconciliation.
  • 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:

• Josh Mandel CDS Hooks Video
• Kevin Skekleton [Cerner Presentations]
• Remote Decision Support with CDS Hooks Kevin Skekleton

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.

• See presentations bit.ly/cds-hooks-hspc2017 and Kevin's presentation Remote Decision Support with CDS Hooks
• 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.

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”. 

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.

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.

• Workgroup Health Update - cont. THU Q2
  • Current 3 Yr Plan
  • Current Project/Product status
  • Security Health Report

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:

• Josh Mandel CDS Hooks Video
• Kevin Skekleton [Cerner Presentations]
• Remote Decision Support with CDS Hooks Kevin Skekleton

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.

• • See presentation bit.ly/cds-hooks-hspc2017
    • https://speakerdeck.com/kpshek/remote-decision-support-with-cds-hooks-hspc-hit-developers-conference
• 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