Bridging the Gap: Applying Lessons from API Development to€¦ · SaaSy startup world, at least For the optimists: HL7 vs FHIR Greatest Common Denominator JSON over HTTP(S) Pipe-delimited

Bridging the Gap: Applying Lessons from API Development to Healthcare Enterprise Integrations

Shelby Switzer | @switzerlyHealthify | @HealthifyUS | www.healthify.us

F o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

Who are you?


3

Who I Am

Open Data

APIs

@switzerlyF o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

ProductWe build community health infrastructure to connect underserved populations with the services they need to thrive.

ServicesWe provide network building services to foster relationships between healthcare organizations, local government, and community services.

4

HealthifyOur mission is to build a world where no one’s health is hindered by their need.

CustomersPayors, providers, government entities

UsersSocial workers, community health workers, program managers

Integration partners7 live integrations with EHRs, HIEs, Case Management Systems


Why I’m Here


6

Before healthcareF o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

7

In healthcare


© 2018 Redox, Inc. 8

Me

F o r r e f e r e n c e o n l y .D o N O T d i s t r i b u t e .

World*

9

The Integration GapHealthcare

* SaaSy startup world, at least * For the optimists: HL7 vs FHIR

Greatest Common Denominator JSON over HTTP(S) Pipe-delimited files via email/server

Most debated topic REST vs GraphQL SFTP vs FTPS*

Culture Standardization Customization

Naming Conventions Puns and animals Obscure acronyms

Modus Operandi Products Projects


10

But still...Your users have problems.

And they’re not going away.

You are not an island.

Neither is your product nor your integrations team.

The future is real.

And you need to plan for it.F o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

11

But still...Your users have problems.

And they’re not going away.

You are not an island.

Neither is your product nor your integrations team.

The future Change is real.

And you need to plan for it.F o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

Design-first product thinking

12

1. Know your users and their problems.

2. Iterate on the design.

3. Define success and measure it.


1. Know your users and their problems.F o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

Key integration user groups

14

Group At Healthify Problems

End users Social workers, community health workers

High on volume, low on time. Wants to find quality services and coordinate care.

Business / admin users Program managers, executive stakeholders

Wants to understand outcomes and value of SDOH investment. Wants to surface relevant data to other hospital staff via EHR.

Patients Underserved communities (for you, may be same as end user)

Does not trust or know how to access community services. Wants help navigating the system. Doesn’t touch the software but they’re why we’re doing this.

Developers CMS dev team, contractors, EHR analysts

Does not know what the workflow is, why they’re building this, or who you are. May not have clear project management on their end.


15

EHRs and Healthcare

They don’t know (or care?) why they’re here

Workflow mock-ups, explicit data + message instructions

Shared drive

Explain the why behind every decision

Weekly check-ins with written follow-ups

Speak their language (and to their egos!)

Act as their project manager as soon as you see it’s needed

Be prepared for hand-holding and relationship management as your core responsibilities

SaaS APIs

They know why they’re here

User-friendly documentation and tutorials

Code snippets and sandboxes

Open source tools and client libraries

Events and hack days (free pizza)

Dev newsletter

Guide product use through collateral and dev marketing

The Developer User GroupF o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

16

Case study: Health System X- We pushed back too hard on their long timeline estimate

Then the IT director de-prioritized the build and we started 6 months later than planned

- We didn’t step up with project management for their team after the second meeting

when their team hadn’t delivered progress

The build dragged on for 6 months, when it should’ve been finished in 12 weeks

- We didn’t supply written info about the project’s data needs or workflow requirements

early enough or follow up on decisions to all stakeholders

We spun our wheels regularly debating topics we’d already discussed, and they had to add

scope late in the game to account for data requirements F o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

2. Iterate

on the design.


Iteration in the wild

18

EHRs and Healthcare

Focus is on workflow and data:

Ask for screenshots of client’s EHR and make mockups (we use InVision)

Make sure IT is part of workflow finalization

Store everything to make future features easier

Use a mock server (Redox’s dashboard) to build against

Look at real data as early as possible

Understand how the Redox models relate to the workflow

“Contract” is the workflow, but even that may change.

SaaS APIs

Focus is on the interface

Design first, build later

Start with an API definition (e.g. API Blueprint or OpenAPI Spec)

Get feedback on the design, update it

Use a mock server as mutual test-bed for design iteration (we use Apiary)

Determine final design (this is the “contract”) and build.


Don’t get into data fights with the EHR.

19

- Be liberal with what you accept, conservative with what you send- Don’t enforce [many] data validations- Empower the user by displaying info about history and origin of the data


“Phase 2” is your friend.

20


21

Case study: Health System Y- We ignored Redox models that we didn’t support in our own data model and didn’t

think we needed

We discovered mid-build that the client expected Visit information attached to the media

message we were sending. We didn’t have a concept of Visit or Encounter...

- We didn’t see real insurance data come in until late stages.

After seeing real data, we realized our assumptions about insurance data quality were

wrong, and we had to add build to account for that (with discord about who would do it).

- We assumed everyone could support (and wanted) a PDF.

We found out PDFs are real hard for Epic customers, and the customer had to go to Epic

directly for blob server support, when they’d rather have discrete data anyway.F o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .



Product success

23

● Usage/activity● Conversion rates (e.g. integration transactions that led to a

referral completion)● NPS or other user satisfaction ratings

● Did each identified user group achieve their end result faster orwith better quality? Was the problem solved?


Project success

24

● Reusability and cost efficacy of integrations● Time to deploy● Dev time spent per integration

● Is this less of a project and more of a product?


25

Case study: Healthify- We built reusable interfaces for EHR integrations using Redox.

Our most recent integration used 3 already built interfaces (ADT, MDM, Flowsheet ORU) and

dev staff time needed was only 5 hours total.

- We implemented reporting for integrations to understand product success.

All clients with integrations have over 66% engagement (much more variable without).

Referral activity related to integrations workflows is at least 3 times higher than activity

without.

- Our integrations roadmap aligns with product roadmap.

This makes it easier to know what to say no to versus what new build to take on.


Design-first product thinking

26

1. Know your users and their problems.

2. Iterate on the design.


RECAP


27

Questions?F o r r e f e r e n c e o n l y . D o N O T d i s t r i b u t e .

Thanks!

Shelby Switzer

@switzerly

www.healthify.us

@healthifyUS

F o r r e f e r e n c e o n l y .D o N O T d i s t r i b u t e .

Documents

Bridging the Gap: Applying Lessons from API Development to€¦ · *SaaSy startup world, at least *For the optimists: HL7 vs FHIR Greatest Common Denominator JSON over HTTP(S) Pipe-delimited

Bridging the Gap: Applying Lessons from API Development to€¦ · SaaSy startup world, at least For the optimists: HL7 vs FHIR Greatest Common Denominator JSON over HTTP(S) Pipe-delimited