Organizations get locked into vendors’ apps
In seeking ways to gather and analyze – and hopefully act upon – electronic health records (EHRs), organizations are following a familiar path: They assess their needs, and then hire a vendor to support them. At this point, they’re locked into the selected vendor’s app, in terms of how they input, review and analyze data.
However, we now exist in an age in which data is delivering endless possibilities; when we pursue information discovery and seek to make good decisions from the resulting, newly acquired knowledge, we’re really only limited by our imaginations. Which is why traditional, vendor-centric approaches are no longer relevant.
In other words, it’s about the data. Not the app. Given that the EHR market is expected to grow to $33.41 billion in value by 2025, according to a forecast from Grand View Research, the stakes are too high to cling to antiquated models.
The limitations of vendors’ apps
Let’s illustrate with a realistic scenario: A patient encounters blood pressure issues, even though he’s already taking medication for his condition, so a hospital doctor writes up a new prescription. Because it’s new, the doctor wants the patient to take daily blood pressure readings with an at home monitor and report back. Steady information over a stretch of time, after all, provides more value than that observed during occasional office visits.
The data isn’t difficult to collect. The patient can do it on his own, and call it into the doctor’s office. But what if the existing vendor tool doesn’t allow for the inputting of daily blood pressure readings? What if it caps this inputting to, for instance, four readings a year? In this case, both the doctor and patient are stuck with what the vendor has to offer. Sure, the doctor can work through higher-ups at the hospital to see if the vendor would upgrade the app so it’s configured for daily blood pressure readings. But the vendor may have other upgrades they need to address first, putting new requests on the back burner for months or longer.
You can apply the same sort of scenario to a patient’s weight, heart rate, blood-sugar level, cigarette/alcohol usage or any one of a number of other components which lend insights into someone’s state of health. The information is ready and available. But if the solution isn’t configured to incorporate it into a data capture/analysis program, the information will end up in limbo.
Tailoring apps to organizations’ needs
So what’s the solution?
Again, it’s about the data. Or, more precisely, thinking “data first” and then app.
Organizations should initially consider what exactly they want to capture, whether it’s blood pressure readings, cancer screenings, cholesterol checks, smoking cessation success rates, etc. Then they can figure out what kind of app will work best. Tech innovation is driving swifter and greater adoption of agile practices. IT departments are now positioned to more readily and easily develop (or pay to have developed) mini-apps to perform specialized functions – further rendering obsolete the monolithic, rigid, “our way or no way” mega-vendor tools.
All that’s required is a secured, indexable database. With this, organizations and users input whatever they wish into the database, and then build mini-apps accordingly so teams create chart visualizations, analytics tools, treatment plans, etc.
Problems with the traditional model
To cite another scenario, let’s say that same hospital doctor from before would like to know if her patients were picking up their prescriptions in a timely manner. Obviously, her local drug stores would have to compile and report this information to her. They could even work together to set up an alert notification system should patients fail to pick up their prescriptions within two weeks. Sounds simple, right?
Not if we’re still talking about the traditional model: The doctor might tell the vendor what she plans to do, and the vendor could respond that their product isn’t configured for data related to prescription pickups. Further complicating things, the app may need to be work with multiple reporting systems used by the various drugstore companies with no way to determine if compatibility. Setting up a workable solution might take a year – or longer.
The modern approach
But through a modern, agile approach, the doctor simply comes up with a data collection/notification alert plan with the drug stores, has IT construct a secure, indexable database, and then design (or, again, hire someone to design) a mini-app to monitor prescription transactions, send alerts for late pickups and otherwise enable the doctor and her team to analyze various patterns within.
Or take another example: two or more unrelated entities (like a pharmacy and a diagnostics lab and a hospital) are all trying to get data into the same EHR, but if they don’t share the same EHR for the same patient (and they don’t) then they can’t do it directly. With a standard data-based health model they could throw transactions into the same pot to be discovered by relevant applications later.
A data-first strategy
The upshot: For too many years, organizations dependent upon EHRs have resigned themselves to an “If we build it, you will come” arrangement with their vendors, i.e., the vendor builds the tool, and organizations buy in and adjust to its quirks and limitations. And being that other hands-on health care priorities often take precedence, who could blame them?
But today, those same organizations can advocate for a “Let the data come first, and then we’ll build it …” strategy. By determining the intent of their discovery initiatives and data models, they necessitate COTS vendors and Open Source developers to build functionality around them. Subsequently, the market ultimately provides a better solution and HCOs end up with information that is more comprehensive, immediate, insightful and actionable – empowering them as more effective healthcare practitioners and better “custodians” of EHRs.
