Reasons why health data is poorly integrated today and what we can do about it

Presented at StrataRX 2012: http://strataconf.com/rx2012/public/schedule/detail/25953

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.

Transcript

1. The Myth of Health Data Integration Complexity An opinionated look at why current health IT systems integrate poorly and what we can do about it By Shahid N. Shah, CEO
2. NETSPECTIVE www.netspective.com 2 Who is Shahid? • 20+ years of software engineering and multi- discipline complex IT implementations (Gov., defense, health, finance, insurance) • 12+ years of healthcare IT and medical devices experience (blog at http://healthcareguy.com) • 15+ years of technology management experience (government, non-profit, commercial) • 10+ years as architect, engineer, and implementation manager on various EMR and EHR initiatives (commercial and non- profit) Author of Chapter 13, “You’re the CIO of your Own Office”
3. NETSPECTIVE www.netspective.com 3 Background • A deluge of healthcare data is being created as we digitize biology, chemistry, and physics. • Data changes the questions we ask and it can actually democratize and improve the science of medicine, if we let it. • While cures are the only real miracles of medicine, big data can help solve intractable problems and lead to more cures. • Healthcare-focused software engineering is going to do more harm than good (industry-neutral is better). Key takeaways • Applications come and go, data lives forever. He who owns, integrates, and uses data wins in the end. • Never leave your data in the hands of an application/system vendor. • There’s nothing special about health IT data that justifies complex, expensive, or special technology. • Spend freely on multiple systems and integration-friendly solutions. What you’ll learn today Let’s stop the hand waving and relying on the government to take care of integration
4. NETSPECTIVE www.netspective.com 4 NEJM believes doctors are trapped It is a widely accepted myth that medicine requires complex, highly specialized information-technology (IT) systems. This myth continues to justify soaring IT costs, burdensome physician workloads, and stagnation in innovation — while doctors become increasingly bound to documentation and communication products that are functionally decades behind those they use in their “civilian” life. New England Journal of Medicine “Escaping the EHR Trap - The Future of Health IT”, June 2012
5. What’s creating the “data deluge”?
6. NETSPECTIVE www.netspective.com 6 Digitize biology Digitize chemistry Digitize physics Predict fundamental behaviors Digitize mathematics Digitize literature Digitize social behavior Predict human behavior We’re digitizing biology Last and past decades This and future decades Gigabytes and petabytes Petabytes and exabytes
7. NETSPECTIVE www.netspective.com 7 What’s creating “data deluge”? Proteomics Emerging •Must be continuously collected •Difficult today, easier tomorrow •Super-personalized •Prospective •Predictive Genomics Since 2000s, started at $100k per patient, <$1k soon •Can be collected infrequently •Personalized •Prospective •Potentially predictive •Digital •Family history is easy Phenotypics Since 1980s, pennies per patient •Must be continuously collected •Mostly Retrospective •Useful for population health •Part digital, mostly analog •Family History is hard Economics Since 1970, pennies per patient •Business focused data •Retrospective •Built on fee for service models •Inward looking and not focused on clinical benefits Biosensors Social Interactions
8. NETSPECTIVE www.netspective.com 8 Data changes the questions we ask Simple visual facts Complex visual facts Complex computable facts
9. NETSPECTIVE www.netspective.com 9 Implications for scientific discovery The old way Identify problem Ask questions Collect data Answer questions The new way Identify data Generate questions Mine data Answer questions
10. NETSPECTIVE www.netspective.com 10 We’re in the integration age Source: Geoffrey Raines, MITRE We’re not in an app-driven future but an integration- driven future. He who integrates the best, wins.
11. Recognizable Data Sources Where is all the data coming from?
12. NETSPECTIVE www.netspective.com 12 Data is hidden everywhere Clinical trials data (failed or successful) Secure Social Patient Relationship Management (PRM) Patient Communications, SMS, IM, E-mail, Voice, and Telehealth Patient Education, Calculators, Widgets, Content Management Blue Button, HL7, X.12, HIEs, EHR, and HealthVault Integration E-commerce, Ads, Subscriptions, and Activity-based Billing Accountable Care, Patient Care Continuity and Coordination Patient Family and Community Engagement Patient Consent, Permissions, and Disclosure Management
13. NETSPECTIVE www.netspective.com 13 More hidden sources of data Clinical systems Consumer and patient health systems Core transaction systems Decision support systems (DSS and CPOE) Electronic medical record (EMR) Managed care systems Medical management systems Materials management systems Clinical data repository Patient relationship management Imaging Integrated medical devices Clinical trials systems Telemedicine systems Workflow technologies Work force enabling technologies
14. NETSPECTIVE www.netspective.com 14 Unstructured patient data sources Patient Health Professional Labs & Diagnostics Medical Devices Biomarkers / Genetics Source Self reported by patient Observations by HCP Computed from specimens Computed real- time from patient Computed from specimens Errors High Medium Low Time Slow Slow Medium Reliability Low Medium High Data size Megabytes Megabytes Megabytes Data type PDFs, images PDFs, images PDFs, images Availability Common Common Common Uncommon Uncommon
15. NETSPECTIVE www.netspective.com 15 Structured patient data sources Patient Health Professional Labs & Diagnostics Medical Devices Biomarkers / Genetics Source Self reported by patient Observations by HCP Specimens Real-time from patient Specimens Errors High Medium Low Low Low Time Slow Slow Medium Fast Slow Reliability Low Medium High High High Discrete size Kilobytes Kilobytes Kilobytes Megabytes Gigabytes Streaming size Gigabytes Gigabytes Availability Uncommon Common Somewhat Common Uncommon Uncommon
16. What’s the problem? What are we doing wrong?
17. NETSPECTIVE www.netspective.com 17 Myth • I only have a few systems to integrate • I know all my data formats • I know where all my data is and most of it is valid • My vendor already knows how all this works and will solve my problems Truth • There are actually hundreds of systems • There are dozens of formats you’re not aware of • Lots of data is missing and data quality is poor • Tons of undocumented databases and sources • Vendors aren’t incentivized to integrate data Why you can’t just “buy interoperability” Interoperability of data is an emergent property of your IT environment
18. NETSPECTIVE www.netspective.com 18 Application focus is biggest mistake Application-focused IT instead of Data-focused IT is causing business problems. Healthcare Provider Systems Clinical Apps Patient Apps Billing Apps Lab Apps Other Apps Partner Systems Silos of information exist across groups (duplication, little sharing) Poor data integration across application bases
19. NETSPECTIVE www.netspective.com 19 NCI App NEI App NHLBI App Healthcare Provider Systems Clinical Apps Patient Apps Billing Apps Lab Apps Other Apps Master Data Management, Entity Resolution, and Data Integration Partner Systems Improved integration by services that can communicate between applications The Strategy: Modernize Integration Need to get existing applications to share data through modern integration techniques
20. How do we modernize integration?
21. NETSPECTIVE www.netspective.com 21 Why health IT systems integrate poorly Technology “Culture” • Permissions-oriented culture prevents tinkering and “hacking” • We don’t let patients drive data decisions. • No scripting or customizing EHRs, lab systems, etc. • Interoperability isn’t required for transactions to be completed (e- commerce) • We have “Inside out” architecture, not “Outside in” Actual Technology • We don't support shared identities, single sign on (SSO), and industry- neutral authentication and authorization • We're too focused on "structured data integration" instead of "practical app integration“ • We focus more on "pushing" versus "pulling" data than is warranted early in projects • We're too focused on heavyweight industry-specific formats instead of lightweight or micro formats
22. NETSPECTIVE www.netspective.com 22 Process and people consolidation won’t work in the future “For decades, businesses typically have been rewarded for consolidation around standard processes and stockpiling assets through people, technology and goods. Companies are discovering they need a new kind of leverage – capability leverage – to mobilize third parties that can add value.” Defining and coordinating interactions across a multitude of organizations is the new way • Outside-in architecture asks you to think about your operations and processes as a collection of business capabilities or services. • Each individual service must be analyzed and packaged to see who can deliver them best. According to Deloitte, “this architectural transition requires new skills from the CIO and the IT organization. CIOs who anticipate and understand the opportunity are likely to become much more effective business partners with other executive leaders.” Promote “Outside-in” architecture The IT department inside your organization cannot possibly do everything you’d like Source: Deloitte “Outside-in Architecture”
23. NETSPECTIVE www.netspective.com 23 Proprietary identity is hurting us • Most health IT systems create their own custom identity, credentialing, and access management (ICAM) in an opaque part of a proprietary database. • We’re waiting for solutions from health IT vendors but free or commercial industry- neutral solutions are much better and future proof. Identity exchange is possible • Follow National Strategy for Trusted Identities in Cyberspace (NSTIC) • Use open identity exchange protocols such as SAML, OpenID, and Oauth • Use open roles and permissions-management protocols, such as XACML • Consider open source tools such as OpenAM, Apache Directory, OpenLDAP , Shibboleth, or commercial vendors. • Externalize attribute-based access control (ABAC) and role-based access control (RBAC) from clinical systems into enterprise systems like Active Directory or LDAP . Implement industry-neutral ICAM Implement shared identities, single sign on (SSO), neutral authentication and authorization
24. NETSPECTIVE www.netspective.com 24 Dogma is preventing integration Many think that we shouldn’t integrate until structured data at detailed machine- computable levels is available. The thinking is that because mistakes can be made with semi-structured or hard to map data, we should rely on paper, make users live with missing data, or just make educated guesses instead. App-centric sharing is possible Instead of waiting for HL7 or other structured data about patients, we can use simple techniques like HTML widgets to share "snippets" of our apps. • Allow applications immediate access to portions of data they don't already manage. • Widgets are portions of apps that can be embedded or "mashed up" in other apps without tight coupling. • Blue Button has demonstrated the power of app integration versus structured data integration. It provides immediate benefit to users while the data geeks figure out what they need for analytics, computations, etc. App-focused integration is better than nothing Structured data dogma gets in the way of faster decision support real solutions
25. NETSPECTIVE www.netspective.com 25 Old way to architect: “What data can you send me?” (push) The "push" model, where the system that contains the data is responsible for sending the data to all those that are interested (or to some central provider, such as a health information exchange or HL7 router) shouldn’t be the only model used for data integration. Better way to architect: “What data can I publish safely?” (pull) • Implement syndicated Atom-like feeds (which could contain HL7 or other formats). • Data holders should allow secure authenticated subscriptions to their data and not worry about direct coupling with other apps. • Consider the Open Data Protocol (oData). • Enable auditing of protected health information by logging data transfers through use of syslog and other reliable methods. • Enable proper access control rules expressed in standards like XACML. Pushing data is more expensive than pulling it We focus more on "pushing" versus "pulling" data than is warranted early in projects
26. NETSPECTIVE www.netspective.com 26 HL7 and X.12 aren’t the only formats The general assumption is that formats like HL7, CCD, and X.12 are the only ways to do data integration in healthcare but of course that’s not quite true. Microsoft Excel & Access, Google Docs, etc. don’t have live access to our data in transactional systems such as EHRs. Consider industry-neutral protocols • Consider identity exchange protocols like SAML for integration of user profile data and even for exchange of patient demographics and related profile information. • Consider iCalendar/ICS publishing and subscribing for schedule data. • Consider microformats like FOAF and similar formats from schema.org. • Consider semantic data formats like RDF, RDFa, and related family. Industry-specific formats aren’t always necessary Reliance on heavyweight industry-specific formats instead of lightweight micro formats is bad
27. NETSPECTIVE www.netspective.com 27 Legacy systems trap valuable data In many existing contracts, the vendors of systems that house the data also ‘own’ the data and it can’t be easily liberated because the vendors of the systems actively prevent it from being shared or are just too busy to liberate the data. Semantic markup and tagging is easy • One easy way to create semantically meaningful and easier to share and secure patient data is to have all HTML tags be generated with companion RDFa or HTML5 Data Attributes using industry-neutral schemas and microformats similar to the ones defined at Schema.org. • Google's recent implementation of its Knowledge Graph is a great example of the utility of this semantic mapping approach. Tag all app data using semantic markup When data is not tagged using semantic markup, it's not securable or shareable by default
28. NETSPECTIVE www.netspective.com 28 Proprietary data formats limit findability • Legacy applications only present through text or windowed interfaces that can be “scraped”. • Web-based applications present HTML, JavaScript, images, and other assets but aren’t search engine friendly. Search engines are great integrators • Most users need access to information trapped in existing applications but sometimes they don’t need must more than access that a search engine could easily provide. • Assume that all pages in an application, especial web applications, will be “ingested” by a securable, protectable, search engine that can act as the first method of integration. Produce data in search-friendly manner Produce HTML, JavaScript and other data in a security- and integration-friendly approach
29. NETSPECTIVE www.netspective.com 29 Healthcare fears open source • Only the government spends more per user on antiquated software than we do in healthcare. • There is a general fear that open source means unsupported software or lower quality solutions or unwanted security breaches. Open source can save health IT • Other industries save billions by using open source. • Commercial vendors give better pricing, service, and support when they know they are competing with open source. • Open source is sometimes more secure, higher quality, and better supported than commercial equivalents. • Don’t dismiss open source, consider it the default choice and select commercial alternatives when they are known to be better. Rely first on open source, then proprietary “Free” is not as important as open source, you should pay for software but require openness
30. NETSPECTIVE www.netspective.com 30 Primary challenges • Tooling strategy must be comprehensive. What hardware and software tools are available to non-technical personnel to encourage sharing? • Formats matter. Are you using entity resolution, master data and metadata schemas, documenting your data formats, and access protocols? • Incentivize data sharing. What are the rewards for sharing or penalties for not sharing healthcare data? • Distribute costs. How are you going to allow data users to contribute to the storage, archiving, analysis, and management costs? • Determine utilization. What metrics will you use determine what’s working and what’s not?
31. Thank You Visit http://www.netspective.com http://www.healthcareguy.com E-mail shahid.shah@netspective.com Follow @ShahidNShah Call 202-713-5409