SHARP Area 3: SMART (Substitutable Medical Apps) - PowerPoint PPT Presentation

yardan
sharp area 3 smart substitutable medical apps n.
Skip this Video
Loading SlideShow in 5 Seconds..
SHARP Area 3: SMART (Substitutable Medical Apps) PowerPoint Presentation
Download Presentation
SHARP Area 3: SMART (Substitutable Medical Apps)

play fullscreen
1 / 43
Download Presentation
SHARP Area 3: SMART (Substitutable Medical Apps)
93 Views
Download Presentation

SHARP Area 3: SMART (Substitutable Medical Apps)

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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, substitutableapps Health IT systems benefit from efficient marketplaceof 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 Posavecfor Wired Magazine informationisbeautiful.net

  6. Vocabulary Apps API Containers

  7. Vocabulary Apps API Containers

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

  9. Vocabulary Apps API Containers

  10. SMART $5K Challenge

  11. SMART $5K Challenge

  12. An app runs againstone container (at a time)A container connects to multipledata sources Apps and containers

  13. SMART components

  14. SMART components

  15. SMART components

  16. 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 ElementsUIStandards-based integration, flexibilityAuthentication In-browser, server-to-server Apps need (at least!)

  19. Contextual data (patient, physician)  low-hanging fruitMedical 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

  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 <sp:labName> <sp:CodedValue> <sp:coderdf:resource="http://loinc.org/codes/2951-2"/> <dcterms:title>Serum sodium</dcterms:title> <sp:codeProvenance> <sp:CodeProvenance> <sp:sourceCoderdf:resource="http://local-emr/labcodes/01234" /> <dcterms:title>Random blood sodium level</dcterms:title> <sp:translationFidelity rdf:resource="http://smartplatforms.org/terms/code/fidelity#automated" /> </sp:CodeProvenance> </sp:codeProvenance> </sp:CodedValue> </sp:labName>

  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 <sp:labName> <sp:CodedValue> <sp:coderdf:resource="http://loinc.org/codes/2951-2"/> <dcterms:title>Serum sodium</dcterms:title> <sp:codeProvenance> <sp:CodeProvenance> <sp:sourceCoderdf:resource="http://local-emr/labcodes/01234" /> <dcterms:title>Random blood sodium level</dcterms:title> <sp:translationFidelity rdf:resource="http://smartplatforms.org/terms/code/fidelity#automated" /> </sp:CodeProvenance> </sp:codeProvenance> </sp:CodedValue> </sp:labName> 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 <sp:labName> <sp:CodedValue> <sp:coderdf:resource="http://loinc.org/codes/2951-2"/> <dcterms:title>Serum sodium</dcterms:title> <sp:codeProvenance> <sp:CodeProvenance> <sp:sourceCoderdf:resource="http://local-emr/labcodes/01234" /> <dcterms:title>Random blood sodium level</dcterms:title> <sp:translationFidelity rdf:resource="http://smartplatforms.org/terms/code/fidelity#automated" /> </sp:CodeProvenance> </sp:codeProvenance> </sp:CodedValue> </sp:labName> SMART translation source

  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-sourcereference implementation Open-source client libraries Apps and Containers needn’t be open-source (promote a commercial ecosystem)

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

  34. Discussion topics! • 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?

  35. Questions?

  36. Container UI

  37. Container UI

  38. Container UI

  39. Container UI

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

  41. App distribution model?

  42. App distribution model? 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?