Historically they and have done what all hospitals do, that is, they have purchased “commercial off the shelf systems” (also known as COTS) to run their business, manage patient care, and even market their services on-line. This approach largely met their needs for years, but now after a series of acquisitions, recent and looming changes to their reimbursement model, and myriad technology challenges that result from the shift from “hospital” to “Health System” they are now at a crossroads.  These systems may have performed fairly well independently, but they were never designed or intended to function as one. Meanwhile, the vendors who originally supplied the systems have run out of answers, and Nirvana is suffering the consequences.

Nirvana has successfully standardized on Epic, one of the tier one vendors, as the primary electronic medical records (EMR) vendor at the main hospital, but what they desire is a single view across the entire patient experience. Patients in Nirvana receive services without consideration for Nirvana Health’s desire for a comprehensive patient record. Most will likely receive some health services beyond the reach of EPIC, often simply by receiving care at a nearby doctor’s office which is a different medical records platform.

So why doesn’t Nirvana just demand that EPIC integrate with other EMR systems? No doubt Nirvana and countless others have. But for EPIC to do so would in essence counter act their own commercial interest. To do so effectively makes the patient record portable, and by extension the EMR system as well. Machiavellian principles of self-interest have proven themselves in healthcare information technology (HIT). The only way out for today’s Health Care Systems is to for them to wean themselves from reliance on any one software vendor for any critically required systems.

One way we recommend that Nirvana and others who face similar challenges introduce effective portability and reduce vendor lock-in is through adoption of standards across an array of disciplines, one specific recommendation would likely be for them to adopt a Service Oriented Architecture (SOA).  Still, SOA is largely a foreign concept to them, not to mention the notion of web services (WS) and enterprise services buses (ESB). It is important to note that SOA is not a product, but a philosophy. As described in OASIS SOA Reference Model’s definition, SOA is a model for “organizing and utilizing distributed capabilities”, and especially “capabilities that may be under the control of different ownership domains”. Nirvana will likely never fully control all the patient access points, certainly not soon enough to reach their stated timelines, and the SOA approach places a layer between the applications they rely on and the user experience they desire.

Success with a SOA initiative will require strong support by executive leaders at Nirvana, but will put in place the foundation upon which Nirvana and others like them will be able to address the requirements of today and the unforeseen challenges of tomorrow.  When Nirvana and others like them realize the cure they seek does not come from a pill they can buy, but rather from a new approach that removes their reliance on any vendor, they will prevail.

It’s simple.  The new Content I/O Suite.  Armedia’s Content I/O Suite allows users to collect information from all of those billions of sources, migrate it to the centralized repository in the company, and then, if needed, deliver that information to the different web portals that may need to view the information later.  In fact, it can even send the information to multiple repositories all from the same interface.  So what if Human Resources uses Documentum, and Accounting uses Laserfiche, and some departments have their own collaborative eRoom set up, but you just merged with another company who uses SharePoint and FileNet.  What if one user could capture the information coming in from the website, or through email, or through regular snail mail, and deliver it into the appropriate system, without that one user ever having to be trained in each of those systems?  Sounds too good to be true, doesn’t it?  Check it out at http://armedia.com/products/suite/.

-Kristin Evans

So why hasn’t there been more progress on this front?  Technology really has little to do with it, technology is actually the easier part of the total effort.  There are several answers and they can vary slightly but it really boils down to the same reasons so many enterprise content management initiatives fail - because there is a lack of analysis, requirements definition, and careful strategic planning up front.  Plus, once systems are deployed, there isn’t sufficient governance and it quickly becomes a support and maintenance headache so the benefits and your ROI disappear.  Something as complex as electronic health records can also be hampered by key stakeholders from different areas failing to agree on a core set of requirements and policies in order to move forward.  If there isn’t a commitment among these interested parties to work together towards a common set of goals and objectives producing a successful solution will be extremely difficult.  This has certainly happened in the past but hopefully with the current momentum this obstacle can be overcome.

One of the key things for organizations planning this type undertaking is to understand and accept that it is not a one time thing.  These aren’t single projects they are programs.  Many projects have failed because the scope becomes way too ambitious and requirements are never properly defined.  With something as complex as electronic health records getting to a refined, specific set of requirements that can be implemented is challenging at best.  Which is why these programs should be broken up into a series of smaller, more tangible projects with scope that can be properly defined and is obtainable during a reasonable period of time.  Taking on more, smaller projects allows you to set more realistic goals, minimize risk, and learn from each iteration so you deploy a more reliable system that meets expectations and yields positive results.  I can’t stress the importance of properly defining requirements down to a specific level, if the requirements are ambiguous and cannot be broken out into use cases you will not wind up with a sound design and the solution will more than likely fail to meet expectations.  I am going to leave this point here since I am starting to cross over into software development methodology and process areas and I have whole separate article planned for that subject.  It may take more than one if I really get on my soapbox!

There certainly have been some good examples, if you haven’t read about it check out the Delaware Health Information Network.  The DIHN (pronounced The Din) as it is lovingly called has been an ongoing program and has been pretty successful.  Will it be a model for other states and possibly more?  I can’t say for sure but having a new VP from the great state of Delaware certainly can’t hurt!

So what can be done to help ensure that an electronic health records system is successful?  For starters realize what I mentioned above, it isn’t a single project, it is a program made up of multiple projects driven towards a common goal.  Of course stakeholder support and resources are a given as with any program but having stakeholders involved that know the different parts of the industry (i.e. Physicians, research, clinical, etc.) and are committed to the common goals is vital.  As with any type of record, health records have compliance regulations that have to be met, the most notable of course is HIPAA.  This is a risky area for electronic health records systems, one that has stumped efforts in the past.  How do you ensure patient privacy when these records become digital, especially with so many potential access points?  This is a big reason key stakeholder input is critical and why there is a great need for governance of the solution once it is deployed.  Roles and permission levels can be established but it is the subject matter experts that need to define them in order to help ensure accuracy.

Once a system is deployed the Governance Committee should be the authoritative body that provides change management guidance and helps ensure the common goals of the solution are being met, including compliance.  As with any good program a road-map should be drawn so the team knows where they are and where they need to go.  The road-map should define key milestones for the program and basically layout the projects to be undertaken along with their high-level scope.  Earlier milestones will probably be more specific and it is OK if future milestones are more nebulous, this should be a living artifact that is revisited, and potentially revised, after each individual initiative at least.  The goal is to lay a solid foundation and build upon it with additional functionality while also factoring in changes in regulation and in the environment.

Although not as important as the aforementioned functional and human factors in ensuring success,  technology certainly has an important role to say the least.  Using content management platforms effectively with intelligent classification, metadata standards, and search applications to manage, relate, and access these records will be vital.  Usability is usually an after thought which is why new system adoption and sustainability can be difficult so it’s role in an initiative like this will be huge.  If the system is difficult to use and frustrating for the end user they simply won’t adopt.  You can build the best solution with all the functionality one could ever need but if nobody uses it the effort will still be an utter failure.  Using proven usability techniques and best practices will help facilitate positive results.  With any major industry shift towards technology, especially with as big as this movement is likely to be, the establishment of certain architectural standards will go a long way to help prevent data from being siloed and to make sure the information can be shared and can cross systems.  There has been success on this front as well that can be used as examples, the Global Justice XML Data Model is certainly one.  Another standard which is in a related area is Regulated Product Submission which is a standard that would allow regulated organizations such as those in the Medical Device, Pharmaceutical, and Veterinary Medicine industries for example to submit regulatory information to the applicable agencies using a single standard message format.

The potential benefits to electronic health records systems are there but what is debatable is whether or not it is realistic to think we can get there.  Eventhough there is strong support there are also those that feel that it is too grand a goal and that the benefit is simply not there.  I was just reading an editorial in the newspaper today where the authors basically said that the money for electronic health records technology would be better spent somewhere else, in fact these authors cited statistics that indicated that this type of technology may actually detrimental to health care.  Sorry, I just can’t buy that.  I just don’t believe we have been doing this long enough and effectively enough to gather accurate data on the subject.  Are there other areas of the health care industry that need funding, of course, this isn’t a silver bullet and to think so could possibly set unrealistic expectations and doom the effort before it ever really got going.

I for one believe that we should, can, and will get there.  Make no mistake, it will be a long complicated journey but one that is long overdue and it looks like it will have a great deal of Federal funding and support which will definitely help.  We really can’t afford not to take this step.  Many experts agree the current state of medical records contributes to rising health care costs.  Furthermore, there is a great deal of knowledge that is sitting there but isn’t being utilized simply because it can’t be found and linked together in context.  I mean, when you go into your Doctor’s office or into a lab to have a test performed do they pull up all your information digitally in a unified context?  No, I am sure they don’t, they walk back to those rolling file bins and pull your folder with hard copies of all your health records, once they find it that is, and only for what you have had done with that Doctor or by that clinic.  Now, think about it again, what if your Doctor is able to have all your records including x-rays, lab results, etc. from anywhere at her finger tips and can be referenced easily?  Or what if you move or are out of town and need to visit a Doctor or hospital and they can have all your records pulled up within seconds?   Once it starts to be put in perspective it becomes a very compelling argument.

What I think has the potential to be a tremendous benefit and improvement in overall health care but isn’t being talked about too much are the eDiscovery possibilities that begin to open up.  Think about it, if this information is digital, well attributed, and classified (content management professionals reading this are chuckling at this notion of ECM Zen but stay with me) this starts to not just be a system that manages discrete electronic health records it starts to become a knowledge warehouse.  For example, with all all of your health records stored this way your Doctors can cross reference past lab results and your history to make a better, more accurate diagnosis.  Intelligence can be built in to flag items if certain tolerances have been met and send alerts.  Reporting across geographical areas can be generated to identify potential outbreaks and if you have ever had the flu you certainly want Doctors and organizations like the CDC to have all the information they can at their disposal.  I genuinely believe that this will not only improve our economy and our health care system but that it will lead to more cures and better health in general.  Health records hold a great deal of valuable information and but they suffer from the same plight that a great deal of other content does, not that it doesn’t exist but that it can’t be found.