In early January, approximately 500 software engineers gathered in Chicago to test the interoperability of their health IT and diagnostic imaging applications at the 11th annual Integrating the Healthcare Enterprise (IHE) Connectathon. The first Connectathon featured one integration profile that was tested among 47 applications from 23 vendors. The 2010 event saw 104 vendors testing the interoperability of 150 unique systems. Literally tens of thousands of transactions were executed among these software tools.
The Connectathon represents a multi-million dollar investment by industry, given the scope of development required to code to IHE profiles and successfully integrate applications across a healthcare enterprise. Despite the cost, the fruits of their labor will result in significant cost savings to the participants.
In the neutral ground of the Connectathon, the varying interpretations of IHE profiles can be hammered out by software engineers and volunteer monitors, eliminating potential problems before a system or application reaches a user site.
I monitored a group-case test that provides an excellent example of Connectathon achievement. In the scenario, four different sources of patient information were exchanged: A text report; PDF document; a Personal Health Record (PHR); and a document encoded using the HL7 version 3 CDA standard. This scenario required interactions among different vendors to retrieve a global patient identifier, submit the information to a repository, update a registry and then retrieve the information by a data consumer—which was represented by yet another vendor.
The test took us only two hours of walking back and forth among the different vendor's tables where their development staff had setup simulators to run their applications. In a real-world environment, this task would probably have taken days—if not weeks—bringing together vendor staff from locations as disparate as Austria and Taiwan. And, inevitably, many hours would be wasted finger pointing and blame making before a solution could be devised.
Of note was a decided shift among the vendor participants this year. In the early days of the Connectathon, the focus was mainly on PACS interoperability. The start of this decade saw nearly three quarters of the profile testing among implementations of electronic health records (EHRs) and device applications such as EKG and heart monitoring systems.
As a volunteer monitor, I was encouraged by the expertise and enthusiasm among the Connectathon participants. The event effectively demonstrates that there is no reason for the two hospitals in my town of Denton, Texas, to not share lab results, x-rays, and other pertinent information. Once they resolve to do so, along with the rest of healthcare, unnecessary duplicate tests can be avoided and negative interactions between drugs and treatment can be prevented.
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.
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.
Subscribe to:
Posts (Atom)