OASIS Open

OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee

Enterprises, including the healthcare enterprise, need a mechanism to exchange privacy policies, consent directives and authorizations in an interoperable manner. At this time, there is no standard that provides a cross-enterprise security and privacy profile. The OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC will address this gap.

The need for an XSPA profile has been identified by the security and privacy working group of the Healthcare Information Technology Standards Panel (HITSP). HITSP is an ANSI-sponsored body charged with identifying standard building blocks that can be leveraged to implement common healthcare use cases. The XSPA profile will require the participation of subject matter experts in several areas, including WS-Federation, SAML, WS-Trust, and possibly others noted below. OASIS has the unique combination of member expertise necessary to complete this work.

The purpose of the XSPA profile is to address common needs: allow parties to adopt a set of methods that, taken together, will enable them immediately interoperate with other diverse participants in the same data exchanges; use readily available open standards, so that participation is broadly possible without significant licensing limitations, hardware or software choice constraints or single-source vendor risks; and provide a fully specified stack or set of specifications or options, all known to be interoperable. The foregoing needs are especially acute when the use of a particular set of methods is mandated, either by law or as a practical matter by its adoption by central actors in a mandatory system.

Governmental health regulators are increasingly requiring certain parties exchange health and health payment information (such as personal health records, and itemize statements of health care charges and benefit payments) in electronic form, and use sets of data standards identified as broadly suitable and secure. Similar government-sponsored or government-encouraged standardization projects are underway in many other countries. The XSPA profile will provide another "building block" in the creation of large scale interoperability of health information. These profiles will also aid in achieving interoperability for secure data exchange among various health care entities including providers, hospitals, pharmacies and insurance companies. It is envisioned that the work produced by this committee will also help the National Health Information Network (NHIN) in the US for secure data exchange.

It specifying the XSPA profile, where stable open standards exist, they should be noted and adopted. Where functions are not available, or some connective choices or additional material is required, it will be created. Doing so is the purpose for this committee's creation.

The profile specified by this TC will have broad applicability to health communities beyond the regulated portion of U.S. healthcare data transactions that the HITSP panel is directed to address. Use cases from other instances of cognate data exchanges, particularly in healthcare privacy contexts, may be solicited and used to improve the TC's work. However, the first priority of this committee will be to deliver and demonstrate sets of standards-based methods that fulfill the identified security & privacy functions needed by HITSP's specifications of functions and mandates.

The XSPA TC may also cover a more general enterprise server profile which will provide the building blocks for business models and industry applications. Some of the models investigated will include enterprise security and more generally SOA security. Application of how these security and privacy models apply to different industry sectors, including domains such as finance where privacy rights must be supported, will also be investigated if time permits.

The purpose of the TC is to specify sets of stable open standards and profiles, and create other standards or profiles as needed, to fulfill the security and privacy functions identified by the functions and data practices identified by HITSP, or specified in its use cases, as all are mandated or specified from time to time. These functions will at a minimum support the HITSP Access Control Transaction Package specification TP20, including those access control capabilities required to support the HITSP Manage Consent Directive Package specification TP30. This includes the support of reliable and auditable methods to identify, select and confirm the personal identity, official authorization status, and role data for the subjects, senders, receivers and intermediaries of electronic data; data needed to convey and/or enforce permitted operations on resources and associated conditions and obligations; and reasonable measures to secure and maintain the privacy and integrity of that data from end to end.

1. The TC may identify existing, stable open standards, and sets of standards, and alternative standards, extensions and profiles, for fulfilling each of the HITSP-identified functions and use cases. Where HITSP subject-matter-specific profiles have already identified such standards as recommended, those approved standards will be included in the TC's identified sets of standards. Where the TC identifies elements or alternatives not already so identified as recommended, the TC should, if it believes the additional alternatives are necessary or advisable, recommend their inclusion to the appropriate HITSP expert panel.
2. The TC may create and approve specifications, and extensions or profiles of specifications, as needed to fulfill HITSP-identified functions and use cases not satisfied by existing stable open standards. Contributions made to the committee for work issued by the committee itself will be subject to the OASIS IPR Policy. Any such work must include appropriate conformance clause or test information. Such work will be recommended for inclusion, as appropriate, in the standing recommendations of the appropriate HITSP expert panel.
3. The TC may elect, in the above specifications, extensions or profile, to indicate methods for the fulfillment of other publicly-available health-related use cases (or mandates), or functions described in those use cases (or mandates), including from other regions and other regulatory regimes; and may elect to create and approve additional specifications, and extensions or profiles of specifications, as needed, to fulfill those use cases or component functions.
4. The TC may elect to elaborate or extend any of the above use cases or functions, publish the same and create additional standards, profiles or extensions to support those augmented use cases or functional descriptions. In any such augmented work the TC must specify whether it is intended to fulfill an HITSP (or other) mandate. Any such work must include appropriate conformance clause or test information. Such work completed may be recommended for inclusion, as appropriate, in the recommendations or reports of any relevant health regulatory or advisory body.
5. The TC may elect to create supplemental information regarding the above matters such as demonstrations, implementation guides, best practices, FAQs, or other explanatory, implementation or promotional material as it may deem useful.
6. In all of its work, the TC should, to the extent feasible, prefer widely implementable, widely interoperable, modular standards, extensions, profiles and methods that permit use by a variety of participants with diverse hardware, software, data architecture and messaging practices. The TC intends to ask OASIS to contribute all or part of its final work, as relevant, HITSP or related panels for incorporation into its recommendations and mandates.

1. A document calling out in detail the specific AHIC / HITSP use cases and functions that the TC plans to address in their work product. This document will be completed and approved by the TC by October 2008.
2. A set of specifications, sets, profiles and extensions, as described in paragraphs #1 and #2 under 'Scope', to fulfill each of the AHIC / HITSP use cases and functions identified for fulfillment in deliverable paragraph #1, with the first such specification or profile to be approved as a Committee Specification by [December 2008], and the remainder if any to be approved by Committee Specifications by [June 2009]. The TC may elect to create one or more of such deliverables in whatever combinations it deems appropriate.
3. An interoperability demonstration of the XSPA profile, consistent with paragraph #5 under 'Scope,' demonstrating the end-to-end enforcement of healthcare security policy at the HIMSS (Healthcare Information and Management Systems Society) meeting (April 2009).
4. Optionally, such other deliverables (e.g., those listed in paragraphs 1-6 under 'Scope') as the TC may elect, until the later of December 2009 or such later date as the TC may elect to conclude.

Royalty Free on Limited Terms under the OASIS IPR Policy

Health-related data transaction participants, especially in exchanges subject to security or privacy regulation; regulators of healthcare, health payment and personal privacy; vendors and integrators supplying products or services to the foregoing; and, secondarily, participants in regulated or closely monitored data exchanges with privacy and security requirements in other topical fields.

English