Skip to end of metadata
Go to start of metadata

Date:

 

Quarters - Q2/Q3/Q4

Minutes approved 2019-06-18 Security WG Agenda/Minutes 


This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."

Goals

Set goals, objectives or some context for this meeting.

Discussion items

TimeItemWhoNotes
Q2 Trish

Chaired by Trish


 Cross-Paradigm Transformation ProjectMatt 

See slide deck.  Cross Paradigm Security May WGM Update
Working with ___ to develop CDA to FHIR use cases and V2 to FHIR to develop use cases
GOAL to develop maps for V2 to FHIR and CDA to FHIR to
Have not included Provenance yet b/c there is no community consensus on how to include Provenance
KC: have they looked at CDA Provenance? Speaker: NO

FHIR meta.security mapping challenges:
• meta.security does not provide structural elements capable of indicating semantic difference between different HCS Security labels.
• VS ARV segment provides different fields (e.g. Security Classification (ARV-7) Security Handling Instructions (ARV-8), Restriction Message Location (ARV-9)
• FHIR meta.security capacity to indicate different semantics limited to -code and .system attributes (not structural, terminological)

Additional FHIR Security Mapping Challenges
• HCS requires that certain security labels be human readable at the clinical statement level of documentation, e.g., 42 USC Part 2, § 2.231
• ARV-5 segment used for rendered content
• No recognizable FHIR solution identified

Discussion with John M. and KC re codes in HCS

45PSAF Vol3 Provenance DAMMike Davis

HL7 Provenance Conceptual Model. See presentation  HL7 Provenance Conceptual Model 0502 2019 1.1.pptx

Plan is to ballot informatively in Sept and normative in Feb is informative is supportive. Top down view hopefully to meet FHIR (bottom up) in middle!

A key point is the references to chaining (Prov-O Chaining).

The security WG and EHR have been working on relationship models between the provenance in general and what this means in healthcare.

Mike Davis

See slide deck.

Threw out other version of work and started over based on comments.

Goal to ballot in January 2020.

Domain Analysis Model for Provenance

Starts from top down, while FHIR starts from bottom up.

SLIDE 1.

SLIDE 2: Federation: a group of organizations, countries, regions, etc. that have joined together to form a larger organization or government by agreeing to the federations policy Didn’t like this model, so came up with another model. See Figure 3.

SLIDE 3. Provenance Store is where the entire history of

SLIDE 4: Definitions (see “redirect” in particular)

SLIDE 5: Provenance Model. Agent sends stuff to recipient. Recipients can request / receive provenance info. Can request from Provenance store….can receive from an agent. Agent can also send REDIRET to the Store to get it to send Provenance info to the Recipient.

SLIDE 6: Broker

SLIDE 7: Provenance Entity Use Cases. NB: The Store can do analysis on Provenance chain and identify error sources…

SLIDE 8: (slide crossed out)

SLIDE 9: Provenance Storyboards: tracking production history, attribution, locate error sources, quality assessment, focused search….(could have others).

SLIDE 10: Federated Provenance Model (slide crossed out)

KC, JM, Discussion re: confidence re integrity (e.g. setting levels re: confidence level based on source of information (patient, provider author, assembler, etc.)

SLIDE 11: Provenance Services (IBM Watson Paper which echoed what was being ballot)

SLIDE 12: (slide crossed out)

SLIDE 13: Illustration of trust mechanism put in place by the Federation.

SLIDE 14: (slide crossed out) boundary view

SLIDE 15: Boundary diagram (current)

SLIDE 16: Core Provenance Metadata to be captured:

  • Who contributed to the generation of a CDA
  • When an information event recorded in a CDA occurred
  • Where an information event recorded
  • Why an information event record
  • Chaining (specifically defined) discussion of “lineage”…this version of the DAM does not go into lineage….it stops at “chain”).
  • What provence metadata ….
  • One more…..see slide

SLIDE 17: Prov Events (non-normative)

SLIDE 18 (slide crossed out) Lineage

SLIDE 19: (slide crossed out) Lineage

SLIDE 20: (slide crossed out) Lineage

SLIDE 21: Provenance Internal Agent Service Model (Appendix) (right now this is in a non-normative appendix to the DAM, but it is not discussed in any great detail.)

SLIDE 22: first effort at Chaining. (slide crossed out)

SLIDE 23: second effort (slide cross out)

SLIDE 24: Provenance Chaining (Prov-0) Now include “informed by” and “acted on behalf of….” Both concepts are important to chaining.

SLIDE 25: (slide cross out)

SLIDE 26: Provenance Class Model 1: Base: (Collection is a collection of entities that are treated as ONE entity).

SLIDE 27: Data Chaining: (slide cross out)

SLIDE 28 (slide cross out)

SLIDE 29: Prov-O Chaining (4 types of chains)

  • Activityy+Entity chain (used and generated by)
  • Activity Chain (“was informed by” relationship)
  • Entity Chain (“as derived from”)
  • Agent Chains (“acted on behalf of”)

SLIDE 30:

20

V2 to FHIR

Craig Newman & Matt Lord

Cross Paradigm Transformation Service. Progress report

Overview - Use cases and functional specification for transformation services between HL7 models. V2, FHIR, CDA etc.

FHIR provenance under consideration but a lack of consensus on how this is handled in FHIR has limited the progress in this to date. 

FHIR meta.security has mapping challenges. For instance the capacity to indicate different semantic is limited to .code and .system attributes (not structural but terminological). SOA and SEC needs to collaborate further on this.  Goal is to work with Security and OO and FHIR-I to find appropriate methods for implementing HCS.  

-

DPROV CDA

Kathleen

Deferred
15

Basic Provenance IG

Brett Marquard/Russ Ott

This session was used to discuss what work can we accomplish with the SEC WG to follow up on the project. The project is advanced sufficiently to go to the functional community and ask where to apply the provenance rules. We know the type of content but what circumstances and level does the information need to be recorded? May be useful to present the Prov-O to the community but the concepts/terminology may need to be adjusted to ensure that the terms are used the same.

Need support as they communicate with the clinical community. Signup for the call on Mondays, - details listed on SEC list.

NEXT STEPS: go to the functional committee and get guidance on where to apply provenance to. Good enough to be at the document level? Does it need to beat the section level? If so, which sections. Does it need to be at the entry level?

Need to ID the elements to be used (look to W3C)

Need to Cross-walk from the terms they are using (Author, etc) to the terms used in the W3C world.

JM: W3C: if something is ACTING then they are agents. If something is acted upon, it’s an ENTITY. ROLE is used to distinguish between the various AGENTS:

BASIC PROVENANCE focuses on TREATMENT:

MIKE’s DAM applies broadly…e.g., RESEARCH etc. as well. 

 JM: putting the PROV-O in front of the clinicians may not be a bad thing…..they are concerned about the meta data in the information itself, ORIGINAL INFO v. COPIED INFO, vs DERIVED FROM info, etc.

 MIKE: there is a lot of provenance in the health record….e.g., record indicates patient said they had an allergy….the PATIENT is the source ….that is the provenance of the information. The TRUST that the clinician has in the information will reflect the source of the information.

WED

Q3






TrishChaired by Trish
40Security - PSAF Work SessionMike David

PSAF Vol 3 Provenance Prep for Sept ballot. Mike went through the changes already made in the document. Document is being kept at a reasonably high level. Fuller descriptions of some concepts has been included. Mike will finished the draft of the document and then send it out to the group for comment and completion of missing sections where more information is requested.  

  • Data flow sequence diagrams are missing currently, John will complete this. 
  • Class models text is a more mature section - all the models established between security and EHR are referred to for comparison. 
  • The provenance chaining has specific definitions and have been grouped together in one section. 
  • Requirements section needs review. Collated from multiple sources - high level requirements for provenance and may not be useful for implementation but for understanding.

Suggestion to send out completed section for comment rather than whole document. Perhaps put it in Confluences as per the development of GDPR white paper.

15ProvenanceKathleen

Review Data Provenance CDA IG.  The DSTU has expired.. There is work going on related to CDA provenance, and renewed interest . So it needs to more forward to normative track or be retired.

CBCP is the owner for the project but Security could take it over if CBCP doesn't have an interest or provide support. Check with ONC about interest in supporting.

MOTION: We vote to refresh with the caveat of finding out what is the administrative process for this. Asking CBCP to more it forward to normative ballot.

Kathleen proposed, Mike seconded. Carried 10:2:0

20Security FHIR ConsiderationsJohn

Resolutions:

GF#22104: Provenance.activity needs ISO 21089 vocabulary

GF#22103: Need Clarity on Provenance.target use to support findable

GF#21646: Need Provenance.activity query parameter posted by john.moehrke

WED Q4GDPR Session




 Chaired by Alex Mense
20MedMij Alexander Henket
  • MedMij  (pronounced med-my) and other HIT security and privacy, Alexander Henket, NICITZ NL

    • video link can be found on YouTube and www.medmij.nl
    • It is focused on giving patients control over their records and collation of these.
    • It contains a trust framework - and contains security aspects.
    • How is GDPR incorporated? It is not overtly incorporated but is assumed that people will follow the regulations.
    • FHIR STU3 based.
25

GDPR FHIR IG

Alex Mense

Finished work on the white paper (available in Confluence) . Security>Projects> FHIR-GDPR.

The confluence page has some use cases (based on the patient summary). The next step is to create an implementation guide on how to implement the requirements. Hence we need a new project and PSS.

Project scope statement - needs to be generalised to be able to create several artifacts from the PSS. For instance initially include 2 Use Cases. Proposal to write IG covering 5 generic use cases. Alex to draft PSS and circulate for comment.

5GDPR White Paper updateAlex MenseFinished work on the white paper (available in Confluence) . Security>Projects> FHIR-GDPR.
5

GDPR Use Cases

Giorgio Cangioli

Will the PSS cover the existing Use Cases on international patient summary and stop this work as a separate item?

There was no plan to continue on this use case, as it is currently really supporting information.

International Patient Summary: Use Cases

10GDPR VocabularyPeter van LiesdonkUse case is radiology /oncology, for instance image reuse. Under GDPR this re-use is identified as processing, and therefore there is a requirement under GDPR.  Going to need to track purposes in use of information. Security labels could be used.
10

GDPR "Right to Be Forgotten"

Theresa Aardal Connor

GDPR "Right to Be Forgotten" with respect to Health Information - Legal Review.

Produced table on how it relates to other national law. Article 23 is the key part for "rights". Collated the corresponding national laws. 

Specifically Article 9 - permission to be able process PHI without consent.

Consideration of not only use, but retaining information to for other legal purposes.

The challenge is how to translate this into IGs and security labels and policies.  Teresa to provide a synopsis of this. 

4.15.2019 DRAFT_comparison of sections subject to national laws.xlsx

10
Peter van LiesdonkResearch with genomic data  -open access. But this is personal information so under GDPR you cannot use this data. The issue is the different countries have different consent processes, and GDPR means you need to re-consent.

Action items