7 attributes next-generation EHRs will need to support
April 18, 2012 in Medical Technology
As the role of the EHR is shifting to support next-generation business models like accountable care organizations and patient-centered medical homes, it’s no secret some of their functions could use a little fine-tuning.
And, in addition to a more data-focused approach and an understanding of EHRs as care coordination platforms, Shahid Shah, software analyst and author of the blog The Healthcare IT Guy, believes EHRs need to support a specific set of characteristics to truly be successful in the years to come.
He outlines seven types of attributes next generation EHRs will need to support.
1. Flexible patient-centric “person” models. Modern and “extensible” databases tend to model patient, physician, nurse, staff member, administrator, contact, insurance policy holder and related data as what Shah called, “person records.” “Instead of having a separate table for each type of person – for example, a different table for a patient versus a physician – you should try to model the different person types in a single inheritable and related table,” he said.
2. Flexible, multi-facility “organization” models. The above goes for organizations as well, said Shah. “Facilities, tenants, hospitals, insurance providers, departments, clinics, administration and related data should be grouped into something conceptually called an organization,” he said. “Any entity that isn’t a ‘person’ type will likely fall into the ‘organization’ record type category – a single tablet with appropriate attributes should work fine.”
[See also: Epocrates returns to mobile core.]
3. Robust patient identification and de-duplication. When working in a multi-entity legal framework, said Shah, there won’t be a single patient identifier to “rule all the systems.” Good data models, he said, allow an unlimited number of “mappable” identifiers for any entity – a primary key for internal consistency, plus any number of external identifiers, he said. “Every ‘person’ record should allow an extensible set of identification values to use for both ID lookups and de-duplication requirements that crop up when integrating multiple systems,” he said.
4. Support for the separation of PHI from clinical and transactional attributes. “A good design is to put PHI data into one database, configured with proper security, and put the clinical, business and other attributes into another database,” said Shah.
5. Support for multiple simultaneous entity roles. Each entity in the database, such as a person or an organization, said Shah, should be able to support multiple entity roles. “We already described that a ‘person’ record should be created in a common table for patients, physicians, nurses, and so on, and why that makes sense,” he said. But, he continued, it’s important to think about a scenario where a nurse at a hospital could, for example, be a patient in the same hospital. “Instead of duplicating records, the same record could take on dual roles,” said Shah. “In this case, as both a nurse and a patient.”
6. Support for long-term storage. Shah said this includes change management, or revision control, of all entity attributes. “When data loves for a long time, it can change,” he said. “Extensible databases support long-term storage, change management of the database structures, and revision control of the data or records.”
[See also: InterSystems spotlights partner for 'breakthrough' app.]
7. Support for multiple applications and devices within the same structures. “When creating a database, always assume multiple applications will write to the same database,” said Shah. This means that, for every record written, you should track which application wrote or changed the record. “And, perhaps which device,” he said.
Follow Michelle McNickle on Twitter @Michelle_writes