Contents
Overview
In July 2008, OASIS members formed a new Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee 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." The TC proposers included representatives from OASIS institutional members Cisco Systems, IBM, Red Hat, Symlabs, and U.S. Veterans Health Administration.
The TC proposers recognized that "enterprises, including the healthcare enterprise, need a mechanism to exchange privacy policies, consent directives and authorizations in an interoperable manner... 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..."
According to the TC Charter, "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...
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...
The profile(s) 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 and privacy functions needed by HITSP's specifications of functions and mandates..."
XSPA Profiles
The OASIS XSPA TC focuses on the development of healthcare profiles of existing OASIS standards used to exchange interoperable security and privacy attributes within and between organizations. As of 2008-10, profiles were being developed for WS-Trust, XACML, and SAML. Working drafts are cited below.
OASIS Cross-Enterprise Security and Privacy Authorization (XSPA): WS-Trust Healthcare Profile. Working Draft. August 20, 2008. Document identifier: 'xspa-ws-trust-profile-01'. 30 pages. Edited by Brett Burley (Department of Veterans Affairs - Near Infinity Corporation); Duane DeCouteau (Department of Veterans Affairs - Edmond Scientific Company); Mike Davis (Department of Veterans Affairs); David Staggs (Department of Veterans Affairs - SAIC). Posted to the OASIS WS-SX TC list on August 20, 2008. Source .doc
Abstract: This document describes how WS-Trust is leveraged by cross-enterprise security and privacy authorization (XSPA) to satisfy requirements pertaining to information-centric security within the healthcare community.
Introduction: XSPA encompasses the mechanisms to authenticate and administer, and enforce authorization policies controlling access to protected information residing within or across enterprise boundaries.
The policies being administered and enforced relate to security, privacy and consent directives. In general, and with respect to this profile, WS-Trust works in concert with additional, supporting, lower-layer standards including WS-Security, WS-Policy and SAML to provide the overarching XSPA specification.
XACML is well suited for, and may be used to provide policy administration and enforcement within XSPA, leveraging a WS-based infrastructure where appropriate. However, this profile does not include the use of XACML within XSPA. XSPA does not mandate the use of XACML. This document provides an overview of the major WS components of the XSPA profile. The profile then establishes how these components may be used to implement cross-enterprise access control requirements relevant to the healthcare community.
This profile does not address security required to protect message transactions such as digital signatures and encryption, but instead discusses how shared messages can be used to negotiate the necessary claims to access a protect resource. It is assumed that the reader is somewhat familiar with the WS standards extended by WS-Trust..."
Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of XACML v2.0 for Healthcare. Committee Draft. October 14, 2008. 16 pages. Edited by Duane DeCouteau (Department of Veterans Affairs - Edmond Scientific Company); Mike Davis (Department of Veterans Affairs; David Staggs (Department of Veterans Affairs - SAIC); Brett Burley (Department of Veterans Affairs - Near Infinity Corporation). Posted to the OASIS Extensible Access Control Markup Language (XACML) TC Kavi repository on October 15, 2008. See the Kavi reference page and source .DOC. Action items: Align with other healthcare standards activities, XSPA Profile of XACML must include both structural and functional roles; XSPA Profile of XACML update to include OID for HL7_PERM... Comment by Erik Rissanen.
Abstract: A profile of XACML used to support cross-enterprise security and privacy authorization.
Enterprises, including the healthcare enterprise, need a mechanism to exchange security and privacy policies, evaluate consent directives and determine authorizations in an interoperable manner. This document provides a cross-enterprise security and privacy profile that describes how to use Extensible Access Control Markup Language (XACML) to provide these functions in an interoperable manner.
The Cross-Enterprise Security and Privacy Authorization (XSPA) profile of XACML describes several mechanisms to authenticate, administer, and enforce authorization policies controlling access to protected information residing within or across enterprise boundaries. The policies being administered and enforced relate to security, privacy, and consent directives. This profile MAY be used in coordination with additional standards including Web Services Trust Language (WS-Trust) and Security Assertion Markup Language (SAML).
This profile specifies the use of XACML 2.0 to promote interoperability within the healthcare community by providing common semantics and vocabularies for interoperable policy request/response, policy lifecycle, and policy enforcement...
Using SNOMED. Systematized Nomenclature of Medicine (SNOMED) Clinical Terms User Guide provides the core general terminology for the electronic health record (EHR). As used in this profile, SNOMED CT is used to designate clinically relevant protected information objects. [See: SNOMED Clinical Terms User Guide, July 2008 International Release. Copyright © 2002-2008 The International Health Terminology Standards Development Organisation (IHSDO).]
Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare. Working Draft. 15-September-2008. Document identifier: 'xspa-saml-profile-02'. 13 pages. Edited by Duane DeCouteau (Department of Veterans Affairs - Edmond Scientific Company); Mike Davis (Department of Veterans Affairs); David Staggs (Department of Veterans Affairs - SAIC); Brett Burley (Department of Veterans Affairs - Near Infinity Corporation). Posted to the SAML TC Kavi document repository on September 22, 2008. Kavi source doc.
Abstract: This profile describes a framework of how SAML and standard candidates encompassed by cross-enterprise security and privacy authorization (XSPA) can be used to satisfy requirements pertaining to information-centric security within the healthcare community... Interoperability is achieved using SAML assertions that carry common semantics and vocabularies in exchanges specified below. This XSPA profile of SAML is required to achieve cross-enterprise authorization of entities operating within a healthcare workflow by providing common semantics and vocabulary for interoperable coarse grain access control...
The XSPA profile of SAML supports sending all requests through an Access Control Service (ACS). The Access Control Service receives the Service User request and responds with a SAML assertion containing user authorizations and attributes. To perform its function, the ACS may acquire additional attribute information related to user location, role, purpose of use, and requested resource requirement and actions. The requesting ACS is responsible of enforcement the access control decision... The Service Provider ACS is responsible for the parsing of assertions, evaluating the assertions against the security and privacy policy, and making and enforcing a decision on behalf of the Service Provider...
Security Considerations. The following security considerations are established for the XSPA profile of SAML: (1) Entities must be members of defined information domains under the authorization control of a defined set of policies; (2) Entities must have been identified and provisioned (credentials issued, privileges granted, etc.) in accordance with policy; (3) Privacy policies must have been identified and provisioned (consents, user preferences, etc.) in accordance with policy; (4) Pre-existing security and privacy policies must have been provisioned to access control services; (5) The capabilities and location of requested information/document repository services must be known; (6) Secure channels must be established as required by policy; (7) Audit services must be operational and initialized; (8) Entities have pre-asserted membership in an information domain by successful and unique authentication..."
"HIMSS Interop Scenarios: Demonstration of XSPA Profile of SAML." Edited by Duane DeCouteau and contributed to the OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC. January 05, 2009. 19 pages. See the posting to the XSPA TC discussion list: 'A draft of the HIMSS Interop Scenario of XSPA Profile for SAML has been submitted for review and comment...' See also: "Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare." [Source .doc]
"The OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee was created by OASIS membership in support of the work of the Healthcare Information Technology Standards Panel (HITSP). Specifically, the Access Control Transaction Package, TP20. As part of that support, the XSPA TC has created this document describing a set of use cases for demonstrating the (XSPA) Profile of Security Assertion Markup Language (SAML) v2.0 for healthcare. TP20 and HITSP Security and Privacy Technical Note TN900 provide additional details in the protection of security and privacy in interactions between parties in the exchange of healthcare information.
Access Control Service (Service User): The XSPA profile of SAML supports sending all requests through an Access Control Service (ACS). The Access Control Service receives the Service User request and responds with a SAML assertion containing user authorizations and attributes. To perform its function, the ACS may acquire additional attribute information related to user location, role, purpose of use, and requested resource requirements and actions. Access Control Service (Service Provider): The Service Provider ACS is responsible for the parsing of assertions, evaluating the assertions against the security and privacy policy, and making and enforcing a decision on behalf of the Service Provider. Attributes: Attributes include access control information such as user location, role, purpose of use, data sensitivity, etc. necessary to make an access control decision.
Security Policy: The security policy includes the rules regarding authorizations required to access a protected resource and additional security conditions (location, time of day, cardinality, separation of duty purpose, etc.) that constrain enforcement. Matching the user attributes against the security policy provides the means to determine if access is to be permitted. Privacy Policy: The privacy policy includes the set of patient preferences and consent directives and other privacy conditions (object masking, object filtering, user, role, purpose, etc.) that constrain enforcement. Privacy policy constraints may narrow allowable access otherwise permitted by entities complying with the security policy...
This document describes an environment capable of supporting exchange of healthcare information consistent with TP20 and a set of use cases for demonstrating the XSPA Profile of SAML..."
XSPA TC Charter and CFP
Excerpts from the Charter and Call for Participation, published July 2, 2008.
Contents
OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC
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 and 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
Section (2). Non-normative information regarding the startup of the TC, which includes:
(2)(a) Similar or Applicable Work
Identification of similar or applicable work that is being done in other OASIS TCs or by other organizations, why there is a need for another effort in this area and how this proposed TC will be different, and what level of liaison will be pursued with these other organizations.
The proposed Cross-Enterprise Security and Privacy Authorization (XSPA) TC will be incorporating several standards in a profile allowing the exchange of privacy policies, consent directives and authorizations in an interoperable manner. The need for an XSPA profile has been identified by the security and privacy working group of the ANSI-sponsored Healthcare Information Technology Standards Panel (HITSP). No other organization is addressing this identified gap in standards. The profile will use standards from several OASIS TCs: SAML (SSTC), WS-Trust (WS-SX) and XACML. Liaison will be established by concurrent work items in the cited TCs' area of expertise.
The date, time, and location of the first meeting, whether it will be held in person or by telephone, and who will sponsor this first meeting. The first meeting of a TC shall occur no less than 30 days after the announcement of its formation in the case of a meeting held exclusively by telephone or other electronic means, and no less than 45 days after the announcement of its formation in the case of a meeting held face-to-face (whether or not a telephone bridge is also available).
The proposed XSPA TC will hold the first official meeting on August 8, 2008 at 1pm ET by telephone and will use a free conference call service.
The projected on-going meeting schedule for the year following the formation of the TC, or until the projected date of the final deliverable, whichever comes first, and who will be expected to sponsor these meetings.
The TC will meet biweekly or as otherwise agreed upon by the members of the technical committee.
The names, electronic mail addresses, and membership affiliations of at least Minimum Membership who support this proposal and are committed to the Charter and projected meeting schedule.
- Sampo Kellomki, sampo@symlabs.com (Symlabs)
- Mark Little, mark.little@jboss.com (Redhat)
- John Moehrke, john.moehrke@med.ge.com (Individual)
- Anthony Nadalin, drsecure@us.ibm.com (IBM)
- Anil Saldhana, Anil.Saldhana@redhat.com (Redhat)
- David Staggs, david.staggs@va.gov (Veterans Health Administration)
- Anil Tappetla, atappetl@cisco.com (Cisco)
The name of the Convenor who must be an Eligible Person. David Staggs.
(2)(f) Affiliated Member Section
The name of the Member Section with which the TC intends to affiliate, if any.
None.
Optionally, a list of contributions of existing technical work that the proposers anticipate will be made to this TC.
None.
Optionally, a draft Frequently Asked Questions (FAQ) document regarding the planned scope of the TC, for posting on the TC's website.
To be provided at a later date.
Optionally, a proposed working title and acronym for the specification(s) to be developed by the TC.
To be provided at a later date.
From the XSPA TC Announcement
October 08, 2008. OASIS, the international open standards consortium, has formed a new group to standardize the way healthcare providers, hospitals, pharmacies, and insurance companies exchange privacy policies, consent directives, and authorizations within and between healthcare organizations.
The OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee will specify healthcare profiles of existing OASIS standards to support reliable, auditable methods of confirming personal identity, official authorization status, and role attributes. This work aligns with security specifications being developed within the U.S. Healthcare Information Technology Standards Panel (HITSP). A cooperative partnership between the public and private sectors, HITSP is a national, volunteer driven, consensus-based organization that is working to ensure the interoperability of electronic health records in the United States.
"Electronic Health Records (EHR) systems must be interoperable so that patients, physicians, hospitals, public health agencies and other authorized users can share health related information with adequate security and privacy protection," explained Johnathan Coleman, facilitator of the HITSP Security, Privacy and Infrastructure Technical Committee.
In accomplishing the work of the XSPA Committee, OASIS is focused on addressing the very sensitive issues related to the access of patient information.
"While the primary focus of our work will center on the HITSP interoperability specifications, we expect XSPA will have broad applicability to health communities beyond government regulated transactions," said David Staggs, co-chair of the OASIS XSPA Technical Committee. "We intend to solicit use cases from other instances of cognate data exchanges — particularly in healthcare privacy contexts — to improve our work."
The work of the OASIS XSPA Technical Committee may even extend beyond healthcare to general business models and other industry applications where support for privacy rights is needed, such as finance.
"Privacy and authorization are areas of security that need to be addressed for standardization. A standard format for privacy, consent directives, and authorization data exchange will foster interoperability and simplification of complex heterogeneous systems," said Anil Saldhana of Red Hat, co-chair of the OASIS XSPA Technical Committee.
XSPA will be developed at OASIS alongside other core security standards, such as the Security Assertion Markup Language (SAML), Web Services Trust (WS-Trust), and the eXtensible Access Control Markup Language (XACML). The XSPA work will draw on these standards and the expertise behind them, as part of its goal to identify and fill in the gaps.
XSPA will be offered for implementation on a royalty-free basis. Participation in the OASIS XSPA Technical Committee remains open to all interested parties. Archives of the work will be accessible to both members and non-members, and OASIS will offer a mechanism for public comment.
Support for XSPA
"The formation of this technical community represents a major milestone in taking OASIS security technology, such as XACML, WS-Trust, and SAML, to the next step by applying standards to solve specific industry challenges. This effort helps provide the foundation for a concrete standard for much needed interoperability within the healthcare industry," said Anthony Nadalin, IBM Distinguished Engineer and chief security architect, IBM Tivoli Software.
U.S. Department of Veterans Affairs
"The work of the OASIS XSPA Technical Committee is a major step towards achieving the goal of international security and privacy interoperability. We are delighted to help lead the creation of these critical healthcare profiles supporting OASIS, HITSP, and the Office of the National Coordinator," said John (Mike) Davis of the Department of Veterans Affairs.
Principal URIs
- OASIS XSPA TC:
- OASIS Technical Committee, Initial Co-Chairs:
- OASIS XSPA Corporate Member support:
- TC Startup URIs:
- Convener Call for XSPA Technical Committee (Conference Call). Date: Wednesday, 25 June 2008. Time: 01:00pm - 02:00pm ET.
- Proposed Charter for OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC. June 09, 2008. Also posted to TC Announce List.
- Other references:
General: Articles, Papers, News
[October 20, 2008] Proposed XSPA Profile Use Cases. By David Staggs (SAIC). October 20, 2008. Posted to the XSPA TC list. "The XSPA TC is required to produce a document describing use cases that will be used to demonstrate our profile. This document can serve as a foundation for the profile document, conformance document, and/or HIMSS InterOp document. I have attached a strawman for discussion. The proposed use cases support HITSP TP-20 and are consistent with our XACML profile work demonstrated in London earlier this month... The proposed use cases just sent have references to sections from a document written for the earlier XACML work. I have attached the document for your reference. See XACML 2.0 RSA 2008 Interop Scenarios Walk Through (Version 0.7, Working Draft, April 05, 2008)...
[October 08, 2008] Announcement October 08, 2008. "OASIS Members Form New Committee to Enable Exchange of Healthcare Security and Privacy Information. IBM, Axiomatics, Cisco, Red Hat, US Department of Veterans Affairs, and Others Collaborate to Meet HITSP Requirements."
[September 22, 2008] Interop Announcement. From Jane Harnad and Dee Schur. Interoperability Demonstration at HIMSS, April 4-8 2009. OASIS, in collaboration with HITSP presents the an opportunity to our XSPA TC members to participate in an Interoperability Showcase Demo at HIMSS 2009. The goal is to demonstrate the XSPA profile based on HITSP TP 20. HIMSS09 Interoperability Showcase: "HIMSS Interoperability Showcases are unique events that bring together the builders, buyers and users of the latest in today's health information technology. The message and direction in healthcare technology is Interoperability. Buyers, end users, clinicians, government agencies, researchers and many other healthcare stakeholders..." alt URI
[September 12, 2008] HITSP Access Control Transaction Package (TP 20). Version:1.2. See the reference page. Per the posting: "Review of the HITSP document TP20 for review and acceptance by the TC. The use cases selected for the XSPA Interop at HIMSS 2009 will be drawn from the TP20 document. Therefore the TC should review TP20 and suggest any changes that might be required..." — "The Access Control Transaction Package provides the mechanism to administer security authorizations which control the enforcement of security policies including: role-based access control; entity based access control; context based access control; and the execution of consent directives. In an emergency, this construct supports the capability to alter access privileges to the appropriate level (failsafe/emergency access), which may include override of non-emergency consents..." [cache/archive]
[August 12, 2008] Videos. "This application was used very successfully at the RSA Conference with the XACML TC. The application allows us to apply and enforce enterprise permissions, patient privacy constraints, and local business security rules. We also have the ability to display protocol exchanges made during access to the EHR." See Followup comment.
[June 24, 2008] OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) — WS-Trust Healthcare Profile. Working Draft. June 24, 2008. Abstracted in XML Daily Newslink; see also the associated posting.
