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!

Why Delaying the Transition to 2015 Edition Technology Would Be a Problem for Patients and Families – MACRA Monday

Posted on September 11, 2017 I Written By

The following is a guest blog post by Erin Mackay, Associate Director, Health Information Technology Policy and Programs, National Partnership for Women & Families.  This post is part of the MACRA Monday series of blog posts where we dive into the details of the MACRA Quality Payment Program (QPP) and related topics.

The National Partnership for Women & Families recently weighed in on the Centers for Medicare & Medicaid Services’ (CMS) proposed rule for 2018 updates to the Quality Payment Program (QPP). In our comments, we express concerns that many of the proposed requirements would have a chilling effect on the country’s badly needed transition to a health care system that rewards quality and value over volume. Of particular concern to us is the proposed delay in clinicians’ transition to the 2015 Edition electronic health record (EHR) certification requirements.

Putting off requirements to use more advanced health IT would be a one-two punch to health transformation. First, new models of care that demand high-quality, efficient practices and coordinated care rely on robust health IT. Likewise, these new models only succeed when patients have the information – about their medications, health status, diagnoses and treatment received – they need to participate in their care and make informed decisions with their health care teams.

Here are three ways the proposed rule would delay critical functionalities that are foundational to a patient and family-centered health care system:

1) Delaying Availability of APIs for Consumer Access
It would undermine the commitment to patient engagement to delay the availability of application programming interfaces (APIs) as a way for patients and their caregivers to access, download and share health data. When available, APIs will let consumers choose from a range of apps that pull in health data from various health care providers and hospitals, helping form a comprehensive picture of their health and health care and facilitating information sharing. Gone will be the days when patients and family caregivers struggled to remember passwords for multiple patient portals, or were able to view only one aspect of their medical history at a time.

2) Slowing More Robust Collection of Demographic Data
To enhance health equity, we must first be able to identify disparities by gathering standardized, granular demographic data. Right now, certified EHRs are not designed to distinguish among Chinese, Indian or Vietnamese patients, for instance, instead collapsing these identities into a single “Asian” category. Similarly, EHRs cannot currently store structured information about patients’ sexual orientation or gender identity. In both these examples, this information has clinical relevance and is vital for improving health outcomes. For example, too often transgender individuals do not receive appropriate “gendered” preventive screenings such as Pap tests, mammograms and prostate exams.

3) Failing to Capture Information on Social Determinants of Health
In addition to better demographic information, to best support providers in delivering patient- and family-centered care, EHRs should also capture information about non-clinical factors pertinent to individuals’ health. The 2015 Edition includes a new criterion to capture relevant social, psychological and behavioral data. This includes information on financial resource strain, educational attainment, stress, depression, physical activity, alcohol use, social connection and isolation, and intimate partner violence. At the individual level, this information could help clinicians and care teams determine treatment options that address the unique needs of the patients and families they serve. To improve population health, clinicians, hospitals and community organizations need this information to identify communities that need additional support in order to get and stay healthy.

Conclusion
Overall, the proposed rule for QPP 2018 raises a number of concerns for the National Partnership, particularly the proposed delay of 2015 Edition certified health IT products. We strongly encourage CMS to maintain the current requirements and timeline for clinicians transitioning to the 2015 Edition to provide the necessary infrastructure for the kind of patient- and family-centered health system our country urgently needs.

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.

Following the Spread of APIs in Health: BaseHealth’s Genomic Health Analysis

Posted on June 3, 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.

Because health care has come late to the party, companies in that field have had plenty of time to see the advantages that Application Programming Interfaces (APIs) have brought to other areas of computing and commerce. BaseHealth Enterprise, which has been offering comprehensive health assessments based on a patient’s genetic information and other health factors for five years through a Software as a Service (SaaS) platform, is now joining the race to APIs. The particular pressures that led to the development of their APIs makes an interesting case study.

Although the concept of an API is somewhat technical and its details call for a bit of programming background, the concept driving API use is simple. We all use web sites and mobile apps to conduct business and interact, but an API allows two applications to talk to each other, serving as a pipe of information transfer. Thus, crucial tasks can be automated and run on a routine basis using an API. BaseHealth modestly suggests in their press release that their API “marks the first time in human history that genomic data is on-call for developers across the globe.”

Example of request for sleep apnea information

Example of request for sleep apnea information

I talked last week to BaseHealth’s CEO Prakash Menon and to Hossein Fakhrai-Rad, founder and Chief Scientific Officer. They offer five basic services, all based on evaluating the genomic and phenomic (observed) data from a patient. A developer can call for such information as:

The patient’s risk for a particular common complex disease, along with risk factors that make it more likely and recommended lifestyle changes The likely effectiveness of a particular drug for a condition, given the patient’s genetic makeup Likely patient responses to various nutrients

Genomic testing is done by companies such as Illumina. Different testing services make very different judgments about the significance of various genes, but there are now evaluation sites (which perform a kind of crowdsourcing to accumulate information validating these judgments) to offer more confidence in the tests. BaseHealth accepts this data along with information about family history, lifestyle, and the patient’s environment to make useful recommendations about handling diabetes, cancer, stroke, gout, sleep apnea, and many other common conditions.

Previously, many health plans and hospitals were interested in the BaseHealth SaaS platform, but did not want to adopt a new application and UI into their existing systems because of the cost of implementation and the time it would take to train healthcare professionals on a new system. The BaseHealth API allows developers at these organizations to use specific features of BaseHealth’s comprehensive health assessment without having to overhaul their existing systems.

Furthermore, large genetic sequencing results are time-consuming and expensive to transmit, and it was wasteful to store them twice (at the provider and at BaseHealth). Some countries also prohibit the transfer of genetic data outside the country’s border for privacy reasons.

BaseHealth’s APIs therefore allow a totally different interaction model. Data can be stored by health care providers and patients, then combined by an application (usually run at the provider’s site) and submitted as a JSON data structure to the API. Only the specific information required by the API needs to be transferred. It is conceivable that apps could be developed for patient use as well. However, because BaseHealth does not offer direct-to-consumer genetic testing, they have none of the problems that 23andMe suffered.

In a field where many vendors scrutinize and limit access to APIs, it’s important to note that BaseHealth’s API is available for all to use–there is no gateway to get through, only a short registration process in which BaseHealth collects a developer’s email address. One can submit 1,000 requests each month for free-making participation easy for small providers-and then pay a small fee for further requests.

APIs hold the promise to streamline health care just as they have reduced information friction in other industries. The BaseHealth experiment illustrates why an API is useful and how it can alter the business of health care.