[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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] 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]