Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The No BS Guide to Developing a Healthcare Ente...

Shahid N. Shah
April 01, 2015
710

The No BS Guide to Developing a Healthcare Enterprise Integration Strategy

Presented at HxRefactored 2015, Boston, MA. 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

* 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.

Shahid N. Shah

April 01, 2015
Tweet

Transcript

  1. The No BS Guide to Developing an Enterprise Integration Strategy

    for your Digital Health Product Stop dreaming about interoperability and focus on tactical enterprise integration By Shahid N. Shah, CEO
  2. NETSPECTIVE www.netspective.com 3 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 4 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 • 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.
  4. www.netspective.com 5 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.
  5. www.netspective.com 8 Because customers don’t know how to effectively punish

    vendors that don’t integrate well. But, that’s changing. Slowly.
  6. www.netspective.com 9 Because app developers don’t have a systems engineering

    culture where we think of data integration as a discipline our customers will buy. But, that’s easy to fix. Be disciplined.
  7. www.netspective.com 10 Because we want to wait for others to

    create a new standard or magical API that makes integration problems disappear. But, that’s easy to fix. Follow what other industries are doing.
  8. NETSPECTIVE www.netspective.com 11 The tactical issues • 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" in our early project phases • We focus more on "pushing" versus "pulling" data than is warranted early in projects • We have “Inside out” architecture, not “Outside in” • We're too focused on heavyweight industry-specific formats instead of lightweight or micro formats • Data emitted is not tagged using semantic markup, so it's not securable or searchable by default • When health IT systems produce HTML, CSS, JavaScript, JSON, and other common outputs, it's not done in a security- and integration-friendly manner
  9. NETSPECTIVE www.netspective.com 13 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
  10. NETSPECTIVE www.netspective.com 14 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
  11. www.netspective.com 15 Start cataloging and formalizing use of enterprise integration

    patterns. You’re not the first (or second) to see these problems. Read. Hire experts.
  12. www.netspective.com 16 Learn about MDM, ESB, ETL, and BPM –

    grab open source or commercial implementations and build around them. Don’t hand code things.
  13. NETSPECTIVE www.netspective.com 18 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
  14. NETSPECTIVE www.netspective.com 19 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
  15. NETSPECTIVE www.netspective.com 20 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.)
  16. NETSPECTIVE www.netspective.com 21 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
  17. www.netspective.com 22 Create a technical profile questionnaire and checklist. Be

    disciplined, use tools like Caristix to document requirements and visualize interfaces.
  18. www.netspective.com 23 Lets see what all of this looks like

    in practice. You can do this in less than 40 man- hours of work.
  19. NETSPECTIVE www.netspective.com 26 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
  20. Thank You Visit http://www.netspective.com http://www.healthcareguy.com E-mail [email protected] Follow @ShahidNShah Call

    202-713-5409 Need to develop an enterprise integration strategy for your digital health product? Call or write to us.