The document discusses what constitutes a healthcare IT platform. It defines a platform as a system that can be programmed and customized by outside developers, allowing it to be adapted to various needs. Most current health IT systems are apps, not platforms, as they cannot be programmed by third parties. True platforms offer various types of connectivity: Type 1 through accessible APIs, Type 2 through plugins, and Type 3 by hosting third-party code. An ideal health IT platform would incorporate patient engagement features while allowing customization, integration, and extensibility. It compares modern platforms favorably to legacy applications on several dimensions.

1. What is a healthcare IT platform?
By Shahid N. Shah
(based on Marc Andreeson’s definitions)

2. Who is Shahid?
• 20+ years of software engineering and
multi-site healthcare system deployment
experience
• 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
www.netspective.com Office” 2

3. NEXT-GENERATION HEALTH IT
NEEDS PLATFORMS

4. First came healthcare services
centralization…
www.netspective.com Source: Jason Hwang, Innosight, via Jeff Selberg of IHI 4

5. …then comes decentralization and
disruptive innovation
www.netspective.com Source: Jason Hwang, Innosight, via Jeff Selberg of IHI 5

6. Which leads to adaptive business
model innovation…
Viability
Models
www.netspective.com Source: Ian Morrison, The Second Curve, via Jeff Selberg of IHI 6

7. …and means the full patient record is
in various places that must connect
www.netspective.com Source: Jeff Selberg, IHI 7

8. Conclusion: we need real platforms
www.netspective.com 8

9. WHAT IS A HEALTH IT PLATFORM?

10. Definition according to Marc Andreeson
founder of Netscape & Opsware
A "platform" is a system that can be programmed
and therefore customized by outside developers --
users -- and in that way, adapted to countless needs
and niches that the platform's original developers
could not have possibly contemplated, much less
had time to accommodate.
...
The key term in the definition of platform is
"programmed". If you can program it, then it's a
platform. If you can't, then it's not.
www.netspective.com 10

11. Most health IT systems are apps, not
platform – be careful what you’re buying
• Remember: if you can program it, then it's a platform. If
you can't, then it's not.
• In this case “you” is not the developers but people outside
the original development team. This is crucial – if only the
original developers can add to a system, it’s not a platform.
To verify if something is a platform, ask the developers a
simple question: “can I, without your help or being on your
server, create software that connects to your system and
allows me to extend it?”
If the answer is no, it’s not a platform. Period.
www.netspective.com 11

12. A real platform’s power curve
Value as a platform
High-value
Platform
Platform
Number of ecosystem partners, community size, integration points
www.netspective.com 12

13. The Ideal Healthcare Platform
• Offers Type 1 connectivity through REST that
can be consumed by third-parties.
• Offers Type 2 connectivity through Java, .NET,
PHP or other language plugins that can be
developed by third parties.
• Offers Type 3 execution capabilities by hosting
3rd party code in a cloud environment.
www.netspective.com 13

14. Platform Type 1: Access API
Marc Andreeson writes that Type 1 is the kind of Internet platform
that is most common today. This is typically a platform provided in the
form of a web services API -- which will typically be accessed using an
access protocol such as REST or SOAP.
Architecturally, the key thing to understand about this kind of platform
is that the developer's application code lives outside the platform --
the code executes somewhere else, on a server elsewhere on the
Internet that is provided by the developer.
Examples: PracticeFusion, eBay, Paypal, Flickr, Delicious
• The entire burden of building and running the application itself is
left entirely to the developer
• The easiest kind of Internet platform to create
www.netspective.com 14

15. Platform Type 2: Plug-In API
This is the kind of platform approach that
historically has been used in end-user
applications to let developers build new
functions that can be injected, or "plug in", to
the core system and its user interface.
In the Internet realm, the first Level 2 platform
was the Facebook platform followed by
LinkedIn, OpenSocial, and others.
www.netspective.com 15

16. Platform Type 2: Facebook Example
Marc Andreeson writes that when you develop a Facebook app, you are not
developing an app that simply draws on data or services from Facebook, as
you would with a Level 1 platform. Instead, you are building an app that acts
like a "plug-in" into Facebook -- your app literally shows up within the
Facebook user experience, often as a box in the middle of a page that
Facebook otherwise defines, such as a user profile page.
• The third-party app itself lives outside the platform
• The entire burden of building and running a Level 2 platform-based app is
left entirely to the developer
• Unlike a Level 1 platform where the burden of exposing the app to users is
also placed on the developer, Level 2 Internet platforms -- as
demonstrated by Facebook -- will be able to directly help their developers
get users for their apps
• Level 2 platforms are significantly harder to create than Level 1 platforms
www.netspective.com 16

17. Platform Type 3: Runtime Environment
In a Level 3 platform, the huge difference is that the third-party
application code actually runs inside the platform -- developer code is
uploaded and runs online, inside the core system. For this reason, in
casual conversation Marc Andreeson refers to Level 3 platforms as
"online platforms".
A Level 3 platform will also superset Level 2 and Level 1 -- i.e., a Level 3
platform will typically also have some kind of plug-in API and some
kind of access API.
A Level 3 platform's developers upload their code into the platform
itself, which is where that code runs. As a developer on a Level 3
platform, you don't need your own servers, your own storage, your
own database, your own bandwidth, nothing... in fact, often, all you
will really need is a browser. The platform itself handles everything
required to run your application on your behalf.
www.netspective.com 17

18. Platform Type 3: The Future
• Level 3 platforms are much harder to build than Level 2
platforms.
• The level of technical expertise required of someone to
develop on your platform drops by at least 90%, and
the level of money they need drops to $0
• The Level 3 Internet platform approach is much more
like the computer industry's typical platform (PC)
model than Levels 2 or 1.
Level 3 platform examples include: Ning , Salesforce.com,
Amazon.com
www.netspective.com 18

19. The Ideal Health IT Platform Provides
Secure Social Patient Patient Communications, Meaningful Use EHR
Relationship SMS, IM, E-mail, Voice, Modules Ready for
Management (PRM) and Telehealth Certification
E-
Patient Education, Blue Button, HL7, X.12,
commerce, Ads, Subscrip
Calculators, Widgets, HIEs, EHR, and
tions, and Activity-based
Content Management HealthVault Integration
Billing
Accountable Care, Patient Consent,
Patient Family and
Patient Care Continuity Permissions, and
Community Engagement
and Coordination Disclosure Management
www.netspective.com 19

20. Comparison with legacy applications
Designed for transaction
Designed for patient /
processing and
documentation
Legacy Modern provider engagement
www.netspective.com 20

21. Comparison with legacy applications
Legacy Modern
Web vs. internal apps separation Same app on web and internal
Fixed workflows, non-social Customizable social workflows
Fixed screens and UI Themable / Branded UX
Standalone applications Designed for integration & mashups
Extensible fields & dynamic
Static fields & relationships
relationships
www.netspective.com 21

22. Modern Platform Connectivity
IHE-compliant health information exchange components that currently
support:
• Patient identity cross referencing (PIX v2/v3)
• Patient demographics query (PDQ v2/v3)
• Multi-patient query (MPQ)
• Cross-community patient discovery (XCPD)
• Cross-enterprise document sharing (XDS, XDS-I, XDS-MS, XDS-LAB, XDS-
SD)
• Cross-community Access (XCA)
• Cross-enterprise user assertion (XUA)
• Document subscriptions (DSUB)
• Shared Value Sets (SVS)
• Audit Trails and Node Authentication (ATNA)
• Basic Privacy and Patient Consent (BPPC)
www.netspective.com 22

23. THANK YOU