Joshua Mandel, MD is on the research faculty at Harvard Medical School and is the lead architect for the SMART project collaboration between HMS and ONC.
Tell me about yourself and your job.
I am on the research faculty at Harvard Medical School. I’m in the department of biomedical informatics there. I work on making it easier for patients, clinicians, and researchers to work with electronic health data. I got there via medical school, where as a medical student I realized there was a lot more that computers could be doing for us than they were doing.
Describe the SMART project and how it relates to FHIR.
SMART Health IT, which is an acronym for Substitutable Medical Applications and Reusable Technologies, is a project that was originally sponsored by the federal government, by the Office of the National Coordinator for Health Information Technology, with a goal of building an app platform that allows third-party apps to plug into various kinds of health information systems. We specifically focus on apps that plug into electronic health records, which might be apps that clinicians use, apps that plug into patient portals, personally-controlled health records the patient would use, or apps that plug into data warehouses that researchers might use.
The goal is to provide apps with everything they need to be able to present a consistent user experience. The apps shouldn’t have to know about all the internal details of each different health IT system. The goal is to abstract the apps from those details. That’s the high-level goal of SMART.
We use a number of technologies under the hood to make that work. We use a set of open technologies everywhere we can. We use an emerging specification from HL7 called Fast Healthcare Interoperability Resources, or FHIR, to provide the data layer of access. FHIR gives us a set of data models and it gives us a Web-oriented REST API that application developers can use to query an electronic health records system for data.
Then on top of that, we layer a security model using OAuth 2 and OpenID Connect so that users can sign into apps using their existing accounts so they don’t have to create a new account for every app they want to use. That includes a permissions model, so you can give apps access just to the data that they need and you don’t have to give apps access to everything in your system.
We wrap all that together with a little bit of glue so that we can actually plug these apps into, for example, an electronic health records system. You might be a clinician working with an EHR system from Cerner, Epic, or any number of vendors beginning to implement these specifications. When you’ve got a patient record open inside one of these systems, you can launch an app and it knows about the context of what you were doing inside of the EHR, so that app can launch directly on the patient that you already have open and help you get some new jobs done that the original EHR didn’t have any functionality for.
How will that be positioned against vendors who have declared themselves to be open and created their own equivalent of an app store or an ecosystem with partners that they’ve approved?
We’re seeing interesting trends from the electronic health record vendors towards allowing certain kinds of third-party tools to integrate with these EHR systems. There’s still some big, open questions about the extent to which we’ll see standards as the basis for that integration versus vendor-specific data access.
We can actually separate out two questions. One question is, what are the technical mechanisms by which the access works? Are we using standards like FHIR? Are we using vendor-specific APIs? That’s the technical piece of it.
Then there’s a policy piece. Regardless of whether you use standards or whether you use vendor-specific APIs, there’s a policy piece about which apps are going to be allowed to talk to a given system and how are vendors and healthcare provider organizations together going to control that access.
What levels of capability or interest in SMART are you seeing from the three significant inpatient EHR vendors?
Overall, the goal of SMART is to provide an interface where apps can plug into outpatient systems, inpatient systems, and various other kinds of health information systems, including health information exchanges and researcher-facing systems. We don’t have an exclusive focus on the inpatient world, but of course it is an important area.
We’ve been very encouraged over the last few months by the participation of a number of the big EHR vendors in a project called Argonaut. Argonaut is running an open implementation program, where anybody who’s building an app or an EHR can join for free and go through a series of development steps with us, where they can build out support for SMART on FHIR one step at a time. We’re running this open implementation program and we’ve had a couple of dozen organizations actively participating. That includes many of the big-name electronic health record vendors.
EHR vendors and even providers themselves don’t have much incentive to let patients choose and use whatever apps they want that tie into their legacy systems. How hard will it be to gain traction when the patient is the only obvious advocate?
There’s a lot of moving parts to an ecosystem like that. I talked a little bit about what’s the technology to make the platform work. I talked a little bit about what’s the access control policy. The other big question is, who’s the audience? Who’s using these apps?
We see a very clear motivation on the side of provider organizations to be able to rapidly adopt, and even to build, new applications that serve direct business interests or direct clinical interests. We see a strong internal motivation from healthcare organizations to be able to launch new apps.
For example, we have an app that we deployed at Boston Children’s Hospital that helps take better care of children with high blood pressure. It takes data from the EHR and uses them to compute blood pressure percentiles, which are normalized by a child’s age, height, and gender. That’s how you’re supposed to make a diagnosis of high blood pressure in children, by calculating those percentiles.
The EHR has all the data, but it doesn’t do the calculation, so we built an app to do the calculation. There’s a very clear motivation on the part of the clinical organization to be able to deploy an app like that –it runs inside the hospital, runs on top of hospital data, helps take better care of patients. We can think about other kinds of apps, which might be patient-facing applications, where a patient says, "I want to use this new health management tool I found." That represents a paradigm shift for provider organizations.
It’s still an open question how internally motivated these organizations will be to let patients bring these apps to the table, but I’m very encouraged by the recent Meaningful Use Stage 3 final rule, which came out and said that patients should have the right to access their own health data using whichever apps they want.
It’s been said that people didn’t know they needed an iPhone until it came out. What would be the equivalent that would tell patients that they need interoperable health apps?
I don’t think we’ve seen our first killer app, so to speak, in this space yet, but we certainly see a strong interest along the lines of patients who are managing chronic diseases, where they have to see a number of healthcare providers and the system is not tight knit enough today that the healthcare providers from these different organizations really communicate very well. A patient is very motivated to improve that communication, so apps and tools that help them do that are a powerful selling point.
Another area which we’re only just beginning to explore is apps that help you shop around for the right healthcare services, whether it’s deciding on the healthcare insurance that’s the best fit for you given your actual usage patterns or shopping around for a procedure or drug given the insurance that you have. The more data that apps can access, both about you individually and about other patients in the ecosystem who might be like you, the better you’ll be able to make decisions that work for you.
What data sources would you need to provide an estimation of utilization? Would it be claims data plus EHR data?
I think looking at a combination of electronic health record data plus insurance claims is a very good place to start. There are some open kinds of claims data at the population level the government makes available that you can use for a very rough cut, but I think we’ll also see more partnerships being formed with aggregated data being shared that can help compute better decisions.
Geisinger formed XG Health to commercialize their apps that tie into Epic. Is that an early example of the kind of ecosystem that could be created around legacy EHRs that aren’t necessarily done through vendor-specific proprietary technology?
We’re seeing a trend in several places and Geisinger is a great early example of an institutional drive to innovate and to find a broader market based on these innovations. If you invest a lot of institutional time and money building a tool that works inside your own organization, that’s great — you can reap the benefits internally.
But more and more, there’s a desire to be able to share these tools, or sell these tools, outside of an organization. Anything you can do to build apps in a vendor-agnostic way, to build them in a standards-compliant, openly integrated fashion, lowers the cost of integrating this app with more systems downstream, makes it easier to export innovations beyond your own organization.
Vendor of mobile apps haven’t usually done the research to prove that the product improves cost or outcomes. They also often seem to target users who are already health focused. Will app developers need prove the value of what they’ve created?
I think there’s a few ways to measure the value of an application. One is to figure out how people like it and how they perceive that value. Two is to try to measure objectively how the app performs on some metrics that you define.
One of the really exciting things about this health app ecosystem is you can start to use apps as the instruments of research. We see examples of this happening along traditional institutional lines. For example, Duke Medicine has built an app that they’re using as part of a research project to evaluate how well patients know their medication regimen — how well they know which medications they’re supposed to take at which time of day. They’ve built a tool as a SMART on FHIR app that provides a patient with an interface for saying, "Here’s what I take in the morning, at noon, and at night." They’re able to drag and drop pictures of pills from a virtual pill box into these various categories. Then researchers can correlate how well patients perform at this task with other measures of medication adherence and start to figure out whether tweaking the parameters of this task can lead to improved adherence.
Whether you think that’s a great idea or not, the fact is we can use an app to do a measurement and to produce a traditional clinical research result, which you would never be able to do if you had to start from scratch and integrate this thing into the EHR just to fetch the med list. The fact that you can get the med list from the EHR and get all the patient demographics from the EHR out of the box with standards is what makes that kind of research possible.
Then we also see research happening in other new and exciting ways, for example, with mobile applications that collect data explicitly through surveys and implicitly through sensors. There’s a lot of good work happening, for example, on the iOS platform with ResearchKit in that direction today.
Are patients involved enough in the design of what they want, need, and will use instead of letting health systems manage app design?
I think the healthcare industry always struggles to figure out where and how to involve patients. Frankly, there’s a lot of bottom-up work that’s happening today in the patient application space, where companies are starting to build consumer-facing tools that don’t always make sense to the traditional healthcare ecosystem. But as consumers adopt them, we have a better and better idea of what’s really interesting and useful from the patient perspective.
I think it’s very hard for institutions, in a lot of cases, to do the right thing by involving patients. But we’re seeing very good bottom-up innovation that happens from outside of the institutions, and that might be the best indication we have of what really matters.
What do you expect to hope and see in the next five to 10 years in terms of how systems are opened up or interconnected?
Looking out to the longer term, my main hope is to see connectivity become more and more invisible, to have established pipelines where data arrive where they need to, and are available at the point of care, and are available at home without our having to take many explicit steps to make it happen.
What I’d like to see are clinical systems that understand the job that a user’s trying to do. Understand what it means to make a diagnosis or choose a correct treatment, taking into account clinical practice guidelines, the particular clinical situation at hand, taking into account patient preferences, and making it much easier to understand the risks and benefits across the board.
We need readily accessible data, both from the individual patient level and from the clinical knowledge domain. We need all those kinds of data available at the point of decision-making. My hope is that, by standardizing the core of these data access protocols, we can get there in the next five to 10 years.
Do you have any final thoughts?
From the perspective of the SMART Health IT project, we’ve seen an incredible amount of interest and enthusiasm around these APIs that, when we started building them in 2010-2011, the feedback we often got was that it felt like a science fair project and it wasn’t ready for the real world. The interesting thing is that not that much about the technology has changed, but given the overall landscape of EHR adoption and an increasing level of demand from end users for tools that fit their needs better, suddenly this technology has become incredibly mainstream in really short order. It’s been really humbling to be part of that experience.