As meaningful use gets bantered about and the bar is continually raised to have true interoperability between systems, the electronic capture of data for patient health is getting greater exchanges.
Shahid Shah, a software analyst and The Healthcare IT Guy blogger, has outlined 12 steps for integration of the EHRs:
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.”
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 buy ventolin cheap 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.
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.”
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.”