This talk was originally given by Redox Developer Nick Hatt at HIMSS18 Developer Innovation Lab.

1. Open vs Closed: APIs to Enable
Interoperability
Nick Hatt
@nickredox
https://github.com/nwhatt
Booth #1275
Interoperability Showcase Kiosk #30

2. About me
Redox 2018
In the past six months I’ve written code that connects to:
Proprietary APIs:
● AdvancedMD
● Allscripts
● Athena
● DrChrono
● Greenway
● EcW
● Kareo
● PointClickCare
XCA/XDR:
● Epic
● Cerner
● Many others
(especially
HIEs)
FHIR
● Just one
Good ol’ HL7v2 over
MLLP
● Many
● Many
● Many
● Others

3. Conclusion - Developers should not be
thinking about APIs as binary “open” and
“closed” - you need to evaluate the
business models behind APIs
There is a ton of variance in the utility an
API provides. This problem can be very
hard or very easy depending on your
product.
Redox 2018

4. Trigger Warning
Redox 2018
This talk includes the names of EHR vendors.
Everyone is working hard to solve this problem. If
success in interoperability were about intelligence - it
would be solved, healthcare is not an industry that
needs more smart people.

5. Thank you
Redox 2018
https://histalk2.com/2018/02/13/news-2-14-18/

6. Why are we talking about APIs?
Redox 2018
2013 - The JASON report
“The body of this report provides the details of an example software
architecture that breaks the stranglehold of current stovepipe
systems and facilitates migration to a software ecosystem, with a
diversity of products and apps, that fosters innovation and
entrepreneurship.”
https://www.healthit.gov/sites/default/files/ptp13-700hhs_white.pdf

7. Recommendations?
Redox 2018
“EHR software vendors should be required to develop and
publish APIs for medical records data, search and indexing, semantic
harmonization and vocabulary translation, and user interface
applications. In addition, they should be required to demonstrate that
data from their EHRs can be exchanged through the use of these APIs
and used in a meaningful way by third-party software developers.”
https://www.healthit.gov/sites/default/files/ptp13-700hhs_white.pdf

8. Three questions when working directly with EHRs
Redox 2018
Developers/Innovators ask yourself:
● Does this vendor make money when more data
enters/leaves their system?
● Does my product help them make money?
● Does my product help their customers (HCOs) make
money/provide better care?

9. Does this vendor make money as they get more
data?
Redox 2018
Example: Athena
● Part of revenue comes from processing claims
● More patients and cleaner data means more money
Counter: Vendor that sells software and services
● They are a few degrees removed from the data/users
● Requires strong engagement and ability to listen to HCO
customers

10. Does my product help them make money?
Redox 2018
● Dragon or Nuance
○ Speech recognition is way outside any EHR
vendors wheelhouse
○ Often makes sense to do OS-level interop
● Counter: does your product compete with theirs?
○ It might even depend on who you talk to
■ Developer - Sweet that’s awesome
■ Executive - uhhhh they do what?

11. Do I help their customers make more money or
provide better care?
Redox 2018
● Redox Customer: Breg
○ Automates inventory management for braces
■ Saves staff time
○ Automatically submits claims for braces
■ Saves billing office time, get paid faster
○ None of this stuff is in the SMART/Government
stuff
○ Features like this have been around for decades!

12. Takeaways: EHR Vendors are businesses
Redox 2018
● That’s not to say they aren’t altruistic
● At some level the business can’t survive being altruistic
● You need to be tactical about that

13. Speaking of altruism...
Redox 2018

14. Case Study: What FHIR® is and what FHIR® is
not
Redox 2018
● FHIR® can offer guidelines but is not an enforcer
● There is a second level called a profile that we’ve just begun to scratch for
FHIR®
● FHIR® is a very easy GET view to implement, a very difficult POST verb
● FHIR® Describes an API but it’s not an API. Would you rather have a
FHIR® API with a 99.90% SLA or a proprietary API with a 99.99% SLA.

15. My advice:
Redox 2018
● Understand that just because something is using a standard does not mean
you can walk up to an EHR vendor and they will support it
● You can still find value no matter what size you’re at
○ It helps developers understand healthcare data
○ Be prepared to deal with change
● It’s better do your own thing consistently than FHIR® inconsistently

16. What about these API companies?
Redox 2018
● A standard should lower the total cost of an
integration for everyone
● API companies and interface engines are
aggregators - they lower the marginal cost of
connecting on one side

17. Analytics Monitoring
AutomationCoordination
Telehealth
Redox 2018
Work For App
Work For Health
System
Point to Point

18. Analytics Monitoring
AutomationCoordination
Telehealth
Redox 2018
Work For App
Work For Health
System
Point to Point w/ Standards

19. Analytics Monitoring
Telehealth
AutomationCoordination
Redox 2018
Siloed Aggregation
Work For App
Work For Health
System

20. Analytics Monitoring
Telehealth
AutomationCoordination
Redox 2018
Work For App
Work For Health
System

21. Redox 2018
Conclusion - Developers should not be
thinking about APIs as binary “open” and
“closed” - you need to evaluate the
business models behind APIs
There is a ton of variance in the utility an
API provides. This problem can be very
hard or very easy depending on your
product.

22. Nick’s Top 3 things to watch out for!
1. Ask not what an API can do for you, ask what you
can do for that API
2. FHIR® needs to be implemented to have value
for you
3. Watch out for building silos - think about who is
on the other side
Redox 2018

23. Why this is important for developers
Redox 2018
I'm not a businessman;
I'm a business, man!

24. What are your questions?
Nick Hatt
@nickredox
https://github.com/nwhatt
Booth #1275
Interoperability Showcase Kiosk #30