Monday, April 6, 2015

XDS Implementation Issues part 4

The previous three parts discussed how the IHE Cross Enterprise Document Sharing (XDS) profile
fits into the IHE technical framework, its relationship with other ITI profiles that are needed to provide the infrastructure to make XDS work, and its “variations” including XDR, XDM, XCA, XCPD and their imaging implementations. In this part we are going to concentrate on the metadata and corresponding issues. Also note that there is an extended version in video format available of this presentation.

Metadata literally means “data about data.” For example, one could consider a “DICOM header” metadata as it has information about the image or other object, its context information such as patient and equipment information, and instructions on how to decode the pixel or other data such as the greyscale or color encoding. In addition, we also have a metadata definition as part of the DICOM standard that describes a DICOM object when it is stored on a CD or other exchange media, aka “Group 0002,” which tells a receiver about the file encoding such as whether it is compressed, the type of object, e.g. a CT image, and who created the file.

The metadata that is stored with each DICOM object has served us well in managing the information at a department level as certain attributes, such as name, ID, sex, accession number, modality, and UID’s, are used to identify the object uniquely and relate it to its series and study. It is typically stored in a database allowing for querying and information management. However, this metadata is not sufficient if we need to manage these objects across multiple domains and/or communities. For example, the accession number is only unique at a local level, and important to be kept, but cannot be used to uniquely identify the study. In addition, it is important to know which specialty created the study, for example, was a CT scan created in radiology, or was it a cardiac CT created in cardiology, or was it a CT taken in oncology to create a therapy simulation? Information about the institution where the document or image was created with the so-called author role and name is important as well.

Why do we need additional metadata? It is important for pre-fetching and display, i.e. browsing a document source database so a practitioner can determine what information to retrieve. Pre-fetching the relevant prior studies based on body part, modality, time of creation, etc, is important, as the information might have to be retrieved from various sources, which are connected with a relatively slow connection. Matching the body part, for example, can be especially hard not only because every vendor uses an encoded attribute such as defined by the usual coding schemes, but also because of “combo” procedures, such as an “abdomen-pelvis” CT. It is critical that the metadata that is part of the header is consistent and normalized, if so needed before any data is stored in a data repository. Some vendors call this normalization “tag morphing” as it cleans up the data and replaces it with consistent terms and/or codes so that proper pre-fetching and browsing can take place. Some of the metadata in the DICOM header is not always correct, and therefore, most data repositories also use the original order information for the procedure information, which is typically available as a HL7 transaction.

In addition to metadata consistency, the actual contents of the metadata file, which by the way is exchanged as part of the XDS protocol, is still not quite cast in stone. Early implementations find that additional or other data elements are needed in addition to the ones that are part of the original XDS specification. The reason is that information sharing across enterprises is still relatively new and different workflows depend heavily on the practice settings, regions and healthcare systems that are very different for each country. That is why most vendors who provide XDS solutions are still in the process of adding and configuring the metadata contents depending on the specific user requirements.

In summary, XDS has been widely implemented and early results for connectivity events such as connectathons have demonstrated that it can work in theory. However, the number of installations using these profiles, including the several variations (XDR, XDM, XCA and XCPD) have been limited. The reason is the lack of infrastructure to make XDS work, the presence of many proprietary solutions for information exchange, the fact that the metadata still needs refinement, and a lack of education among customers and potential users. Hopefully, this will change as the early adopters of this technology begin to share their success stories.


2 comments:

  1. Thank you for sharing your experience.
    I have saved a lot of time having used your article as a manual for troubleshooting the project connected with virtual data rooms. More information on virtual data room reviews.

    ReplyDelete
  2. Due to the diversity of cloud types and service models, maintaining cloud security is therefore an extremely broad task that demands a similarly large toolkit and range of disciplines.
    virtual data rooms review

    ReplyDelete