12 integration capabilities EHRs will need to have

By Michelle McNickle
05:40 PM
Share

With Stage 2 waiting in the wings, the focus is now shifting onto the electronic capture of health information and fostering data exchange at points of care transitions, said Shahid Shah, software analyst and author of the blog, The Healthcare IT Guy. And unlike meaningful use Stage 1, Stage 2 is looking to "raise the bar" and require true interoperability. 

"Current generation EHRs already do some, if not most, of the requirements recommended for Stage 2," he said. "But the reason they won’t meet or exceed the requirements of modern interoperability is [because] next-generation EHRs need far more sophisticated integration capabilities, not just basic interoperability between systems as suggested by the MU Stage 2 NPRM." 

Shah outlined 12 integration capabilities the next-generation of EHRs will need to have. 

1. Single sign-on (SSO) using SAML and other commercial industry standards. One attribute of applications, particularly mHealth apps, said Shah, is they proliferate. "You start with one small one, then another, and then more," he said. "That's exactly what should happen, because healthcare is complex and needs [a lot] of solutions." But, he continued, if you don't manage user authentication and authorization centrally, while allowing people to switch between these applications using a common login and password, you'd soon have applications that users don't want to use. Luckily, he said, there are a myriad of options for "common authentication and single sign-on, such as SAML and CAS … your next-generation EHR should include an industry-standard SSO capability." 

2. Patient context awareness and context transitions between apps. As applications proliferate and you need to integrate them into an EHR system, Shah said, you'll realize that, even if you have Single Sigh On in place, you will lose the context – or the "active patient" or "active task" being performed – unless you understand how to track patient context and transition of context between the applications. "There are a few good approaches, such as CCOW," he said. "You can start with [that], but, allowing your EHRs to be controlled through custom APIs is a great approach, too." 

3. Publishing widgets. According to Shah, next-generation EHRs should allow the ability to "publish" their features as widgets, through proper authorization and authentication, as well as single sign-on. "As Wikipedia notes, a widget is a 'generic type of software application, comprising portable code,' which, 'implies that either the application, user interface, or both, are light, [or] relatively simple and easy to use,'" he said. "EHRs often have hundreds of functions, and if some, or many, of those functions are exportable or publishable as 'widgets,' then they become much easier to integrate into new user interfaces in the future." 

[See also: Epocrates drops plans for EHR.]

4. Consuming widgets. "Some forward-leaning EHR vendors already know how to consume basic widgets that are already published across the web," said Shah. "Next-generation EHRs will need to do so in a sophisticated and easier manner than the current offerings allow." Future EHRs, he continues, will become more like containers of cross-application functionality, instead of innate functionality. "So consuming widgets will be a basic requirement," he said. 

5. Mash-ups, with or without CMIS. To Shah, EHRs are "really nothing more than fancy content management systems (CMS) or document management systems (DMS)." According to him, next-generation EHRs should allow access to their content through the "relatively mature" content management interoperability services (CMIS) standard. "The CMIS specification provides a Web service interface that is designed to work over existing repositories, enabling customers to build and leverage applications against multiple repositories." In turn, this allows customers to unlock content they already have in their various health record solutions. "EHRs with good CMIS interfaces provide common Web services and Web 2.0 interfaces to dramatically simplify application development," he said. 

6. Customizable dashboards. With proper single sign-on, patient context awareness, widgets and mash-up capabilities, future EHRs will be able to provide "sophisticated and highly customizable dashboards that can be tailored by user, by user role, by organization, or [by] other rules," he said. 

Continued on the next page. 

7. Interactive Voice Response (IVR). IVR has been around for a while, said Shah, and allows computer systems such as EHRs to interact with users through phones and other voice systems, such as Skype, through keypads or basic voice commands. "Next-generation EHRs should use IVRs to help improve collaboration with patients and other physicians, since they won't always be at a computer," he said. 

8. Voice recognition. "Voice recognition systems, like Apple's Siri, may seem like they're new, but they've actually been around for decades," said Shah. "Integration with voice commands and speech recognition to be able to perform data collection and other tasks in EHRs should be basic functions." But, he continued, most of today's EHRs don't know how to consume voice. "With modern solutions … voice-recognition based integration is actually pretty easy." 

[See also: Adventist to roll out EHRs at 130 clinics.]

9. Natural language understanding. Since most data in EHRs will still be human-entered and manually collected, unstructured text data, next-generation EHRs, "must integrate with natural language-understanding systems that can take human spoken [word] or typed text and automatically convert it to structured data to whatever extent possible," said Shah. 

10. Customizable import and export of data. Although this may seem like a basic requirement, said Shah, many current EHRs don't allow the easy import or export of data. "Future EHRs must allow customizable importing and exporting of simple lists, like patient census, population health, and other data lists in common formats, like Excel, CSV and XML." If you're looking at an EHR that doesn't support customizable import or export, he said, "don't buy it." 

11. HL7 info button. Because online health sources that provide up-to-date information to patients and doctors are widely available, it's important for future EHRs to connect the "patient context and details available in the EHR to public knowledge resources," said Shah. "The HL7 info button is a proposed standard for this capability, and in MU Stage 2, it's a recommended requirement for certified systems." 

12. HL7 messages and data types. "HL7 is widely used across many EHRs, but its depth of capabilities and usage across its vast message sets is not always thoroughly implemented," said Shah. "MU Stage 2 has standardized on HL7 2.5.1, and next-generation EHRs need to use it across their ecosystems." 

Follow Michelle McNickle on Twitter, @Michelle_writes