1. Indivo and SMART: enabling standardized, substitutable, patient-facing apps
Daniel Haas
Harvard Medical School
Children’s Hospital Informatics Program
18 June, 2012

2. What is SMART?
“SMART provides a unified mechanism for diverse applications to interact with medical-record data.”

3. What is SMART?
Apps
API
Containers

4. What is SMART?
Apps
API
Containers

5. Isn’t that Indivo?
Apps
API
Containers

6. Nope. Unlike SMART, Indivo (pre-v2.0) supported: A different API
Different data-models
A different authentication scheme
Patient-facing apps only
Extra functionality:
Sharing
Writing Data
Auditing
Etc.

7. But they are similar… Reading Medical Data:
Problems, Meds, Lab results, Vital Signs, etc.
Authentication: OAuth-inspired
Philosophy: substitutability

8. So let’s take advantage of that!
Apps
Indivo App
API
Indivo-specific
data models/APIs
Containers

9. Goals Enable existing (and future) SMART apps to run against Indivo
Shift Indivo apps towards adopting SMART standards
Enable hybrid SMART/Indivo apps that offer additional functionality when run against Indivo

10. Architecture: Before Indivo API Indivo-Specific Apps Indivo
Data Read API
Indivo
Clinician-Facing Apps
Pure SMART Apps
Indivo-Specific Apps
Sharing API
Data Write API
Admin
API
Other Indivo Data Models
Indivo Core Data Models

11. Clinician-Facing Apps
Architecture: After
Indivo API
SMART API
Indivo
Clinician-Facing Apps
Pure SMART Apps
Indivo-Specific Apps
Sharing API
Data Write API
Admin
API
Other
Indivo Data Models
SMART Data Models

12. Technical Implications
SMART Containers supply Apps with
UI integration
Authenticated API Access
Data
Data models are critical to enable app developers
Keeping developer experience in mind
Data need to be predictable, (relatively) simple
The work we’ve done. Data models ‘require effort’, ‘bulk of the work’, in other containers

13. Technical Implications: Data
Data Fidelity in Indivo
Coding Systems
Non-SMART data
What happened to ‘pluggable document processing?’
Held to a higher standard: blue sky: advantages for developers

14. Technical Implications: SMART app Developers
Your apps will now run on Indivo!
If your apps are patient-facing (or might be appropriate for patient eyes), you can add Indivo-specific calls to write data, share data, and more.
Good coding practice: make sure to fail gracefully if Indivo calls aren’t available

15. Technical Implications: Indivo app Developers
Start learning SMART!
APIs
data models
Code your data
Data in Indivo must be consistent with SMART standards
When you build new Indivo apps, they will run on other SMART containers
But only if you fail gracefully when Indivo-specific APIs aren’t available
(Hint: Can you tell that I think this is important?)

16. Future Directions: The SMART-Indivo Portal
Mapping data from local EHR formats to other ontologies requires effort.
Goal: If you’ve done it for any SMART container, you shouldn’t have to do it for Indivo as well.
Obtaining data has been a primary obstacle for personal health platforms
Goal: If you have a SMART container exposing good medical data, Indivo should be able to run apps against that data.
For instance: 60+ academic medical centers with i2b2 could all provide Indivo, running apps, simply by setting up the SMART-Indivo Portal.

17. Future Directions: The SMART-Indivo Portal
Indivo API
Indivo
SMART API
SMART Container
Clinician-Facing Apps
SMART-Indivo Connector App
Clinician-Facing Apps
Patient-Facing Apps
Local EHR

18. Summary
By deeply integrating Indivo with SMART technologies, we have enabled Indivo to:
consume apps written for other SMART platforms
adhere to SMART standards for data models and data quality
support hybrid apps that add patient-facing components which are not yet ratified as part of the SMART model
Apps
API
Containers
Indivo App
Indivo-specific
data models/APIs