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."
Chaired by Trish
|Cross-Paradigm Transformation Project||Matt|
See slide deck. Cross Paradigm Security May WGM Update
FHIR meta.security mapping challenges:
Additional FHIR Security Mapping Challenges
Discussion with John M. and KC re codes in HCS
|45||PSAF Vol3 Provenance DAM||Mike 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.
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 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:
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)
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.
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.
|Trish||Chaired by Trish|
|40||Security - PSAF Work Session||Mike 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.
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.
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.
|20||Security FHIR Considerations||John|
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
|WED Q4||GDPR Session|
|Chaired by Alex Mense|
GDPR FHIR IG
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.
|5||GDPR White Paper update||Alex Mense||Finished work on the white paper (available in Confluence) . Security>Projects> FHIR-GDPR.|
GDPR Use Cases
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.
|10||GDPR Vocabulary||Peter van Liesdonk||Use 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.|
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.
|10||Peter van Liesdonk||Research 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.|