[Openid-specs-heart] Alice's health resource set
Adrian Gropper
agropper at healthurl.com
Fri Aug 5 10:52:01 UTC 2016
Hi Robert,
We've known each other in the imaging PACS standards business for maybe 20
years and I completely disagree with you from two perspectives: performance
and security. Doctors deserve the same image speed and quality no matter
where they are. The imaging network doesn't stop at some firewall of the
imaging center. Second, the security has to accommodate tablets and other
personal devices that are owned by the physician and the patient. Perimeter
defenses around some hospital silo are less important day-by-day. Eve calls
it the "hard shell, soft center" defense approach.
At one of the venerable PACS businesses I worked relatively recently the
project was to secure and stream high performance imaging under the
protection of standard OAuth. There's no particular reason, HIPAA or
global, why streaming an imaging study in the order the physician wants to
review it is any different from streaming the genome or the health record
in the OAuth Client's chosen order. Visualize telemedicine.
Adrian
On Thursday, August 4, 2016, Robert Horn <robert.horn at agfa.com> wrote:
> If I understand correctly the answer is "it depends".
>
> Almost all tertiary providers are well prepared to handle DVDs as part of
> admission. This is sometimes the case with primary and secondary
> providers. All it takes is some software, a DVD reader, and simple
> procedures. There is an IHE profile that gets routinely tested at
> connectathon for integrating this process into the internal PACS facility
> at the provider. This is the default baseline process, since it can handle
> admissions from anywhere in the world, regardless of network connectivity
> or capacity issues.
>
> There are also many directly negotiated inter-ties that go from PACS to
> PACS between providers. The primary barrier that I've seen to these
> inter-ties is the substantial administrative costs of setup. The
> operational PACS is a highly sensitive bit of equipment from much more than
> the privacy point of view. Interference with the PACS can bring radiology,
> cardiology, radiation therapy, and pathology to a grinding halt. So the
> administrative staff is very cautious about connections to the outside.
> They will happily use privacy, security, and any other buzzword as part of
> their justification for extreme caution about outside connections.
>
> These sorts of connections certainly exist. In large networks like Kaiser
> or the UK NHS there is a hierarchy of PACS archives, etc. There are many
> such connections between affiliated organizations. These are typically
> designed to withstand network outages, provide redundancy, etc. The NHS
> has all the database recovery issues to deal with split system operation
> restoration for patients that have been treated on both sides of a split
> system, with the resultant mutual contradictory information that needs to
> be reconciled and combined properly. They do not expect to maintain
> continuous network connectivity between all NHS sites at all times. They
> expect significant connectivity failures and build in the ability to ride
> through them.
>
> Privacy, consent, and security are all part of the administrative concerns
> that do need to be addressed as part of such an inter-tie. It's one reason
> things like OpenID are interesting. When connections exist there needs to
> be a way to bridge between the internal privacy and security models of the
> different organizations. The DVD model is much simpler. The patient
> either provides the DVD or they don't. (Realistically, they always provide
> the DVDs. It makes no sense to go for treatment and then refuse to provide
> the imaging results. Those who don't want to reveal the imaging data also
> refuse to go for treatment at that organization.)
>
> Extending this kind of connection to the general public terrifies people.
> The discussions are all around portals of various sorts, not direct
> access. The portals will be given highly limited access to the internal
> operational PACS system, so that when the portal is penetrated by a hostile
> actor, the hostile actor will not be able to penetrate further. Please
> note, it is "when" the portal is penetrated, not "if". The extent to which
> the portal presents the appearance of FHIR, DVD, DICOM, or whatever is a
> matter of discussion. But the public interaction would be with the portal,
> not the internal system.
>
> 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: Debbie Bucci <debbucci at gmail.com
> <javascript:_e(%7B%7D,'cvml','debbucci at gmail.com');>>
> To: Robert Horn/MOPOO/AGFA at AGFA
> Cc: openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart at lists.openid.net');>,
> Aaron Seib <aaron.seib at nate-trust.org
> <javascript:_e(%7B%7D,'cvml','aaron.seib at nate-trust.org');>>
> Date: 08/04/2016 05:37 PM
> Subject: Re: [Openid-specs-heart] Alice's health resource set
> ------------------------------
>
>
>
> 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*
> <javascript:_e(%7B%7D,'cvml','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* <%2B1%20978%20897%204860>
>
> Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405,
> USA
> *http://www.agfahealthcare.com* <http://www.agfahealthcare.com/>
> *http://blog.agfahealthcare.com* <http://blog.agfahealthcare.com/>
> ------------------------------
> Click on link to read important disclaimer:
> *http://www.agfahealthcare.com/maildisclaimer*
> <http://www.agfahealthcare.com/maildisclaimer>
>
>
>
> From: "Aaron Seib, NATE" <*aaron.seib at nate-trust.org*
> <javascript:_e(%7B%7D,'cvml','aaron.seib at nate-trust.org');>>
> To: "'Adrian Gropper'" <*agropper at healthurl.com*
> <javascript:_e(%7B%7D,'cvml','agropper at healthurl.com');>>
> Cc: *openid-specs-heart at lists.openid.net*
> <javascript:_e(%7B%7D,'cvml','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 at lists.openid.net*
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart-bounces at 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_3516374923822591767_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_3516374923822591767_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_3516374923822591767_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_3516374923822591767_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* <301-540-2311>
> (m) *301-326-6843* <301-326-6843>
> [image: cid:image001.jpg at 01D10761.5BE2FE00] <http://nate-trust.org/>
>
> * From:* *agropper at gmail.com*
> <javascript:_e(%7B%7D,'cvml','agropper at gmail.com');> [
> *mailto:agropper at gmail.com*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','agropper at gmail.com');> [mailto:
> *agropper at gmail.com* <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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*
> <javascript:_e(%7B%7D,'cvml','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_3516374923822591767_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_3516374923822591767_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_3516374923822591767_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_3516374923822591767_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*
> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart at lists.openid.net');>
> *http://lists.openid.net/mailman/listinfo/openid-specs-heart*
> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> *Openid-specs-heart at lists.openid.net*
> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart at lists.openid.net');>
> *http://lists.openid.net/mailman/listinfo/openid-specs-heart*
> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>
>
--
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160805/f374d6fe/attachment.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/20160805/f374d6fe/attachment.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/20160805/f374d6fe/attachment-0001.jpe>
More information about the Openid-specs-heart
mailing list