Example from the Dutch Healthcare Exchange Program

Federated SOA SECURITY

Federated SOA Security © CSC 2010

1. The business rationale

People can receive care during their whole life Care is often provided by multiple care institutions Care institutions are in charge of their own registrations

Information about one patient is distributed over many information systems over many care institutions

•  There is no complete and accurate “patient record”

+

Federated SOA Security © CSC 2010

•  A woman of 67 years old suffers from heavy pain when she walks, cycles or dances

•  She visits her family doctor and he prescribes a painkiller

•  She takes the painkiller during some time. First with good results but after a while she needs more and more. Her doctor sends her to a physiotherapist

•  The physiotherapist sends her to a hospital for an X-ray •  The X-ray shows a worn hip. She’s placed on the

waiting list for the hospital for hip replacement •  During the intake for the operation the woman

remembers that in her youth she has had allergic reactions against penicillin

•  She is operated on and after that receives therapy from another physiotherapist

For example: “the total hip”

Family doctor

Pharmacist

Physiotherapist

Hospital

Federated SOA Security © CSC 2010

2. Business Constraints

•  Security is key. The patient can grant or deny access to his information and may forbid to exchange his patient data

•  Healthcare institutions have their own responsibilities. The way information is registered and stored is part of their responsibility for the quality of care provision. So we can’t “replace” their applications with prescribed information systems

•  The solution should support small care providers (like family doctors with one PC) as well as the very big ones (like university hospitals with their own dual data center)

•  Authorization should be fine-grained. The information available for a healthcare provider should be dependant of his role and the care institution he’s working for

Federated SOA Security © CSC 2010 The Netherlands

3. Some more detail

Federated SOA Security © CSC 2010

The Netherlands (“Holland”)

•  23rd most densely populated country in the world – almost 1500 people per square mile

•  High life expectancy – 82 years for newborn girls, 77 years for boys

•  16th largest economy in the world •  Aging population

– More and longer demand for (health-)care – Working population decreases

•  Challenges for healthcare – Doing more with less – Growing demand for extramural care

Federated SOA Security © CSC 2010

The National Switchboard for healthcare

Federated SOA Security © CSC 2010

Smartcard for care providers

Federated SOA Security © CSC 2010

4. Architectural starting points - 1

• Patients’ information stays at the source • The Dutch National Switchpoint is a pointer index • The Switch Point also retrieves the information from local healthcare

information systems and transfers the information to requesting healthcare information systems

•  Importance of authentication and autorization – privacy aspects – reliability of information (responsibility) – Citizen Service Number for patients identification – UZI pass for the identification, role and working relationship of doctors etc.

•  Importance of logging • The patient in the driving seat

– final autorization of healthcare professionals by the patient – right to see logged information by law

Federated SOA Security © CSC 2010

Architectural starting points - 2

• HL7v3 is the protocol to be used for the exchange of information with the National Switchpoint – HL7 is one of the leading standardization organizations within international

healthcare – HL7v3 offers semantic interoperability – HL7v3 supports web services / Service Oriented Architecture

• The Switchpoint acts as a “ broker” for the underlying healthcare information systems – Requesting systems don’t have knowledge about addresses etc. this is all

handled by the Switchpoint

• The network connections are encrypted using SSL – Authentication on the network layer (SSL) done with the organization’s “ service

certificate” – Authentication for the message (token) done with the healthcare providers

personal “UZI pass”

Federated SOA Security © CSC 2010

Result: The‘virtual patient record’

Information from Healthcare System A

Information from Healthcare System B

Information from Healthcare System C

Federated SOA Security © CSC 2010

5. Basic Security architecture

Perimeter 1 Use of private networks

Healthcare organization

Healthcare organization

National Switchpoint

Perimeter 2 SSL based on server

certificates

Perimeter 2 SSL based on server

certificates

End-to-end Token based

authentication on message level

Federated SOA Security © CSC 2010

Implementation challenges

•  Large number of SSL connections to take care of •  2000 concurrent connections growing towards 10.000 connections

•  Security token to be checked in every message •  2000 messages/minute growing towards 40.000 messages/minute

•  Multiple changes expected in authentication •  SHA-2 for better security •  Support needed for other means of authentication than the UZI-pass

•  Other smart cards for public officers •  Delegated authentication for patients portal

Federated SOA Security © CSC 2010

Solutions architectural principles

•  “Offload” core system – Move simple tasks, not requiring business logic, to the “outside’ of the

switchpoint – Use dedicated (hardware) components when appropriate

•  SSL offloaders •  XML security gateways [Layer7]

• Keep communication layers separated • Define and design “generic authentication and authorization”

– Independent from specific implementations of means of authentication – Creating flexibility for changes in the future

Federated SOA Security © CSC 2010

Offload Core System

XML validation

& Token

handling

Switchpoint

SSL handling

Out

side

wor

ld

Autori-zation

& Consent

Core Business Logic

Generic authentication and autorization

Federated SOA Security © CSC 2010

Keep communication layers separated

SSL

Physical Layer

Data Layer

Network Layer (IP)

Transport Layer (TCP)

Session Layer

Presentation Layer

Application

OSI model

SOAP/XML

HL7v3

Federated SOA Security © CSC 2010

Keep communication layers separated

XML validation

& Token

handling

SSL handling

Autori-zation

& Consent

Core Business Logic

SSL XML validation

HL7 wrappers HL7

content

Federated SOA Security © CSC 2010

Generic authentication & authorization

XML validation

& Token

handling

SSL handling

Autori-zation

& Consent

Core Business Logic

Generic authentication & authorization

Federated SOA Security © CSC 2010

1.  Develop “generic components” for authentication and authorization. This results in flexibility and better maintainability

2.  “Offload” specific tasks, like handling SSL connections, verifying XML structures and handling tokens to dedicated components. This results in scalability

3.  Use “Commercial Of The Shelf” products for specific tasks. Invest in learning to know and appreciate these components: they are part of your system

4.  It is good practice to put “security” on every layer in your system. However, also put “security” on the relationship between those layers.

7. Experiences and lessons learned