[Openid-specs-heart] Patient Consent

[John Moehrke]

that is the whole set of securityLabels, inclusive of the _confidentiality
codes... I am recommending we start small and deterministic with just the
_confidentiality value-set.
 http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Tue, Jul 12, 2016 at 3:46 PM, Debbie Bucci <debbucci at gmail.com> wrote:

>
> To the standards purist .. my apologies in advance - not very good at
> abstract thinking.  I need to *see* an implementation to *get* how things
> work.    I get the content of the profiles will be a few levels removed and
> the need to not tightly constrain anything.  Ok that said ...
>
> Kenneth - thanks so much for sending to the list.    After yesterday's
> conversation, I do agree with John's suggestion that   the consent process
> is separate from the token transaction (RPT right?).  It may happen at the
> same time but very separate functions.   Was beginning to wonder how
> something like C2S or other PDP/PEP implementations would integrate  -
> coexist  with and UMA AS.
>
> Wanted to revisit Adrian's discussion around release of information.   For
> an initial visit -that some how seems important.
>
>
> Is this the correct reference for FHIR  confidentiality codes?
> https://www.hl7.org/fhir/v3/Confidentiality/index.html  ?
>
>
>
>
>
> On Tue, Jul 12, 2016 at 4:00 PM, Salyards, Kenneth (SAMHSA/OPPI) <
> Kenneth.Salyards at samhsa.hhs.gov> wrote:
>
>> Hi John, sorry if I quoted you wrongly. The bottom line is if you are
>> tagging something or redacting something you still have to have something
>> that can facilitate that process; i.e., a segmentation engine or a tagging
>> engine. Without this capability, tagging or segmenting cannot work. Ken
>>
>>
>>
>> *From:* John Moehrke [mailto:johnmoehrke at gmail.com]
>> *Sent:* Tuesday, July 12, 2016 3:55 PM
>> *To:* Salyards, Kenneth (SAMHSA/OPPI)
>> *Cc:* Debbie Bucci; openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] Patient Consent
>>
>>
>>
>> Ken,
>>
>>
>>
>> I didn't say that... I said that the FHIR 'resources'  structure is not
>> appropriate as a segmentation boundary. That is, in normal REST models one
>> puts sensitive data into different kind of Resources. Where in FHIR
>> resources contain a wide mixture of sensitive data.
>>
>>
>>
>> The mechanism that is built into FHIR to enable privacy/security
>> segmentation is the securityLabel. One can absolutely use this meta tag
>> system to segment data. This is indeed what I am recommending through the
>> suggestion that we use the _confidentiality valueset.
>>
>>
>>
>> John
>>
>>
>> John Moehrke
>> Principal Engineering Architect: Standards - Interoperability, Privacy,
>> and Security
>> CyberPrivacy – Enabling authorized communications while respecting Privacy
>> M +1 920-564-2067
>> JohnMoehrke at gmail.com
>> https://www.linkedin.com/in/johnmoehrke
>> https://healthcaresecprivacy.blogspot.com
>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>>
>>
>>
>> On Tue, Jul 12, 2016 at 2:12 PM, Salyards, Kenneth (SAMHSA/OPPI) <
>> Kenneth.Salyards at samhsa.hhs.gov> wrote:
>>
>> Hello Debbie, here is a high-level view of the Consent 2 Share (C2S)
>> architecture. For the RS to be able to do what you are proposing, it would
>> need to have a segmentation engine to enforce fined grain consent
>> directives. Enforcing these consent directives is based on (for C2S at
>> least) value sets based on diagnosis, medications, tests/labs and
>> procedures associated with the sensitive conditions. We have defined these
>> types of value sets which are used in C2S for data segmentation. I can send
>> them to you if you would like to see the content. Also, segmentation can
>> only be accomplished currently on structured clinical content. We are
>> exploring ways in which to use the value set content to redact textual
>> information related to sensitive conditions, however currently we redact
>> all text in a segmented document.
>>
>>
>>
>> With the current state-of-art in EHR technology, the content of exchanged
>> records is highly variable from simple text documents (all CDA really
>> requires) to documents with text and actual clinical entries. In the future
>> FHIR may improve this pitiful condition.
>>
>>
>>
>> As John has said before, there is no inherent capability within FHIR that
>> can define a resource set that provides data segmentation at any level.
>>
>>
>>
>> Hope this helps, Ken.
>>
>>
>>
>> *From:* Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Debbie Bucci
>> *Sent:* Monday, July 11, 2016 3:31 PM
>> *To:* John Moehrke
>> *Cc:* openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] Patient Consent
>>
>>
>>
>> So ... the RS  *should* have an idea of what medications aligns with
>> each diagnosis.   Wouldn't a patient request to not reveal /release HIV for
>> some purpose of use info be enough info to provide to the RS to use (but
>> note the RS may not comply due to various reasons  - but should record for
>> audit purposes)
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160712/55e7ddd1/attachment.html>