Four reasons why the modular approach taken by traditional EHRs can’t support Integrated Care.
In truth, there is no such thing as an Integrated Care module, and though Integrated Care is generating a lot of interest among healthcare providers and technology vendors alike, it will never be realized by means of the traditional, module-based, customized EHR software approach. The solution is something new and entirely different.
The fundamental problem of the old approach is strategy. Integrated Care is an ambitious step toward whole patient wellness, and reconciling the processes between providers and specialists across the individual EHR technologies that support them is an unprecedented challenge in the realm of health care. New challenges often call for new solutions. Integrated Care is no exception, and the solution is not just another EHR module.
Traditional EHR software has done its best to address the unique needs of behavioral health care, but it has never been without its own limitations. The static functionality of bolt-on modules have enabled EHR software to keep abreast with regulatory changes and emerging business needs with limited success, but the hard-coded nature makes it difficult in an industry that consistently changes. Producing a change means having an engineer revise the core code or design a module to bolt on to the existing application, a process which invariably carries a lengthy turnaround time. But lengthy turnarounds are not the only issue with relying on modules to execute integrated care. Below are the four main reasons why Integrated Care cannot be supported by EHR modules:
1. Integrated Care does not fit into one standardized mold
Integrated Care is a dynamic, experimental, and evolving paradigm. It is a matter of discovering best practices through trial, error, and validation, and each state and county has its own ideas of how to achieve the most success given its unique set of regulations and reporting requirements. Fluidity is a must.
In order for EHR software to lend itself well to this process, it would need to be able to change very quickly very often, and this is simply not possible.
2. Modules are programmatically isolated
Software modules have been necessary to add to the existing functionality of an EHR application. This approach allows organizations to select desired feature sets and bolt them on, but it does not subject them to the inherent limitations of legacy software any less.
EHR software modules are built to satisfy a specific set of functional requirements, so each module might only cover one use case (at the very best, a few) instead of spanning many. Furthermore, use cases will grow and evolve over time as providers continue to collaborate and improve clinical quality metrics. Legacy EHR software’s reliance on engineering support in order to support new workflows means that they simply cannot keep pace, and can never be designed with adequate foresight into future data which must be collected, aggregated, and shared across multiple programs and scenarios.
3. Modules are not extensible
Legacy EHR software is designed to fulfill a very specific purpose. When an organizational need arises that doesn’t fall within the purview of the application, the gap in functionality is filled either by an additional module or a staff workaround. The lack of extensibility stifles any real chance at making Integrated Care work.
Integrated Care is about establishing network effects between prescribers, specialists, and community care providers, all of whom contribute to whole patient wellness in their own way. Data proliferates across a multitude of use cases as network effects continue to expand. In order for Integrated Care to work, an adaptive EHR solution that continually embraces change and new innovation in real time is needed.
To learn more about platform technology and network effects, click here
4. Modules introduce technical debt
A new module always poses a technical risk to the reliability of a legacy EHR. New modules can come from an EHR vendor as a standard offering or as a customized solution designed to close functional gaps. Either way, an engineer must design and code this new module to play nicely with all the other aspects of the EHR.
The creator must also take versioning into account. For example, if the code base of the EHR or module is updated, will this supposed upgrade break other functionality? The more times a modular approach is used to address a use case, the greater amount of technical debt.
The more feasible approach to Integrated Care is through a modern platform, architected for and supported by true cloud technology. The freedom to configure administrative and clinical workflows without reliance on highly technical forms of support not only improves the collaborative potential between multiple providers and specialists, it enables the experimentation, evaluation, and validation processes necessary to make Integrated Care a success.
Integrated Care is an ambitious goal in health care based on the current landscape of available technology solutions. It carries with it a new set of challenges that demands support from technology in ways that have not been previously provided by EHRs. It is important to think about Integrated Care not as a module, but as a process that involves multiple use cases, providers, support systems, and the associated data sets and workflows for payment and compliance made possible only by a truly configurable platform.
Community behavioral health agencies that are serious about making Integrated Care work must be prepared to break away from the modular approach and embrace configurable platform technology.
[DEMOCTA cta=”Learn More”]
