The XDS factor
- 18 October 2007
It is widely recognised that the current medical records system, using paper for medical records, has limitations, and that an electronic system could lead to better patient care. This has been achieved for certain clinical areas such as GP systems, laboratory results and radiological reports. Connecting for Health hopes to add medical summaries to the list in the next few years, but little real-life progress has been made in wider clinical practice, largely due to lack of agreement on how such clinical data should be stored and transmitted.
IHE Cross Enterprise Document Sharing (XDS) attempts to overcome these implementation problems and differs from previous approaches by making a logical separation between the indexing information (the meta-data) and the actual content. This allows XDS to support a wide range of documents, yet still have a simple and consistent method to store, index, locate and retrieve them for clinical use. The separation greatly simplifies the addition of an XDS export function to existing systems, allowing them to use existing output formats such as CDA, PDF and even simple text documents, as well as DICOM and JPEG Images. XDS deliberately allows the use of unstructured formats in order to allow systems to become clinically useful as soon as possible, whilst not precluding an easy progression to more structured data in the future.
XDS has been defined by Integrating the Healthcare Enterprise (IHE), a not-for-profit international organisation, which publishes technical specifications, and organises annual test sessions called “connectathons” where vendors show that their systems can properly communicate and interoperate with at least three other vendors’ systems. XDS uses existing ‘open’ IT standards (http and ebXML – an OASIS and ISO standard) to share stored electronic documents, and therefore to enable development of wide-area electronic healthcare records. XDS helps to address the interoperability problems inherent in sharing electronic healthcare records between different IT systems and is rapidly being adopted around the world with ongoing national programs in Austria, Italy, USA, Canada, France and also several regional projects.
There are four main components to an XDS system, as shown in the diagram below:
Document Source:
This is the system which publishes the clinical document. It only needs to produce the document itself and the meta-data, then push them to a repository. Unless it needs to update the data it has sent, it has no further part to play in the overall system, making this role easy to implement.
Document Repository:
There can be multiple repositories, and these are where the documents themselves are stored.
The repository passes only the meta-data on to the registry, together with a pointer to where it has stored the document.
Document Registry:
There is normally only a single logical registry for an XDS project, though of course it can be duplicated to provide resilience. This is where all the meta-data is indexed, and the searching functionality is provided. It is possible for registries to be linked together to provide cross-project or international integration.
Document Consumer:
This is a user system, which could be either a web-browser, an interface to an existing system or a specialist system. It directs queries to the registry, for example to locate records of a particular type for a particular patient, and it can then retrieve the original documents from the repositories.
The repositories and registry use only standard web services and as they use ebXML, this enables use of standard off-the-shelf (or even open source) solutions. As far as the registry and repositories are concerned, the documents themselves are simply blobs of data – any interpretation only happens in the consumer. All transactions happen over http, or more usefully in a clinical scenario, https, giving secure communications.
An important difference between XDS and many other systems is that the data storage is inherently decentralised, with the documents themselves held in multiple “repositories”, and where these coincide with organisational units such as health authorities or hospitals, this can help to address some security and data ownership issues.
The basic XDS model has been extended to support specific types of document including XDS-I for DICOM Images, XDS-MS for HL7 CDA Medical Summaries, and XDS-Lab for structured laboratory reports, but it is important to realise that these specific profiles all share exactly the same central indexing and storage mechanisms, differing only in the constraints placed on the stored document, in order to improve its usefulness for specific functions.
The only significant extension to the main XDS model is XDS-I for imaging, which was developed for the Canada Health InfoWay project. This avoids the costs of duplicating terabytes of PACS data, by defining a mechanism for the “document” stored in the repository to be simply a list of DICOM objects (it is itself a small DICOM “key object selection document”), allowing the document consumer to retrieve those (again using http/https) from the original PACS.
XDS was only defined about four years ago, but has been embraced enthusiastically by developers because of its simplicity as shown by the fact that 69 companies and other groups have successfully tested XDS compliant systems at connectathons, and are starting to offer them commercially around the world. The XDS-I version has been particularly successful, with nine of the major imaging vendors (including most of those active in the UK) demonstrating their practical support for it at the major US radiology meeting, the RSNA, last year, with another similar demonstration happening again next month. The IHE-UK committee has plans to organise demonstrations at Healthcare Computing and UKRC next year, giving UK vendors the chance to participate in this exciting new model for electronic healthcare records.
For more information on IHE in general, see www.ihe.net.
For slide-sets going into more detail on XDS, see:
http://www.ihe.net/Presentations/IHE_2005_Webinars.cfm
http://www.ihe.net/Participation/upload/iti6_ihewkshp07_xds_majurski.pdf
