[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 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 4100
Monument Corner Drive, Suite 540
Tel: (703) 766-3871, Ext. 400 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 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 Mailstop 2142 GE imagination at work |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]