By Tony Cotterill
As IT adoption grew within healthcare, it happened at different speeds and without a clear lead from the IT department. Many departments ‘grew their own’ applications. In fact, Radiology, in many hospitals, grew its IT infrastructure faster than the IT Department itself. Applications were often written or acquired by a clinician in the department without IT involvement, and when this person left or retired, the application was left unmanaged and unmaintained. Over time the function of many of these applications have been consumed by other systems but frequently this has left the original data at risk. This data cannot be simply deleted, at least no one is likely to authorise its deletion, and as a result legacy applications are kept running just to have access to their data.
The net result is the unnecessary cost of maintaining obsolete applications and the substantial risk to what is essential data because:
- IT are often unaware of these applications and as a consequence they are not fully protected;
- These applications often live on older operating systems and have not been upgraded (possibly cannot be upgraded) in line with technology advances.
This is only one scenario among many which cause an application, once vital to the running of a department, to now be obsolete. And what’s worse, the problem is not insignificant. Even a modest sized hospital will have hundreds of applications, many of which are either peripheral to the main hospital systems or completely dormant as they have reached their end of life. Add to this, the current trend of one hospital acquiring another and matters only get more compounded. With each acquisition, duplicate application types are introduced and need to be retired which only adds to the volume of data which is now “homeless”.
Application Retirement
In most hospitals, a strategy to advance and maintain the core systems, essential department applications and key information systems exists. However, the more peripheral or obsolete systems frequently fall by the wayside. But these systems often manage critical patient data that should not be compromised as it needs to be accessed and is essential to the full patient record.
Examples of peripheral and dormant systems might be:
- Systems that have been created in house have no real data management or security but whose data is fundamental to the operation of the department and which contributes to the patient record. For example:
- Wound photography, where the application is a hierarchical windows file system using the folder structure and file naming convention to manage and access the operational data;
- Cancer treatment application which relies on IT intervention to recover prior treatment plans and return them to the physician.
- Applications that are no-longer creating or accepting new content as they have been superseded. Data is still needed for reference purposes and may also be required as part of the patient record.
- One hospital saved $6M by retiring an old Siemens system and migrating the data into a repository for future reference;
- Another calculates that they spend $1.2M per year maintaining legacy applications just so the historic data can be accessed. This is more than their annual IT staffing costs!
Not only is there a cost in maintaining these application types, but generally the data they contain cannot be easily accessed or shared, as it’s trapped in an application that is no longer operational or does not comply to any data interchange standard (DICOM, HL7 or XDS).
In addition, these application are frequently based on legacy storage systems or on infrastructure that is no longer supported, which means they are at best expensive to maintain and at worst an accident waiting to happen[PL1] .
So What Can Be Done?
BridgeHead have developed services and tools to migrate content from its current location or current application into a standards based repository, otherwise known as an Independent Clinical Archive (ICA). BridgeHead’s HealthStore ™ product is an ICA that can store and index any type of Healthcare content or data. As such, ICA is the ideal solution to store the reference content which is found in these redundant or difficult to maintain applications. HealthStore makes management and access to all of your content efficient and consistent.
HealthStore allows a hospital to suspend, and in many cases completely remove, the original application saving software license and maintenance fees as well freeing up IT resources.
Once in HealthStore, the data can be maintained and its lifecycle managed. For example, HealthStore ensures:
- Demographic updates are applied. This means that relevant changes to details that apply to the data, such as changes in the patient name, address, etc., are administered and maintained.
- Data is stored in the most appropriate storage system in accordance with its age and value. Storage of data is expensive and as that data ages, the frequency and speed that is required to access it diminishes. HealthStore automatically moves data deeper into the archive according to the rules set for that data type.
- Data retention rules are applied. We can, if the politics allow, manage the retention of data, deleting it when it expires according to user defined ageing rules.
- Data is managed through changes in infrastructure. HealthStore virtualizes storage, which means that we are able to cope with changes that take place in your storage infrastructure.
“Garbage In, Garbage Out”
Before an ICA can make data available, that data needs to be ingested into the archive. How that ingestion is done is critical, because any ability to retrieve and use the data in the future will be set by the decisions made at ingestion time.
Typically an Ingestion Would Go Through the Following Steps:
- Create a manifest of all the content that exists and needs to be transferred.
- Sample that content for data quality and decide with the department how data will be repaired. This will involve:
- Creating some transformation rules to enable data to be repaired as it is ingested;
- Deciding on what external checks to apply to the data to ensure that it can be used in the future. For example we have a patient ID but is it the correct one?
- Decide what meta-data will be needed to register the data in the archive so that it can be searched and retrieved in the future and where that metadata is going to come from.
- Migrate the identified data, applying transformation rules and creating meta-data on ingestion so that the data object in the archive is clean and its presence registered.
- Validate the migration by comparison against the initial manifest for assurance that the entire dataset has been accounted for.
BridgeHead HealthStore solves many of the problems surrounding obsolete healthcare applications. By eliminating the need to license these applications, it saves you significant amounts of money. In addition, by migrating obsolete application data into its single data repository, HealthStore goes a long way toward creating a more efficient EMR.
