RLUS and SOA Security
German National Personal Health Record
Jörg Caumanns, Olaf Rode, Raik Kuhlisch (Fraunhofer ISST)
SOA in Healthcare Conference
Hyatt Dulles Hotel, Herndon, VA USA
July, 14th 2011
Agenda
Project Scope and Focus Areas
Key Concepts
Architectural Overview
Semantic Signifiers
SOA Security
2
Project Scope and Focus Areas
Project Scope
Research and Development (R&D) Project funded by the German Federal Ministry of Health
(BMG)
Investigate on concepts and technologies for the German National Personal Health Record
Infrastructure
»Open Minded« Approach: No preliminary constraints – anything can be put into doubt that
hinders innovative care scenarios, stable business models, and better patient participation
Project Participants
Fraunhofer Society (Fraunhofer ISST and Fraunhofer SIT)
Federation of German Clinical Research Networks (TMF)
German Hospital Federation (DKG) & German Medical Association (BÄK)
Society for Telematic Applications of the Healthcare Card (gematik)
Focus Areas
Assessment of implementation options for the German electronic Patient Record as outlined by
»health card act« (§ 291a SGB-V)
Usability and feasibility analysis to support a future implementation
Elaboration of additional use-cases and scenarios stretching beyond § 291a SGB-V with a
particular focus on enabling medical research
Patient Record as a platform for patient centric applications (medication plan, diary, ...)
Highly challenging wrt security, privacy and patient rights
Innovative information model to allow for semantic differentiation and data selection
5
Key Concepts
Key Concepts
Power of Disposal of the Citizens of their Data
Basic Idea:
The PHR acts as a »tool of the citizen« to support its medical care.
The citizen does not regularize flow of data between systems of health service providers, but
initializes, and
controls it.
Citizen as source and target of flows of data
Citizen as a beneficiary of his medical data
Approach:
No »virtual integration« of data from systems of health service providers
Transmission of copies from medical data objects to the citizen‘s record system
Optional user interface for the citizen to interactively control flow of data
7
Key Concepts (2)
Platform for Target-Group-Specific Record Systems
Basic Idea:
Every Citizen has specific needs wrt concrete definition of his record
Needs result from current living situation and mirror in expectations of record features
Vendors should be able to provide target-group-specific records systems and product
variants.
Approach:
Support of different interaction and communications patterns (synchronously /
asynchronously communication)
Support of different authorization mechanisms (ad hoc, in advance, interactively)
Offer maximum design flexibility for vendors
8
Key Concepts (3)
Binding of Online Records and Decentralized Data Storage
Basic Idea:
Individual requirements of citizens:
secure »online storage« or
decentralized storage devices (e. g., USB flash drives)
The project addresses such different requirements
Approach:
Solution for binding of online records AND decentralized storage devices
Difference not »in sight« of the primary system of the health care provider
9
Key Concepts (4)
Communication of Normalized Information Objects
Basic Idea:
Besides normalized interfaces, medical data objects needs to be interoperable, too
Approach:
Definition of a model for a unified handling of different content structures based on RLUS
Semantic Signifiers
Level-based concept for step-by-step implementation of normalized content structures (e.
g., for a medication summary or a vaccination certificate)
Basis: HL7 CDA with additional supply of fallback documents (e. g., PDF/A) for the
interoperable processing throug primary and record systems
10
Architectural Overview
Integration Platform
Separation of Application and Security Services
Objectives:
Reduce complexity of particular services SoD
Reuse services in other application contexts
Provide flexibility for operator models
Security Services:
Identity Provider (central)
Access Token Service (decentral)
Guarantor Token Service (decentral)
Application Services of the Integration Platform
PHR Communication Service
(HSP Mailbox Service)
(PHR Research Adapter)
12
Integration Platform (2)
Architectural Overview
13
Integration Platform (3)
Consistent Use of International Standards
Coding of Content Structures
HL7 CDA
Service Invocations of Application Services
HL7 SFM / OMG RLUS (Retrieve Locate and Update Service)
Security Standards
SAML – Security Assertion Markup Language
WS-Trust
WS-SecurityPolicy
WS-SecureConversation
XACML – Extensible Access Control Markup Language
14
Semantic Signifiers
Semantic Signifiers
Motivation
Communicated data with PHR must be described semantically as well as structurally
Background
For interoperability reasons, classification and description of the data must be available in
order to ensure the processing in primary systems
Requested data from a PHR must be identifiable and transferable into return types
The exchange format must not be exactly the same as the one stored in PHR
Search requests and filters should be pointed to the specific information model depending
on the content type
Analogy to WSDL
No service but rather underlying information model described
16
Semantic Signifiers
Content-Agnostic vs. Content-Aware
No statements about the data storage on PHR-side
PHR might be implemented in two flavours
Content-agnostic
No interpretation of the (medical) data by the PHR
Similar to IHE XDS.b Document retrieval with a document identifier
Characteristically for encrypted data
Content-aware
Data storage can be analysed in order to fulfill a semantic signifier
Requests as »Give me all DICOM X-ray images relevant to hip joint« are possible
Data Warehouse Online Analytical Processing
Medical terminologies and ontologies such as SNOMED CT might be contributed
17
Semantic Signifiers
Pros and Cons
Pros
[Implementation Independence]
No explicit requirements for data storage and information models
[Flexibility]
Any contents and structures might be described
Cons
[Implementation Independence]
Each vendor must implement an adapter functionality for the mapping between internal and
external structures defined by semantic signifiers
[Flexibility]
Each semantic signifier must be explained in detail in order to prevent unchecked
distribution
[Management]
A processing for the development of semantic signifiers must be introduced in order to
provide the max interoperability
18
Semantic Signifiers
Management
Supported Semantic Signifiers listed in capability list
Semantic Signifier Catalogue
Versions of semantic signifiers
Liability of semantic signifiers
References to implementation guidelines, schemas etc.
Maintenance by a working group that represents interests of HSPs, vendors and citizens
Level-based concept for step-by-step implementation of normalized content structures
Level 1: HL7 CDA R2 Level 3 with embedded PDF/A that is liable
Level 2: Tightening of L1; Primary systems MUST provide solely data the is conformant to
structures defined in voted implementation guidelines
Level 3: Tightening of L2; No embedding of representation objects allowed; Structured data
from CDA is liable
RLUS Meta Data Interface might be implemented
19
SOA Security
SOA Security
Authentication and Authorization
Fundamentally important security principles for loosely coupled services
1. Distinct separation of the security processes/sub-systems from the business functionality
The business services are not directly affected by potential changes in the security
infrastructure
Separation of the security functionalities yields a significantly higher flexibility along the
flow-of-control of a business application
Facilitates re-use of security subsystems for additional business application
2. Externalise security tasks such as: identification, authentication, and authorization
Decoupling the tasks of authentication and authorization requires the means to communicate
authenticated subject information to the authorization sub-systems
The abstraction of those security architecture principles leads to Security Token Services
21
Trust and Communication Relationships
Communication Relationship
Trust Relationship
Authentication Process
Central Infrastructure provides authentication service (Identity Provider) WS-Trust
Credential: electronic health professional card (HPC)
Authentication evidence by issued SAML v2.0 assertion
SAML assertion might be used for different health data services
WS-Security defines placement of SAML assertions
Authorization Processes
Ad hoc
Local authorization in medical care unit (practice clinic) by means of citizen‘s health card
Citizen digitaly signs a policy on the physican‘s permissions that can by used by the physican
for further requests (as long as the resp. policy token is valid)
In Advance
The citizen registers access rules in its PHR system
Without the presence of the citizen access might be granted
Interactively
In asynchronous mode, the citizen decides which data should be send to a HCP by the
creation of provisioning objects
A GUI is necessary in order to select the data accordingly
Thank you.