HxRefactored 2016 Keynote: The No BS Guide to Future Proofing your Digital Health Product Development Approach

At HxRefactored 2016 Shahid presented the following formula:

Px = Ux + Dx2 + Ix

It's the "digital health product success formula" that describes the main ingredients of a healthcare IT development approach that is most likely to succeed in a competitive market.

Many enterprise apps are being built these days, most are designed to work as a stand alone system similar to consumer apps. Any enterprise app which acts like a consumer app that doesn’t integrate well into hospital or ambulatory systems and workflows is doomed long term.

Transcript

1. Px = Ux + Dx 2 + Ix The No BS Guide to Future Proofing your Digital Health Product Development Approach By Shahid N. Shah, CEO This deck is available at: www.SpeakerDeck.com/shah
2. 2 www.SpeakerDeck.com/shah This and many of my other presentations are available at www.SpeakerDeck.com/shah @ShahidNShah shahid@shah.org www.ShahidShah.com
3. @ShahidNShah 3 www.SpeakerDeck.com/shah Who is Shahid? • Serial entrepreneur with externally funded startups including exits. • Angel investor, board member, in several digital health and Internet startups. • 20+ years of software engineering and multi-site healthcare system deployment experience in Fortune 50 and Government sectors. • 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) Entrepreneur, investor, contributing author, blogger, engineer, and healthcare futurist
4. @ShahidNShah 4 www.SpeakerDeck.com/shah What’s this talk about? Background • Many enterprise apps are being built these days, most are designed to work as a stand alone system similar to consumer apps • Healthcare-specific software engineering and integration tools are going to do more harm than good (industry-neutral is better). Key takeaways • Any enterprise app which acts like a consumer app that doesn’t integrate well into hospital or ambulatory systems and workflows is doomed long term • There’s nothing unique about health IT data that justifies complex, expensive, or special technology. • There’s a lot unique about healthcare workflows that require common technologies to be adapted properly.
5. 5 www.SpeakerDeck.com/shah My focus today P x = U x + D x 2 + I x Digital Health (SMACk*) (Patient, Provider, Payer, Pharmacy, Pharmaceutical, or Phamily) Experience Multi-stakeholder, multi-institution Outcomes and results focused
6. 6 www.SpeakerDeck.com/shah P x = U x + D x 2 + I x My focus today User (human*) experience Design centered, empathy-driven Culture-sensitive JTBDs and PTBS aware
7. 7 www.SpeakerDeck.com/shah P x = U x + D x 2 + I x My focus today Data experience (liquidity & access) Developer experience (extensibility & platform) DIY ready Maker movement ready “Boost the signal” #InventHealth
8. 8 www.SpeakerDeck.com/shah P x = U x + D x 2 + I x My focus today Integration experience information architecture alignment, workflow synchronization, context coordination
9. @ShahidNShah 9 www.SpeakerDeck.com/shah My focus today P x = U x + D x 2 + I x
10. First, let’s look at some common developer myths and misconceptions Reality needs to set into developers’ expectations
11. @ShahidNShah 11 www.SpeakerDeck.com/shah No, you will not disrupt healthcare… This is $1 Trillion and the Healthcare Market is about $3 Trillion This is $1 Billion
12. @ShahidNShah 12 www.SpeakerDeck.com/shah Because path to payment is not easy
13. 13 www.SpeakerDeck.com/shah Nothing you do matters to the healthcare “industry”. But a lot of what you do could matter to specific stakeholders.
14. 14 www.SpeakerDeck.com/shah No, your big data, telehealth, or mobile ideas will not change the practice of medicine. But if you can use them to add or extract value from the existing system, you’ll do just fine.
15. 15 www.SpeakerDeck.com/shah No, your EHR/PHR or app will not be used by enough doctors or patients to matter to the “industry” or SoC. But if you can get even a fraction of them to use your software, you’ll do just fine.
16. 16 www.SpeakerDeck.com/shah No, your new genomics, diagnostics, or medications will not easily be accepted by permissions-oriented “eminence driven” institutions. Find customers with a problem-solving culture willing to share risks and reward failures.
17. 17 www.SpeakerDeck.com/shah No, your offerings will not be easily integrated into regulated device-focused clinical workflows. Incumbent vendors will not entertain the potential of new legal liabilities without someone to share it with or new competition without direct compensation.
18. 18 www.SpeakerDeck.com/shah No, I do not believe you when you say you have no competition. Staying with the “status quo” or indirect competition from entrenched workflows and slow-changing business models are huge barriers.
19. Which experience are you targeting? We struggle to build the right products
20. @ShahidNShah 20 www.SpeakerDeck.com/shah PIBU: Payer vs. Influencer vs. Benefiter vs. User Payer Benefiter Influencer User If you don’t understand the exact interplay between PIBU your sale will fail The payer is the person/entity that writes the check for your product. The person or group that benefits most from the use of the product. Or the person or group who influences the users. The person or group that actually uses the product.
21. @ShahidNShah 21 www.SpeakerDeck.com/shah Why building healthcare tools is hard Easy sell (e.g. iPhones, tablets, pagers) Physician Pays Physician Benefits Physician Uses Hard sell (e.g. medical devices / EHRs) Institution Pays Gov’t Benefits Physician Uses
22. @ShahidNShah 22 www.SpeakerDeck.com/shah Why your customers don’t trust you 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
23. @ShahidNShah 23 www.SpeakerDeck.com/shah 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 How they will begin to trust you Need to get existing applications to share data through modern integration techniques
24. 24 www.SpeakerDeck.com/shah There is no interoperability crisis in healthcare. Even if there was, there’s nothing you can do about it so stop complaining. There is, however, a vendor management and incentives alignment crisis.
25. @ShahidNShah 25 www.SpeakerDeck.com/shah This practical view is possible today
26. 26 www.SpeakerDeck.com/shah http://blog.syntelinc.com/it-healthcare-data-transmission-standards-health-information-exchange/ • EDI (Electronic Data Interchange): EDI is primarily used for interactions between care providers and health insurers. • HL7 (Health Level Seven): HL7 is similar to EDI; it is mainly used for transmitting data for all events that occur within a hospital. • DICOM (Digital Imaging and Communications in Medicine): Medical Images (X-Ray, MRI, etc.) are stored/transmitted/printed in a PACS (picture archiving and communication system) system using DICOM. • CCR/CCD (Continuity of Care Record / Document): CCD/CCR is a compact form with Patient’s health status summary. Under Meaningful Use a new format—CDA—which is a combination of the best features of CCD and CCR, is proposed. • NCPDP (National Council for Prescription Drug Programs): Family of pharmacy data standards • HITSP (Healthcare Information Technology Standards Panel): Related to transmission of immunization data, bio surveillance, clinical research, etc.
27. 27 www.SpeakerDeck.com/shah Source: http://jimenezconsulting.com/industries/healthcare/regulatory/hipaa5010
28. 28 www.SpeakerDeck.com/shah Interoperability without job stories, use cases, and incentives is just hand waving. Specialization is key. Take lessons from SureScripts, IHE, S&I Framework, PokitDok, Redox, MI7, etc.
29. 29 www.SpeakerDeck.com/shah Why do health IT systems integrate poorly?
30. 30 www.SpeakerDeck.com/shah Because customers don’t know how to effectively punish vendors that don’t integrate well. But, that’s changing – startups are being punished now, incumbents will be next.
31. So what do we do? And now…
32. @ShahidNShah 32 www.SpeakerDeck.com/shah Legacy integration Application A Data Functionality Presentation Feature Y Feature X Application B Data Functionality Presentation Feature Y Feature X Feature Z Copy features and enhance (everything is separate) Application A Data Functionality Presentation Feature Z Feature X Application B Data Functionality Presentation Feature Y Feature X Feature Z Connect directly to existing data, but copy features and enhance
33. @ShahidNShah 33 www.SpeakerDeck.com/shah Services Modern integration Application A Data Functionality Presentation Feature Y Feature X Application B Data Functionality Presentation Feature Y Feature X Feature Z Create API between applications, integrate data, create new data Application A Data Functionality Presentation Feature Z Feature X Application B Data Functionality Presentation Feature Y Feature X Feature Z Create common services and have all applications use them REST SOAP, RMI SOA ETL WOA APIs
34. 34 www.SpeakerDeck.com/shah Start cataloging and formalizing use of enterprise integration patterns. You’re not the first (or second) to see these problems. Read. Hire experts.
35. @ShahidNShah 35 www.SpeakerDeck.com/shah Start with read-centric integration, move to enrichment later Where users spend time What they’re missing
36. @ShahidNShah 36 www.SpeakerDeck.com/shah Stop and think about workflows Sexy but wrong: Device-centric closed systems Dull but right: Workflow-centric open solutions
37. 37 www.SpeakerDeck.com/shah Learn about MDM, ESB, ETL, and BPM – grab open source or commercial implementations and build around them. Don’t hand code things.
38. @ShahidNShah 38 www.SpeakerDeck.com/shah Promote “Outside-in” architecture Think about clinical and hospital operations and processes as a collection of business capabilities or services that can be delivered across organizations.
39. @ShahidNShah 39 www.SpeakerDeck.com/shah Promote “Outside-in” architecture Patients and Referral Partners Clinical Personnel Admin Personnel IT Personnel Unsophisticated and less agile focus Sophisticated and more agile focus Inside-out focus Outside-in focus
40. @ShahidNShah 40 www.SpeakerDeck.com/shah 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
41. @ShahidNShah 41 www.SpeakerDeck.com/shah 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
42. @ShahidNShah 42 www.SpeakerDeck.com/shah 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) • Use HL7 FHIR or 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
43. @ShahidNShah 43 www.SpeakerDeck.com/shah FHIR will not save us 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. 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
44. @ShahidNShah 44 www.SpeakerDeck.com/shah 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
45. @ShahidNShah 45 www.SpeakerDeck.com/shah 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
46. @ShahidNShah 46 www.SpeakerDeck.com/shah 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
47. How to integrate into hospital networks
48. 48 www.SpeakerDeck.com/shah Create a formal Enterprise Integration Group (EIG). Even get a cool logo and team mascot.
49. @ShahidNShah 49 www.SpeakerDeck.com/shah Popular cloud data exchange approach DHP Protected Environment CDO’s Protected Environment * Practice’s Systems Filter for DHP Patients Encrypt and Transmit DHPSB DHPSB DHP Data Repository (DHPDR) Encrypt and Transmit * EHR could be a standalone or hosted by a service provider DHP = Digital Health Product DHPSB = Digital Health Product Service Bus
50. @ShahidNShah 50 www.SpeakerDeck.com/shah In cloud, data filter strategy is crucial Encrypt and Transmit Filter using CDO’s rules Customize to send only filtered data Send data for all CDO’s patients Preferred Option Send all data and let the DHP Gateway perform the filter Alternate Option Pre-filter data from each practice system before it reaches DHP Gateway Alternate option requires more work on the CDO’s part; the preferred option requires more work on the DHP’s part Encrypt and Transmit DHP Protected Environment
51. @ShahidNShah 51 www.SpeakerDeck.com/shah Data architecture questions to pose 1. Kinds of data to collect (e.g. demographics, medications, labs, physician notes, etc.) - we need this in excruciating, painful detail. Lots of arguments will emerge here and that's really good. This means we give specific field names, field types, data lengths, etc. as part of the requirements. 2. Frequency of data to collect (e.g. real-time, hourly, daily, etc.) 3. Data code types (e.g. LOINC, CPT, ICD9, ICD10, etc.) 4. Discrete and structured data standards (e.g. CCR, CCD, BB+, etc.) 5. Directionality (unidirectional from EHR to DHP , bidirectional between both EHR and DHP) 6. File types and transport types (HL7, CSV, etc.) 7. Broad source types (BlueButton, BlueButton+, Ambulatory EHR, Health System EHR, Private HIE, Public HIE, etc.) 8. Specific sources (e.g. named customers, named EHRs, named HIE, etc.)
52. @ShahidNShah 52 www.SpeakerDeck.com/shah Healthcare integration RACI • Name the EHR or HIE (or any other source named in #7/#8 above) • Coordinate with the legal and executive team to ensure that you have legal rights to the data • Coordinate with the IT team at the system owner at the client (usually a covered entity but could be a systems integration firm or consulting outfit) • Coordinate with the EHR or HIE vendor see how cooperative they are • Send the EHR or HIE vendor the Enterprise Integration document and have them fill that out in collaboration with your team • Get physical access to the vendor’s database or system
53. 53 www.SpeakerDeck.com/shah Create a technical profile questionnaire and checklist. Be disciplined, use tools like Caristix to document requirements and visualize interfaces.
54. 54 www.SpeakerDeck.com/shah Lets see what all of this looks like in practice. You can do this in less than 40 man- hours of work.
55. Thank You Visit http://www.netspective.com http://www.healthcareguy.com E-mail shahid.shah@netspective.com Follow @ShahidNShah Call 202-713-5409 Need help with your innovation? Tweet, call or write to me.