|
YES ... Sign me up for the ebXML Forum Newsletter
Email Address:
ebXML Forum does NOT send unsolicitied e-mail.
More ebXML Forum
|
ebXML Registry Specified for Integrated Health Care Framework
Integrating the Healthcare Enterprise (IHE), a health care consortium that aims to get relevant and accurate information for patient care into the hands of practitioners at the right time for making medical decisions, released its draft specifications for document sharing, and the core of the mechanism is the ebXML registry. When implemented, the IHE specifications, including ebXML registries, will affect our day-to-day health care experiences.
Health care presents one of the most difficult challenges for information technology, yet it also offers some of the best opportunities for improving the work of health care practitioners, which affects just about everyone as consumers of health care services. Among the most pressing challenges faced by the industry is the need to get all of the relevant and accurate information needed for patient care into the hands of practitioners at the right time for making medical decisions. This is the objective of Integrating the Healthcare Enterprise (IHE), an initiative that encourages the integration of systems in health care institutions.
IHE is a technical consortium under the Healthcare Information and Management Systems Society that is building a technical framework to encourage the integration of health care systems. Rather than creating new standards to define this framework, the group relies on existing standards, one of them being ebXML On 17 June 2004, IHE issued for public comment four draft technical supplements to its Infrastructure Technical Framework, with one devoted to Cross-Enterprise Clinical Documents Sharing, or XDS. The XDS document specifies the ebXML registry (version 2.0) as a key part of its proposed solution.
Access and process patient records from multiple sources
Integration of medical data is no small concern. Patients can visit any number of health care facilities (e.g. a company or school clinic, HMO-specific clinic, hospital emergency room) even over a short period of time, and for any of these enterprises to provide quality care, they need to access and and process the data from all patient records. As the IHE document notes, “Without commonly accepted mechanisms for accessing these repositories, it becomes difficult, if not impossible, to share documents from separate care delivery systems across a collection of cooperating enterprises.”
XDS offers a common mechanism for the sharing of medical documents for patients within a community of care – defined as a set of enterprises that agree to collaborate on patient care and record sharing -- over time. That mechanism consists of document repositories and registries, and borrowing from the ebXML concepts, XDS makes a distinction between the repository and registry ideas. According to the specifications, the repository provides transparent and persistent document storage, to respond to document retrieval requests. The registry, on the other hand, has information about the document - metadata - so health care professionals can find, select, and retrieve the documents, no matter where those documents may be stored.
XDS uses the profile methodology that identifies and describes a subset of available working standards, and levies stiff requirements on the components making up that profile. IHE envisions supporting many collections of cooperating enterprises: local or national networks of health care providers, specialized or disease-oriented (e.g. cardiology, oncology) providers, government-sponsored (e.g., VA, military) health programs, and insurance-provided communities. The IHE integration profiles identify a set of actors in the enterprise and specifies their interactions. These interactions are defined as standards-based transactions that address specific clinical needs. The registry and repository are the core technologies in these transactions.
Because of multiple health care record standards in practice today, XDS needs to accommodate all of the current formats and probably others not yet defined. The XDS specification requires the repository/registry mechanism to be content-neutral and support any type of document format, including plain text, formatted text, images, structured code, or vocabulary-coded clinical data. Documents can be either machine or human readable, and for now defined by the HL7 Clinical Document Architecture and CEN Electronic Healthcare Record standards.
The actors defined by the XDS specification include:
- Document source - The producer and publisher of health care documents, responsible for putting the document in the repository and supplying the metadata for the registry
- Document consumer - Queries the registry for documents meeting specified criteria and retrieves documents from one or more repositories
- Document registry - Maintains the metadata about each registered document, provides links to repositories that store the documents, responds to queries from document consumers searching for documents, and enforces health care technical policies ensuring validity of the metadata at the time of registration.
- Document repository - Provides persistent storage for the document, and assigns and maintains a unique identifier for each document to enable its retrieval by a document consumer
- Patient identity source - Assigns a unique identifier for each patient instance and maintains a collection of traits for identification.
Health care and ebXML: made for each other
The health care community has made increasing use of ebXML standards, due in large part to ebXML's design that meets the demanding requirements of the health care industry. The Shareable Active Guideline Environment (SAGE) project that creates a standards-based infrastructure for machine-readable clinical guidelines uses an ebXML registry for indexing and retrieval of those guidelines.
In 2003, the U.S. Centers for Disease Control and Prevention adopted ebXML messaging and collaboration protocol agreements (CPAs) for its Public Health Information Network. In April 2004, as reported here in ebXML Forum, HL7 released its transport standards that include support for ebXML messaging. And discussed earlier here as well, at the XML 2003 conference, six vendors demonstrated a combination of ebXML specifications applied to public health scenarios: BPSS, messaging, and registry.
|
These actors define roles in the transactions. Physicians, medical labs, clinics, or hospitals can be either document sources or consumers, depending on their roles in the transactions. XDS then defines the transactions that provide the documents to a repository, register those documents in a registry, query the registry for documents, and retrieve documents from the repositories. A separate profile describes the feeding of patient identifiers and corroboration of demographic data.
Patient identity data are of course extremely important to the entire operation and the specification goes into considerable detail in order to reliably associate health care documents to the appropriate individual. However, the registry is designed to support health care documents, not patient demographics or identities. The document source actor has the responsibility of associating the appropriate patient identifiers with the documents.
|
Short-term and long-term scenarios
The specification provides two scenarios that show the value and robustness of XDS. One scenario outlines a three-week cardiac care episode for a patient with initial complaints of shortness of breath, nausea, tiredness and chest pains. The patient reports these symptoms to her primary care provider (PCP) who works with a hospital that is part of a local cardiac care network. This network includes PCPs, cardiologists, medical labs, and local hospitals that share clinical documents.
In this scenario, the patient visits the PCP who schedules the patient for tests and a follow-up visit with a cardiologist. Each of these encounters results in a new document placed in the appropriate repository and indexed in the cardiac care network's registry. But before completing the tests and cardiologist consultation, the patient experiences even more severe chest pains and she visits the emergency room of her local hospital. The ER physician consults with the cardiologist who queries the network's registry to get the latest test results and prescribes a set of interventions requiring inpatient care at the hospital. Each of the interventions results in more documents, again placed in the hospital's repository and registered with the cardiac care network. Following discharge from the hospital, the patient's follow-up rehabilitation records and visits with the cardiologist are likewise registered.
The second scenario describes interactions of a patient over her adult lifetime with a community of care network. This community network includes a university hospital, country hospital, PCPs, specialists (like the cardiologist from the previous scenario), drugstores, medical labs, and physical therapists. The scenario covers 30 years of patient care including a pregnancy, cancer treatment, and a cardiac problem.
Each of these episodes, like the cardiac care scenario above, results in a series of separate documents, but the documents are organized into folders, with one folder for each episode. Folders provide a way of organizing related health care documents. The health care providers define and determine the contents of these folders. The sharing of these documents and folders enables the different providers to contribute to a patient's electronic health care record over time, what the specification calls the patient's longitudinal health record.
The XDS document is available for public comment through 15 July 2004.
|