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
SMART goals
Health IT users work with
installable, substitutable apps
Health IT systems benefit from
efficient marketplace of apps
vibrant developer community
Why substitutable apps?
Improved user experience
More integrated innovation
Case study: Wired competition
Why substitutable apps?
Improved user experience
More integrated innovation
Case study: Wired competition
Why substitutable apps?
David McCandless &
Stefanie Posavec for
Wired Magazine
informationisbeautiful.net
Vocabulary
Apps
API
Containers
Vocabulary
Apps
API
Containers
A Substitutable App
SMART Reference EMR
i2b2
Indivo PCHR
Your system here.
Vocabulary
Apps
API
Containers
SMART $5K Challenge
SMART $5K Challenge
Apps and containers
An app runs against one container
(at a time)
A container connects to multiple
data sources
SMART components
SMART components
SMART components
SMART components
Inspired by Web APIs
Facebook, OpenSocial, Google
Web standards!
Apps can run on separate servers,
different implementation stacks
Apps need
(at least!)
Data
Context, Medical Record Elements
UI
Standards-based integration, flexibility
Authentication
In-browser, server-to-server
Apps need data!
Contextual data
(patient, physician)  low-hanging fruit
Medical data
(blood pressure, cholesterol)
existing standards?
pragmatic approaches?
Open standards?
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.”
Intuitive payload?
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
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 CT
Labs: LOINC
Containers may need to translate from other
terminologies, with provenance
Data principles
Consistent coding systems
Example of a translated LOINC code
<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>
Medications: RxNorm (SCD, SBD)
Problems: SNOMED CT
Labs: LOINC
Containers may need to translate from other
terminologies, with provenance
Data principles
Consistent coding systems
Example of a translated LOINC code
<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>
Medications: RxNorm (SCD, SBD)
Problems: SNOMED CT
Labs: LOINC
source
Containers may need to translate from other
terminologies, with provenance
Data principles
Consistent coding systems
Example of a translated LOINC code
<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>
Medications: RxNorm
SBD)
SMART(SCD,
translation
Problems: SNOMED CT
Labs: LOINC
source
Containers may need to translate from other
terminologies, with provenance
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, documentation
Open-source reference implementation
Open-source client libraries
Apps and Containers needn’t be open-source
(promote a commercial ecosystem)
Ongoing projects
Translation / Integration efforts
• CHB’s Cerner
• OpenMRS
• HealthVault, Indivo
• i2b2
Exploring
• Extended data models
• Integration of CDS
• Mobile apps + containers
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?
Questions?
Container UI
Container UI
Container UI
Container UI
Authentication
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.
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?