Skip to end of metadata
Go to start of metadata

Chair: @Kathleen Connor

Scribe: @Suzanne Gonzales-Webb 

Weekly calls Tuesdays 3PM ET

FreeConferenceCall Online Meeting Link https://www.freeconferencecall.com/join/security36

Please use free conference audio

Agenda Topics 

 Minutes Approval

Approve Meeting Minutes:  

2020-02-18 Security WG Agenda/Minutes

Motion to Approve  2/18/2020 Minutes 

Moved /Second: Dave/Mike

Approve/Abstain/Oppose: 11 - 0 - 0

PSAF Provenance Volume 3 Ballot

Review George Dixon comments 73 - 76


Amalgamated_ballotcomments_V3_PSAF_R1_N4_2020FEB mj.xlsm

Review FHIR Provenance to DAM Class Model Map

PSAF_R1_N3_2019SEP_Vol3_Provenance Recon Mark Up 20200220.docx


Motion to Approve  George Dixon comments 73-76

Moved /Second: Mike/Mohammad

Approve/Abstain/Oppose: 11 - 0 - 0

NIBs for May Ballot


Need approval of following NIBs for submission by March 1 for May ballot

Cross-Paradigm US Regulatory Security Label IG NIB

FHIR DS4P IG NIB

Motion to Approve NIBs

Moved /Second: Mike/Mohammad

Approve/Abstain/Oppose: 11 - 0 - 0

DaVinci Payer Provider Exchange IG

Privacy and Security items to discuss prior to PDex IG Block vote next week:

(1) FHIR-23312 PDex Provenance requirements went from SHALL to SHOULD

When and why did PDex 6.7 Provenance conformance requirements get lowered?

Sept 2019 Ballot http://hl7.org/fhir/us/davinci-pdex/2019Jun/6-7_Handling_Data_Provenance.html Conformance statements are SHALL – which VA voters tasked to review applauded.

Continuous Build http://build.fhir.org/ig/HL7/davinci-epdx/HandlingDataProvenance.html Conformance statements are SHOULD.

Discussion on this listed under FHIR-23312

  • Need to wait and see what comes down the pike with TEFCA and NPRM
  • Providers would like to know that it was patient generated data
  • Future IG would need to be updated to reflect regulatory requirements when they come out
  • If there's no regulatory requirements now, and implementer community doesn't feel like it's not a requirement right now, we wouldn't include in the IG at this time
    • Reluctant to enforce the industry as a whole to require something that's an unknown
    • First round make it a SHOULD, and as we learn more make it a SHALL in the next version
    • Some may require and others won't
    • That's usually point to point, and in FHIR world there will be multiple stopping points
    • There are multiple stops occurring now as well
    • Have payers, EHRs said this is a requirement?
    • Payer/provider liability if they don't have Provenance information
    • If don't know where the data came from, payer likely won't store it at all because data can't be confirmed
    • Reality is that data sharing is happening now with X12, V2, and they don't have any Provenance capability 
  • Little industry experience in sourcing Provenance - thus a SHOULD as we learn more
  • Purpose of IG is to enable greater exchange of this information - if not going to require Provenance, should at least have a statement in IG re: expectation of someone receiving this information
    • If payers can't use information without having provenance, then we could make it a SHALL, but payers haven't said this - payers just don't know yet
    • What should recipient assume if don't receive Provenance
    • Receiver knows the data was received from the source, but they don't know where the source got it from (because the source system doesn't know, or it's not able to tell me)
    • Won't have complete Provenance chains for decades
    • Nobody is required to implement this IG - if they're going to implement it, why can't it be a SHALL?
    • Payer receiving tons of clinical data, sending it to thousands of providers without provenance today - in how many situations has the information been unreliable and caused a false diagnosis?  To date, payer has not received any feedback indicating this has occurred
    • Default assumption is that receiver will treat the data as 'real' - patient safety is at risk if it's false
  • Work with Kathleen to create a paragraph in the IG that describes the issues covered in this conversation - the issues that should be considered by senders and receivers when Provenance is not sent or received - this would be an acceptable resolution to this issue 
  • Related Tracker Items:
    #23304, #23305, #23306, #23307, #23309

  • Kathleen Connor will help craft this language
  • Current Resolution:
    The PDEx work group is developing Provenance examples based upon the real-world needs of the Payer community. The value sets developed to support these requirements to record provenance activities by payors in the conversion of source data to clinical (us-core) resource formats.
    The revised Provenance profile will be incorporated into the HREx IG for use by other Da Vinci IGs and the work will also be shared with the Security Work Group as examples of real requirements that need to be supported in future revisions of the base Provenance resource.
    Related Tracker Items:
    #23304, #23305, #23306, #23307, #23309

This response indicates that PDex intends to develop Provenance examples based on Payer needs rather than simply fix the value set reference – so this disposition is off course of resolving the issue raised.Also, I may be mistaken, but my understanding is that the PDex and DaVinci Community is wider than the payer community, and work on the FHIR Provenance Resource value sets should be done during FHIR Security calls, because there’s clearly a need to ensure that participants are aware of underlying methodology and terminology.  It’s not a great idea for a select few to go off and develop payer community Provenance examples when there’s clearly some misunderstanding of the FHIR Provenance Resource.

Also, I objected on calls to this disposition, and to the change to SHOULD.  I agreed to write some guidance about what issues could result in this change.  VA voters supported SHALL, but not sure that they will support SHOULD for the simple reason of critical mass – if I have a fax machine and no one else does, why bother?  If I collect and convey Provenance and no one else does, why bother?  

Given that USCDI put Provenance as a priority, TEFCA will absolutely need it to successfully improve information liquidity, and ONC is sponsoring the Basic Provenance work, which has mandatory requirements, why would HL7 FM and Security WG support this seemingly undocumented downgrade in PDex Provenance based on what a few payers indicated as their experience or lack thereof?

(2) FHIR-23301: Does Right of Access for 3rd Party require a written request and signature?

Section 2-2-2. Change the following paragraph:

The Member-mediated Information Exchange method will build upon established OAuth2.0 protocols for patient access to their health and claims information that enables the sharing of information with third-party applications. The health history payload for the exchange would be the same FHIR resources that are passed to providers under the Provider-Payer exchange scenario.

To:

The Member-mediated Information Exchange method will build upon established OAuth2.0 protocols for patient access to their health and claims information that enables the sharing of information with third-party applications. The process of Member Authentication, typically using the member's user credentials from the Health Plan's portal, and OAuth2.0 authorization to share will form the basis of the member Consent to share.

The health history payload for the exchange would be the same FHIR resources that are passed to providers under the Provider-Payer exchange scenario.

Existing Wording: 1-1-1-2 OAuth2 Authorized Exchange:

After authenticating the Member SHALL be presented with an Authorization screen that enables them to approve the sharing of information with the Third Party, or new Health Plan, Application that has client application credentials registered with the Health Plan.

Proposed Wording: After authenticating the Member SHALL be presented with an Authorization screen that enables them to approve with a signature the sharing of information with the Third Party, or new Health Plan, Application that has client application credentials registered with the Health Plan.

KC Comment:

Individual's Right to Direct the PHI to Another Person https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html

An individual also has a right to direct the covered entity to transmit the PHI about the individual directly to another person or entity designated by the individual. The individual's request to direct the PHI to another person must be in writing, signed by the individual, and clearly identify the designated person and where to send the PHI. A covered entity may accept an electronic copy of a signed request (e.g., PDF), as well as an electronically executed request (e.g., via a secure web portal) that includes an electronic signature. The same requirements for providing the PHI to the individual, such as the fee limitations and requirements for providing the PHI in the form and format and manner requested by the individual, apply when an individual directs that the PHI be sent to another person. See 45 CFR 164.524(c)(3).

Summary:

According to OCR, the Authorization screen must provide the capability for Member to sign when directing that the payer share information with a Third Party, new Health Plan, or an Application.

Discussion

From: Mark Scrimshire [mailto:mark@ekivemark.com]
Sent: Friday, February 21, 2020 11:06 AM
To: Robert Dieterle; Kathleen Connor
Subject: FHIR-23301 citation from HHS

FHIR-23301: According to OCR, the Authorization screen must provide the capability for Member to sign when directing that the payer share information with a Third Party, new Health Plan, or an Application

The following page on hhs.gov covers making a written request and cites a secure web portal as a suitable method.

I have added this as a comment to the tracker item. Should I add this to the proposed resolution and move this to Ready-For-Vote?

https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html

"Requiring a Written Request

A covered entity may require individuals to request access in writing, provided the covered entity informs individuals of this requirement. See 45 CFR 164.524(b)(1). Covered entities also may offer individuals the option of using electronic means (e.g., e-mail, secure web portal) to make requests for access. In addition, a covered entity may require individuals to use the entity’s own supplied form, provided use of the form does not create a barrier to or unreasonably delay the individual from obtaining access to his PHI, as described below."

Note: 
Offering an electronic means is acceptable. One example cited is a "secure web portal". This implies that an individual using their secure web portal credentials to authenticate to a secure api in order to authorize an exchange of data would be a valid method for requesting access.

KC Response

This is not guidance about ROA for 3rd parties.  It doesn’t satisfy as the evidence I requested unfortunately, so I can’t agree that this comment is ready for vote.

The section of the FAQ below - Requests for Access - is about a patient requesting access for themselves.

It does not address the 3rd Party App use case, where OCR explicitly says that the provider MUST require the request be in writing and signed.

Please scroll down ½ way down this FAQ page https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html

 to the following:

Individual’s Right to Direct the PHI to Another Person

An individual also has a right to direct the covered entity to transmit the PHI about the individual directly to another person or entity designated by the individual.  The individual’s request to direct the PHI to another person must be in writing, signed by the individual, and clearly identify the designated person and where to send the PHI.  A covered entity may accept an electronic copy of a signed request (e.g., PDF), as well as an electronically executed request (e.g., via a secure web portal) that includes an electronic signature.  The same requirements for providing the PHI to the individual, such as the fee limitations and requirements for providing the PHI in the form and format and manner requested by the individual, apply when an individual directs that the PHI be sent to another person.  See 45 CFR 164.524(c)(3).

Now compare the 2 sections:

https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/a- ccess/index.html

"Requiring a Written Request

A covered entity may require individuals to request access in writing, provided the covered entity informs individuals of this requirement. See 45 CFR 164.524(b)(1). Covered entities also may offer individuals the option of using electronic means (e.g., e-mail, secure web portal) to make requests for access.

Note the differences

Additional Guidance

Right to Have PHI Sent Directly to a Designated Third Party

Can an individual, through the HIPAA right of access, have his or her health care provider or health plan send the individual’s PHI to a third party?

Yes.  If requested by an individual, a covered entity must transmit an individual’s PHI directly to another person or entity designated by the individual.  The individual’s request must be in writing, signed by the individual, and clearly identify the designated person or entity and where to send the PHI.  See 45 CFR 164.524(c)(3)(ii).  A covered entity may accept an electronic copy of a signed request (e.g., PDF or scanned image), an electronically executed request (e.g., via a secure web portal) that includes an electronic signature, or a faxed or mailed copy of a signed request. From <https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html>

Individual’s Right to Direct the PHI to Another Person

An individual also has a right to direct the covered entity to transmit the PHI about the individual directly to another person or entity designated by the individual.  The individual’s request to direct the PHI to another person must be in writing, signed by the individual, and clearly identify the designated person and where to send the PHI.  A covered entity may accept an electronic copy of a signed request (e.g., PDF), as well as an electronically executed request (e.g., via a secure web portal) that includes an electronic signature.  The same requirements for providing the PHI to the individual, such as the fee limitations and requirements for providing the PHI in the form and format and manner requested by the individual, apply when an individual directs that the PHI be sent to another person.  See 45 CFR 164.524(c)(3).  From <https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html>

(3) RE FHIR-23293 CDS Hooks OAuth Tokens

Mohammad states that the Proposed Disposition “A token for access to the Payer FHIR API and the URI of the appropriate endpoint  is issued by the Payer CDS service in response to a successful CDS-Hook request” to his comment seems to have missed the point. I.e., OAuth tokens are issued by OAuth servers. The CDS server is not an OAuth server and cannot “issue” OAuth tokens; that’s why I asked the question of who issues this token that’s returned by the CDS.

 BACKGROUND

FHIR-23293 – Jira Comment

From minutes:

  • Following the CDS Hooks/ SMART on FHIR use case, which has been tested at multiple Connectathons
  • Up until we used it for PDex, the use of CDS Hooks was always from a 3rd party to a provider, and not from a provider to a payer
  • Token is being issued exactly the same way
  • Responder of the CDS Hook is issuing a token in this case (the data holder is issuing the token)
  • FHIR Specification Feedback
  • FHIR-23293

It is not clear who issues this Access Token and who it is issued to - PDex #101

http://hl7.org/fhir/us/davinci-pdex/2019Jun/6-4_Hook_Configuration.html

 Resolution Description:

A token for access to the Payer FHIR API and the URI of the appropriate endpoint  is issued by the Payer CDS service in response to a successful CDS-Hook request. 

Description

Existing Wording: When a Card is returned from the CDS Hooks appointment-book service by a Health Plan it will provide the following elements:

  • An Access Token for secure access to the Health Plan's FHIR API

Comment:

It is not clear who issues this Access Token and who it is issued to. If this is an OAuth access token, the flow for issuing it and identifying the client to the OAuth server must be clarified. It is also a major flaw from the OAuth perspective that the Access Token which must be known only to the specific client (in order to ensure accountability) is shared with the CDS service. Generally access tokens should not be known to any party other than the Client and the OAuth Server.

Moreover, it must be clearly stated that this access token must be restricted only to the Member in question and the recipient must not be able to recover any other members' information using this access token.

Summary:

It is not clear who issues this Access Token and who it is issued to

Proposed Disposition

A token for access to the Payer FHIR API and the URI of the appropriate endpoint  is issued by the Payer CDS service in response to a successful CDS Hook request. 

Long discussion begins a 8:30 minutes on  2/25/2020 Meeting Recording
CARIN IG Report OutSecurity is a cosponsor of CARIN Blue Button IG. Amol will give us an update on the IG progress.
Share with Protections

Mike Davis



PDF Presentation

Two matured documents

  1. Share with Protections (doc)
    1. security healthcare information, Share with Protections--an HL7 concept in order to further DS4P in conceptual components
  2. Data Protections, Privacy, Security, Access, Liquidity and Availability Series (PPT)


Mike is requesting for critical review - please send comments to Mike Davis (mike.Davis@va.gov or


FHIR Security

Permission Resource

http://zeora.net/blog/2019/11/19/permission-is-key/

Further discussion on sub-resource security labeling and a consent extension being used as a usage restriction policy.

https://chat.fhir.org/#narrow/stream/179166-implementers/topic/FHIR.20Security.20Partial.20Display.20of.20Instance

http://build.fhir.org/ig/HL7/VhDir/Bundle-womens-shelter.xml.html - IG with security label extension

http://build.fhir.org/ig/HL7/VhDir/StructureDefinition-vhdir-restriction.html VhDir "Restriction" Consent profile

http://build.fhir.org/ig/HL7/VhDir/StructureDefinition-usage-restriction.html VhDir "Usage Restriction" extension





FHIR DS4P IG

Discuss

FMG approved: FHIR DS4P IG

For background - https://register.gotowebinar.com/recording/8462533483478463489 Webinar

Cross Paradigm US Regulatory Security Label IG


Review

FMG approved the revise FHIR US Regulatory Security Label IG proposal 1/08/2020

FHIR GitHub set up.  John and Mohammad are committers.

For Look and Feel see

http://build.fhir.org/ig/JohnMoehrke/security-gov-regs/branches/master/index.html

Meeting Adjournment

Meeting adjourned at 12:58 PT

Security Calls:  next meeting will be 3/03/2020

Temporary meeting recording: 2/25/2020 Meeting Recording


Attendees

  •  
@Adam Wong adam.wong@hhs.govHHS
  •  
ONC
  •  
HL7 Austria
  •  
Kaiser
  •  
Amol Vyas amol.vyas@cambiahealth.comCambia Health
  •  
Wave One
  •  
Aegis
  •  
Celine Lefebvre Celine.Lefebvre@ama-assn.org AMA
  •  
Clara Y. Ren clara.y.ren.ctr@mail.milFederal Electronic Health Records Modernization (FEHRM) Office
  •  

Chris Shawn, Co-Chair

VA
  •  

Craig.Newman@altarum.org

  •  
 Ready Computing
  •  
 @David Staggs drs@securityrs.comSRS 
  •  
Sequoia
  •  
Heather McComas heather.mccomas@ama-assn.org AMA 
  •  
EPIC
  •  
Jim KamperAltarum
  •  
Federal Electronic Health Records Modernization (FEHRM) Office
  •  
SRS
  •  

John Davis (Mike)

VA
  •  

John Moehrke Co-Chair

By-Light
  •  
Aegis
  •  
Julie Chan jchan@cwglobalconsult.comCWGlobal
  •  

Kathleen Connor  Co-Chair

VA (Book Zurman)
  •  
Laura Bright laurabright4@gmail.com
  •  
Laura Hoffman laura.hoffman@ama-assn.orgAMA
  •  
Lenel James lenel.james@bcbsa.comBCBSA
  •  
EMR Direct
  •  
Sequoia
  •  
Mark Roberts mark.roberts@leavittpartners.comLeavitt Partners - CARIN
  •  
Matthew Reid matt.reid@ama-assn.orgAMA
  •  
VA (Book Zurman)
  •  

  •  
Pat Taylor pat.taylor@bcbsaBCBSA
  •  
 PJM Consulting
  •  
Phillips
  •  
Trustworthy EHR 
  •  

@Ricky Sahu, @1up.health  

1up Health
  •  

Robert Dieterle rdieterle@enablecare.us

Enablecare

Russ Ott rott@deloitte.comDeloitte
  •  
Saul Kravitz saul@mitre.orgMITRE
  •  
Scott Fradkin sfradkin@flexion.us
  •  

Jopari

  •  
Stephen MacVicar smacvicar@mitre.orgMITRE
  •  
VA (Book Zurman)
  •  
 AMA
  •  

  •  
Flinders University
  •  
Vicki Giatzikis vig9034@nyp.orgNYP


  • No labels

3 Comments

  1. Also posted here: FHIR-23312 - Getting issue details... STATUS


    We understand concerns from BCBS (and likely others) that they cannot accurately provide Provenance for the data that comes through their system. There has to be a whole health IT shift within the industry to start providing the needed data elements and also to ensure that the attribution is correct (we all know the stories about people using other people’s logins; but also, some of these systems use default values that no user put in, resulting in a user is potentially being associated to those automated inputs). To be fair, all kinds of “sausage-making” is going to be uncovered by Provenance. At some point, the industry has to pull off the band-aid though. The recent ONC Strategic plan discusses an explosion of data-sharing and app availability, but the users of that data need to understand what level of trust they can have in the data.

    Additionally, while Provenance doesn’t really have a way to say how accurate it is, we do have the AuditEvent that can describe the when/how a Provenance was built for the resource (Audit can be for the resource, so you could have audit on say, the patient resource, but also an audit on the provenance for that resource). That could be an option for vendors to provide information about their own Provenance so that end-users can judge for themselves how trustworthy the Provenance is. While we recognize that at this time, many vendors might have issues providing good, accurate Provenance, we’ll never get there if we don’t start enforcing it at some point. We also believe with the inclusion of provenance in the USCDI, physicians will increasingly expect and request access to data history—becoming critical in informing their clinical decision making based on that data.

    In sum, the AMA believes provenance in the PDex will be very important to helping physicians know the history of the data they’re getting from payers so they can trust it. We’d want Provenance to be a SHALL, not SHOULD.

    1. Laura, can you explain a bit more about your second paragraph? What do you feel is missing in the Provenance that you find in AuditEvent? Or is your paragraph more about the realities of historic practice, and thus not a statement about the FHIR object model?

      1. Hi John, I was commenting more on the realities of historic practices. I'm not advocating changing the Provenance resource, but rather just noting that there are options for vendors who have not historically been gathering the kind of data needed to fully execute a Provenance resource, like AuditEvent that can show a history of the underlying resource. While we understand the difficulty that some systems may have in generating Provenance today, that problem doesn’t get better by delaying implementation.