Monday, February 1, 2010

XDS, Solving the Health Record Puzzle

The Cross-enterprise Document Sharing (XDS) profile as defined by the Integrating the Healthcare Enterprise (IHE) is key to interoperability among various healthcare enterprises wishing to share healthcare information. This profile and its cousin, the XDS-I (for imaging) profile, allows for the exchange of clinical records, including images, among healthcare delivery organizations. The important components of these profiles are a repository and registry for the documents. Standard transactions defined by ebXML, SOAP, HTTP, SMTP--and in the case of image exchange, the DICOM WADO protocol--are used to exchange information. 

A common misconception is that to enable information exchange, one needs to have a central data repository. This is incorrect; instead, the registry has a critical role in providing an index of all the clinical documentation, which can be stored locally and/or centrally. 

Typical documents for this profile are electronic health records (EHRs), which contain a longitudinal record of healthcare information, in the form of the CDA and CCR, but also simple text documents and/or PDF files. To make documents available, a document and/or image source will register its information with a central registry, so that a document consumer can retrieve them after it queries the registry for the location. 

Some organizations might opt to also have a central repository, for example, a government-run healthcare system such as in a Canadian Province, or a large healthcare provider such as Kaiser Permanente in the U.S. Whether or not the information is centrally stored or distributed is irrelevant. 

Because of multiple transactions, one single standard cannot address sharing. Registry services are executed using ebXML, which includes the Registry Information model, services and protocols. The protocol for communicating among registries and repositories is SOAP, using standard SQL queries. 

The first part of this exchange is the document source, i.e. the location where the care is provided, such as an ER in a local hospital. This source could submit its information to a repository or keep it locally. The repository will register the information with a central registry. The document consumer, which could be a primary care physician, or any other healthcare provider, will query for the documents with the registry, and then can retrieve the information from the repository. 

Unfortunately, in the U.S. there is no universal patient identification, such as is present in other countries, in which case a Patient identity source actor is needed to identify the patient. A patient has a local identifier that is related to their global identifier. In the case that the consumer knows the global identifier, it can query the registry directly; if not, the registry will have to access it to determine its global identifier. 

The documents which are exchanged must be human and/or application readable. In the first case, it could be a text file, in the second case a PDF reader or DICOM viewer might be used. A MIME type (e.g. "PDF" or “DCM”) has to be provided to the document repository. 

The document source is responsible for managing the document submitted, i.e. approve, or, if applicable, deprecate it if it becomes obsolete or even delete it. A critical task is managing addendums, which are not uncommon; for example, if a staff radiologist wants to correct a finding of a resident or even replacing it with a later, more up-to-date finding. The source can also submit sets of documents and/or folders containing multiple documents. 

A registry does more than just indexing the submitted information; it identifies document sources, consumers and repositories and assigns patient identity domains. It also establishes document sharing policies and security and privacy policies, i.e. who can query for what information. It issues node certificates to allow for secure communications. 

XDS and XDS-I are not just paper specifications; many manufacturers have implemented it, tested it at the IHE Connectathon, and are incorporating it into their products. Toolkits to implement the transactions are becoming available and the National Institute of Standards and Technology (NIST) has been instrumental in providing a test bed to validate XDS transactions. 

As EHR's continue to be implemented, XDS and XDS-I provides the key to integrate multiple organizations and allow for the access of vital health information to multiple practitioners and organizations.

No comments:

Post a Comment