Although the healthcare community has been clamoring for integration of its IT systems for decades, the industry is still in a rather elementary stage when it comes to useful and practical systems integration, according to Shahid Shah, software analyst and author of the blog The Health IT Guy.
"Our problem in the industry is not that engineers don’t know how to create the right technology solutions or that somehow we have a big governance problem," he said. "[Although] those are certainly issues in certain settings, the real cross-industry issue is much bigger – our approach to integration is decades old [and] opaque, and [it] rewards closed systems."
Shah outlines six reasons today's health IT systems don't integrate well.
1. They don’t support shared identities. These shared identities include single sign-on (SSO) and industry-neutral authentication and authorization, said Shah. "Most health IT systems create their own custom logins and identities for its users, including roles, permissions, access controls, etc., stored in an opaque part of their own proprietary database," he said, adding that ONC should mandate all future EHRs use "industry-neutral" and well-supported identity management technologies, so each system has, at least, the ability to share identities. "Without identity sharing and exchange, there can be no easy and secure application capabilities, no matter how good the formats are," he said.
2. They're too focused on "structured data integration." Instead, said Shah, systems should be focused on practical app integration in the early phases of a project. "In the early days of data collection and dissemination, it's not important to share structured data at detailed, machine-computable levels first, [but it's more] important that different applications have immediate access to portions of data they don't already manage." Once app integration is in good shape, he continued, then it's time to focus on structured data integration, and all the governance and analytics associated with it. "When we do structured data integration too early, we often waste time because we don't understand the use cases well enough, so we can't iterate to best-case solutions," he said. "We're driven to worst-case implementations."
[See also: 5 technologies every hospital should be using.]
3. They're more "push" data-focused versus "pull" data-focused. "A common question we ask at the beginning of every integration project is, 'What data can you send me?'" said Shah. "This is called the 'push' model, where the system that contains the data is responsible for sending to all those that are interested." Future EHRs need to implement syndicated ATOM-like feeds, which could contain HL7 or other formats, for all their data, so they can share and allow anyone who wants it to "subscribe" to the data, continued Shah. In turn, this is known as the "pull" model, or when data holders simply allow secure, authenticated subscriptions to their data without worrying about direct coupling with other apps. "If our future EHRs became completely decoupled secure publishers and subscribers of the data, many of our integration problems would go away like they did for others using modern Internet approaches," said Shah.
4. They're more focused on "heavyweight, industry-specific formats" instead of "lightweight, or micro formats." According to Shah, appointment scheduling in the "health IT ecosystem" is a major source of "health IT integration pain," he said. "If EHRs just used industry standard iCal/ICS publishing and subscribing, we could solve 80 percent of appointment schedule integration instantly." Shah continued and said to think about how an iPad can sync with an Outlook/Exchange server at work. "It's not magic – it's a basic, industry-neutral and appropriately securable standard, widely used and widely supported." Another example, he said, is the use of HL7 ADTs for patient profile exchanges, instead of more common and better-support standard like SAML. "If you've ever used your Google account/profile to log into another app on another website, you're using SAML," said Shah. "Again, no magic – it works millions of time a day with 'good enough' security and user-controlled privacy."
5. Data emitted are not tagged using semantic markup, so they're not shareable by default. "Even when we do have full data governance, we do our structured data integration and then we present information on the screen," said Shah. "We don't tag data with proper semantic markup, when it's basically free to do." Future EHRs, he continued, should generate Resource Description Framework-in-attributes (RDFa), using industry neutral schemas for common information, such as personal data. "Using RDFa as a start, EHRs can then start publishing full RDF in the future, so it's easier to discover where certain kinds of meta data can be found, without requiring massive registries and other old-style opaque techniques," he said. "None of this is technically challenging, insecure, or difficult to implement, if we really care about integration and are not just giving it lip service."
[See also: 5 stages of EHR maturity and patient collaboration.]
6. They don't produce common output in a security- and integration-friendly way. Shah said future EHRs should start to use industry-neutral CSS frameworks, such as Twitter's Bootstrap, which is both free and open source. "When using Javascript, EHRs should use common, lightweight, and integration-friendly libraries, like jQuery, and not Javascript frameworks that take over the app and view port, and prevent easy discovery and integration." When you omit Javescript Object Notation (JSON) from your APIs, Shah continued, offer both JSON and JSONP, so secure integration can occur more easily. "All of these techniques … are commonly accepted, secure Web practices and need to make their way into our EHRs," he said.
No comments:
Post a Comment