Description

Presented at StrataRX 2012:

While the entire healthcare community, for decades, has been clamoring for, cajoling, and demanding integration of its IT systems, we’re actually in a pretty elementary stage when it comes to useful, practical, health IT systems integration beyond on-premise and in-building hospital software. 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; while those are certainly issues in certain settings, the real cross-industry issue is much bigger – our approach to integration is decades old, opaque, and rewards closed systems.

For decades, starting in the 50’s through the mid 90’s before the web / Internet came along, systems integration meant that every system had to know about each other in advance, decide on what data they would share, engage in governance meetings, have memoranda of understanding or contracts in place, etc. After the web came along, most of that was thrown out the window because the approach changed to one that said the owner of the data provides whatever they decide (e.g. through a web server) and whoever wants it will be provided secure access and they can come get it (e.g. through a browser or HTTP client). This kind of revolutionary approach in systems integration is what the health IT and medical device sectors are sorely lacking and something that ONC can help promote.

Specifically, the following things are holding us back when it comes to poor integration in healthcare and what future EHRs can do about it:

• We don’t support shared identities, single sign on (SSO), and industry-neutral authentication and authorization. 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. ONC should mandate that all future EHRs use industry-neutral and well supported identity management technologies so that each system has a least the ability to share identities. Without identity sharing and exchange there can be no easy and secure application integration capabilities no matter how good the formats are. I’m continually surprised how little attention is paid to this cornerstone of application integration. There are very nice open identity exchange protocols, such as SAML, OpenID, and oAuth as well as open roles and permissions management protocols such as XACML that make identity and permission sharing possible. Free open source tools such as OpenAM, Apache Directory, OpenLDAP, Shibboleth, and many commercial vendors have drop-in tools to make it almost trivial to do identity sharing, SSO, and RBAC.

• We’re too “structured data integration” focused versus “practical app integration” in our early project phases. In early days of data collection and dissemination (it’s sad to say that after 50 years of computing we’re in early days of health IT but it’s true) it’s not important to share structured data at detailed machine-computable levels first but more important that different applications have immediate access to portions of data they don’t already manage. Once app integration, using SSO and identity sharing and simple formats like JSON, is in good shape, then we should focus on structured data integration with 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 (we’re driven to worst-case implementations). The VA’s successful Blue Button approach has demonstrated the power of app integration vs. structured data integration – it has more immediate benefit to users while the data geeks figure out what they need for analytics, computations, etc. Future EHRs must be masters at producing and consuming secure authenticated application widgets using industry-standard approaches such as JavaScript and JSON. Widgets are snippets or portions of apps that can be embedded or “mashed up” in other apps without each app needing tightly coupling each other.

• We’re more “push data” versus “pull data” focused than is warranted early in projects. A common question we commonly ask at the beginning of every integration project is “what data can you send me?” This is called the “push” model where the system that contains the data is responsible for sending to all those that are interested (or to some central provider like an HIE). What future EHRs should do is to implement syndicated ATOM like feeds (which could contain HL7 or other formats) for all their data that they can share and allow anyone who wants it to “subscribe” to the data. This is called the “pull” model where data holders simply allow secure authenticated subscriptions to their data and not worry about direct coupling with other apps. If our future EHRs became completely decoupled secure publishers and subscribers of then data many of our integration problems would go away just like they did for others using modern internet approaches.

• We’re more “heavyweight industry-specific formats” focused instead of “lightweight or micro formats” focused. Appointment scheduling in the health IT ecosystem is a major source of health IT integration pain (in fact much worse than most other areas). If EHRs just used industry standard iCal/ICS publishing and subscribing we could solve 80% of appointment schedule integration instantly. Think about how your iPAD can sync with your Outlook/Exchange server at work – it’s not magic, it’s a basic industry-neutral appropriately securable standard widely used and widely supported. Another example is the use of HL7 ADTs for patient profile exchanges instead of more common and better supported like SAML (which emerged due to industry-neutral user identity and profile exchange requirements). If you’ve ever used your Google account/profile to log into another app on another website you’re using SAML. Again, no magic—it works millions of times a day with “good enough” security and user-controlled privacy.

• Data emitted is not tagged using semantic markup so it’s 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 (usually to HTML) we don’t tag data with proper semantic markup when it’s basically free to do (no extra development is required). Future EHRs must at least generate companion RDFa using industry-neutral schemas for common information (e.g. person data) and create microformats to specific information (e.g. clinical). 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. 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. Google’s recent implementation of its Knowledge Graph is a great example of the utility of this semantic mapping approach. Once even basic microformats are in place with RDFa for authenticated or unauthenticated semantic tagging then we can create SPARQL endpoints for easier to understand data.

• When we produce HTML, CSS, JavaScript, JSON, and other common output we don’t produce it in a security and integration-friendly manner. Future EHRs should start to use industry-neutral CSS frameworks like Twitter’s Bootstrap (which is free and open source). When using JavaScript, ERHs should use common lightweight and integration-friendly libraries like jQuery and not JavaScript frameworks with take over the app and viewport and prevent easy discovery and integration. When you emit JSON from your APIs, offer both JSON and JSONP so that secure integration can occur more easily. All of these techniques I’ve mentioned are commonly accepted secure web practices and need to make their way into our EHRs.