Information Technology Reference
In-Depth Information
client, the patient's personal data is removed from these files. This anonymization
decreases the level of security measures to be implemented by the service provider
both in the server and in the host building, to comply with the European regulations
on health data protection, because the patient's identity is never known outside the
hospital premises. The web client communicates with a web portal which translates
the request in a suitable message to call the second layer: a set of web services.
These services expose the main functionality of the platform. There are specific
services for the different supported operations such as user data management, file
management, or process request. These are the unique ways to access the stored
information and to control the status of the requests. In the last layer, the back-end
stores the information about each user, the treatment plan and manages the execu-
tion of the different processes. Alternatively to the web client, the hospital can call
directly to the web services (but in this case it will be responsible for removing
the patient's personal data from the files) from its own application, although this
method has not been used yet.
There are three kinds of users in the platform: the main administrator who works
for the service provider and manages the platform; the hospital leader, who admin-
isters the information needed about the hospital facilities, as the model and param-
eters of the Linacs or the tomographs; and the final users, mainly medical physicists,
who demand the main services. No other user type is provided by the platform, so
the patients and doctors are not expected to use it.
To leverage the security of the platform, two components were added, inte-
grated, and validated during the Business Experiment (represented as WS-Security
gateway in fig. 9.1). The first one is a Policy Enforcement Point (PEP). It is an
XML security gateway which securely exposes services by checking and validating
service requests. All requests are checked against a security policy to ensure they
are legitimate. To do so, the PEP may require additional security services such as
an identity broker or an authorization service. In particular, in this scenario, the PEP
delegates access control requests to an authorization service: the Policy Decision
Point. The PEP can also perform other tasks, such as checking them for XML
threats and validating them against the service interface definition. In particular, it
has the ability to encrypt/decrypt and sign/check the signature of the communica-
tion thus ensuring privacy, integrity and confidentiality. The PEP used is a commer-
cial product: Vordel's XML Gateway. The second component is the Policy Decision
Point or PDP. It is an authorization service based on the XACML standard for repre-
senting and evaluating access control policies and requests, returning its decision to
the requestor. The response can be either PERMIT, DENY, NOT APPLICABLE, or
INDETERMINATE. Access control policies can be more or less fine-grained, are
defined by the administrator and can deal about who is permitted to do what and
when. E-IMRT used Axiomatics's Policy Server to implement PDP.
