Re: [xspa] Policy scope

[steven meyer <smeyer@hipaat.com>]

This discussion is at the heart of consent management, and I am glad to
see this being raised.

The experience of my colleagues and myself  is that a consent policy is
ideally a document made up of the following;

1. A human-readable  legal script; something like a pdf, scanned
document or pages that can be rendered somehow.  This defines the
contract that the patient sees and agrees to.
2. A machine-actionable policy that accurately and demonstrably reflects
the intentions of the legal script. This is where the XACML will apply,
and there is a definite need for further development here.
3. Meta-data to support the signing, control and management of the
document as a clinical document.  Since it refers to clinical
information it must be disseminated, updated, handled and protected like
any other clinical document.

The organization that accepts the policy from the patient is then
responsible for its security and its enforcement. There is a chain of
responsibility radiating outward from that organization. This suggests
there will be a centralizing of consent management within these
organizations to ensure that consent policies are uniformly applied. 
Sharing of consent documents between organizations requires more than
just technical capabilities and could lead to a clustering model where
many organizations can share a consent registry/repository (or a
clinical registry/repository that includes consents).

Steven

Anthony Mallia wrote:
>
> John,
>
>  
>
> In these discussions there appears to be a more basic underlying theme
> which we have not directly addressed but comes up when we discuss
> specific solutions (e.g. NHIN). Policy scope could be thought as
> policy domain which is the environment for policy formulation,
> acceptance and possibly its enforcement.
>
>  
>
> A number of policy domains already exist – federal and state
> jurisdiction, enterprise or covered entity. An organization may be
> required to operate within multiple policy domains and a couple of
> approaches can be taken – consolidation or isolation. If a healthcare
> provider is operating in multiple states it is faced with these
> choices. Sometimes isolation is not possible.
>
>  
>
> I believe that both approaches are valid and that the solutions should
> facilitate them both.
>
>  
>
> When we consider the patient consent directive (a type of policy), US
> law specifies that it is the covered entity which may accept that
> policy and if so must enforce it. There is at the moment no higher
> level policy domain which can accept and enforce that policy.
>  However, by mutual agreement between covered entities, the patient
> might be able to make the formulation and have it accepted by multiple
> covered entities thereby simplifying the complexity for the patient.
> This appears to be a main driver in these discussions due to the
> autonomy of the covered entity.
>
>  
>
> Hopefully this starts to address your last sentence which reflects the
> need to identify who has accepted the policy since another party is
> under no legal obligation to enforce it. Maybe we need a language for
> describing what a colleague has described as “Policy Engineering”.
> This would cover the concepts in law such as restriction,
> authorization (HIPAA Privacy) and the lifecycle of formulation,
> acceptance and enforcement. XACML could refer to this language either
> directly in naming or indirectly through comments.
>
>  
>
> Tony
>
>  
>
> *From:* Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com]
> *Sent:* Wednesday, July 15, 2009 5:46 PM
> *To:* Anthony Mallia; Davis, John M.; xspa@lists.oasis-open.org
> *Subject:* RE: [xspa] Policy scope
>
>  
>
> Tony,
>
>  
>
> I agree with what you say. And it is your last paragraph that is the
> focus of my question.
>
>  
>
> So, to the general XACML audience I am interested in how this might be
> enabled by general XACML standard. If it is not, then I suggest that
> XSPA will need to address it as it is related to cross community
> security and privacy authorization. Healthcare does have a specific
> need, yes. I just don’t think this is unique to healthcare, nor NHIN
> as the USA example.
>
>  
>
> If I understand correctly the NHIN consumer preferences presumes it
> can put in a subscription that would result in a notification being
> sent to the ACS when an updated consent is agreed to. If this is the
> model, I can accept that. I just wondered if there was a way to look
> into a privacy policy encoded in XACML to determine which
> organizations it is scoped for.
>
>  
>
> John
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Anthony Mallia [mailto:amallia@edmondsci.com]
> *Sent:* Wednesday, July 15, 2009 9:15 AM
> *To:* Moehrke, John (GE Healthcare); Davis, John M.;
> xspa@lists.oasis-open.org
> *Subject:* RE: [xspa] Policy scope
>
>  
>
> John,
>
>  
>
> A small point has been missed in the discussion. The NHIN DURSA
> autonomy principle allows that the requesting community and the
> responding community may have totally separate policies. They do not
> even need to know each other’s policies.
>
>  
>
> The requesting community has an ACS which it uses to authorize the
> request based on its own policies (institutional and consumer
> preferences) and the responder has its ACS where it authorizes the
> response based on its own policies. In order for the complete
> transaction to be successful, both must authorize.
>
>  
>
> Between the two communities, the NHIN Authorization Framework carries
> the assertions which were used by the requesting community to
> authorize the request and this is equivalent to the XSPA SAML profile
> where the firsts community is making a request to the second
> community. The conformance point is clearly in scope for the NHIN.
>
>  
>
> The PEP/PDP exchange is within each ACS and is not exposed to the NHIN
> and therefore is out of scope for NHIN but not for OASIS. The XSPA
> XACML Profile conformance point (which I believe is between the PEP
> and the PDP) is important because it gets many of its attributes (but
> not all) from the XSPA SAML Profile.
>
>  
>
> From the view of harmonizing NHIN and XSPA we only need to align the
> XSPA SAML Profile and the Authorization Framework.
>
>  
>
> The second discussion which is the exchange of consumer preferences or
> consent directives is a broader and more complex topic. However it
> must be harmonized with the XSPA XACML profile which provides
> attributes for the PDP decision.
>
>  
>
> *Tony Mallia*
>
> Practice Director
>
> Edmond Scientific Company//
>
> 4100 Monument Corner Drive,  Suite 540                      Tel:     
> (703) 766-3871, Ext. 400
>
> Fairfax, Virginia 22030-8610                                          
> Fax:     (703) 766-3872
>
> Email: amallia@edmondsci.com
> <mailto:amallia@edmondsci.com>                                     
> Cell:    (978) 729-4479
>
>  
>
> *From:* Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com]
> *Sent:* Wednesday, July 15, 2009 7:04 AM
> *To:* Davis, John M.; xspa@lists.oasis-open.org
> *Subject:* RE: [xspa] Policy scope
>
>  
>
> Mike, I am glad you expressed how this is handled in the NHIN DURSA
> world. This is also a good example of how the NHIN DURSA got around
> the issue. This solution is based on the tools they had available at
> the time. What I am trying to get discussed is if there is a more
> flexible way to support this in the XSPA standards future.
>
>  
>
> The problem I see with the NHIN DURSA solution is that it simply makes
> the problem the responsibility of ACS requestor. This does not
> eliminate the problem, it simply moves the problem out of DURSA space
> and into the hie/hospital/clinic space where, in general, there is
> little expertise to solve the problem. I am well aware that you
> personally are happy with this solution as you do have solutions and
> architects in the VA space. I think we must think of the whole
> architecture. This is not to say that we must define an internal
> architecture for the ‘participants’, but the underlying XACML schema
> seems should support appropriate metadata coding to support the need.
>
>  
>
> As you very clearly indicated a policy is not enforced until both
> parties agree to enforce it. So, how is this ‘scope’ of the policy
> encoded? This is my question.
>
>  
>
> So to be clear. The reason I am asking this question on XSPA is
> because I see this as an unsolved problem that our ‘standards’
> development should consider. I am well aware of ways that it is
> handled in the old days, as I also indicated one of these old days as
> well.
>
>  
>
> John
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Davis, John M. [mailto:Mike.Davis@va.gov]
> *Sent:* Tuesday, July 14, 2009 1:40 PM
> *To:* Moehrke, John (GE Healthcare); xspa@lists.oasis-open.org
> *Subject:* RE: [xspa] Policy scope
>
>  
>
> John,
>
>  
>
> The NHIN DURSA follows the principal of “autonomy”, meaning that each
> participant follows it’s own policies in making access control
> decisions.  The NHIN does not gather policies, the participants do,
> but only from their own policy stores.  When a request is made, it is
> decided upon based upon the participants policy and the consent
> directives on hand. 
>
>  
>
> In the case of the VA, for example, we would not release information
> unless there was a consent directive to do so (Opt-In is a minimal
> consent directive).  That means that anyone requesting information
> must provide the consent directive at the time of the request.  There
> are many ways to do this, for example, by reference to an XDS directory.
>
>  
>
> Date reuse requires that the patient establish appropriate consent
> directives at each participant site.  The patient consent directive at
> the responding participant needs to reflect their preferences
> established with the requesting participant.
>
>  
>
> Again, the autonomy principal requires that each participant have all
> policies on hand for their decision, since they are the authoritative
> source for all policies, including patient ones that they are
> enforcing.  A participant is NOT responsible for enforcing policies
> not in its policy repository.  BTW, Consent directives themselves are
> not automatically enforced and do not become participant policies
> until the agency agrees to enforce them.  This enforcement agreement
> is a binding contract between the participant and the patient.  That
> requires an administrative action (since it involves liability on the
> provider) as part of the process.  Finally, participants will not push
> a consent directive as an obligation. 
>
>  
>
> So what is important are the attributes asserted at the time of the
> request.  These are used to inform the participant policies (whatever
> they are).  Since different participants are under jurisdiction of
> different laws, there can be no guarantee of a “common” set of
> enterprise policies, but I believe that might be possible with consent
> directives which will probably be related to specific law at some
> point.  On the other hand, Federal law (e.g., FISMA) that applies only
> to federal agencies may require different policies than California
> does.  Since we are not passing policies back and forth, this should
> be transparent.  In other words, the requester only needs to know what
> authorization attributes need to be asserted, not what policy set is
> being enforced.  Also, there is no burden on a participant to tell
> another “Why” a decision was revoked, only to respond, e.g. “Data not
> available”.
>
>  
>
> Here are the core policy assumptions:
>
>  
>
> §  *Multi-Party Agreement*. Single agreement to which all Participants
> agree that establishes trust framework and rules of engagement.
>
> §  *Participants in Production.* Assumes the agreement is for those in
> production and complements end user trust agreements.
>
> §  *Privacy and Security Obligations. *Defers to Applicable Law and
> establishes HIPAA as contractual standard of performance for other
> non-HIPAA or non-governmental entities. 
>
> §  *Requests for Data Based on Permitted Purposes. *Permits exchange
> of information among NHIN for certain purposes for the pilots,
> including treatment, payment, health care operations, public health
> activities, quality reporting for “meaningful use” and disclosures
> based on an authorization from the individual (e.g. SSA disability
> determination).
>
> §  *Duty to Respond**.*  All Participants have a duty to respond to
> requests for data for treatment purposes, and may respond to other
> types of requests. 
>
> §  *Future Use of Data Received Through the NHIN*.  Data are received
> and integrated into end-user’s system and may be reused or disclosed
> as any other information in its records, in accordance with Applicable
> Law and local policy. 
>
> §  *Duties of Requesting and Responding Participants*.  Each
> Participant has certain duties when acting as a requesting or
> responding Participant, including conformance with NHIN requirements.
>
> §  *Autonomy principle for access* - When responding to a request for
> data, Participants will apply their local policies to determine
> whether and how to respond to the request.
>
> §  *Responding Participant’s Legal requirements. *A Responding
> Participant must make sure that it has met any legal requirements
> before disclosing the data including, but not limited to, obtaining
> consent or authorization for treatment purposes.
>
> §  *Authorizations. *When a request is based on an authorization (e.g.
> for SSA benefits determination), the requesting Participant must send
> a copy of the authorization with the request for data.
>
> §  *Participant Breach Notification*.  Participants are required to
> promptly notify the NHIN Coordinating Committee and other impacted
> Participants of breaches which involve the unauthorized disclosure of
> data through the NHIN.
>
> §  *Mandatory Non-Binding Dispute Resolution*.  Participants will
> agree to participate in a mandatory, non-binding dispute resolution
> process that preserves the Participants’ rights to seek redress in the
> courts if not resolved through the dispute resolution process. 
>
> §  *Allocation of Liability Risk*.  With respect to liability, the
> DURSA memorializes the Participant’s understanding that each
> Participant is responsible for its own acts or omissions.
>
>  
>
>  
>
> /Regards, Mike Davis, CISSP/
>
> /Department of Veterans Affairs/
>
> CHIO Emerging Health Technologies
>
> Security Architect
>
> 760-632-0294
>
>  
>
> *From:* Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com]
> *Sent:* Tuesday, July 14, 2009 10:08 AM
> *To:* xspa@lists.oasis-open.org
> *Subject:* [xspa] Policy scope
>
>  
>
> A question came up today in discussion on Access Control white paper
> in IHE. How is it known when all applicable policies have been
> gathered? Specifically in an environment like the USA NHIN, how does
> the NHIN know when they have done sufficient gathering of policies in
> order to make the specific-access-control-decision?
>
>  
>
> I have heard discussions where the access control decision logic
> simply is happy making a positive response based on the knowledge it
> has, but how does it not know that there is a ‘new’ policy declaration
> available that indicates that the patient has revoked authorization?
>
>  
>
> The same can be said for a decision of NO could have been rather a YES
> because of a new authorization.
>
>  
>
> But the most concerning is how does the system understand that there
> is a policy available to be gathered/retrieved that is simply not
> applicable.
>
>  
>
> In the ‘old days’ under BPPC, this is handled simply because each
> policy identifier is either understood by the access-control-service
> (meaning the policy logic was configured into the ACS) or it is NOT.
> Therefore a query for all policies that have been acknowledged results
> in a list of unique identifiers to enable, therefore the decision is
> made based on the cross-section of those that are acknowledged vs
> those that are understood.  This results in a self limited set of
> policies.
>
>  
>
> In the XACML world, it is possible for the ACS to pull down the
> computable policy and make it known to my ACS… so how do I determine
> which I SHOULD incorporate vs which ones should I continue to ignore?
>
>  
>
> I presume that much of this is simply encoded into the policy as the
> scope of the policy. For example which organizations does this policy
> affect. If a policy indicates that it is scoped to a set of
> organizations that are not involved in a transaction, then that policy
> is not applicable. Is this already built into XACML core?
>
>  
>
>  
>
>  
>
> *John Moehrke*
> Principal Engineer: Interoperability and Security
> GE Healthcare
>
>  
>
> M +1 920 912 8451
>
> John.Moehrke@med.ge.com <mailto:John.Moehrke@med.ge.com>
> www.gehealthcare.com <http://www.gehealthcare.com>
>
>  
>
> 9900 Innovation Drive
>
> Mailstop 2142 
>
> Wauwatosa, WI  53226
>
>  
>
> GE imagination at work
>
>  
>


-- 
Steven Meyer Ph.D. P.Eng.
Head, Engineering & Technology  | HIPAAT Inc.
Consent Management Specialists
p. +1.905.405.6299
m. +1.647.299.1020 
f. +1.519.925.0951 
mailto:smeyer@hipaat.com
http://www.hipaat.com