This document proposes standards and solutions for healthcare data exchange and interoperability. It discusses the goals of electronically exchanging health information while maintaining meaning. Standards discussed include HL7, RBAC, ABAC, PBAC, and XACML for access control policies. Implementing attribute-based access control is proposed to allow flexible, multi-factor access decisions. Integrating the Healthcare Enterprise (IHE) and Oracle Entitlement Server are presented as initiatives supporting interoperability and fine-grained authorization.

1. Healthcare Exchange
Interoperability
Standards Overview
and Solution Proposal
Tomislav Milinovic

2. National Strategy
http://www.who.int/goe/policies/countries/hrv/en/

3. Exchange of Health Information
• The vision for exchange of health information is to
electronically move health information among disparate
health care information systems while maintaining the
meaning of the information exchanged.
• The goal is to facilitate access to and retrieval of health
data in order to:
– improve health care quality
– increase patient safety
– reduce health care costs
– improve public health

4. e-Health Interoperability
• Interoperability of Electronic Health Records (EHR) systems
means the ability of two or more EHR systems or components
of EHR systems to exchange information electronically,
securely, accurately and verifiably, when and where needed.

5. Access ControlModel
• An access control system designed to operate in the healthcare scenario
should:
– be flexible and extensible
– should protect the privacy of the patients,
– not allow the exchange of identity data, in compliance with government legislation
• The majority of the electronic health record (EHR) systems uses the RBAC
model. It is considered to be particularly well-suited to health care systems.
Journal of Biomedical Informatics 46 (2013) 541–562
• In RBAC, a precise semantic of roles must be defined among organizations,
which can be unrealistic in service-oriented architectures, where no
agreement on the capabilities assigned to roles can be achieved in advance
by the different involved entities.

6. Security/Privacy Considerations
• HL7 v3 does not suggest any data security mechanism, but
specifies data formats and data fields in messages that can carry
such information within a message for its security.
• HL7 is evolving a RBAC specification for role and permissions-based
access control over health information of patients stored
in EHR.
• RBAC specification covers authorization and access control
aspects of security. In a distributed healthcare system
implementation, such a policy framework comes as a necessary
add-on over a message exchange.
• For example, a patient is being seen by a physician for a diabetic
consultation. The physician needs access to the patients’ medical
history and results from tests which are being performed during
the visit (Physician with Review Documentation privileges)

7. RBAC
• HL7 V3 Standard: Role-Based Access Control Healthcare Permission Catalog, Release 2
– Core RBAC elements (users, roles, objects, operations, and permissions) are transferred into
operation and object definitions that can be adopted.
– Introduces normative language to the HL7 permission vocabulary in constructing permissions
{operation, object} pairs, for example, Permission Name: New Laboratory Order {CREATE,
Laboratory Order}
– should be considered as a baseline for interoperability between different policy domains.
• ISO/TS 22600-2:2006 Health informatics — Privilege management and access control
– Defines RBAC control schema based on harmonized functional and structural roles
– The American ASTM E1986–98 standard has defined an American list of roles. ISO DTS 21298
defines a similar set of structural and functional roles which are referred to in the International
Labour Organisation .
• HL7 Version 3 Standard: Security and Privacy Ontology, Release 1
– Individual request for permission to perform an operation on an object must be logically
consistent with the ontology.
For example, the PhysicianFunctionalRole role has permission to create order entries, including
laboratory orders, etc. On requesting permission for the actor of that role to create an account
receivable, the reasoner will report an inconsistency.

8. ABAC
• A key advantage to the Attribute-based Access Control (ABAC)
model is that there is no need for the requester to be known in
advance to the system or resource to which access is sought.
• As long as the attributes that the requestor supplies meet the
criteria for gaining entry, access will be granted.
• Ability to determine access without the need for a predefined list of
individuals that are approved for access is critical in large
enterprises where the people may join or leave the organization
arbitrarily.

9. ABAC vs. RBAC
• Gartner Identity and Access Summit, Nov 2013
– By 2020, 70% of all businesses will use ABAC as the dominant mechanism to protect
critical assets, up from 5% today
• NIST Special Publication 800-162:
Guide to ABAC Definition and Considerations
– RBAC does not easily support multi-factor decisions (for example, decisions
dependent on physical location, and specialized training such as for Health Insurance
Portability and Accountability Act (HIPAA) records access; recent training on HIPAA
data protection may be a prerequisite to view medical records.)

10. PBAC
• A resource is governed by a document that exactly specifies what
subject credentials and requirements must be fulfilled in order to
obtain access.
• PBAC can be said to be a harmonization and standardization of the
ABAC model at an enterprise level in support of specific governance
objectives (regulation and legislation).
• PBAC is by now the de-facto standard model for enforcing access
control policies in service-oriented architectures.

11. XACML
• A widely used implementation of PBAC is given by eXtensible
Access Control Language (XACML). It defines a language for the
definition of policies and access requests and a complete workflow
to achieve policy enforcement
• EU Project epSOS uses XACML as a policy language for expressing
access control for sensitive data such as patients healthcare
information.
• Core and hierarchical role based access control (RBAC) profile of
XACML v2.0 (OASIS Standard, 1 February 2005) defines a profile for
the use of XACML in expressing policies that use “core” and
“hierarchical” RBAC

12. Request
<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os
access_control-xacml-2.0-context-schema-os.xsd">
<Subject>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>Julius Hibbert</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
<AttributeValue>http://medico.com/record/patient/BartSimpson</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>read</AttributeValue>
</Attribute>
</Action>
<Environment />
</Request>

13. Response
<Response xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os
access_control-xacml-2.0-context-schema-os.xsd">
<Result>
<Decision>Permit</Decision>
<Status>
<StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok" />
</Status>
</Result>
</Response>

14. Cross-Enterprise Security and Privacy Authorization
(XSPA) Profile of XACML v2.0 for Healthcare v1.0
OASIS Standard, 1 November 2009, http://docs.oasis-open.org/xacml/xspa/v1.0/saml-xspa-1.0.html
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.
Attribute ID* Identifier Type Valid Values
subject:subject-id urn:oasis:names:tc:xacml:1.0:subject:subject-id String Is the name of the user as
required by Health Insurance
Portability and Accountability Act
(HIPAA) Privacy Disclosure
Accounting. The name will be
typed as a string and in plain text.
subject:organization urn:oasis:names:tc:xspa:1.0:subject:organization String Organization the requesting user
belongs to as required by Health
Insurance Portability and
Accountability Act (HIPAA)
Privacy Disclosure
Accounting. The name will be
typed as a string and in plain text.
subject:organization-id urn:oasis:names:tc:xspa:1.0:subject:organization-id anyURI Unique identifier of the
consuming organization and/or
facility
subject:hl7:permission urn:oasis:names:tc:xspa:1.0:subject:hl7:permission String Refer to [HL7-PERM] and its OID
representation.
subject:role urn:oasis:names:tc:xacml:2.0:subject:role String Structural Role refer to [ASTM
E1986-98 (2005)] and its OID
representation.
subject:purposeofuse urn:oasis:names:tc:xspa:1,0:subject:purposeofuse String TREATMENT, PAYMENT,
OPERATIONS, EMERGENCY,
MARKETING, RESEARCH,
REQUEST, PUBLICHEALTH
resource:resource-id urn:oasis:names:tc:xacml:1.0:resource:resource-id String Unique identifier of the resource
defined by and controlled by the
servicing organization. In
healthcare this is the patient
unique identifier.
resource:hl7:type urn:oasis:names:tc:xspa:1.0:resource:hl7:type String For minimum interoperability set
of objects and supporting actions
refer to [HL7-PERM] and their
OID representations.
resource:org:permission urn:oasis:names:tc:xspa:1.0:resource:org:hl7:permi
ssions
String Refer to [HL7-PERM] and its OID
representation. This attribute
holds permissions required by
the servicing organization to
grant access to a specific
resource.
SOAP SAML XACML Request wrapper
The request message contains three protocol layers:
• soapenv: A SOAP Envelope contains a SOAP Body.
• xacml-samlp: SAML protocol layer, which is enabled by the
XACML extension to the SAML protocol
• xacml-context: is the XACML request/response layer
The response message above contains three protocol layers:
• soapenv: is the SOAP layer. A SOAP Envelope contains a
SOAP Body.
• samlp: in the response case the xacml extension is lower in
the samlp: protocol. In particular, samlp: requires a
saml:Assertion, which in turn includes a saml:Statement. It is
within the saml:Statement that the xacml extension occurs
and is referred to as xacml-saml: because it extends the
saml:Assertion/saml:Statement with the
XACMLAuthzDecisionStatementType.
• xacml-context: is the XACML request/response layer

15. Integrating the Healthcare Enterprise
(IHE) Initiative
• Designed to stimulate the integration of the healthcare information systems
• Support the use of existing standards, e.g., HL7, ASTM, DICOM, ISO, IETF, OASIS
rather than to define a new standards
• IHE Europe (IHE-EUR) is supported by the European Institute for health Records
(EuroRec).
• IHE IT Infrastructure Technical Framework
– Volume 1 (ITI TF-1): Integration Profiles
• Cross-Enterprise Document Sharing (XDS), sharing clinical records within an XDS Affinity Domain
• Cross-Enterprise User Assertion Profile (XUA), communicate claims about the identity
• Basic Patient Privacy Consents (BPPC)
• Patient Identifier Cross-referencing HL7 V3 (PIXV3), correlate a patient information from
multiple sources
• Cross-Community Access (XCA), query and retrieve patient relevant medical data held across
multiple domains

16. IHE IT-Infrastructure Access Control
White Paper
• Inflexibilities of RBAC in healthcare
– people often switch among multiple roles
– access rights vary depending on the state of the patient or the “operational mode” of
the organization (e.g., nightshift, disaster management)
• Policy Based Access Control
– A policy is a set of rules, which control the security and privacy behavior of a given
system.
– Policy activation requires that attribute values have to be available.
This can either be realized by:
• the requestor, who includes them with the request message
• the processing party who retrieves them on demand from a policy information
point
• XACML as candidate for policy encoding

17. Policy Attributes and Attribute Sources

18. Oracle Entitlement Server
• A fine grained authorization solution
– While OAG and OAM has authorization capabilities, in this field OES offers a
much richer model.
• OES supports ABAC(XACML), RBAC (NIST RBAC), ERBAC (Enterprise
RBAC) and JAAS policy models.
• Oracle API Gateway is natively integrated with OES - this requires
no changes to the application code.
– Oracle API Gateway can use OES to manage authorization for Web Services.
The integration hook between OAG and OES is the OES 11g Authorization
filter

19. Oracle Entitlement Server
• API Gateway ‘s XACML PEP filter enables you to configure the API Gateway to act as a PEP.
The API Gateway intercepts a user request to a resource, and enforces the decision from the
Policy Decision Point (PDP).
• When Oracle Entitlements Server is deployed, a Policy Decision Point (PDP) receives a
request for authorization, evaluates it based on applicable policies, reaches a decision and
returns the decision to the Policy Enforcement Point (PEP).