With the rise of accountable care organizations (ACOs) and patient-centered medical homes (PCMH), the spotlight has been put on IT to help make a smoother transition to those new care models. And although the partnership between patient and EHR plays a critical role in their success, Shahid Shah, software analyst and author of the blog The Healthcare IT Guy, believes EHRs have a long way to go before they can take on the full responsibility of supporting these organizations.
"Today's reality of patient management is 'disjointed care,' and most of the collaborators in a patient's care team don't know what each other is doing for the patient in real time," he said.
[See also: 5 reasons EHR functionality hasn't changed since 1982.]
"Knowing all the different participants in the patient's care team – providers, payers, family members, etc. – and coordinating and integrating their electronic activities is what successful EHRs must handle with ease, as they look to graduate from basic retrospective documentation systems to modern patient collaboration platforms."
Shah outlines five things that need to change for EHRs to support next generation business models.
1. "Legal entities" need to go. Today's EHR apps are typically restricted to what Shah called "legal entities," or a single hospital, hospital system or ambulatory practice. "To manage integrated and coordinated care, successful EHR systems must open themselves up beyond legal boundaries," he said. "But, most of them have created their databases and data models to preclude that capability."
2. Multi-entity designs need to come to the forefront. Most EHRs, and even those that were built for meaningful use, said Shah, have traditionally done a bad job of understanding and designing "multi-entity" or "multi-tenant" database models, which encourage secure and trusted electronic collaboration between, for example, two hospitals or two clinics. "This is due not to the lack of availability of good design patterns, but a lack of comprehension that tomorrow's shared savings initiatives, capitated payment models, ACOs, and PCHMs require a level of coordination and amount of measurements of quality metrics that are tough to define, implement, and secure," he said.
3. EHRs need to be seen as care coordination platforms. In the future, EHRs can't be seen as just applications, said Shah, but instead, as "broad care coordination platforms, [which] must allow dynamic business models that can accommodate a great deal of uncertainty and flexibility." This is especially true, he added, when it comes to legal boundaries. When transitioning from supporting a set group of users in one organization, to supporting a multitude of user communities and relationships, "application architectures and data models must accommodate more fluid workflows," said Shah.
4. The focus needs to be on the data. "The healthcare IT applications development community needs to lean that data modeling isn't just a technical exercise," said Shah. "That's what leads to bad designs that don't incorporate next generation business models. You can't define a data model with a bunch of engineers and other geeks sitting around a table." Instead, he said, data modeling is about understanding all of the data's uses, and, not to mention, the relationships and attributes involved in the data. Most importantly, Shah added, is understanding how the data management approach will grow and change in the future.
[See also: Oregon Health Network's 12 HIT best practices, part 4: Implementation pain.]
5. Organization and communication is key. Extensibility of the database, said Shah, is what developers most often forget when designing most systems. "All of this involves direct communication with end users, stakeholders, and other non-technical personnel," he said. "Too often, databases are treated as a file cabinet – just let your application toss whatever is necessary in there and then deal with organizing it later. But in the emerging world of ACOs and PCMH, that won't be possible."
Follow Michelle McNickle on Twitter, @Michelle_writes.
