So we have definitely convinced you to move the data off your retired system and you are shopping your options…that is great! Beware of marketing pitches that say the same words but actually solve your problem in completely different ways…

If one of the alternatives you are looking at is a "pre-built" or "turn-key" Data Archiving solution, make sure you recognize the differences:

1. A pre-built application requires data mapping. Hours of spreadsheets, validations, definitions, clarifications, issue to resolve. Left over data? They will “find a home for it” or can “accommodate it”. Where I come from, that is called a conversion.

2. A pre-built application requires a functional gap analysis between the functions it already does (and that you bought even if you did not need them) and the functions you really need.

3. A pre-built application’s functions that ARE on your requirements list need to be tested and evaluated to make sure that they are actually performing the functions as you know them and that your incoming data supports
.
4. The pre-built application will require custom programs and extracts to be written from your retiring system that must conform to the final version of the data mapping activities.

5. The custom extracts and programs cannot even begin until data mapping and definitions are completed, extending your project timeline and potentially causing you to incur more hardware and software support costs to keep the retired system alive while you implement the solution.

6. Functional requirements can extensively change the scope (a.k.a cost) of your packaged software implementation and support.

7. The current pre-built solutions we have found that are being marketed are primarily an option for Patient Accounting applications. If you have extensive medical records, admissions history, or clinical systems or data that must also be retired, you have not solved the problem for those applications. Others claim to have a “HR” or "clinical" modules – but where are these actually live as the main archived product and not just an afterthought, and how long did that take for the solution to be built? Will one set of clinical "modules" truly accommodate all the different data models and complexities of the hundreds of different types of systems in a hospital?

8. The installations we have researched on packaged archiving applications that are in production are in-house solutions. If you go this route, your IT department has to allocate technical resources to install, care, and feed yet another server and learn another system, and add another system to your DR and backup plans. There is software to be licensed that gets more expensive based on the hardware and the number of users. Even if the solution will work for additional applications or can bring up "modules", you will potentially pay software licenses each time it grows. Don't forget to budget internally and plan for the application software upgrades that will be released and must be installed and tested - and if there are no application releases - how is the system remaining compliant? There are also numerous security and infrastructure software patches and updates that must be planned and managed.

9. For pre-packaged solutions that are marketing a remote model – how many hospitals are really live on it? How is it deployed? How is it kept secure? How is the access managed? What are the SLA's? What is the vendor's experience in managing and keeping those SLA's? Is it just a remote location for the server, or is it truly software as a service?

10. When you are ready to retire the third party, pre-packaged solution, what are you going to do with the data? Or do you keep upgrading that hardware, paying software support, keeping the operating system up to date, and hope that the vendor keeps the software compliant with the latest hardware and operating systems? Seems like to me that was the problem that started this whole discussion…

Check back tomorrow for a point-by-point response on LDA's solutions to the above items! And thanks for reading!