Not sure where I got this from, but at some point I was told that one of the keys to successful selling was
“Tell them what you do,
Then tell them what you do again
And finally, tell them what you do one more time.”
I understand the importance a strong sales strategy has on our company’s success – and how much that old badge of honor “He/She can sell Refrigerators to Eskimos” is coveted in any industry. I do hope, however, that no matter how proficient our team or our message, we would never sell someone something they don’t need…
The converse is also true – if we cannot effectively communicate what we do, then “they”, (The Eskimos, in this example) will never know that they needed us. In our efforts to improve ourselves, part of our 2010 start-up is to refine our message. We are looking for a better way to effectively communicate exactly what we do. We have been using the tag line ‘Data Storage and Access’ for ten years now – and frankly, don’t think it really describes the value we provide. Sort of like an Inkblot test – when I say ‘data storage and access’, the first thing that comes to mind is hardware storage solutions, backup solutions, network attached devices and the like. While we certainly use our share of these products and services in our delivery model, this is not what we do.
We take data
(That’s the easy part!)
Out of retired applications
RETIRED meaning systems that are still running but are no longer being used as the primary production system for that department or job function. It might still be getting intermittent updates in terms of payments or adjustments (if it is revenue cycle) or notes or memos or be used for requests for information, etc.
We put that data in its original or near original format in an SQL database.
The DATA defines the FORMAT and the FUNCTIONS. We do not CONVERT. We do not MAP. NEAR original meaning if the data is not an open data source, we mimic the users experience with the data in our database. We do not have a predefined target layout or singular function or set of functions for the data.
We build a view-only application that displays the data.
The DATA defines the VIEW. The retired system is used as a guideline for the inquiry screens.
Modules can be installed “cafeteria style” based on the needed update, edit, or workflow functionality.
We have modules that can be implemented in the application that provide UPDATE features, revenue-cycle functions, standard patient balance, transaction, guarantor and account summary screens, and claims production and editing, documentation production, workflow support and report writing.
THAT is a lot of words.
We put together some of the best brains we have (!) And are working on a new tag line and ad campaign. It is going to be a lot of fun, and - hopefully – be a better embodiment of who we are and what we do. Those Eskimos might not need refrigerators, but I know glass-sized ice-cubes could be a big hit!
Stay tuned! Launch is at HIMSS! T minus 5+ weeks!
It seems like we're always trying to explain exactly what we do. Not that we mind, of course. We are always trying to raise Data Retirement awareness. Over the last few years we've seen the light bulb go on in more and more healthcare organizations. It's a wonderful thing. And yet I, personally, am surprised at how the old thought patterns still prevail, even among those who understand the challenges of retiring a production application and risks of data conversions. They want to pull all the data out into reports and put the reports into a document imaging system or find some pre-fab "online archive" box to store everything in. It's not that those ideas don't solve the problem (technically, at least). It's just that they don't aim very high.
While I was an undergrad I had a professor who related a story to the class about this kind of situation, which I would like to share with you.
It was a brutal summer, the kind that keeps even native Georgians indoors. After a great deal of sacrifice and hard work through his PhD program, my professor decided it was time to take a real vacation with the family. They left town and stopped at a hotel. The hottest part of the day was over, but it was still pretty toasty, so he went to the swimming pool with his two small children in tow. It is a universally accepted mathematical formula that children + swimming pool = fun. A good time was had by all. But sadly, all good things come to an end, and the children were taken back to the hotel room despite their insistent complaints. The swimming pool was great, but there would be more fun tomorrow, he promised them. In the morning the children wanted to go back to the swimming pool. Their father promised them more fun, and fun = children + swimming pool (refer to formula above). But that wasn't the plan. Instead the children were herded into the car, again over voluminous complaints. The entire car ride was a cacophony of whining and complaining as the children voiced, as only small children can, their disappointment with the current arrangement.
After this car ride, which was not enjoyed by any of the car's occupants, the family arrived at their destination. The kids grumbled out of the car and sulked down the path from the parking lot, kicking, stomping, and generally abusing the ground as they went. When the path ended they looked up and their jaws dropped and, for the first time all morning, they children were speechless.
They were looking out at the endless blue of the ocean.
Now, I'm not so bold as to claim that Legacy is a whole ocean better than any other solution. What I am trying to say is that it is worth the time and effort to see the difference. There are as many potential solutions to the data retirement problem as there are IS professionals with a compiler. Any developer worth his salt could come up with that swimming pool on a hot day. But we've been around for a while (over ten years). We've seen the ocean. Let us help you get there.
Happy 2010! Or 2K10. Or Two-thousand Ten. Or Twenty-Ten. Whatever you want to call it! It is amazingly the topic of TONS of blogs. I think some people have too much time on their hands.
Here at Legacy, that is definitely not the case. I want to apologize for our sporadic blog posts – I know the number one rule of blogs is to update the content frequently (not to mention with interesting material). The good news for us (but bad for our blog) is that we have been super busy this last quarter, bringing in new clients, upgrading and taking care of existing ones, forging new partnerships, and becoming the #1 active archiver of legacy system data in the industry.
So the New Year is a chance to set goals and resolve to better our world and ourselves. Kind of trite, but any excuse to re-affirm your strategy, make course corrections, and continuously improve is a good thing. I am going to start by making sure this blog gets updated at least once per week. As we move through projects, have customer experiences, find meaningful examples that we think would help even one healthcare entity, we will post it.
This company was founded based on a simple need – that there were healthcare enterprises out there that were running old, antiquated, non-supported, at-risk applications just to get to, report on, manage, and possibly continue to update or follow up old data. Converting data to its replacement application costs time and money. Mapping it and moving it to a stand-alone, single-purpose archiving application is just not strategically sound. Keeping the box running is risky. I have blogged on all this before. Point is, we are going to use the New Year to re-affirm our message and our position in the marketplace. We are going to emphasize our strengths and advantages over our competition. We are going to share our vision and our culture with the market so each and every customer knows what they are getting for a very fair price. Our honesty and hard work is the hallmark of our success; we are going to share that with everyone and anyone that is willing to listen.
So check back once per week – maybe even more – as we try to exceed expectations in every sense – starting here!
Happy New Year.
- Thou shalt retire all data.
- Thou shalt not alter thy data, neither content nor layout nor format.
- Honor thy data that it may go well with you in future audits.
- Thou shalt not convert thine old data into thy new system, for this is detestable.
- Thou shalt not map thy data to fit another format lest ye fall into the trap of data conversion, for the Immutable Law of Unintended Consequences is absolute and unyielding.
- Thou shalt not lose functionality essential to thy business.
- Yolk not the users of thine old system with unfamiliar screens.
- Thou shalt expect flexibility in thine implementation.
- Thou shalt continue to receive benefit from thine old data as the fruit of this labor.
- Thou shalt save money.
Shelly gave some very important points in the previous posts about pre-built data archiving solutions and how they can impact your application retirement plan and you business in general. I would like to take a few minutes to convince you that there is a very strong technical case against using one of the "turn-key" data archive products.
Algorithms + Data Structures = Programs. Not only is it the title of a classical tome that should grace every Computer Science nerd's bookshelf, it is a fundamental principle that underlies all of computing. Data Structures are coherent, structured sets of data. Like patient records, with names and account numbers and discharge dates all that good stuff. We all know pretty much what the data structures are for our industry. Some of the data structures are just common sense: if you want to charge a patient, you ought to know where to send the bill, so we track billing addresses. Some of the data structures are mandated by our current socio-political situation: we track NPI and SSN, and a host of other seemingly random strings of numbers that the government says are important. Some of the data structures are included in applications by people who "know what they're doing" (and most of the time they do -- nothing acquaints you with data quite like writing an application to manage that data).
So we have all this data. Gigabytes. Terabytes. The old system is going away and we're going to save a lot of money when it does. Now it's just a matter of finding somewhere to put the old data, right? Well, yes and no. Storing the data is only half of the equation. After all, we aren't just retiring data, we're retiring a program -- the data and the algorithms that work on the data. There is no such thing as a one-size-fits-all algorithm, even when it comes to simple data. Even algorithms that do the same thing, such as sorting a simple array of data, can have very different properties (time complexity, space complexity, stability, etc). If you want to preserve any level of non-trivial functionality, you have to have bring the algorithms along for the ride. Otherwise we could just write it all to tape and be done with it!
So why doesn't a pre-built "turn-key" application solve the problem? Well, it's pre-built, for starters. That means it's done -- it was written before the vendor ever knew your company's name, much less the particular characteristics of your data. The algorithm is what it is and the way they will make it work is to fit your data into their mold. They'll tell you that data mapping is different from a conversion. A first name is a first name, right? So they just map it over and move on. But what happens when you have data that doesn't fit the mold? What if your system keeps track of names and aliases? How will the Data-Archive know the difference? Will it let you go automatically from an alias to the actual account number? What about complex, recursively defined reports that don't fit well into the relational database model? That's where the "we'll find a home for it" answer just doesn't cut it. Sure it can be stored, but that isn't a solution. It used to be queried and viewed in a particular manner, through the filter of the algorithms that performed whatever function the data was intended for, be it a simple search or an intricately detailed patient data summary. In order for the data to remain useful beyond the life of the application, it must be usable in the same way so it can support the same activities and decision making processes that it used to.
So how is Legacy Data Access different? I'm glad you asked. The main difference is that we don't write a line of code until we have your data. We look at the data and figure out how it needs to be represented and delivered. In essence your data and your processes dictate what the end result looks like and how it behaves, making it a much better fit for your data.
If I stopped describing our process here you might think the project would take forever. The truth is that, not only is our solution driven by your needs, we can implement it faster than the competition. We've been doing the same thing for the last ten years. When you do something for that long you tend to get good and doing it. We have a custom, flexible, open-ended application framework designed specifically for creating applications to house retired data. As a result we can usually get 80% to 90% of the application's functionality finished without writing any custom code. The other 10% to 20% of the functionality does take a little longer, but not much. Most of the time we can still leverage our framework to finish the project with minimal modification. For those parts that don't fit in to the framework, we simply extend the framework to solve the problem, meaning that the next implementation we do that presents a similar problem is handled by the framework as well, minimizing development time. This is one of the advantages of using Legacy in the context of an enterprise-wide solution: the more we work with your data the better our solutions get.
In short, don't be fooled by someone trying to sell you a solution that doesn't fit your problem. Your data is valuable and the value it can give your company should not end when the application that houses it is retired. When all is said and done, it is your data. You should be the one to determine the best way to access and utilize that data.
In a previous post, I detailed how a pre-built application to store and manage legacy data from a retired application may not be the best solution. In this post, I will address each point and explain how LegacySuite will provide a custom solution without the custom price tag and extended time line usually associated with custom projects.
1. LegacySuite requires NO data mapping. The files and fields that exist in the source system are the same files and fields, in their natural order, that are loaded into LegacySuite. If your source system has 10 files with 20 fields each, keyed by an internal key field, then that is how they will exist in LegacySuite. The field and file names even remain the same whenever possible. This is made possible by LegacyToolkit, our collection of self-developed tools and processes that we have perfected over our 10 years of providing legacy data storage solutions.
2. LegacySuite is modular. This means we install, and you pay for, only the modules you need to use and only while you are using them. No need to edit claims after 4 months? Your monthly fees go down. No need to access the data at all after 2 years except to prove compliance? Your data moves to LegacyVault and your yearly fees reduce dramatically. Furthermore, if there is a function that you need that LegacySuite does not perform, our tool-based development platform means that we can design and code those functions for a fixed-fee, dramatically reducing your risk and potential cost.
3. Because the data is not converted in any way, we ensure that the LegacySuite applications perform to your functional requirements and the format of your data.
4. Data extracts are dramatically simplified. If the system is an open one, such as a mainframe application or one that uses third party databases such as SQL, Pervasive, Informix and many others, all that is required is a backup or a standard export. If the database is closed or proprietary and no user tools exist to extract data, we will help you work with your vendor to get the extract done. Because there is no data mapping or predefined extract layout, extract efforts are typically very inexpensive.
5. Data extracts for LegacySuite can begin as soon as the contract is in place.
6. With Legacy’s Assessment services, all functional requirements are documented and determined in advance. This enables us to propose the custom application you need for a fixed price.
7. LegacySuite is a STRATEGIC, single-source solution for any type of data regardless of the business function the source system performed. Legacy Data Access, Inc. has applied the LegacySuite product line and our LegacyToolkit methodology to just about every type of system in a healthcare institution, including of course Patient Accounting but also clinical, ERP, departmental, and even specialty clinics. The implementation methodology and timeline does not become dependent on the development of a new “module”.
8. LegacySuite is delivered via an ASP delivery model where all hardware and software installation and management is done by Legacy Data Access, Inc. If an ASP model does not fit your culture, it can also be installed using our OnSite services in your data center on an appliance provided by LDA. The OnSite implementation model includes all the same software and services from Legacy Data Access, Inc. such as application and system software update installations, hardware upgrades and support and even backup and DR support.
9. LegacySuite is live for about 100 implementations. Each contract has SLA’s that are measured and reported on quarterly or monthly with financial penalties for non-compliance. LegacySuite’s infrastructure is a true software as a service. Our LegacyLink product provides a single portal to access all LegacySuite applications and also provides value added tools that allow for report creation and distribution, single sign-on security, user logging, and even cross-database functionality such as LegacyID.
10. LegacyVault is the LegacySuite component that handles the true end of online life for legacy data. Your entire set of data and the LegacySuite components that are used to access the data are packaged up and taken off-line and put into storage. Monthly fees stop. Yearly storage fees are very affordable. Data and applications are brought back online once per year to accommodate any software, hardware, or operating system upgrades that must be done and tested by Legacy. The data is stored this way for the remainder of the regulatory period. If the data is needed during this time, it is re-activated and the web applications are made accessible. In this way, you remain compliant and only pay for the access you need, when you need it. Once the regulatory period is over, Legacy Data Access, Inc. will destroy the data and provide documentation or return it to the owner for destruction.
Review our web site for more information on LegacySuite, or contact us at info@legacydataaccess.com to see a demo. And thanks for reading!
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!
With the ARRA getting the focus back on IT spending and system replacements, the need for legacy system retirement options is more urgent that ever. Deadlines for payment and tax incentives are fast tracking implementations, making data conversions from old to new even more unlikely. With the assistance of a partner, we have developed a matrix that helps you identify at-a-glance the critical success factors for your legacy system data and the potential risks and costs associated with them. We will provide detail in future blogs.
Here at Legacy, we are constantly seeking to improve our processes from the front to the back. Because we are small, we like to look to others in our industry to mentor us (although probably unknowingly) so that we can quickly identify what works and stay clear off the paths that don't. To that end, we have come upon some ideal videos that help our sales and customer care teams as they work on their strategic plans for 2010.
Part 1 of the series is a lesson on handling an unhappy customer and developing listening skills:
Part 2 of the series demonstrates following up and working the situation to the company's best advantage:
The computer voices are clearly a ploy to make sure the video creators are not identifiable. The "tickets to the Braves game" and the "IBM Account Rep" reference may give a hint as to the author, but beyond that, one can only guess who the "vendor" is supposed to be. Sadly, there are more than a few choices.
Please join us and welcoming our latest addition to our family....our server family, that is!
Weighing in at just over 900 lbs and 79 inches long, LDA welcomed the newest addition to our family yesterday - a System Z10. One proud employee was overheard to say "AWWW! It's got Legacy's green in the front window!"
The Z10, whose official family name has yet to be determined, is the largest of it's three mainframe siblings and is a welcome addition to our new data center. With it, we will be able to improve our services to our current customers and have vastly increased our excess capacity for new applications.
The Z10 was made possible through the great folks at Mainline Information Systems as well as through our ongoing, now more than 10 year relationship with IBM as a Development and Business Partner.