By Tim Kaschinske
In my last blog in this six-part series focusing on how healthcare organizations are dealing with unprecedented volumes of unstructured data, I talked about solutions within the market, one of which is the Independent Clinical Archive. In November, BridgeHead announced HealthStore™, the first Independent Clinical Archive (ICA) for long-term storage, protection and sharing of hospital data. So what is HealthStore? And what makes it an Independent Clinical Archive?
First, HealthStore is a clinical archive from the perspective that it supports the standards widely used in healthcare to distribute clinical data, such as DICOM, HL7 and XDS. As a result, other clinical applications can send and receive clinical data to and from HealthStore as a long term archive for that clinical data. Further, by supporting all of these standards, it is not limited to a single type of clinical data, but can archive any type of clinical data in its native format.
HealthStore is an independent archive in that it separates the data from the application that created it, and from the storage on which it sits. The benefits of this include:
- Significant cost savings in terms of data migration, both when replacing applications and physical storage:
- Data separation from the application provides access to the data even after the application has been retired;
- Data separation from the storage allows data to exist on multiple storage platforms for protection, and to migrate the data to new storage platforms when available.
- Continuous access to data even if the primary application is unavailable (either planned or unplanned);
- The ability to search the archive for ALL data based on content;
- The ability for the archive to present the data in a standards-based format to any presentation layer that you want to deploy; whether that be an EPR application, a clinical portal, or a specialized clinical viewer.
BridgeHead’s HealthStore Independent Clinical Archive
BridgeHead HealthStore is designed as a modular solution that provides:
- Tools to ingest data into the archive;
- Core services to manage the data once it has been ingested;
- Data storage management to virtualize access to different types of storage;
- Recovery data management to ensure data is protected and can be recovered in the event of a disaster;
- Access interfaces, based on standards, to allow access to the data within the archive from any application.
Figure 1: BridgeHead HealthStore architecture
Putting BridgeHead HealthStore to Work
Here’s an illustration of how HealthStore can be used to store, protect and share clinical data. In this example, a male patient presents with an injury to his ankle. The ankle is badly bruised and swollen, and the patient is unable to put any weight on the ankle.
In the course of treating the patient, a photograph of the ankle is taken and stored as a JPG file in a folder on disk with the patient ID as the folder name. An X-ray is taken of the ankle and is stored to PACS in DICOM format. A radiologist reads the X-ray and dictates a report which is distributed using HL7. How can all three of these files, which are in different formats, be archived and searchable as part of the patient’s record?
HealthStore is able to archive all three of these files in their native format by using the appropriate ingest method for each data type.
The X-ray study can be ingested from PACS using a DICOM agent. HealthStore receives the study in DICOM, extracts the patient metadata from the DICOM header, stores and protects the study, and publishes the study using XDS-I.
The radiologist report can be ingested by receiving the HL7 message that broadcasts the report. Any patient Meta data is extracted from the HL7 message, and any missing patient data is obtained by issuing a Patient Demographics Query (PDQ). The report is then stored and protected in its native format, and then is published using XDS.
Figure 2: Unstructured data agent screen shots
Finally, the photograph of the ankle can be ingested using an unstructured data agent that scans the folder structure to ingest data. The agent can be “taught” about the folder structure and recognize the patient ID as the folder name. Subsequently, as the JPG photograph is ingested, the patient ID is obtained from the folder name. The patient ID is used to perform a Patient Demographics Query (PDQ) to obtain the necessary patient Meta data. The photograph then is stored and protected in its native format, and then it is published using XDS.
Now, all three data objects have been ingested into HealthStore in their native formats using three different ingest methods. All three have not only been stored by HealthStore, but they have also been protected so that they can be recovered in the event of a disaster. All three data objects have been published using XDS such that a portal can search for, and find, all three objects for the patient.
Interested in hearing more? Stop by and see me at RSNA in booth #2978, where I’ll be happy to go into more detail on how HealthStore works to store, protect and share all your healthcare data.
Learn more about the BridgeHead HealthStore Independent Clinical Archive.
Read the previous BridgeHead blog about “Possible Solutions” to the healthcare data tsunami.