SMART at HIMSS 2018!

All times are PST. Session schedule may change – check back for updates.

  • Tuesday (3/6)

    • FHIR for Bulk Data
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      Learn about an exciting new effort by SMART and HL7 to bring the FHIR standard to bear on the challenges of bulk-data export.
      1:00 – 1:30pm | HL7 – Booth 5623
    • Sync for Science and the CMS Blue Button on FHIR API: Claims Data for Research
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Carly Medosch, Program Analyst, CMS
      2:00 – 3:00pm | CMS Booth #10110
    • SMART on FHIR: Building apps that integrate with clinical systems through open standards
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project; Josh Mandel, Health IT Ecosystem Lead, Verily
      Learn how SMART Health IT’s open source, standards-based technology platform enables innovators to create apps that run seamlessly and securely across the healthcare ecosystem.
      3:30 – 4:15pm | HIMSS Developer Innovation Lab (Hall G, Booth 9900-DL)
  • Wednesday (3/7)

    • Sync For Science Scientific Session
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Teresa Zayas Caban, Chief Scientist, ONC
      In this session, the Sync for Science team will sit down with the research community to talk through use cases, challenges, wish lists, and pragmatics of working with EHR data.
      10:00 – 10:45am | The Venetian, Room Zeno 4601
    • Argonaut Project Town Hall Meeting
      Micky Tripathi, President & CEO, MAeHC; Aneesh Chopra, President, CareJourney; Ryan Howells, Principal, Leavitt Partners; Josh Mandel, Health IT Ecosystem Lead, Verily; Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      The town hall will cover 1) Argonaut Project 2017 deliverables and 2018 work plan, 2) CARIN Alliance consumer directed exchange trust framework updates and TEFCA alignment, 3) SMART and ONC efforts to accelerate bulk data access via FHIR APIs.
      5:30pm – 6:30pm | Hall G, Booth 11955ET | RSVP Here
  • Thursday (3/8)

    • Sync For Science Demonstration
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Teresa Zayas Caban, Chief Scientist, ONC
      In this session we’ll review the consumer workflow, the underlying technologies and the regulatory environment that support Sync for Science, and describe upcoming extensions to support new data types.
      10:00 – 10:45am | The Venetian, Room Zeno 4601
    • CDS Hooks: Integrating decision support at the point of care
      Josh Mandel, Health IT Ecosystem Lead, Verily; David McCallie, Senior Vice President for Medical Informatics, Cerner
      We’ll review the technology, clinical use cases, standards development, and real-world implementation experience for the emerging CDS Hooks specification.
      11:40am – 12:10pm | HL7 – Booth 5623
    • FHIR for Bulk Data
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      Learn about an exciting new effort by SMART and HL7 to bring the FHIR standard to bear on the challenges of bulk-data export.
      1:00 – 1:30pm | Hall G, Booth 9900-DL

We’ll Be At HIMSS!



  • Monday, February 20th
    • 1:00pm – 2:00pm / Quest Diagnostics Panel (room 203C)
    • 1:40pm – 2:10pm  / Introduction to SMART on FHIR at HL7 booth (#943)
    • 3:00pm – 3:30pm / SMART App Gallery 2.0 Beta Launch at Federal Health IT Pavilion (booth #230)
  • Tuesday, February 21st
    • 11:00am – 11:45am / HSPC Interoperability Showcase Demonstration (booth #9000)
    • 2:30pm – 4:30pm / Argonaut Roundtable (room 240ABC)
    • 4:20pm – 4:50pm / Introduction to SMART on FHIR at HL7 booth (#943)
  • Wednesday, February 22nd
    • 11:40am – 12:10pm / Introduction to SMART on FHIR at HL7 booth (#943)

Vital Directions for Health and Health Care


About the Initiative

Guided by an 18-member steering committee, the National Academy of Medicine (NAM) has called on more than 100 leading researchers, scientists, and policy makers from across the United States to provide expert guidance on 19 priority focus areas for U.S. health policy. The resulting collection of discussion papers is organized around three overarching goals for the United States: better health and well-being; high-value health care; and strong science and technology.

“As the country orients toward alternative payment models, measuring individual health outcomes and disparities among vulnerable populations is crucial for driving innovation toward outcomes that matter most to individual lives.”

“Simply building APIs into EHR products so that data can be called by external applications will improve the current state. But the most important goal is that—as in an “app store”—an app written once will be able to run anywhere in the health care system and that a decision support service will be able to be created once and be called from any care point in the system. “

Read the Discussion Paper On Information Technology Interoperability and Use for Better Care and Evidence



President Obama’s Cancer Panel Points to SMART On FHIR for Connected Health


President Obama’s Cancer Panel defines connected health as “the use of technology to facilitate the efficient and effective collection, flow, and use of health information.” In their 2016 report to the President, the panel highlights the benefits of using the SMART On FHIR open-access API for development of health applications.

“The Precision Cancer Medicine (PCM) app was designed to present patients’ genomic test results to oncologists in real time as a component of clinical practice, as well as provide links to external knowledge bases that otherwise would be unavailable through the native EHR system. PCM was piloted at Vanderbilt University and integrated into that institution’s EHR system. However, because the app was developed based on an open-access API (Substitutable Medical Applications and Reusable Technology, or SMART) and uses the emerging HL7 Fast Healthcare Interoperability Resources standard, it could easily be deployed for other compatible EHR systems.”

“The Panel urges all stakeholders—health IT developers, healthcare organizations, healthcare providers, researchers, government agencies, and individuals—to collaborate in using connected health to reduce the burden of cancer through prevention and improve the experience of cancer care for patients and providers.”

Improving Cancer-Related Outcomes with Connected Health: A Report to the President of the United States from the President’s Cancer Panel. Bethesda (MD): President’s Cancer Panel; 2016.

A web-based version of this report is available at:

AMA and SMART Collaborate to Survey Physician Interest in EHR Connected Apps


As part of a broader survey of 1,300 physicians covering digital health tools, the SMART Health IT Project and the American Medical Association collaborated on a set of questions to better understand how providers wish to discover, evaluate and purchase apps that connect with their EHR system.

One important finding for app creators is that 81% of physicians ranked integration with their EHR as a very important or important requirement for digital health tools. Additionally, more than half of the physicians indicated that they are extremely likely or very likely to purchase apps that extend their EHR system’s capabilities and securely integrate into the EHR workflow.

Download the full report at:

The SMART Team is Hiring!

We’re looking for a senior developer to work full time on the open source SMART on FHIR project!

Senior Developer

The Boston Children’s Hospital Computational Health Informatics Program (, a Harvard Medical School affiliate, is seeking an experienced full stack web developer to join the SMART Health IT team.

The platform is REST-based, incorporates OAuth2 and related technologies on the security layer and can use JSON and XML serialization formats. The team you will be joining writes services, applications and frameworks for web and mobile platforms in various programming languages and likes to give the latest and greatest technology a try.

The ideal candidate:

  • Has a Bachelors or Masters in Computer Science or equivalent industry experience, plus at least 3 years of experience in real-world software development
  • Lives and breathes full stack web development using open-source development and tools, can discuss the pros and cons of various web application toolkits
  • Writes quality code: source control, testing, and clear documentation are all musts
  • Has experience with JavaScript and at least one other programming language
  • Has experience with at least one web framework
  • Is comfortable doing basic system administration in a Linux environment

Bonus points if:

  • You have experience with Python or the JVM
  • You’re familiar with both statically and dynamically typed languages
  • You can share a link to your work on GitHub

Please submit a cover letter describing your background, a resume and a code sample that represents your best work to:

MACRA / MIPS Comment: We need API Support!

Today is the last day of the comment period for CMS’s MACRA and MIPS proposed rules. Below, we share a comment we submitted promoting the use of APIs for patient and provider access alike.

CMS states that priorities for “Advancing care information” are patient engagement, electronic access, and information exchange:

> These measures have a focus on patient engagement, electronic
> access and information exchange, which promote healthy behaviors
> by patients and lay the ground-work for interoperability.

… but nothing in CMS’s proposed MIPS measurement strategy in fact places an emphasis on these goals. Consider patient API access through third-party apps, which falls squarely in the intersection of these focus areas. Under the proposed scoring rubrics, a provider can earn 100% full marks on “advancing care information” while making API access available only to a single patient!

CMS should take actions to ensure that the “priority goals” are in fact met. One clear way to fix this issue would be to define a scoring function where patient API access is a hard line. For example, MIPS could require providers to offer API access to all patients in order to be eligible for the “base score”. This special-priority treatment is already given to one objective (“Protect Patient Health Information”); it should be extended to other priority items including patient API access. Otherwise, these “priorities” can, in fact, be entirely ignored by MIPS EPs, given the elaborate structure of bonus points and the “ceiling effect” of earning just 100 points out of a possible 131 points.

CMS should also add an explicit requirement for APIs that be used by healthcare providers as well as patients. Current meaningful use requirements focus on patient API access; MACRA should expand access to clinicians as well. To be concrete in advancing interoperability, MIPS could award points for clinicians who run at least one third party application against their EHR data (for example, see the SMART on FHIR open app platform specifications at and at least one third party decision support service (for example, see the SMART CDS Hooks specifications at

SMART Health IT Awarded Funding to Enhance App Discovery Tool


Following a competitive process, the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology has awarded SMART Health IT, a project of Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department of Biomedical Informatics, the “Discovery Infrastructure for Clinical Health IT Apps” funding opportunity.

Under this agreement, SMART Health IT will study the healthcare app ecosystem, enhance the SMART App Gallery ( with additional functionality, and expand the sample data available to users and developers through the SMART Sandbox. To achieve these goals, SMART Health IT has partnered with organizations that include, HL7, the American Medical Association, American Nursing Association, as well as consultants from world-class market research firms and design companies.

More at:

Precision Medicine Initiative (in Blank Verse)

I’m deeply excited about the Precision Medicine Initiative. With Cohort Program grant deadlines approaching in a matter of hours, I thought it might be time for a brief distraction with this blank verse reflection on the funding opportunity announcements:

Precision Medicine Initiative:
a blank verse summary and overview.

Recruit a million volunteers across
the country, spanning age, geography,
ethnicity and race, the ill and well,
a cohort of participants engaged
as partners for a long-term effort to
transform our understanding of the links
that bind genetics, our environment,
disease and health: a cohort big enough
for wide association studies of
diverse and non-prespecified effects.

We’ll weave a network joining scientists
from academia and industry,
and someone’s loft or basement or garage
to generate hypotheses, compare
results and methodology, and share
interpretations with participants.

We’ll gather physical exam reports
from EHRs and clinics, collate SNPs
and genomes, track activity from phones
and wearables, and questionnaires to learn
as much as each participant will share.

And how to organize a study with
unprecedented capabilities?
The cast of characters includes at least

* Enrollment Centers (seven) to recruit
one hundred thousand people each, and build
a pipeline for transmitting data to…

* Coordinating Center (one) composed
of interlocking Cores for Data (with
facilities to scale analysis),
Research Support (including phenotype
selection algorithms, software tools,
and science help desk), plus a centralized
Administrative Core to oversee
the project and collaborations with…

* Participant Technologies, to build
a suite of mobile applications that
engage participants through questionnaires,
acquire sensor data (GPS
and wearables) and share research results.

* A central Biobank for specimens
collected from the cohort, offering
facilities to handle, process, store,
prepare, and ship to labs upon request.

A cohort of one million volunteers
will chart a course across the next five years.
Jump in and grab the helm — but science steers:
discoveries ho! Let’s sail to new frontiers.

Patient API Access in MU3

We’re in a Meaningful Use Stage 3 comment period!

The Meaningful Use Stage 3 final rule was published on October 16th, and came with a 60-day open comment period. Anyone can submit a comment here.

Patient API access is a critically important MU3 guarantee

I want to share a comment I’ve submitted that deals with a critically important (and strongly worded) guarantee that MU3 provides: a patient’s right to access data through an API, using “any application of their choice”. This is a critical issue because this guarantee would open up data access in a very wide, very real way — but it also comes with a host of security and privacy concerns (as well as business concerns) that will cause provider organizations to push back against it.

Below is my comment, verbatim. I’d love to hear your thoughts @JoshCMandel.

Josh’s Comment on Patient API Access

The following language pertaining to patient access must be be clarified to ensure it retains its intended potency:

The provider ensures the patient’s health information is available for the patient (or patient-authorized representative) to access using any application of their choice that is configured to meet the technical specifications of the API in the provider’s CEHRT.

The key question here is: which parties need to agree that an app is (so to speak) “okay to use”?

The regulatory intent appears to support the idea that patients make this decision, choosing among all apps that have been configured to work with the provider’s EHR. But what does it take for an app developer to configure an app to work with the provider’s EHR? Beyond technical details, is it okay for a provider to tell an app developer something like:

1. “Sorry, your app sounds good and useful, but we don’t choose to make it available to our patients.”

2. “Sorry, your app might be useful but it’s duplicitive: we already offer a similar functionality to our patients through another app, or through our own portal.”

3. “Sorry, your app is designed to help patients move away from our practice by seeking a second opinion, and that’s against our business interest.”

4. “Sorry, your app offers what we consider to be questionable clinical advice.”

5. “Sorry, we don’t believe your app will do an adequate job of protecting patient data.”

CMS should clarify that providers may not use these excuses to prohibit apps from becoming available to patients. If a provider can reject apps for policy reasons like the ones described above, this will lead to an environment that fails to provide patients a right to access their data in a useful way.

But of course some of the concerns above are important, especially as they begin to touch on clinical utility and data protection. CMS should clarify that protection comes, ultimately, from allowing patients to make informed decisions about which apps to use. It is reasonable for providers to share warnings, or endorsements, or to ask questions like “Are you sure?” with specific confirmations, or to assign apps to different levels of trust or approval — but a provider must not prohibit a patient from using a specific app (just as they must not refuse to fax a patient’s data to a patient-specified phone number).

One important step in ensuring this kind of access will be clarification about who is responsible for a data breach in the case where a patient has approved an app to access EHR data. The Office for Civil Rights should issue a clear statement that providers are not responsible for what happens downstream, after healthcare data are shared with a patient-selected and patient-authorized app. By analogy, we expect providers to share healthcare information by fax to any phone number that a patient identifies, as long as the patient has authorized the transmission; we should look at sharing data with apps the same way. This kind of clear statement from OCR will be a necessary step to ensure that providers do not perceive conflicting obligations.