Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and HIPAA for FREE!!

HealthTap Announces a Comprehensive Health App Platform

Posted on November 10, 2016 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

For the past five years, HealthTap has been building a network of doctors and patients who exchange information and advice through information forums, messaging, video teleconferencing, and other integrated services. According to CEO Ron Gutman, all that platform building has taught them a lot about what health app developers need–knowledge that they’ve expanded by listening to hospitals and third-party app developers over the years. On Tuesday, November 1, HealthTap announced a comprehensive cloud platform pulling together all these ideas. The features in the press release read like a wish list from health app developers:

  • Text, voice, and video messaging

  • Telemedicine

  • Population health

  • Predictive modeling

  • Device input and other patient-generated data

  • Handling clinical data from electronic health records

  • Aggregated data on patient groups, such as the frequency of concepts in the population

  • The ability to view timelines on patients

  • Searchable content from the huge library of clinical advice posted to HealthTap by its roster of more than 100,000 doctors

  • Identity management, so that patients and clinicians can verify who they are and connect securely

  • Customer relationship management through messaging

Many of the APIs covering these topics are covered in the developer documentation, and others are available by application from qualified developers.

Gutman told me that three to four years of work went into this platform, and that he hopes it can reduce the multi-year developments efforts his team had to deal with to just weeks for other developers hoping to innovate in the health care field. Transparency is promoted as a key value, because the developer terms required developers to “Clearly inform users what data you collect (with their consent) as well as and how you use the data you collect or that we (HealthTap) provides to you.” Even so, some items are restricted even more, such as adherence data and health goals.

In addition to RESTful APIs, the platform has SDKs for iOS, Android, and JavasScript. CTO Sastry Nanduri says that these SDKs permit apps to incorporate some workflows, such as making virtual appointments. His philosophy is that, “We do the work and make it easy for the developers.”

HealthTap has created its own formats and APIs instead of using existing standards such as the Open mHealth defined for medical devices (described in another article). A diversity of formats may make adoption harder. But the platform does harmonize diverse data from different sources into predictable formats, so that things such as blood glucose and body weight are shown in fixed units. Nanduri points out that most of their work has not been done by other organizations in an open, API format.

In any case, central to HealthTap’s goals and efforts is the sharing of data among organizations. If Partners Healthcare or Kaiser Permanente can open their data through HealthTap’s APIs, it can all be combined with the aggregated data from millions of records HealthTap has built up over time.

Offering this platform in HealthTap’s cloud gives it many advantages. Foremost is the enormous data repository of both patients and content served up by the platform. Second, identity management is automatically provided through the secure and robust platform HealthTap has always used for signing up patients and clinicians. Clinicians are carefully validated. Theoretically, a developer could also use an independent means of authenticating patients, so that someone can use apps built on the platform without a HealthTap account.

They are also exploring a blockchain solution for tracking permissions and contracts.

The proof of this huge undertaking will be in its adoption. I’m sure HealthTap’s partners and many other organizations will play with the platform and try to bring apps to life through it, either for internal use or for widespread distribution. Nanduri says that they are ramping up carefully, reviewing applications one by one, and will talk to each of their early developers to find out their goals and offer guidance to creating a successful app. Time will tell whether HealthTap has, as Gutman says, created the platform their developers wish they had when they started the company.

Sansoro Hopes Its Health Record API Will Unite Them All

Posted on June 20, 2016 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

After some seven years of watching the US government push interoperability among health records, and hearing how far we are from achieving it, I assumed that fundamental divergences among electronic health records at different sites posed problems of staggering complexity. I pricked up my ears, therefore, when John Orosco, CTO of Sansoro Health, said that they could get EHRs to expose real-time web services in a few hours, or at most a couple days.

What does Sansoro do? Its goal, like the FHIR standard, is to give health care providers and third-party developers a single go-to API where they can run their apps on any supported EHR. Done right, this service cuts down development costs and saves the developers from having to distribute a different version of their app for different customers. Note that the SMART project tries to achieve a similar goal by providing an API layer on top of EHRs for producing user interfaces, whereas Sansoro offers an API at a lower level on particular data items, like FHIR.

Sansoro was formed in the summer of 2014. Researching EHRs, its founders recognized that even though the vendors differed in many superficial ways (including the purportedly standard CCDs they create), all EHRs dealt at bottom with the same fields. Diagnoses, lab orders, allergies, medications, etc. are the same throughout the industry, so familiar items turn up under the varying semantics.

FHIR was just starting at that time, and is still maturing. Therefore, while planning to support FHIR as it becomes ready, Sansoro designed their own data model and API to meet industry’s needs right now. They are gradually adding FHIR interfaces that they consider mature to their Emissary application.

Sansoro aimed first at the acute care market, and is expanding to support ambulatory EHR platforms. At the beginning, based on market share, Sansoro chose to focus on the Cerner and Epic EHRs, both of which offer limited web services modules to their customers. Then, listening to customer needs, Sansoro added MEDITECH and Allscripts; it will continue to follow customer priorities.

Although Orosco acknowledged that EHR vendors are already moving toward interoperability, their services are currently limited and focus on their own platforms. For various reasons, they may implement the FHIR specification differently. (Health IT experts hope that Argonaut project will ensure semantic interoperability for at least the most common FHIR items.) Sansoro, in contrast can expose any field in the EHR using its APIs, thus serving the health care community’s immediate needs in an EHR-agnostic manner. Emissary may prevent the field from ending up again the way the CCD has fared, where each vendor can implement a different API and claim to be compliant.

This kind of fragmented interface is a constant risk in markets in which proprietary companies are rapidly entering an competing. There is also a risk, therefore, that many competitors will enter the API market as Sansoro has done, reproducing the minor and annoying differences between EHR vendors at a higher level.

But Orosco reminded me that Google, Facebook, and Microsoft all have competing APIs for messaging, identity management, and other services. The benefits of competition, even when people have to use different interfaces, drives a field forward, and the same can happen in healthcare. Two directions face us: to allow rapid entry of multiple vendors and learn from experience, or to spend a long time trying to develop a robust standard in an open manner for all to use. Luckily, given Sansoro and FHIR, we have both options.