1. SHARP Area 3: SMART (Substitutable Medical Apps) Josh C. Mandel, MD Joshua.Mandel@childrens.harvard.edu Lead Architect, SMART (http://smartplatforms.org) Research Faculty, Harvard Medical School Sharp Area 4 Face-to-face, July 1 2011

2. SMART goals Health IT users work with installable, substitutable apps Health IT systems benefit from efficient marketplace of apps vibrant developer community

3. Why substitutable apps? Improved user experience More integrated innovation Case study: Wired competition

4. Why substitutable apps? Improved user experience More integrated innovation Case study: Wired competition

5. Why substitutable apps? David McCandless & Stefanie Posavec for Wired Magazine informationisbeautiful.net

6. Vocabulary Apps Containers API

7. Vocabulary Containers Apps API

8. A Substitutable App Your system here. SMART Reference EMR Indivo PCHR i2b2

9. Vocabulary Containers Apps API

10. SMART $5K Challenge

12. An app runs against one container (at a time) A container connects to multiple data sources Apps and containers

13. SMART components

17. Web standards! Apps can run on separate servers, different implementation stacks Inspired by Web APIs Facebook, OpenSocial, Google

18. Data Context, Medical Record Elements UI Standards-based integration, flexibility Authentication In-browser, server-to-server Apps need (at least!)

19. Contextual data (patient, physician)  low-hanging fruit Medical data (blood pressure, cholesterol) existing standards? pragmatic approaches? Apps need data!

20. Open standards?

21. CCR: “Licensee may access and download an electronic file of a Document (or portion of a Document) for temporary storage on one computer for purposes of viewing, and/or printing one copy of a Document for individual use. Neither the electronic file nor the single hard copy print may be reproduced in any way.” Open standards?

22. Intuitive payload?

23. What’s practical? PCHRs provide practical data models Indivo http://wiki.indivohealth.org/index.php/Indivo_Document_Model MS HealthVault Data Types: http://developer.healthvault.com/types/types.aspx Google Health Subset of CCR: http://code.google.com/apis/health/ccrg_reference.html

24. SMART data 80/20 approach concentrate on common outpatient data Payloads specified down to coding systems e.g. SNOMED for problems Extensible representations in RDF iterative design, building models over time

25. Data elements Sample SMART Problem (RDF) Backache (finding) 2007-06-12 2007-08-01

26. Data principles REST Paradigm: Each patient, data element has a URI John Smith: http://smart-emr.hospital.org/records/123 John Smith’s atorvastatin: http://smart-emr.hospital.org/records/123/medications/456 URIs can map to underlying EMR IDs

27. Data principles Consistent coding systems Medications: RxNorm (SCD, SBD, Packs) Problems: SNOMED CT Labs: LOINC Containers may need to translate from other terminologies, with provenance

28. Data principles Consistent coding systems Example of a translated LOINC code Medications: RxNorm (SCD, SBD) Problems: SNOMED CT Labs: LOINC Containers may need to translate from other terminologies, with provenance Serum sodium Random blood sodium level <sp:translationFidelity rdf:resource="http://smartplatforms.org/terms/code/fidelity#automated" />

29. Data principles Consistent coding systems Example of a translated LOINC code Medications: RxNorm (SCD, SBD) Problems: SNOMED CT Labs: LOINC Containers may need to translate from other terminologies, with provenance Serum sodium Random blood sodium level <sp:translationFidelity rdf:resource="http://smartplatforms.org/terms/code/fidelity#automated" /> source

30. Data principles Consistent coding systems Example of a translated LOINC code Medications: RxNorm (SCD, SBD) Problems: SNOMED CT Labs: LOINC Containers may need to translate from other terminologies, with provenance Serum sodium Random blood sodium level <sp:translationFidelity rdf:resource="http://smartplatforms.org/terms/code/fidelity#automated" /> source SMART translation

31. Data challenges Different coding systems e.g. for medications, NDC  RxNorm e.g. for problems, ICD9  SNOMED CT (?) Different models e.g. is a problem event-at-a-time, or duration? No models – can’t expose data you don’t have. (but some may be worth storing, e.g., fulfillments)

32. SMART governance Open specifications, documentation Open-source reference implementation Open-source client libraries Apps and Containers needn’t be open-source (promote a commercial ecosystem)

33. Translation / Integration efforts CHB’s Cerner OpenMRS HealthVault, Indivo i2b2 Exploring Extended data models Integration of CDS Mobile apps + containers Ongoing projects

34. Cross-SHARP sharing of: sample data logical models Collaboration around integrating SHARPN functionality as SMART apps (e.g. CTAKES pilot) extracting patient record data Other opportunities? Discussion topics!

35. Questions?

36. Container UI

40. Health IT systems have different authentication mechanisms! How to keep apps agnostic? Each container implements a consistent mechanism for delegating access: OAuth. The app only needs to speak OAuth. Authentication

41. App distribution model?

42. Light, test-driven certification as SMART Independent groups may endorse apps Individual containers install selected apps (local arrangements, e.g. contractual terms)

43. App distribution model?