Technical description of the solution

A detailed technical description of the solution which is currently being used in the pilot project appears below. This section has been written primarily for people with a professional IT background.
To obtain access to PasientLink, the user connects to a service which is placed in the outer zone of the health network - the "demilitarized zone" (DMZ). This is achieved using an ordinary browser and an encrypted connection. The communication between the demilitarized zone and the secured zone takes place as follows: A service (EnvelopeServer) in the secured zone sends data to an associated service in the demilitarized zone (EnvelopeProxy). This is done only after users have been authenticated, and only the information which the user has requested and has the right to see can be sent. No data is stored permanently in the demilitarized zone, and data is held in the memory of computers here only for the period during which the user is logged in. Permanently saved data in the secured zone is also encrypted, and can only be decrypted in the demilitarized zone.

Messages to the health professionals are sent from EnvelopeServer in S/MIME-format to the e-mail server. The messages to the GP practice are encrypted in accordance with the CEN TC/251 Env-13608 standard, and the message content is an XML Schema document. In principle, any e-mail client which supports S/MIME can read the documents, but the pilot uses Well Communicator software to facilitate integration with the patient record.

SOAP (Simple Object Access Protocol) has been used to a great extent for communication between the modules. We have used Apache's SOAP implementation. Java is primarily used as the programming language. We have emphasized open standards for messaging, and the use of software which is already available at the GP practice.

Authentication of users uses SMSAuthenticator, which is a module for two-phase authentication. The patient logs on through a browser with a user name and password. A one-time code will then be sent to their personal mobile telephone. The patient keys in this code during the next phase of the log-on. The wide distribution of mobile telephones makes this a cost-effective solution. SMSAuthenticator is available as open source code. No decision has yet been made on licensing of other parts of the system.

Click the picture to see a larger version:

Arkitekturskisse PasientLink

Encryption and signature of messages
Encryption of messages uses techninques and technologies described in the European standard Env-13608 for secure data objects and secure data channels in healthcare communication . This involves packaging the messages using S/MIME CMS (Cryptographic Message Service). The algorithms used are 3DES for encryption of the content of the message and RSA for the exchange of keys. SHA-1 with RSA is used for signatures.

We use an S/MIME implementation from "Legion of the Bouncy Castle", which also implements the provider interfaces in JCE (Java Cryptography Extension). Messages sent from the patient are packaged using S/MIME and encrypted by EnvelopeProxy. The encryption uses both EnvelopeProxy and the public keys of the recipient (known within the system as the "provider"), so that the message can be read both by the recipient and by the patient. No signature takes place here. When the message is later forwarded from EnvelopeServer to the e-mail server, the message - which has already been encrypted - is signed using EnvelopeServer's private key. The S/MIME-packaged, signed and encrypted message is sent as an attachment to an e-mail message. EnvelopeServer adds a separate attachment, which includes an XML document with information about what is being sent. This document is also packaged using S/MIME. It is encrypted with the recipient's public key and signed with EnvelopeServer's private key.

Incoming messages retrieved by the EnvelopeServer from the e-mail server (using the POP protocol) are inspected to check that they have been signed by the provider. If so, they are saved in the database. The message to the patient is encrypted for EnvelopeProxy and cannot be read here. The e-mail message also includes an attachment containing an XML document with header information, which must be encrypted for EnvelopeServer and signed by the provider as a condition for acceptance of the message.

All HTTP traffic in PasientLink is through SSL with 128-bit encryption. This applies to traffic between the Web server and the patient's browser as well as to all SOAP traffic between different computers.

The Web server
An Apache Web server runs on the outermost computer in the PasientLink system, the Web server. A Java-based Web application runs here as well. The Apache server and the Web application run in separate chroot environments.

Apache handles static files and implements transport encryption of all traffic using SSL/TLS. The Web application implements the Web interface with respect to the patient's browser and handles the communication with EnvelopeProxy through a SOAP interface. The Web application marshals and unmarshals messages, that is, it performs the mapping between XML schemas and Java objects. Unencrypted XML messages are sent and received through EnvelopeProxy, where encryption/decryption takes place. While a patient is logged in, some of the patient's messages will be held in volatile memory (RAM) on the Web server. These unencrypted messages are stored only in memory on the Web server, never on the disk (with a potential exception for swapping). Between the Web server and the patient's browser, the messages will be encrypted because the HTTP traffic is over SSL.

The Web application has been developed using Java and Apache Velocity. For mapping messages between XML Schema and Java objects, Castor XML is used.

EnvelopeProxy
All enquiries to the service from outside the system and the replies to these enquiries are sent to EnvelopeProxy. Both the Web application and EnvelopeServer access EnvelopeProxy as a SOAP Web service. EnvelopeProxy receives enquiries (called "service requests" within the system) from the Web application. These join a FIFO queue, from which EnvelopeServer retrieves and processes them. Encryption and decryption of messages takes place in EnvelopeProxy; the Web application sends and receives unencrypted XML messages. Decryption of all messages uses EnvelopeProxy's private key. The key is stored in EnvelopeProxy. At start-up, the passphrase for the key must be entered.

Methods that are available for the Web application through the SOAP interface:

Method name Description
requestAuthentication First phase of the authentication. The user name and password are arguments to the method.
authenticateSession Second phase of the authentication. If the one-time password was approved and EnvelopeServer created a new session, the method returns a String value which includes the session identifier. This session identifier must be specified in all subsequent method calls, and is used by EnvelopeServer to identify the session/user.
getNumberOfEnvelopes Number of messages of a given type which exist for the patient.
sendEnvelope Sends a new message from the patient to the service.
getEnvelopes Retrieves a subset of the messages which belong to the patient.
deleteEnvelope Deletes a message which belongs to the patient.
changePassword Changes the password for the patient.
disconnectSession Logs out from the service.

The authentication service
SMSAuthenticator is used for authentication of users. EnvelopeServer accesses SMSAuthenticator as a SOAP Web service.

SMSAuthenticator implements a two-phase authentication process. In the first phase, the authentication service receives a request for authentication of a particular user, in the form of the user identity and password hash. If the user name and password hash are correct, a single-use password is generated and sent as a GSM SMS message to a GSM telephone registered for the user. The single-use password has a configurable time-out (5 minutes in this case).

In the second part of the authentication process, the authentication service receives an enquiry which includes the user identity and a hash of the single-use password. If the hash of the single-use password corresponds to the transmitted single-use password, the user is authenticated; that is, the SOAP call returns a Boolean "true" value.

The single-use passwords are generated using a pseudo-random-number generator (SHA1PRNG algorithm). Single-use passwords are stored only in memory, and for a limited period. As soon as an authentication request has been processed, the single-use password is deleted.

The following methods in SMSAuthenticator are available for EnvelopeServer:

Method name Description
requestAuthentication First phase in the authentication. The user name and hash of the password are arguments to the method.
authenticate Second phase in the authentication. The user name and single-use password are arguments to the method.
changePassword Change the password for the user.
sendNotification Sends an SMS message to the user. The message itself is entered as an argument to the method.
SMSAuthenticator is available as open source code.

EnvelopeServer
EnvelopeServer processes enquiries from outside parties to the service by communicating with EnvelopeProxy through a SOAP interface. EnvelopeServer communicates further with the authentication server through its SOAP interface, for example in handling requests to log on or change passwords. The PollProxyThread class implements functionality to retrieve service requests from EnvelopeProxy and process them. See the description of EnvelopeProxy for an overview of the various types of requests which are handled by EnvelopeServer. This thread manages the transport of messages between EnvelopeProxy and the database. PollProxyThread instances run as separate threads, and a pool of such threads is available so that multiple requests can be processed in parallel, depending on the load.

EnvelopeServer maintains the permanent store for messages that pass through the service. A separate class includes all methods for interaction with the store, currently a PostgreSQL database. A separate thread (MailBoxThread) transports messages between the database and the e-mail server. It checks whether there are messages in the database which have not yet been sent to the provider. If so, it sends them to the e-mail server (SMTP protocol). If there are new messages to patients on the e-mail server (POP3 protocol), the messages are added to the database. At the same time, an SMS notification is sent to the patient by calling a method available in the SOAP interface with the authentication server.

When messages to patients are received, a confirmation of the transport acknowledgements are sent in return. In the same way, EnvelopeServer receives confirmation of messages that are sent to the provider. Both sent and received confirmations are stored in the database. All messages which are sent and received are encrypted - see the section on encryption for more information about this.


<<
icon tip a friend E-mail this