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 EHR for FREE!

Analytics is the Driver for Useful Health Services at Philips

Posted on March 16, 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.

Although pioneer health care organizations jumped into risk sharing and fee-for-value without a good grounding in data, they have come to recognize the critical role analytics play over the past few years. Results of a 2015 survey of ACOs show that, “Nearly 85 percent of respondents report they have in place advanced analytics software to analyze disparate data sets.” The data tends to be limited (mostly claims and EHR data) and data sharing is still rare between organizations, but basic practices such as identifying high-risk patients are becoming more widely seen.

Philips has been in health care informatics for a long time, gradually building a data platform with analytics capabilities and basing more and more services on this platform. I talked to Dr. ck Andrade, Director of Product Management of Philips’ HealthSuite Digital Platform, to find how their basic analytics drive their services.

Like the ACOs mentioned earlier, Philips allows a single organization to combine and mine data of different types. Philips does not combine data from different unrelated organizations–in fact, to respect privacy, they don’t peek at user data at all. The platform is intended to aid institutions with precisely the types of data integration that are now so difficult. Now it is being incorporated by Philips into their own high-level services, showing how analytics can be a platform for building businesses.

Philips’s HealthSuite digital platform offers FHIR APIs. EHR data is read in through the vendors’ APIs when they’re available, by using the platform’s other interoperability capabilities, or through the CCD-A format. Imaging support was announced on February 18. Genomics is being pursued. Finally, device data can be taken in through several sources. Philips Device Cloud manages 8 million connected devices today, and a recently announced integration with Validic connects to data from 130 different device vendors over a wide range of protocols.

Clearly, all these data sets are interdependent. For instance, an image is of no value without the patient history that comes from an EHR.

What sorts of questions can all this data answer? The Philips platform provides a framework for aggregating data, running analytics, and exposing results through an API. The same API is used internally by Philips to develop its solutions, by customers to write apps, and by third-party developers to develop clinical solutions or packages for healthcare analytics: for instance, data scientists testing predictive models. As an example of the API’s power, it can offer access to blood glucose, wellness measures, responses to past medications, mood, and stress for diabetes patients. Healthcare organizations can run their algorithms against this data to suggest the current insulin dose and track fluctuations in glucose level.

Most customers use such information for simple interventions such as letting someone know they forget to do a reading or that the reading is outside the normal range. The platform can find patients with similar demographics and find duplicates caused by such common errors as misspelled names. A more sophisticated use of analytics would check how people are responding to medication, or how different interventions produce different effects.

The API supports both data push and data pull. Pull may be chosen for data that needs to be read several times a day.

Now Philips is enjoying the fruits of its labors by offering services based on its analytics, which are constantly getting richer. Here are examples operating at three levels of care:

  • Inpatient: Philips’s eICU tracks patients from ICU through follow-up. Tools provided by Philips take in, analyze, and form data into visualizations on dashboards.

  • Outpatient: Philips’s in-hospital and ambulatory telehealth programs are aiding transitions. Data from the inpatient EHR can be connected to data from the patient at home and from different health care providers using Philips services. Patients can upload data, using eCare Companion, allowing providers to monitor them using the same model as inpatient care. This is crucial for outpatient care, where each care coordinator might have to monitor hundreds of patients. A dashboard, eCare Coordinator, organizes critical information for the clinician. For instance, a dashboard can highlight the five people with the most disturbing trends. If a patient’s blood pressure rises even though he reports taking his medication, a clinician can prescribe a medication change.

  • Consumer health and wellness: Healthwatch uses the same analytics as other services, but for healthy living instead of recovery from illness. For instance, analytics can track different types of vital signs for people who have been identified as prediabetic. A self-management platform, which offers instant feedback as well as a look at progress over time, can measure activity and other contributors to health. Although it can run separately from any health care provider, users can share logged data with their providers.

Philips also builds some services on others. For instance, the Lifeline program for fall detection, which has been available for some time, now uses its Caresage predictive analytics for the frail and elderly. This turns Lifeline from a reactive to a predictive platform. Using analytics on a person’s frequency of falls, and patterns in their incidence, it can warn if another fall is likely.

March brought with it announcements for a whole set of new services were announced, such as for sleep and respiratory problems, for healthy seniors, and for intensive care units. I believe these advances aren’t due merely to Philips’s size and investments. They have learned how to make use of a flexible, integrated platform. It’s the direction all health providers need to head in.

Using APIs at the Department of Health and Human Services to Expand Web Content

Posted on October 21, 2015 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.

Application Programming Interfaces (APIs) appeal mostly to statisticians and researchers whose careers depend on access to data. But these programming tools are also a useful part of a Web that is becoming increasingly supple and sophisticated. I have written a series of articles about the use of APIs to share and run analytics on patient data, but today I’ll cover a cool use of an API developed by the Department of Health and Human Services for disseminating educational material.

The locus for this activity started with the wealth of information created by the Centers for Disease Control for doctors, public health workers, and the general public. Striving to help the public understand vaccinations, West Nile fever, Ebola (when that was a major public issue), and even everyday conditions such as diabetes, the CDC realized they had to make their content simple to embed in web sites for all those audiences.

The CDC also realized that it would be helpful to let outsiders quickly choose content along a number of dimensions. Not only would a particular web site be interested in a particular topic (diabetes, for instance), but they would want to filter the content to offer information to a particular audience in a particular language. One Web page might offer content aimed at doctors in English, while another might offer content for the general public in English and yet another offer content in Spanish. To allow all these distinctions, a RESTful API called from JavaScript allows each Web page to bring in just what is needed. Topics and languages are offered now, and filtering by audience will be supported soon. At some point, the API will even recognize ICD-10 codes and find any content related to those disease conditions.

We are all familiar with Web pages that embed dynamic content from other sites, such as videos from YouTube or Vimeo. Web developers embed the content by visiting the desired page, clicking on an Embed button, and copying some dense HTML to their own pages. The CDC offers several ways for visitors to syndicate content in this manner to their own web sites. If they are using a popular content management system (WordPress, Drupal, or Joomla!) they can install a plug-in that uses familiar practices to embed the content. Mobile app support is also provided. But the API developed by the CDC takes the process to a much more advanced level.

First, as already described, the API lets each page specify filters that extract content on the desired topic for the desired audience. Second, if a new video, e-card, or microsite is added to the CDC site, the API automatically picks it up when a user revisits the embedding page. Thus, without fussing with HTML, a site can integrate CDC content that’s tailored pretty precisely to its needs.

This API is also in use at the FDA–see for instance their Center for Tobacco Products–and at HHS more broadly. A community is starting to build around the code, which is open source, and soon it will be on GitHub, the most popular site for code sharing. A terse documentation page is available.

The API from Health and Human Services offers several lessons for health IT. First, communications can be improved by using the advanced features provided by the Web. (In addition to the API, the CDC tools make sophisticated use of HTML5 and iFrames to offer dynamic content in ways that fit in smoothly with the sites that choose to embed it.) Second, sites need to consider the people at the other end of the transaction in order to design tools that deliver an easy-to-use and easy-to-understand experience. And finally, releasing code as open source maximizes its value to the health care community. These trends need to be more widely adopted.

Shimmer Addresses Interoperability Headaches in Fitness and Medical Devices

Posted on October 19, 2015 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.

The promise of device data pervades the health care field. It’s intrinsic to patient-centered medical homes, it beckons clinicians who are enamored with hopes for patient engagement, and it causes data analysts in health care to salivate. This promise also drives the data aggregation services offered by Validic and just recently, the Shimmer integration tool from Open mHealth. But according to David Haddad, Executive Director and Co-Founder of Open mHealth, devices resist attempts to yield up their data to programmers and automated tools.

Every device manufacturer has its own idiosyncratic way of handling data, focused on the particular uses for its own device. According to Haddad, for instance, different manufacturers provide completely different representations for the same data, leave out information like time zones and units, and can provide information as granular as once per second or as vague as once per day.. Even something as basic as secure connectivity is unstandardized. Although most vendors use the OAuth protocol that is widespread on the Web, many alter it in arbitrary ways. This puts barriers in the way of connecting to their APIs.

Validic and Shimmer have to overcome these hurdles one by one, vendor by vendor. The situation is just like the burdens facing applications that work with electronic health records. Haddad reports that the cacophony of standards among device vendors seems to come from lack of attention to the API side of their product, not deliberate obstructionism. With all the things device manufacturers have to worry about–the weight, feel, and attractiveness of the object itself, deals with payers and retailers offering the product, user interface issues, etc.–the API always seems to be an afterthought. (Apple may be an exception.)

So when Shimmer contacts the tool makers at these vendors, most respond and take suggestions in a positive manner. But they may have just one or two programmers working on the API, so progress is slow. It comes down to the old problem in health care: even with government emphasis on data sharing, there is still no strong advocate for interoperability in the field.

Why did Open mHealth take on this snake’s nest and develop Shimmer? Haddad says they figured that the advantages of open source–low cost of adoption and the ease of adding extensions–will open up new possibilities for app developers, clinical settings, and researchers. Most sites are unsure what to do with device data and are just starting to experiment with it. Being able to develop a prototype they can throw away later will foster innovation. Open mHealth has produced a detailed cost analysis in an appeal to researchers and clinicians to give Shimmer a try.

Shimmer, like the rest of the Open mHealth tools, rests on their own schemas for health data. The schemas in themselves can’t revolutionize health care. Every programmer maintains a healthy cynicism about schemas, harking back to xkcd’s cartoon about “one universal standard that covers everyone’s use cases.” But this schema took a broader view than most programs in health care, based on design principles that try to balance simplicity against usefulness and specificity. Of course, every attempt to maintain a balance comes up against complaints the the choices were too complex for some users, too simple for others. The true effects of Open mHealth appear as it is put to use–and that’s where open source tools and community efforts really can make a difference in health care. The schemas are showing value through their community adoption: they are already used by many sites, including some major commercial users, prestigious research sites, and start-ups.

A Pulse app translates between HL7 and the Open mHealth schema. This brings Open mHealth tools within easy reach of EHR vendors trying to support extensions, or users of the EHRs who consume their HL7-formatted data.

The Granola library translates between Apple’s HealthKit and JSON. Built on this library, the hipbone app takes data from an iPhone and puts it in JSON format into a Dropbox file. This makes it easier for researchers to play with HealthKit data.

In short, the walls separating medicine must be beaten down app by app, project by project. As researchers and clinicians release open source tools that tie different systems together, a bridge between products will emerge. Haddad hopes that more widespread adoption of the Open mHealth schema and Shimmer will increase pressure on device vendors to produce standardized data accessible to all.

Ready For a Third-Party Market for Apps on Your EHR? athenahealth Explains How (Part 2 of 2)

Posted on July 20, 2015 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.

In part 1 of this article, I explained why EHR vendors need to attract outside developers to remain competitive, and how athenahealth’s More Disruption Please (MDP) program pursued this goal by developing open APIs. This part goes on to describe how they made their athenahealth Marketplace an actuality.

Through experimentation, API developers throughout companies and governments have found a toolbox of best practices to develop and promote their APIs. athenahealth pretty much did everything in this toolbox:

  • A prominent public announcement (in this case, coming from the CEO Jonathan Bush himself)

  • A regular set of hackathons to answer developer questions and familiarize them with the APIs,

  • An early pilot partnership that created a demonstration project and produced insights for further development, described in Part 1 of this article

  • An accelerator program that offers seed funding, free office space, mentorship, technical resources, support, and contacts with the client base

  • A commitment to support both physicians and partners, including a requirement that athenahealth developers work on API documentation

Access to the APIs is easy–for security purposes, a developer has to agree to the run-of-the-mill terms and conditions, but the process is fast and there is no charge. The athenahealth Marketplace is large and thriving, with more than 2,500 members.

Having spent a lot of money for an EHR, clinicians who are growing more tech-savvy and have come to love their mobile apps will demand more and more value for the money. Vendors are coming to realize that they can’t produce all the value-added solutions and functionality their customers want.

The SMART Platform has, for several years, championed the availability of EHR data to fuel app development by EHR users and third-party companies. The recent FHIR standard has drawn enthusiasm from vendors. A number of them, including athenahealth, have formed the Argonauts project to develop shared definitions and ensure that, in an interoperable way, they can provide the most common types of data used by US clinicians.

But as explained before, supporting an API does not automatically lead to more effective, beneficial apps or services. athenahealth has gone to the next level to attract real-time, dynamic applications to its Marketplace, and in turn is reaping the benefits.

Ready For a Third-Party Market for Apps on Your EHR? athenahealth Explains How (Part 1 of 2)

Posted on July 17, 2015 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.

A number of electronic health record vendors now grant access to EHR data to programmers at user sites through an application programming interface (API). Hospitals and ambulatory practices are making great use of APIs to extract data on patients and analyze it to improve care (or at least their bottom lines–it’s good for marketing to patients as well as protecting them from adverse medical events).

Far fewer EHRs allow totally new applications to be built by outsiders, suitable for sale or free distribution to health care providers. To find out more about how this can be jump-started, I talked recently to Chip Ach at athenahealth, whose outspoken CEO Jonathan Bush has committed to dealing with health care in new ways. (I reviewed Bush’s book, Where Does It Hurt?,in another article.) Chip Ach is senior architect for athenahealth’s More Disruption Please (MDP) program.

MDP is building an open, API-based ecosystem on athenahealth’s cloud-based platform for entrepreneurs to connect, collaborate, and scale more efficiently in health care. athenahealth allows both established and start-up health IT companies to sign up as partners, creating a large marketplace of innovative, third-party health care solutions. Applications solve such problems as scheduling, speeding up payments, and increasing engagement with patients.

The value of a third-party market
Let’s step back a minute to look at why both vendors and health care providers would want a marketplace for companies to write apps based on their EHR data. Start with the obscurity of the data itself: very few health care providers can find out from their EHRs which patients are frequent ER visitors or which surgeons have consistently better outcomes–data that could trigger critical interventions. Even fewer EHRs provide information to patients, and the patient portals that some providers have made available usually offer extremely limited views.

Second, most EHRs have poor interfaces, a gawkiness that becomes especially evident on the tablets and cell phones that are just as popular among clinicians as the general population. A healthy competition and atmosphere of experimentation among interface developers will greatly improve EHR usability.

Clinicians are just too diverse for one vendor to take into account all their needs. More often than now, clinicians report a drop in productivity after the introduction of EHRs, even after the users get acclimated. If an agile development process could create unique and customizable interfaces, doctors and nurses could go back to focusing on patients.

Finally, unanticipated uses for patient data can emerge from an open marketplace. The use of analytics and clinical decision support could skyrocket.

athenahealth management decided several years ago that the health care system needs a radical change toward generating and accepting new solutions to its pain points. Calling this a “Health Care Internet,” they see it as a place for health care providers to compare and “shop” for nearly any product or service they might want or need, whether it be data management, digital check-in, self-pay, mobile charge capture, or transcription. MDP and the athenahealth Marketplace are their contributions to change.

Steps toward athenahealth’s Marketplace
It takes a special program like MDP to draw developers to a platform, particularly in health care where so many developers are deterred by the field’s complexity and issues of liability. In keeping with the company vision to straighten out the operation of the health care system, athenahealth embraced an open platform, adhering to industry standards such as HL7 and investigating the publication of open APIs.

At the same time, their programmers were modularizing a rather monolithic code to reap the productivity benefits that this would offer. Modularization facilitated the design of APIs to connect one module with another. After announcing a few open APIs and seeing the program catch on, the MDP team asked itself: why not make all their modules available to outside programmers, including those that were previously considered internal?

Early in the program, they found a company eager to develop an appointment scheduling application, and worked closely with them to make it possible. Ach’s team promised to get the API working in three months, which was quite a tight deadline. None of the team had prior experience doing an open API for a market, and they needed to face a lot of new requirements that openness created–for instance, adding an authentication layer, deciding how to deliver documentation on the APIs, and offering the opportunity for developers to get a feel for using the APIs. They now have a developer’s portal open to those who sign their modest terms and conditions. There is no fee or vetting process.

To speed up delivery of an API, athenahealth developers sought out a management service and chose Mashery to do the job. In the end, after a lot of long workdays, they met their three-month deadline. The partner was so sure they’d miss the deadline that it wasn’t ready to use the API–but it caught up and successfully released the app. Along the way, the MDP team learned some of the range of data that needed to be exposed by their APIs.

Eventually, athenahealth dedicated itself to rigorously modularizing their code with well-defined interfaces between all components–like Amazon.com–and to exposing as many interfaces as they could to partners. Naturally, this was potentially frightening; both managers and programmers have to take a leap of faith. What would design decisions made years ago look like when put out in the light of day? How many changes would they have to make?

According to Ach, developers were not resistant for ego reasons (they didn’t mind showing the architecture to outsiders), but worried about their ability to seamlessly upgrade the API in the future. A lot of decisions had to be made quickly before opening the APIs to third-party developers, who would come to depend on them and assume they would remain unchanged. Ach says the teams have been happy with their choices, although early on, in the effort to keep the process moving forward, they didn’t create all their naming standards and left that to be done later.

So the process went smoothly on the inside–but how did it fare externally? That’s the subject of part 2 of this article.

Innovative Collaboration on Medication Management and Community Resources

Posted on April 23, 2015 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.

Although experts agree that the future of health is coordinated care, it is sorely lacking in the US health care system now. This article focuses on the single, relatively simple issue of medication management. Patients are prescribed barrels of pills, but there is little coordination other than looking for contra-indications and drug interactions–and these often suffer from the caretaker’s not knowing the patient’s full complement of drugs.

Sandra Raup, president of Datuit, points out that all kinds of subtleties get lost when patients are simply told how often to take a medication. For instance, if medications are spaced out throughout the day instead of being being taken all at once when we remember to take them (as so many people do), they may be absorbed more effectively and tolerated by the body. Patients–especially those with lower incomes and less education, who are more likely to be on multiple medications in the first place–need all sorts of support.

Here we come to an interesting twist: coordinated care does not have to be initiated by doctors. Given the doctor shortage and the forces keeping clinicians from adopting new models of treatment, other professionals can take on the long-term goals of improving patient health.

In a pilot ramping up in a residence for low-income seniors and the disabled in Maryland, Connected Health Resources is working with Alfa Specialty pharmacy using its Community Health Gateway to help patients straighten out their medications and keep to their schedules. This works because the pharmacy is in a somewhat unusual position: they have supported this community for some time and have built relationships with patients informally. The Gateway pilot has created a service, using Datuit’s SafeIX public API, that can potentially fulfill these needs with less work on the pharmacist’s part. The service is designed for easy navigation by the patients and their family caregivers, making it attractive to the patients and the pharmacists.

Connected Health Resources logo

The SafeIX Platform is designed using modern programming technologies to integrate data from multiple sources (including EHRs and HIEs) into a patient record for both patients and healthcare providers to use, based on their rights to access and share it. In the Gateway implementation, the pharmacist uses the SafeIX Platform to receive CDA documents from the HIE and to auto-assist medical data reconciliation between the various documents.

This information, along with the pharmacist recommendations, are organized into a daily medication calendar using an application from Polyglot Systems Incorporated, a company that offers medication regimen summaries in 18 languages. Low health literacy and the estimated 50 million people who do not speak English at home result in many patients not understanding their medication instructions. The plain language and multilingual, easy-to-use daily calendar can make the difference between understanding and total confusion.

Datuit’s SafeIX Platform uses interoperability standards (including, in test mode, the next-generation FHIR standard) to create a patient record that can show patients everything seen by multiple clinicians and allow a patient’s self-selected care team to view and add to a shared care plan. Datuit is encouraging app developers to build mobile apps for SafeIX that would prompt patients to take medications and record whether they did so, but that’s outside the scope of the pilot. There are plenty of challenges just fulfilling the tasks they have already taken on.

First, Connected Health Resources has to break down the clinical data silos that make it difficult for patients to collect their information. According to co-founder Shannah Koss, Maryland has a relatively advanced Health Information Exchange (HIE) called CRISP. However, it is defined as a provider-to-provider exchange, so it was only after a long-term relationship and negotiation that Connected Health Resources could collect medical data on behalf of the patients. This is the first time CRISP has allowed data to be retrieved for a patient-facing organization that is not a provider.

When enrolling, the patient gives the Gateway permission to get data through CRISP. Family and friends can be invited by patients to be part of their health community and enroll in the Gateway. The invitation includes a unique code that allows the Gateway to securely share records and help with health and social services navigation. If the patient wants help or is incapable of managing the medication list, a caregiver can do so.

CRISP transmits data primarily from hospitals. To round out a more comprehensive listing of medications from clinics and other healthcare providers, CRISP has enabled the ability to query Surescripts, which provides prescription fill data from chain pharmacies and pharmaceutical benefit management companies.

Pilot participants authorize the Gateway and the Alfa pharmacists to access their medication information and maintain, share, and augment the information in the secure SafeIX Platform. The CRISP data gives more complete medication records for the pilot participants. CRISP also provides an event notification system that let’s the pharmacist know whether a patient has been admitted to a hospital or visited the emergency department. These types of transition are precisely when medications get changed, but the clinicians at those crucial junctures often don’t know all of a patient’s current medications.

Finally, over-the-counter (OTC) medications can play an important role in a patient’s care. This has to be added to the daily calendar. The Alfa Pharmacist is helping round out the complete medication picture by working with the patient and family to identify OTC medications, supplements, and the medications that are actually being taken through the medication therapy management (MTM) program. The Gateway provides the means for everyone to better understand and manage the medicines for the best outcomes.

Further, the Gateway Community Resource Finder has enabled information about important resources such as transportation, meal delivery, social services, and home nursing. The MTM pharmacist knows that patients without food or transportation to their physicians cannot adequately manage their health or medications. The underlying SafeIX Platform also allows the Gateway to offer secure messaging that looks like email and lets the pharmacist, patient, friends, and family exchange messages about the patient’s care.

Traditional EHRs don’t accommodate treatment plans of the specificity designed by the pharmacy for patients in the pilot. This is where Datuit is pushing the EHR to new horizons: its SafeIX Platform helps multiple clinicians (including long term care providers), patients, and family caregivers contribute data. For example, patients can enter their own healthcare problems, such as fear of falling. The patients, families, and clinicians can then add interventions to address them.

Like other new organizations I’ve spoken too in health care, Connected Health Resources has grand plans beyond the current pilot. They are taking it slow, because Koss believes personal health records (PHRs) have tried to do too much at once and have overwhelmed their users with too many possibilities. But she would like Connected Health Resources to grow in response to what patients and families say they need. The Gateway tools already include the ability to generate multi-lingual discharge instruction from Polyglot. The initial pilot purposefully focuses on the more narrow scope of medications along with the health and social services support. The next step will be to engage hospitals to provide the plain language multi-lingual discharge instructions.

Chronic care ultimately goes beyond medications to things supported by a patient-centered medical home (PCMH), community health workers, and the many community-based service providers. The Gateway in partnership with the Datuit SafeIX Platform are poised to allow all participants identified by the patient and families to contribute to and be part of their health community.

Open Standards Advance in Health Care Through the Appeal of FHIR and SMART

Posted on October 13, 2014 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.

The poor state of interoperability between EHRs–target of fulminations and curses from health care activists over the years–is starting to grind its way forward. Dr. Kenneth Mandl, a leader of the SMART Platform and professor at the Boston Children’s Hospital Informatics Program, found that out when his team, including lead architect Josh Mandel, went to HIMSS this year to support Cerner’s implementation of his standard, and discovered three other vendors running it.

That’s the beauty of open source and standards. Put them out there and anyone can use them without a by-your-leave. Standards can diffuse in ways the original developers never anticipated.

A bit of background. The SMART platform, which I covered a few years ago, was developed by Mandl’s team at Harvard Medical School and Children’s Hospital to solve the festering problem of inaccessibility in EHRs and other health care software. SMART fulfilled the long-time vision of open source advocates to provide a common platform for every vendor that chose to support it, and that would allow third-party developers to create useful applications.

Without a standard, third-party developers were in limbo. They had to write special code to support each EHR they want to run on. Worse still, they may have to ask the EHR vendor for permission to connect. This has been stunting the market for apps expanding the use of patient data by clinicians as well as the patients themselves.

SMART’s prospects have been energized by the creation of a modern interoperability resource called FHIR. It breaks with the traditional health care standards by being lean, extendible in controllable ways, and in tune with modern development standards such as REST and JSON.

It helps that SMART was supported by funds from the ONC, and that FHIR was adopted by the leading health care standards group, HL7. HL7’s backing of FHIR in particular lent these standards authority among the vendor and health care provider community. Now the chocolate and peanut butter favored by health IT advocates have come together in the SMART on FHIR project, which I wrote about earlier this year.

Mandl explains that SMART allows innovators to get access to the point of care. As more organizations and products adopt the SMART on FHIR, API, a SMART app written once will run anywhere.

Vendors have been coming to FHIR meetings and expressing approval in the abstract for these standards. But it was still a pleasant surprise for Mandl to hear of SMART implementations demo’d at HIMSS by Intermountain, Hewlett-Packard, and Harris as well as Cerner.

The SMART project has just released guidlines for health care providers who want to issue RFPs soliciting vendors for SMART implementations. This will help ensure that providers get what they ask and pay for: an API that reliably runs any app written for SMART.

It’s wise to be cautious and very specific when soliciting products based on standards. The notion of “openness” is often misunderstood and taken to places it wasn’t meant to go. In health care, one major vendor can trumpet its “openness” while picking and choosing which vendors to allow use of its API, and charging money for every document transferred.

The slipperiness of the “open” concept is not limited to health IT. For years, Microsoft promulgated an “open source” initiative while keeping to the old proprietary practices of exerting patent rights and restricting who had access to code. Currently they have made great progress and are a major contributor to Linux and other projects, including tools used with their HealthVault PHR.

Google, too, although a major supporter of open source projects, plays games with its Android platform. The code is nominally under an open license–and is being exploited by numerous embedded systems developers that way–but is developed in anything but an open manner at Google, and is hedged by so many requirements that it’s hard to release a product with the Android moniker unless one partners closely with Google.

After talking to Mandl, I had a phone interview with Stan Huff, Chief Informatics Officer for Intermountain. Huff is an expert in interoperability and active in HL7. About a year ago he led an effort at Intermountain to improve interoperability. The motivation was not some ethereal vision of openness but the realization that Intermountain couldn’t do everything it needed to be competitive on its own–it would have to seek out the contributions of outsiders.

When Intermountain partnered with Cerner, senior management had by that time received a good education in the value of a standard API. Cerner was also committed to it, luckily, and the two companies collaborated on FHIR and SMART. Cerner’s task was to wrap their services in a FHIR-compliant API and to make sure to use standard technology, such as in codes for lab data.

Intermountain also participated in launching a not-for-profit corporation, the Healthcare Services Platform Consortium, that promotes SMART-on-FHIR and other standards. A lot of vendors have joined up, and Huff encourages other vendors to give up their fears that standardization is a catheter siphoning away business and to try the consortium out.

Intermountain currently is offering several applications that run in web browsers (and therefore should be widely usable on different platforms). Although currently in the prototype stage, the applications should be available later this year. Besides an application developed by Intermountain to monitor hemolytic disease among neonates and suggest paths for doctors to take, they support several demonstration apps produced by the SMART project, including a growth chart app, a blood pressure management app, and a cardiovascular app.

Huff reports that apps are easy to build on SMART. In at least one case, it took just two weeks for the coding.

Attendees at HIMSS were very excited about Intermountain’s support for SMART. The health care providers want more flexible and innovative software with good user interfaces, and see SMART providing that. Many vendors look to replicate what Intermountain has done (although some hold back). Understanding that progress is possible can empower doctors and advocates to call for more.