[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xspa] Policy scope
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] 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] 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
Cell: (978) 729-4479 From: Moehrke, John (GE
Healthcare) [mailto:John.Moehrke@med.ge.com] 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] 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] 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 M
+1 920 912 8451 John.Moehrke@med.ge.com 9900 Innovation Drive
Mailstop 2142 Wauwatosa, WI
53226 GE imagination at work |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]