Terry Paddy - RostersEtc Limited
An initial and brief look at the question of accessing and distributing medical records has lead us to look at the following specific areas.
We have read the ISO draft technical report and appreciate that the main concern is the concept of the model whereas, as a technical organisation, we are discussing concepts surrounding the implementation of a particular solution.
We have done no analysis of the medical sector, or do we have any specific medical knowledge, therefore our interpretation of the interaction of segments of the medical industry may not be technically accurate, but indicates our conceptual picture.
As we consider that the techniques we have developed using XML, SOAP, encryption etc are significant intellectual property items; we have not indicated their implementation as deeply as we normally would in a commercial relationship.
In discussing a medical environment, the following diagram indicates our understanding of the problem domain (area of interest).
The system, broadly described in this document, retrieves all "allowable" known medical data on a patient by accessing health records across a wide range of medical entities (GPs, hospitals, etc).
It is based on the premise that centralised record keeping is not an option, and that security and privacy is paramount. We have assumed that all participating medical entities are accessible via the Internet.
This is a technical concept document, the specific scenarios listed below should be seen as generic ideas and not as placing any limit on the application.
Scenario 1
A GP requires information on the full medical history of a new patient.
The GP logs into the EHR (Electronic Health Records) system at his desk terminal using a purpose-built software application. Strong Authentication (described below) is used to confirm his identity. The GP types the name/identification of the patient and initiates the sending of a "discovery" message to all other medical entities.
The XML appliance in the GP's practice carries out the following tasks:
The XML appliances at the other medical entities receive the discovery message and carry out the following tasks:
The originating GP receives, on the purpose-built application on his desktop, a list of all HES (Health Event Summery) messages available to his attribute level. The GP can then select the event(s) required, which may include references to X-rays or other external data.
Scenario 2
Resulting from a discovery message, or because the medical entity knows the specific information it requires, a request message is sent to a specific location asking for a specific record, using the same encryption/authentication technique described in scenario 1, resulting in actual XML-formatted medical data being returned to the requestor in an encrypted envelope.
Scenario 3
An external medical entity, with approved access, requests information on a patient. The request comes in the XML data format of the originating country. All external entities access the New Zealand environment via a specific XML appliance acting as a gateway into the local EHR network. The XML appliance carries out the following tasks:
Information is returned to the external medical entity in the reverse of the process listed above, including the application of a stylesheet to convert the message body into the XML format of the receiving country.
As has already been outlined, all medical data should move in an XML-based format. Many organisations worldwide are developing "schemas" or "Data Type Definitions" (DTDs) that describe medical information.
The advantage of XML is that, with the application of a "stylesheet", XML in one layout/format can be seamlessly transformed into another format. XML and XSL (stylesheet language) are open standards of the W3C (World Wide Web Consortium) and are not proprietary in any way. This application of XML data is being widely introduced in the e-commerce environment and will work very well in the medical environment.
A nation or culture can decide on the definition that they want to use (maybe a combination of many other "standards"), and if the information is required by another external organisation, the data can be transformed effortlessly. Conversely, New Zealand organisations requesting information from an international organisation could automatically transform the data to the local format as it arrives. The only requirement for this to occur is the public availability of schemas or DTDs from all participating organisations.
Similar transformations occur internally. A schema describes every HES, and that schema is applied to the data to ensure correctly formatted data is sent to the requestor. This could implement some of the security requirements, as a radiologists HES schema could be different from a specialists or a GPs.
The Internet is chosen as the method of communication and HTTP as the delivery protocol because of the widespread availably and scalability of those services. The addition of medical entities, from a one-doctor practice to an entire hospital, is not complex.
Our model envisages the use of a server appliance that connects the medical entity to the Internet externally and to the "in-house" local area network and data stores. The server appliance at the GP end would be a normal computer at a cost of a few thousand dollars whereas the appliance at a large centre may need to be a high-performance machine costing tens of thousands; however, the functionality, level of security and software is the same, just on a different scale.
The XML appliance would carry out the following functions:
All software elements (except one, described below) reside on the XML appliance, which makes it fully self-contained, and therefore easy to install and maintain. A small desktop application would exist on any computer requiring access to the access and transfer system. Strong authentication of the user could be established with a 'smartcard' containing the user's certificate or a biometric reader such as a thumbprint scanner. Smartcards can be handed to others, lost or stolen; thumbprints cannot. Thumbprint scanners are becoming more common and cost in the region of NZ$200, a very cost-effective solution.
We assume that there are several standard "practice management" software packages currently in use by GPs and others. Software on the XML appliance would link to those packages, allowing seamless extraction and insertion of data.
All security would be based on Public Key Infrastructure (PKI) and strong encryption based on the emerging US Government's implementation of its Advanced Encryption Standard (AES). All message would be encrypted and have certificates/signatures attached.
A central medical authority would act as (or outsource) the Certifying Authority (CA) issuing and revoking certificates and attributes.
To ensure secure communication channels, the Secure Socket Layer (SSL) protocol would be used to transport the encrypted messages so that no message could be "intercepted" or "faked". SSL is the most common security mechanism for e-commerce.
Only information that is allowed to be released, based on the requestors' attributes, would be transmitted.
The system briefly outlined above is a peer-to-peer messaging system utilising currently available software implementations of XML, XSL and SOAP standards. These standards are open and can be extended or developed by any competent organisation with expertise in this area.
RostersEtc Limited creates the type of low-cost XML appliance described in this document and can assemble a prototype or demonstration network to display the above techniques. We also create, and define XML Schemas and DTDs.
The low cost of this system arises from the use of existing infrastructure such as the Internet, Telecom's "ADSL" product (or equivalent) and the use of commercially available open-source standards currently in wide use in e-commerce.