View source for Enterprise Security and Privacy Authorization Profile

__NOTOC__

==1. Proposed Profile: ''Cross-Enterprise Security and Privacy Authorization (XSPA) Profile''==

* Proposal Editor: ''Mike Davis, David Staggs, Matthew Metheny''
* Profile Editor: ''N/A'' 
* Date:    N/A (Wiki keeps history)
* Version: N/A (Wiki keeps history)
* Domain: ''IT Infrastructure''

==2. The Problem==

''The Cross-Enterprise Security and Privacy Authorization (XSPA) profile addresses the security and privacy requirements for enforcing privacy and access control policies between multiple EHR (Electronic Health Record) systems within a Cross-Enterprise Data Sharing (XDS) Regional Health Information Organization (RHIO).  Currently there are mechanisms that exist to support the basic security requirements of identifying [Personnel White Pages (PWP), Enterprise User Authentication (EUA)] and authenticating users [EUA, Cross-Enterprise User Authentication (XUA)], authenticating nodes [Audit Trail and Node Authentication (ATNA)], auditing (ATNA), data integrity [Consistent Time (CT), ATNA, Transport Layer Security (TLS)], and data confidentiality (ATNA, TLS), however there is no mechanism that provides a fine-grained interoperable approach to controlling access to a patient’s healthcare information through strictly enforced privacy (patient consent and authorization) and security (enterprise organizational implementation) policies.''


==3. Key Use Case==

''Within an XDS RHIO, an EHR system may receive a request for information from an Electronic Health Record (EHR) for a specific patient.  The request could originate from many different sources to include, but not limited to, insurance providers, parents or guardians, law enforcement, and other insurance subscribers under the same policy.  The protection of health information must not only include who has access to the health information, but also the types of information that the requestor should be granted access to receive.  This requires the enforcement of complex privacy policies (consents and authorizations) that enable constraints on the types of healthcare information (i.e., medications, psychiatric evaluations and treatments, fertility results), and who is able to access the information (i.e., primary care physicians, specialists, nurses, employers, spouses, parents/guardians, insurance agents) conveyed in patient consents and authorizations.

'''Use Case: Patient Consent Scenario #1 (Physician’s Request for New Patient Health Information):'''

'''Description:'''
''A primary care physician (Provider “A”) within the RHIO requests healthcare information from a new patient’s EHR.  The patient’s EHR could be located within multiple EHR systems (e.g., Hospital, Private Physician, Mental Health Professional, Insurance Provider, etc.), each with individual policies for protecting a patient’s health information.  A patient may also set an obligation that he/she be notified when their health information was accessed (permitted or denied).  The EHR system which receives the request will need to obtain the patient’s consent information and the requestor’s (Provider “A”) information (Provider “A” ID) to determine if the patient has consented, through a patient specified privacy policy, the release of their healthcare information to the requestor, and specifically what type of information the patient has approved to be released.

'''Transactions:'''
:1.	Physician requests access to a patient’s health information (access is based on the consent of the patient).
:2.	Information (sensitivity level – confidentiality code within the XDS and permissions) about the Physician would be gathered to determine the authorization based on the applicable policy.
:3.	The EHR system sends health information to the physician from the patient’s EHR (permit is based on patient consent).
:4.	The EHR system notifies the patient of the physician’s requested access (including the access decision – permit or deny) to the patient’s health information.
''


==4. Standards & Systems==

''The EHR systems could be interconnected to multiple EHRs across the XDS RHIO within the National Healthcare Information Network (NHIN), or within XDS RHIO in which the EHR systems reside using a decentralized architecture.  For the XDS RHIO to enable multiple EHR systems to exist independently (i.e., each system could be proprietary in nature), the mechanisms of Web Service (WS)-Trust and WS-Federation need to be used to enable the enterprises to brokerage trustworthy identity tokens, and discover and share authorization attributes based on the authorization and privacy policies across enterprise organizational boundaries.  While an open standard such as the Organization for the Advancement of Structured Information Standards (OASIS) eXtensible Access Control Markup Language (XACML) can be used for the exchange and enforcement of access policies to specific functions within the EHR system or access to specific health care information within the EHR of a specific patient through policy-based decisions, WS-Trust, WS-Federation, and XACML offer an interoperable mechanism for cross enterprise communication and the expression of privacy and access control policies in a common language.  An ontology- based vocabulary will also need to be defined to convey the multiple combinations of consent rules that will be enforced at a granular level through security and privacy policies.

'''Standards relevant to the solution:'''

:*OASIS eXtensible Access Control Markup Language (XACML) v2.0
:*OASIS Role Based Access Control Profile of XACML v2.0
:*OASIS Security Assertion Markup Language (SAML) v2.0
:*World Wide Web Consortium (W3C) eXtensible Markup Language (XML)
:*W3C XML Schema
:*WS-Federation v1.1
:*WS Trust v1.1
:*Health Level Seven (HL7) Confidentiality Codes
:*HL7 RBAC Healthcare Permission Catalogs
:*XACML 2.0 Interop Scenarios v 0.1
''


==5. Discussion==

''The XSPA Profile defines an interoperable approach for dynamic information access to healthcare information, and a vocabulary for addressing policy-level decision-making that is flexible and extensible.  A goal in the development of the XSPA Profile is to satisfy the American Health Information Community (AHIC) Use Case security requirements and overcome the current shortcoming of existing IHE Information Technology Infrastructure (ITI) profiles for granular access control mechanisms through privacy, security, and other regulatory policies.  This proposal addresses these shortcomings, and therefore IHE should consider creating this profile using a phased in approach within the IHE IT Infrastructure domain.

''In 2007, a White Paper was developed by the ITI Technical Committee identifying the limitations in the current profiles within the IHE IT Infrastructure domain that identified the lack of granular controls to allow patients to control access on individuals that are authorized and individuals that must not be given access.  “A profile should be developed that offers an advanced level of control for complex consents.”  This proposal proposes a profile that utilizes the functionality offered by OASIS XACML, WS-Trust, and WS-Federation to define a policy-based language to control access to healthcare information, as well as interoperable mechanisms for communicating access control decision requests/responses for accessing healthcare information.  For details related to the protection of patient privacy and information security refer to the IHE IT Infrastructure White Paper (“HIE Security and Privacy through IHE”) at:
''[http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_and_Privacy_2007_07_18.pdf  HIE Security and Privacy through IHE]