sharp area 3: smart (substitutable medical apps)

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?

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

An app runs against one container (at a time)

A container connects to multiple data sources

Apps and containers

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

http://code.google.com/apis/health/ccrg_reference.html

http://developer.healthvault.com/types/types.aspx

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


<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





source

Data principles





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

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?

sharp area 3: smart (substitutable medical apps)

Documents

smart http

challenge smart

smart goalshealth

google data context

contextual data patient

multiple data sourcesapps

substitutable apps health

server apps