SHARP Area 3: SMART(Substitutable Medical Apps)
Josh C. Mandel, [email protected] Architect, SMART (http://smartplatforms.org)Research Faculty, Harvard Medical School
Sharp Area 4 Face-to-face, July 1 2011
SMART goals
Health IT users work withinstallable, substitutable apps
Health IT systems benefit fromefficient marketplace of appsvibrant developer community
Why substitutable apps?Improved user experienceMore integrated innovation
Case study: Wired competition
Why substitutable apps?Improved user experienceMore integrated innovation
Case study: Wired competition
Why substitutable apps?
David McCandless &Stefanie Posavec for Wired Magazine informationisbeautiful.net
Vocabulary
Apps
Containers
API
Vocabulary
Containers
Apps
API
A Substitutable App
Your system here.
SMART Reference EMR
Indivo PCHR
i2b2
Vocabulary
Containers
Apps
API
SMART $5K Challenge
SMART $5K Challenge
An app runs against one container (at a time)
A container connects to multiple data sources
Apps and containers
SMART components
SMART components
SMART components
SMART components
Web standards!
Apps can run on separate servers,different implementation stacks
Inspired by Web APIsFacebook, OpenSocial, Google
Data Context, Medical Record Elements
UI Standards-based integration, flexibility
Authentication In-browser, server-to-server
Apps need (at least!)
Contextual data (patient, physician) low-hanging fruit
Medical data (blood pressure, cholesterol)
existing standards? pragmatic approaches?
Apps need data!
Open standards?
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?
Intuitive payload?
What’s practical?
PCHRs provide practical data models
Indivohttp://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
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
Data elements
Sample SMART Problem (RDF)<sp:Problem> <sp:problemName> <sp:CodedValue> <sp:code rdf:resource="http://www.ihtsdo.org/snomed-ct/concepts/161891005"/> <dcterms:title>Backache (finding)</dcterms:title> </sp:CodedValue> </sp:problemName> <sp:onset>2007-06-12</sp:onset> <sp:resolution>2007-08-01</sp:resolution> </sp:Problem>
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
Data principles
Consistent coding systems
Medications: RxNorm (SCD, SBD, Packs)Problems: SNOMED CTLabs: LOINC
Containers may need to translate from other terminologies, with provenance
Data principles
Consistent coding systemsExample of a translated LOINC code
Medications: RxNorm (SCD, SBD)Problems: SNOMED CTLabs: LOINC
Containers may need to translate from other terminologies, with provenance
<sp:labName> <sp:CodedValue> <sp:code rdf:resource="http://loinc.org/codes/2951-2"/> <dcterms:title>Serum sodium</dcterms:title> <sp:codeProvenance> <sp:CodeProvenance> <sp:sourceCode rdf: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>
Data principles
Consistent coding systemsExample of a translated LOINC code
Medications: RxNorm (SCD, SBD)Problems: SNOMED CTLabs: LOINC
Containers may need to translate from other terminologies, with provenance
<sp:labName> <sp:CodedValue> <sp:code rdf:resource="http://loinc.org/codes/2951-2"/> <dcterms:title>Serum sodium</dcterms:title> <sp:codeProvenance> <sp:CodeProvenance> <sp:sourceCode rdf: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
Data principles
Consistent coding systemsExample of a translated LOINC code
Medications: RxNorm (SCD, SBD)Problems: SNOMED CTLabs: LOINC
Containers may need to translate from other terminologies, with provenance
<sp:labName> <sp:CodedValue> <sp:code rdf:resource="http://loinc.org/codes/2951-2"/> <dcterms:title>Serum sodium</dcterms:title> <sp:codeProvenance> <sp:CodeProvenance> <sp:sourceCode rdf: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
SMART translation
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)
SMART governance
Open specifications, documentationOpen-source reference implementationOpen-source client libraries
Apps and Containers needn’t be open-source(promote a commercial ecosystem)
Translation / Integration efforts• CHB’s Cerner• OpenMRS• HealthVault, Indivo• i2b2
Exploring• Extended data models• Integration of CDS• Mobile apps + containers
Ongoing projects
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!
Questions?
Container UI
Container UI
Container UI
Container UI
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.
AuthenticationAuthentication
App distribution model?
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)
App distribution model?