Wednesday, January 25, 2012

The Spaces Between




As a systems integrator our greatest value is in understanding the ins and outs of “the spaces between” our clients existing systems, but expect stares as blank as a freshly cleaned whiteboard when offering such an explanation. How then do we describe our craft?  Engagements generally start with an implied question from our prospects… “How can you possibly help us when we know so much more about our business and systems than you”? Telling a new client who has spent years or even decades grappling with their very specialized workflows and unique data that, “data is data to us”, comes off as either ignorant, insulting, or both. How many times have you ended a conversation with a client and thought to yourself, “they simply don’t know what they don’t know”. More importantly, how many times do you think they were thinking the same thing about you?

It is much easier to explain [and bill for] boxes, cylinders, screens, circles, and even clouds, than it is the lines and arrows that connect, or at least should connect them. It is within theses “shapes” that our clients live and work, but in the spaces between that they need us most. In their eyes lines depict connections, but therein also reside workflows, dependencies, and logic, or more often than not, the lack thereof. It is also often in these spaces that the most important, and often unstated and hidden customer requirements lurk. We win customers when we see, understand, and have solutions we can articulate for these hidden problems. 

This brings to mind recent interactions with a few new Armedia prospective clients listed below. What they share is one-of-a-kind technology ecosystems that evolved over many years but that have become increasingly dysfunctional, while at the same time their user experience expectations have risen dramatically. 

  • ·        A Health Sciences company developed systems to manage a speakers’ bureau, and solutions to help pharmaceutical and medical device manufacturers manage clinical trials. In the process, they also created a software maintenance nightmare.
  • ·        An international program that manages independent educators, and uses systems that require no fewer than 13 separate user names and passwords to access. They maintain several web based systems, each built “in a vacuum” by different providers, and each created without coordination under a common architecture .
  • ·        A Health System that provides care for a patient population of nearly one million people, they are suffering under authentication, interoperability, duplication, and maintenance issues that together manifest in cascading user experience shortcomings for patients, practitioners, and staff alike.
We will never fully appreciate the history, evolution or the politics that contributed to their current state, and we will never know these businesses like they do, but with the right approach we should be able to gain their trust and help them as they strive to answer the increasing loud chorus from their constituents, “please make your systems work together, now!”

We as integrators are confident we can help them, but how do we gain their confidence? The buying pattern they are comfortable with is to purchase software directly from independent software vendors (ISV’s) and then attempt to hold them accountable. The challenge is that one cannot “buy” the interoperability they need from an ISV. What they seek is “not available in pill form”. One must adopt an approach that fosters interoperability and then must build a system to support it, and for that, integrators like us are the only way. If the answers resided internally or via ISV’s, then the issues would already have been addressed.

Is your EMR holding you hostage?



Consider “Nirvana Health System” (fictionalized) a nearly 1000 bed system in the City of Nirvana that has 7000 employees, 7 hospitals, 200+ doctors on staff, with another 800 or so who independently perform services in the area. Historically they have done what all Hospitals do, that is, they have purchased commercial off the shelf (COTS) systems 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 cross-roads.  These systems may have performed fairly well independently, but they were never designed or intended to function as one, the vendors who supplied them 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 they desire 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 the EPIC, often simply by receiving care at a nearby doctor’s office not using Epic. So why don’t they just demand that EPIC integrate with other EMR systems? No doubt Nirvana and countless others have. But for EPIC to do so is counter to EPIC’s 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 out 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) yet SOA is largely a foreign concept to them, not to mention the notion of web services (WS) and enterprise services buses (ESB). 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 leadership 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, and perhaps we will have yet another new customer.