Policy Profile

1. Proposed Profile: Policy Profile

• Proposal Editor: Maryann Hondo
• Profile Editor: TBD
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: ITI

2. The Problem

The Policy profile introduces a set of xml policy expressions to capture the constraints and capabilities of the various IHE profiles either individually or in composition ( i.e, XUA or XUA with XDS.b). For example, the XUA profile currently defines a cross user assertion protocol but there is no way to express the constraints and capabilities of the features of that protocol exchange to enable interoperability between two entities that might have variations of the same constraints and capabilities and wish to find compatible alternatives. As IHE moves to adopt web services and SOA practices, it will be important to embrace and extend other policy expressions currently being defined by standards organizations for basic service operation (i.e. Kerberos and SAML token profiles through WS-SecurityPolicy in OASIS, or WS-Policy in the W3C) so that IHE does not invent its own infrastructure requirements where these already exist. One way is to adopt WS-Policy expressions as a way to communicate between web service requestors and providers and to augment the set of defined domains ( i.e, WS-SecurityPolicy) with a set of assertions for the healthcare domain where these do not exist ( i.e, PIX-PDQ policy). The first example of this could be demonstrated by taking the XUA profile and evaluating the WS-SecurityPolicy sample document (for the symmetric binding, the SAML token profile, and the Kerberos token profile) and create sample policy expressions including these assertions for any IHE web services profiles.

3. Key Use Case

1. Assume within a given domain, such as the State of California, we have several healthcare communities (or affinity domains or RHIOs). One in Los Angeles, one in Sacramento and one in San Francisco. A patient X, who travels frequently, has received healthcare in each of these communities. Patient X is admitted to a hospital in LA. The attending physician uses his hospital information system to query across multiple domains for healthcare information about this patient. Patient X then goes for followup to the hospital in Sacremento.
2. Each system needs to identify the patient and authenticate the physician accessing the record and create an audit trail of the actions.
3. The identity of each physician should be recorded regardless of the infrastructure that provided the web service. This implies that the policy of authentication should be compatible in the State of California, regardless of whether LA uses one type of token, and Sacramento uses another type of token. As long as they both conform to the same policy for authentication and audit, and as long as an identifier meets the requirements of the affinity the systems should be able to accept the appropriate credentials and provide the required identifier for common audit purposes.
4. As patients are also enabled to access their health information ( PHRs, EHRs) any action they take should be recorded and this means a variety of methods for identifying and authenticating principals needs to be supported. A policy can enable client requestors and providers of services to know what kinds of information is required to be able to access a service. Policy enabled components can even dynamically discover and use a mutally trusted broker to negotiate a way to communicate which can enable RHIOs, who may be the trusted broker, to provide authorized access to healthcare information based on established federated relationships through trusted exchanges.

4. Standards & Systems

• WS-I Basic Profile SAML policy profile
• WS-I Basic Security Profile 1.0
• WS-Policy
• WS-SecurityPolicy
• WS-Trust
• WS-Federation

5. Discussion

For reference the proposed transactions diagram from the WS-Federation White Paper is illustrated here. This is not to suggest that this will be the final diagrams, but only a reference to work already done elsewhere. For more details please refer to the WS-Federation White Paper submitted to the working group at: Understanding WS-Federation.pdf