[Openid-specs-heart] Alice's health resource set
Debbie Bucci
debbucci at gmail.com
Thu Aug 4 21:37:07 UTC 2016
Hi Robert
Curious ... is this the same for a provider that do not have access to the
PACS internal system?
On Aug 4, 2016 3:46 PM, "Robert Horn" <robert.horn at agfa.com> wrote:
> As a specific example, the normal practice in radiology is that while the
> patient's images (X-ray, CT, etc.) will be available internally from the
> PACS by network, this option is not made available to the patient. The
> patient is offered a CD/DVD with the DICOM images. These are two
> completely different technical mechanisms. HIPAA is entirely satisfied.
> The internal use and external delivery need not be the same mechanisms.
>
> The CD/DVD has full fidelity complete DICOM images, and the
> interoperability of these media is excellent. There are annual
> connectathons, plus other verification. The feed back that I have from
> tertiary hospitals (where the patient frequently arrives carrying their
> DVDs) is that well over 95% of external media are useable. The primary
> issue is physical damage to the media due to poor storage.
>
> This system is well established now, with 300-500 million DVDs being
> delivered annually around the world.
>
> It also reflects a very different set of tradeoffs and expectations than
> the network centric discussions here. With media the patient has total
> control and complete responsibility for proper security and storage. There
> are advantages, in that there is no infrastructural or organizational
> barrier to patient access and patient makes all decisions about what to
> share and with whom. It has become the norm for the patient to bring their
> images to a selected provider as part of the admission process. (A
> chronic patient can easily accumulate 100+ GBytes of images. Delivering
> these by DVD is often more convenient than managing the huge network
> transfers.)
>
> There are also disadvantages. Many patients are unable to provide proper
> security and storage for their DVDs.
>
> Kind Regards,
>
> * Robert Horn | **Agfa HealthCare*
> Interoperability Architect | HE/Technology Office
> T +1 978 897 4860
>
> Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405,
> USA
> http://www.agfahealthcare.com
> http://blog.agfahealthcare.com
> ------------------------------
> Click on link to read important disclaimer: http://www.agfahealthcare.com/
> maildisclaimer
>
>
>
> From: "Aaron Seib, NATE" <aaron.seib at nate-trust.org>
> To: "'Adrian Gropper'" <agropper at healthurl.com>
> Cc: openid-specs-heart at lists.openid.net
> Date: 08/03/2016 10:58 AM
> Subject: Re: [Openid-specs-heart] Alice's health resource set
> Sent by: "Openid-specs-heart" <openid-specs-heart-bounces@
> lists.openid.net>
> ------------------------------
>
>
>
> Good.
>
> Before I jump into responding to your summary I think it would be helpful
> to unpack the statement you make about the other important aspect of HIPAA
> that is relevant.
>
> Below, where you say:
>
> · “when a HIPAA Covered Entity (e.g. typical EHR) has an
> electronic means for sharing data available, it MUST offer that method to
> the patient as well. This means that if FHIR is used for sharing data under
> TPO, regardless of what the NPP say or don't say, Alice has a HIPAA right
> to request her data on FHIR.”
>
> I think this is in the right vein but is imprecise and if we are going to
> make any progress we have to be more precise – if those on this thread are
> having a hard time parsing what is said we can be sure external
> stakeholders think we are talking gibberish.
>
> This ascertain “When a HIPAA Covered Entity (CE) has an electronic means
> of sharing data it must offer that method to the patient as well.” is a
> reasonable sound bite but I think since some of the folks that are part of
> this work group are relatively healthcare neophytes and it would be
> valuable to unpack that a bit because there are two qualifiers under HIPAA
> for covered entities..
>
> The two qualifiers that apply from HIPAA are “readily producible” and the
> notion that the discloser is not required to do anything that would expose
> their system to additional risk. We shouldn’t gloss over these
> pre-conditions because I think it will only result in heart-ache and
> disappointment for those who set their expectations on the notion that ‘if
> they can do it with providers they should be able to do it with
> consumers’. I agree that this is the intuitive expectation but there is
> enough wiggle room in the preconditions to pass a container ship through
> and if we are serious about making progress we need to figure out how to
> address or constrain the qualifiers IMHO.
>
> If our work doesn’t address what it means for a consumer facing disclosure
> to be readily producible in a way that does not expose the RS to new
> security risks we will be creating a false expectation on the part of the
> families that are depending on us to get this right – so for me I feel we
> have a responsibility to speak to it.
>
> Adrian – I am not trying to say that you meant to side step these
> qualifiers in any way – but I think it is important for us to document them
> somewhere as part of the preconditions that need to be true before we
> create inaccurate expectations. Like the policy related issues that Oliver
> was bringing to the table yesterday – I think it is important for a
> technical only solution to point out these “policy” constraints so that we
> don’t fool ourselves into thinking we solved the problem of patient access
> without actually solving anything.
>
> This is the way that I simplify it so that I can keep it straight. I
> welcome everyones feedback.
>
> I believe that in the real world the API’s that will be exposed to
> extra-enterprise users (other providers, consumers and the apps that either
> give authority to act on their behalf) are going to be striated by the type
> of user accessing them. I believe this is true because the applicable law
> differs based on whether the API is being used by a Covered Entity or a
> Patient or by Joe’s Credit Worthiness algorythm or what have you. I may
> have an API that I expose that allows a provider to use an API that
> provides all the clincal data I have for a patient based on a partial match
> search criteria. Because I know that theprovider is also covered by HIPAA
> and should have a policy about what they do when they see PHI for someone
> they shouldn’t I may feel that the risk is tenable (this is what RLS based
> HIE relies on in some ways). I can’t expose this same API to a
> patient\consumer because I have an obligation to prevent non-professionals
> from inadvertently (allegedly) seeing the data of others.
>
> I am not trying to be a nay-sayer – I just think it is important that we
> don’t gloss over these facts of life before we have documented them and –
> as John M. said earlier last week clearly delineated what is in scope and
> what is out.
>
> Before an API that exposes FHIR Resources (and possibly resource sets or
> scopes of same such as ‘Immunization’) to a consumer they need to have some
> reason to believe that the remote system accessing the API has a right to
> see the PHI of the subject of the PHI that is being disclosed.
>
> In the Direct world we rely on the face-to-face encounter of the consumer
> and the Provider to associate consumer’s Direct Address with the right
> medical records held by the Provider. For the API task force we made
> reference to the use of the patient portal and its authentication of the
> remote user (conditioned on there being an encounter between the Family
> Caregiver or Patient first) to allow access to the appropriate PHI for the
> person who authenticated into the portal. There is still some *magic*
> that we assume exist that allows the consumer’s chosen Client to receive a
> token from the EMR before we even start talking about the rest of the
> workflow and perhaps that is a gap we can address but I don’t know if
> anyone has gottent to the point of actually doing this yet – does anyone
> know? Does SMART or the Argonauts have a solution for this already or are
> we all relying on the same magic to occur?
>
> I think it is at this point – after the consumer has authenticated into
> the Patient Portal of the EMR – that you could realistically start to talk
> about binding a consumers chosen AS to the data held by a CE. Just like we
> have proposed for allowing a user to supply their Direct Address I assume
> that a widget on the portal could be provided that allowed the patient to
> navigate to the URL for their chosen AS – is that true? Let me assume that
> this is how the RS can find out what the consumer’s prefered AS is for the
> sake of getting my head around this. There may be equivalents that emerge
> in the future but I think this is probably the shortest path to getting
> things off the ground and running in the current eco-system. (If a user
> doesn’t provide a preferred AS the Provider would be expected to comply
> with applicable law and where law allows them to decide their local policy
> decisions).
>
> At least for me I have to picture a realistic path to getting to your
> bulleted list below before I can respond in line as follows…
>
> a) All resources *[AS1]* <#m_-4742296256565409933__msocom_1> available as
> FHIR resources MUST also be provided for registration with a HEART resource
> server even if the RS decides to bypass the AS or override the AS
> authorization.
> a1) The HIPAA CE can choose to notify the patient as to whether they
> bypass or override in the NPP but it makes only a slight difference*[AS2]*
> <#m_-4742296256565409933__msocom_2> .
> b) HIPAA has a data minimization requirement for some transactions that
> don't strictly require patient authorization so HEART MAY want to consider
> how data minimization would be handled using scopes in the cases where an
> RS is using a HEART AS for all sharing.
> b1) In theory, a HIPAA CE could register two paths to the patient's
> resources with two separate HEART ASs. One AS would bypass the
> patient-specified AS for Clients that were not subject to patient
> authorization. The other AS would be specified by the patient. Maybe this
> is the kind of thing Justin has in mind when he talks of an RS buying an AS
> from a separate vendor.*[AS3]* <#m_-4742296256565409933__msocom_3>
> c) Any resource server, HIPAA covered or not, MAY choose to register sets
> of resources in order to improve the user experience at the AS. These
> resources may or may not all be specified by FHIR. These bundling and
> definition of these resource sets may be done by HEART or by standards
> organizations like the HL7 DAF. (Debbie says that HEART must use only
> accepted standards so it seems to me that HEART getting into the resource
> bundling business is a bit of a slippery slope*[AS4]*
> <#m_-4742296256565409933__msocom_4>
> I may be wasting my breath but I am concerned that the real nay-sayers in
> the eco-system are well supported when they say what we are talking about
> is unintelligible to them.
> I could be completely off base and all of these assumptions are documented
> and I need to do more homework but I am feeling beat up trying to assert
> that there is some there there when doubters ask me about HEART.
> If I am alone I will remove myself from the list serve and you guys can
> continue in peace without me.
>
> Aaron Seib, CEO
> @CaptBlueButton
> (o) 301-540-2311
> (m) 301-326-6843
> [image: cid:image001.jpg at 01D10761.5BE2FE00] <http://nate-trust.org>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com <agropper at gmail.com>]
> *On Behalf Of *Adrian Gropper
> * Sent:* Wednesday, August 3, 2016 9:35 AM
> * To:* Aaron Seib, NATE
> * Cc:* Maxwell, Jeremy (OS/OCPO); openid-specs-heart at lists.openid.net
> * Subject:* Re: [Openid-specs-heart] Alice's health resource set
>
> Aaron,
> I think you are accurately describing HIPAA and that should allow us to
> re-center this thread on the core subject of Alice's resources.
> The key point for this thread is that HEART needs to enable
> patient-directed exchange for the full set of FHIR resources with other
> subsets as options. The reasons for this include the fact that some
> providers will choose to differentiate themselves by giving the patient a
> voice in sharing for Treatment, Payment, and Operations even though HIPAA
> does not force them to do so.
> The other important aspect of HIPAA that has not been discussed yet is
> that when a HIPAA Covered Entity (e.g. typical EHR) has an electronic means
> for sharing data available, it MUST offer that method to the patient as
> well. This means that if FHIR is used for sharing data under TPO,
> regardless of what the NPP say or don't say, Alice has a HIPAA right to
> request her data on FHIR.
>
> Here's my summary of the discussion AND HIPAA as far as HEART is concerned:
> a) All resources available as FHIR resources MUST also be provided for
> registration with a HEART resource server even if the RS decides to bypass
> the AS or override the AS authorization.
> a1) The HIPAA CE can choose to notify the patient as to whether they
> bypass or override in the NPP but it makes only a slight difference.
> b) HIPAA has a data minimization requirement for some transactions that
> don't strictly require patient authorization so HEART MAY want to consider
> how data minimization would be handled using scopes in the cases where an
> RS is using a HEART AS for all sharing.
> b1) In theory, a HIPAA CE could register two paths to the patient's
> resources with two separate HEART ASs. One AS would bypass the
> patient-specified AS for Clients that were not subject to patient
> authorization. The other AS would be specified by the patient. Maybe this
> is the kind of thing Justin has in mind when he talks of an RS buying an AS
> from a separate vendor.
> c) Any resource server, HIPAA covered or not, MAY choose to register sets
> of resources in order to improve the user experience at the AS. These
> resources may or may not all be specified by FHIR. These bundling and
> definition of these resource sets may be done by HEART or by standards
> organizations like the HL7 DAF. (Debbie says that HEART must use only
> accepted standards so it seems to me that HEART getting into the resource
> bundling business is a bit of a slippery slope.)
> A MUST and two MAYs. Can we move on to discussing scopes in this context
> now?
>
> Adrian
>
>
> On Wed, Aug 3, 2016 at 7:48 AM, Aaron Seib, NATE <
> *aaron.seib at nate-trust.org* <aaron.seib at nate-trust.org>> wrote:
> Regardless of how it makes me feel – my question earlier is how do we
> actually address it.
>
> I think the NPP is one way for providers to convey that they will or won’t
> acknowledge what your Privacy Preferences are – indicated via a AS.
>
> Does anyone disagree with that?
>
> There are providers that will argue that they have an ethical
> responsibility to share with other doctors that may treat you.
>
> My question comes down to – is a provider obligated to share for Treatment
> purposes or is it just that they are permitted to despite a patient like
> Adrian’s preferences.
>
> Anyone have an authoritative answer?
>
>
> Aaron Seib, CEO
> @CaptBlueButton
> (o) *301-540-2311* <301-540-2311>
> (m) *301-326-6843* <301-326-6843>
> [image: cid:image001.jpg at 01D10761.5BE2FE00] <http://nate-trust.org/>
>
> *From:* Openid-specs-heart [mailto:
> *openid-specs-heart-bounces at lists.openid.net*
> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Adrian
> Gropper
> * Sent:* Tuesday, August 2, 2016 5:27 PM
> * To:* Maxwell, Jeremy (OS/OCPO)
> * Cc:* *openid-specs-heart at lists.openid.net*
> <openid-specs-heart at lists.openid.net>
>
> * Subject:* Re: [Openid-specs-heart] Alice's health resource set
>
> If an organization wants to be nice to their patients and also reduce the
> scope of data breaches they would notify patients when their data was
> shared the way my bank and Apple do when they use my data in a third-party
> context. We can hope that FHIR and HEART become so much standard practice
> that every respectful organization adopts the Society for Participatory
> Medicine motto: "Nothing about me without me."
> The "consent for TPO" you seem to be describing however is just another
> contract of adhesion that gives no meaningful choice to the patient at all.
> I, for one, am insulted when presented by such a thing and I've never met
> any patient that appreciates it.
> Adrian
>
>
> On Tue, Aug 2, 2016 at 5:12 PM, Maxwell, Jeremy (OS/OCPO) <
> *Jeremy.Maxwell at hhs.gov* <Jeremy.Maxwell at hhs.gov>> wrote:
> Not sure I follow. HIPAA does not require consent for TPO—it is a
> permitted use. An organization may still choose to collect consent for
> TPO, either because of their own organizational policy or because another
> law requires it. But this is not “HIPAA TPO consent.” In ONC parlance, we
> call this “basic choice for TPO” in both our Interoperability Roadmap as
> well as our Patient Choice Technical Project. Of course others may call
> this by a different term, but calling it a “HIPAA TPO consent” is imprecise
> and can perpetuate existing misunderstandings about what HIPAA actually
> requires.
>
>
>
> *From:* *agropper at gmail.com* <agropper at gmail.com> [mailto:
> *agropper at gmail.com* <agropper at gmail.com>] *On Behalf Of *Adrian Gropper
> * Sent:* Tuesday, August 02, 2016 5:01 PM
> * To:* Maxwell, Jeremy (OS/OCPO)
> * Cc:* Debbie Bucci; *openid-specs-heart at lists.openid.net*
> <openid-specs-heart at lists.openid.net>
> * Subject:* Re: [Openid-specs-heart] Alice's health resource set
>
> Jeremy,
>
> Sorry, I should have said HIPAA TPO "consent".
> If access to the FHIR resources does not require Alice's authorization and
> the RS wants to keep Alice in the dark because HIPAA's accounting of
> disclosures is seldom implemented as well, then HEART is not involved. I
> would not call the TPO loophole consent except sarcastically.
> Adrian
>
> On Tue, Aug 2, 2016 at 2:22 PM, Maxwell, Jeremy (OS/OCPO) <
> *Jeremy.Maxwell at hhs.gov* <Jeremy.Maxwell at hhs.gov>> wrote:
>
> Also, want to clarify what “typical of HIPAA TPO consent” means? TPO is a
> permitted use under HIPAA that does not require consent.
>
>
>
>
>
>
>
> *From:* Openid-specs-heart [mailto:
> *openid-specs-heart-bounces at lists.openid.net*
> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Debbie Bucci
> * Sent:* Tuesday, August 02, 2016 2:17 PM
> * To:* Adrian Gropper
> * Cc:* *openid-specs-heart at lists.openid.net*
> <openid-specs-heart at lists.openid.net>
> * Subject:* Re: [Openid-specs-heart] Alice's health resource set
>
>
>
> Lost me again Adrian -
>
>
> We should also not ignore the Client-to-AS first flow. This is the
> preferred flow from a privacy engineering perspective. (see other thread
> with Justin). In the majority of cases of HIE, the Client has a
> relationship with Alice already (this is typical of HIPAA TPO consent) or
> the Client has found Alice via a "Relationship Locator Service" which is a
> directory operated by the state or some private entity like CommonWell.
> When the Client matches with Alice in the RLS, does the RLS return a list
> of RSs or a pointer to Alice's AS?
>
>
>
> The most privacy-preserving thing would be for RLSs to return pointers to
> Alice's AS and in the future this is what Alice might insist on if she is
> still given a choice to opt-in or opt-out of HIE. Alice does have that
> choice today in the US. In other countries, not-so-much.
>
>
>
> Are you suggesting the AS is some sort of proxy for all data - I don't
> think you were saying that. At some point the Client would need a
> relationship with the RS as well - correct? Is the Client to AS flow a
> separate spec? Would you please provide the link? Looking at UMA 1.01 -
> client needs a permission ticket first - that is generated from AS - to RS
> to client (?)
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: *http://patientprivacyrights.org/donate-2/*
> <http://patientprivacyrights.org/donate-2/>
>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: *http://patientprivacyrights.org/donate-2/*
> <http://patientprivacyrights.org/donate-2/>
>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: *http://patientprivacyrights.org/donate-2/*
> <http://patientprivacyrights.org/donate-2/>
>
> ------------------------------
>
> *[AS1]* <#m_-4742296256565409933__msoanchor_1>This is inaccurate. There
> may well be FHIR resources that describe the availability of a hospital
> asset (lets’ say an Operating Room) one day. An API that can access a
> resource that knows when an OR is in use is very useful to the Enterprise
> users but there is no reason that this should be shared with a Consumer.
>
> I think you have to qualify what you are saying here to be All resources
> that are specific to the consumer’s care – I think HIPAA has a term for it
> – something like the Common Data Set.
>
> Being inaccurate here will just degrade the audiences ability to know what
> we are really saying here.
>
> The RS would be able to decide if they need to check the AS based on
> whether or not the resource set had data that was part of the Common Data
> Set (if they were committed to supporting the patient’s preferences).
> *[AS2]* <#m_-4742296256565409933__msoanchor_2>These kind of qualitative
> subjective opinions will only frustrate the audience. It may be slight to
> you but it may be mission critical so some Foster Parents who need to
> explain to the state why their ward’s private health information was still
> shared even though the Judge ordered them to take steps necessary to ensure
> that it wasn’t.
> *[AS3]* <#m_-4742296256565409933__msoanchor_3>I think this is a horrible
> idea. I think there are better ways to handle policy enforcement when the
> Client isn’t subject to the AS.
>
> Ken Salyard’s work comes to mind. I think trying to do it this way is
> possible but it seems like we are treating every Policy Enforcement need
> like it is a nail. Sometimes a Philips Head is what you should really be
> using.
> *[AS4]* <#m_-4742296256565409933__msoanchor_4>I don’t know if this is
> right or wrong but I do know that I am going insane talking about this in
> the abstract and even if it is just for discussion purposes – in my opinion
> - we are on the right track trying to find a reference case like
> Immunization or the Patient Registration example. The simpler the better
> in my opinion._______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160804/823b40d3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160804/823b40d3/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160804/823b40d3/attachment-0003.jpe>
More information about the Openid-specs-heart
mailing list