Blog

Is Healthcare Ready for SMArt’er Applications??

September 2, 2010

The researchers at Harvard University think so and so do I. Last week I had the chance to attend the first developer’s conference for the Substitutable Medical Applications, reusable technologies, or SMArt. The architecture will provide a set of core services to facilitate substitutable healthcare applications, or plug-ins, similar to the App Store found in the iPad, iTouch or Droid. In attendance were open source solution vendors, healthcare IT thought leaders (Stan Huff and John Halamka), commercial healthcare application vendors, researchers, software developers and federal healthcare agency representatives (FDA, VA and DoD).

I will attempt to provide a brief overview of the ideas presented by the team. First, you need to imagine an app store where the user can select a variety of clinical applications or SMArt Apps. Similar to the iPhone, the application has no idea where the data for the application is coming from. Next, The SMArt App makes calls to the SMArt Container using HTML5 to a set of Web services in a RESTful (Representational State Transfer) manner. The SMArt Container addresses marshalling data from various computing system in their own specific syntax and presents it as XML/RDF.

One demonstration included an application called Got Statins? The SMArt app decided if the patient’s medication list included a statin and would respond with yes or no. This app was integrated into three different existing healthcare applications include a personal health record, an electronic health record and an analytical tool operating on different platforms. One great idea was the use of authentication (oAuth) tied to each API call made by the application.

The SMArt Program’s leadership team in attendance included:

  • Zak Kohane, Co-Director Children’s Hospital Boston, Harvard Medical School
  • Ken Mandl, Co-Director Children’s Hospital Boston, Harvard Medical School
  • Ben Adida, Lead Architect Children’s Hospital Boston, Harvard Medical School
  • Rachel Ramoni, Executive Director Harvard Medical School
  • Josh Mandel, M.D. Children's Hospital, Boston Lead Developer

In addition to discussion from leadership, other attendees added to a lively discussion. For example, a question posed by John Halamka, was, “How do we represent existing data standards such as HL-7 and X12 in RDF?” It was a great question and the team did not have an immediate answer. But I believe that there are existing technologies that can take an X12 or HL-7 message and represent it as RDF.

A question from the VA’s Doug Rosendale asked, “How does SMArt handle distributed data existing in multiple health record systems?” It was a great question. However, addressing this specific problem is not the core focus of the team’s research. I wonder if there is a solution that can already address this issue?

This process aims to spur a discussion about how a development community in the SAML/SOAP camp would work with an oAuth/REST camp. Could we bend the complex and secure approach of SAML/SOAP to be easier to use in a RESTful way? After some discussion, I offered the following perspective. The combination of a program focused on application reuse would dovetail nicely with a program such as CONNECT focused on the data exchange. CONNECT is not an end user application. SMArt is not a data exchange technology. However, the two together would be a powerful combination. The data exchange platform (CONNECT) would focus on exchanging information with multiple distributed systems providing a service such as Query for Analytical Document. The SMArt application would provide the container and the end user application to do something useful with the data.

Integration Options

There is a natural fit between the SMArt Container being offered and CONNECT. I see two possible integration options. The first option could be putting CONNECT inside the SMArt Container, whereby the container with the responsibility to get the data could use the CONNECT services to handle the SAML/SOAP exchanges. The second option could be placing the SMArt Container in the adapter later in the CONNECT gateway. This might replace our universal client framework and provide us with a RESTful way to build effective applications. The SMArt application could also leverage the audit log and SAML assertions made by CONNECT. The information in the application’s oAuth would populate the SAML assertion made by CONNECT. CONNECT could also record the oAuth API calls in the audit log. This means we would have knowledge and log what information the user’s application accessed. This would promote both increased application and data reuse; the best of both worlds. It sort of reminds me of the old Reese’s commercial, “You put chocolate in my peanut butter…..”

For more information, the Web site for the program can be located at http://www.smartplatforms.org/. There is also a developers’ group forming at http://groups.google.com/group/smart-app-developers.

I look forward to learning more as the program continues and wish the team best of luck in their endeavor. If you have anything to add please bring it up on the forum.

Thanks, Chief

Greg Fairnak, CONNECT Chief Architect

Add new comment