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

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

View Slide

2
www.SpeakerDeck.com/shah
This and many of my other presentations are available at
@ShahidNShah
[email protected]
www.ShahidShah.com

View Slide

@ShahidNShah
3
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

View Slide

@ShahidNShah
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 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.

View Slide

5
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

View Slide

6
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

View Slide

7
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

View Slide

8
P
x
= U
x
+ D
x
2 + I
x
My focus today
Integration experience
information architecture alignment,
workflow synchronization,
context coordination

View Slide

@ShahidNShah
9
My focus today
P
x
= U
x
+ D
x
2 + I
x

View Slide

First, let’s look at some common developer myths
and misconceptions
Reality needs to set into developers’ expectations

View Slide

@ShahidNShah
11
No, you will not disrupt healthcare…
This is $1 Trillion and the
Healthcare Market is about
$3 Trillion
This is $1 Billion

View Slide

@ShahidNShah
12
Because path to payment is not easy

View Slide

13
Nothing you do matters to the
healthcare “industry”.
But a lot of what you do
could matter to specific
stakeholders.

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Which experience are you targeting?
We struggle to build the right products

View Slide

@ShahidNShah
20
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.

View Slide

@ShahidNShah
21
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

View Slide

@ShahidNShah
22
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

View Slide

@ShahidNShah
23
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

View Slide

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

View Slide

@ShahidNShah
25
This practical view is possible today

View Slide

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

View Slide

27
Source: http://jimenezconsulting.com/industries/healthcare/regulatory/hipaa5010

View Slide

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

View Slide

29
Why do health IT systems
integrate poorly?

View Slide

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

View Slide

So what do we do?
And now…

View Slide

@ShahidNShah
32
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

View Slide

@ShahidNShah
33
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

View Slide

34
Start cataloging and
formalizing use of
enterprise integration
patterns.
You’re not the first (or second) to see
these problems. Read. Hire experts.

View Slide

@ShahidNShah
35
Start with read-centric integration, move to enrichment later
Where users spend time What they’re missing

View Slide

@ShahidNShah
36
Stop and think about workflows
Sexy but wrong: Device-centric closed systems Dull but right: Workflow-centric open solutions

View Slide

37
Learn about MDM, ESB, ETL, and
BPM – grab open source or
commercial implementations and
build around them.
Don’t hand code things.

View Slide

@ShahidNShah
38
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.

View Slide

@ShahidNShah
39
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

View Slide

@ShahidNShah
40
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

View Slide

@ShahidNShah
41
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

View Slide

@ShahidNShah
42
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

View Slide

@ShahidNShah
43
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

View Slide

@ShahidNShah
44
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

View Slide

@ShahidNShah
45
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

View Slide

@ShahidNShah
46
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

View Slide

How to integrate into hospital networks

View Slide

48
Create a formal Enterprise
Integration Group (EIG).
Even get a cool logo and team mascot.

View Slide

@ShahidNShah
49
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

View Slide

@ShahidNShah
50
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

View Slide

@ShahidNShah
51
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.)

View Slide

@ShahidNShah
52
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

View Slide

53
Create a
technical profile
questionnaire
and checklist.
Be disciplined, use tools like
Caristix to document
requirements and visualize
interfaces.

View Slide

54
Lets see what all
of this looks like in
practice.
You can do this in less than 40 man-
hours of work.

View Slide

Thank You
Visit
http://www.netspective.com
http://www.healthcareguy.com
E-mail [email protected]
Follow @ShahidNShah
Call 202-713-5409
Need help with your innovation?
Tweet, call or write to me.

View Slide

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

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

Shahid N. Shah

More Decks by Shahid N. Shah

Other Decks in Technology

Featured

Transcript