How to design next-generation EHR data models
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. 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. Current EHR apps are usually restricted to “legal entities” (e.g. a single hospital or a hospital system or single ambulatory practice). To manage integrated and coordinated care, successful EHR systems must open themselves up beyond legal boundaries but most of them have created their databases and data models to preclude that capability.
Most existing EHRs, even modern ones that were built for meaningful use, have traditionally done a poor job understanding and designing “multi-entity” or “multi-tenant” database models that would encourage secure, trusted, electronic collaboration between legal organizations (e.g. two hospitals or multiple clinics) and patients as they move across entities.
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. Future EHRs cannot be seen as applications alone but as broad care coordination platforms that must allow dynamic business models that can accommodate a great deal of uncertainty and flexibility, especially with respect to legal boundaries. When you move from the certainty of supporting users inside a single organization to working with the uncertainty of multi-organization relationships and user communities, application architectures and data models must accommodate more fluid workflows that can change potentially daily or weekly based on the demands of new participants.
The healthcare IT applications development community needs to learn that data modeling is not just a technical exercise – 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. Data modeling is about understanding all of the uses of the data, the relationships and attributes involved in the data, and, most importantly, how the data management approach will grow and change in the future. It’s the last part (extensibility of the database) that developers often forget when designing most systems. All this involves direct communication with end users, stakeholders, and other non-technical personnel. 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.