An ongoing lawsuit between two health IT companies raises questions that call for more discussion. Already, the judge’s preliminary injunction in the case (Real Time Medical Systems, Inc. v. PointClickCare Technologies, Inc.) has led independent observers to predict a shake-up in health care and the potential for future lawsuits.
Some of the issues covered in this series include:
- The demands made on infrastructure by hot, new analytic technologies, which often run automated queries (called “bots” in the court documents) on data at frequent intervals
- What EHRs offer clinicians, and what new capabilities clinicians are asking for
- Safety and reliability in data extraction from the EHR
- The competitive advantage that accrues to the institutions storing data
More specific questions raised in the case include the legitimacy of an extensive 1990s-era web technique called “screen scraping,” and how broadly the ban on “information blocking” by the U.S. Department of Health & Human Services should be applied.
But looming over all these arcane discussions is our data. Every person in the U.S. health care system should be concerned about the points made in this article, because companies are fighting over our personal information, and the repercussions affect our health outcomes.
This series is not going to take sides or analyze the merits of the arguments in the lawsuit. One reason is that the U.S. District Judge Paula Xinis has issued only a preliminary injunction, and publicly available information about the case is meager. Furthermore, I have no desire to play a judge, even on TV.
Finally, both litigants are sponsors of this publication, Healthcare IT Today. Both have provided me with formal statements but don’t want to discuss what they do in detail for the press. However, short summaries of aspects of this case will appear in this series as I explore general issues.
Locating PointClickCare in the Health IT Industry
PointClickCare has a long history of offering data storage and services to clinical organizations, “enabling meaningful care collaboration and actionable patient insights” according to their product summary. The service has developed several facets over time. They write to me, “More than 1.2 million clinicians, nurses, and other healthcare professionals access our platform on a daily basis to deliver patient care to approximately 1.6 million patients and collaboratively share clinical data.” The company has made particular progress as a provider for skilled nursing facilities.
During the past year, PointClickCare certified their service as an EHR with the Office of the National Coordinator (ONC), which allows the company to demonstrate compliance with laws and standards such as HIPAA. In particular, certification demonstrating interoperability, which the company describes as “central to this litigation” and “a key driver for PointClickCare.” The certification turns out to have other legal consequences examined in a later article in this series.
In addition to logging in as individuals and viewing reports, clinicians can run automated programs using APIs provided by the PointClickCare Marketplace, just as with most EHRs today.
Overall, PointClickCare offers eight options for data access, which range from downloadable PDFs to the Marketplace APIs and the popular, cross-platform CareQuality interoperability framework.
Now we should step back from the court case to examine the relatively new role of APIs in health care. Although the term “application programming interface” is very general and could apply to any computer library ever created, the abbreviation became a buzzword a few decades ago, referring specifically to web services that offer automated, programmatic access to the third-party services.
Third-Party Program Access Comes to EHR Data
In 2002, Amazon.com famously committed itself to API access to everything, first for internal efficiencies, and then to support a market of other vendors and institutions.
The movement toward public APIs spread rapidly. EHR vendors at first had no incentive to support third-party access, although they were urged to do so by health care reformers such as SMART. Eventually, recognizing a changed environment, the vendors joined the API movement. But API coverage is still extremely limited, as I learned from Lisa Bari, CEO of Civitas Networks for Health, and Brendan Keeler, Interoperability and Data Liquidity Practice Lead at HTD Health.
These observers point out that patient data is extraordinarily large and complex. It takes time to write a programming library that can extract each field from an EHR and present it to an outside program, even given the modern FHIR standard (itself complex and evolving). The API gap is, Bari says, “when regulation meets reality.”
Now let’s turn back to Real Time v. PointClickCare. Real Time is an analytics firm offering predictive analytics through AI to skilled nursing facilities. Typically, Real Time analyzes data from the nursing facility and acute care settings on a daily basis or more often, and reports which patients are at risk of adverse events.
In short, Real Time is typical of a very hot, fast-growing area of analytics in health care. Emphasizing the clinical value of its offering, they pointed to a recent independent study published in the American Journal for Managed Care, showing that facilities using Real Time enjoyed much lower hospital readmissions, more successful discharges, lower Medicare spending per beneficiary, and fewer health care–acquired infections.
For more than nine years, Real Time had gotten the access it desired to records in PointClickCare. But in recent years, they found that the “eight secure options” provided by PointClickCare gave access to only 30% of the needed data. This finding appears in the judge’s ruling, along with details about negotiations for more access that broke down. But PointClickCare writes to me that “more than 1,900 partners abide by its bot prevention policy and have been accessing patient data through the eight secure options it provides. Real Time is the only one who claims there’s an issue.”
So Real Time found a workaround: It would run an automated program—a bot—that logged in through an account created by its client, pulled up a web page with the relevant data, and extracted it using screen scraping.
Now let’s dive into the automated bots for data access and a practice called screen scraping, which I’ll define here along with its implications in health care. But to understand the issues at stake, we also have to take a broad view of what has happened to patient data since the rise of big-data, AI-driven analytics.
Sliding Into Big Data
As I explained above, PointClickCare is a certified EHR that serves a range of clinical care sites and particularly skilled nursing facilities.
PointClickCare was founded more than 25 years ago in a simpler, more innocent era of health care data. A health record was an archive, assiduously updated at patient visits but rarely consulted. A few daily reports could help hospitals do capacity planning and resource management.
But the analytics side of health grew and grew. The government required more and more data to be collected, including quality data and data revealing inequity in health care delivery. Hospital administrators wanted to go beyond simple utilization trends and delve more deeply into their data, goaded by companies providing new analytics tools who promise (and deliver, in the case of Real Time) significant clinical and administrative benefits.
PointClickCare has evolved to keep up with the times. Their statement to me says, “We collaborate with and provide data to numerous parties on the PointClickCare Marketplace,” many of them companies who do analytics like Real Time.
I think that different approaches to data use are getting blurred nowadays. If a clinical site wants to deploy its data in a variety of ways, and leave open opportunities for the rapid adoption of new analytics, they need either to store it on-premises or contract for Data Storage as a Service (DSaaS). Downloading and uploading the data should be as seamless and natural as maintaining a database on-premises. And the client can run as many automated tools or bots as they can afford under their data access plan. This sort of service is available from all the major, generic cloud vendors (Amazon Web Services, Microsoft Azure, Google Cloud, and more).
I doubt that the hospitals and skilled nursing facilities who contracted with PointClickCare really thought about their ongoing data needs. Few of us read the terms of service on the sites we log into every day. Data administrators and corporate lawyers at the clients who use data services, however, should be intimately aware of the limitations imposed by a storage service.
Real Time’s customers, I deduce, signed deals that were overly limiting given the uses they came to make of their patient data. I ultimately hold the customers partly at fault for the dispute between Real Time and PointClickCare. Although each side of the lawsuit lakes different claims about where the problem lies, the bottom line is that Real Time resorted to screen scraping because it could not do what its clients needed under PointClickCare’s current APIs and data sharing models.
What is Screen Scraping, and What are Its Implications in Health Care?
As mentioned earlier, screen scraping is a programming technique dating back to the early years of the Web. To see why it has been popular, consider the web page from Healthcare IT Today displayed in Figure 1. A human reader with normal eyesight can easily pick out headlines, dates, and article summaries. A blind person using a screen reader, or a computer programmer hoping to analyze the web site, would have much more trouble.
Here’s how screen scraping can get the computer programmer what they need. The programmer views the HTML behind the page and looks for unique elements that mark headlines, dates, and summaries. A headline, in the particular template currently in use at Healthcare IT, is fairly easy to recognize because it is preceded by a regular heading tag, h2, plus some other verbose HTML. Then comes a div tag that (after stripping away more HTML) leaves the date. A second div tag contains the summary.
The programmer can now write a program that downloads the HTML of the home page and extracts the useful information. The program, traverses the page for h2, div, and other expected HTML. The program can be run automatically to produce information about Healthcare IT Today on a regular basis.
But screen scraping is inherently unreliable and fragile. Healthcare IT Today might change the template it uses, or the template’s designer might silently change the HTML. Suddenly the screen scraping program would break, the programmer would receive an emergency phone call, and the system would be down for however long it takes the programmer to revisit the site, decipher the new HTML, and write a new program.
Furthermore—and of particular concern to health care—what if a change in the page led the program to extract incorrect information? What if the program filled in the wrong field or assigned a field to the wrong patient?
In short, screen scraping is a kludge. It’s a desperate way to get data that is not (but usually should be) available in a more structured manner.
And yet, numerous analytics firms (not just Real Time) employ screen scraping to extract EHR information. I learned this from Lisa Bari, CEO of Civitas Networks for Health, and Brendan Keeler, Interoperability and Data Liquidity Practice Lead at HTD Health. Let’s look at the reasons for this practice, and its implications.
Screen Scraping and Terms of Service
Bari and Keeler tell me that screen scraping is widely practiced at analytics companies using EHR data. Therefore, Keeler says, many EHR vendors (including PointClickCare) prohibit logins by bots, and screen scraping in particular. Also like PointClickCare, some vendors put technical measures in place to prevent this practice.
Why? In addition to the risks explained here, the vendor might want to monitor and charge for data use through its APIs. The company may also feel uneasy in general having programs do unanticipated things with web pages designed for human consumption. Bari says, “EHR vendors like knowing who got the data, when, and how.”
Why, then, is screen scraping so common? As the previous article pointed out, there may be important data for which the EHR vendor did not yet provide an API. If the API is provided, there may be onerous limits on or high charges for its use.
Documents from the court case show that Real Time engaged in long negotiations over data access with PointClickCare before adopting screen scraping. This process leaves the impression that cost or restricting access were the motivation, but we really don’t know.
When PointClickCare denied access to Real Time, the latter sued. Besides demonstrating that they could not offer their analytics to their nursing facility clients without access to the data, Real Time submitted 222 pages of correspondence and other historical data to back up its claims that PointClickCare is deliberately blocking access to patient data.
Integral to Real Time’s complaint is that PointClickCare wants to replace Real Time with its own service, and therefore is engaging in anti-competitive practices. I won’t explore that side of the suit, but the judge did suggest that the timing of PointClickCare’s behavior made it “a device to hamstring or eliminate Real Time as a competitor.” In response, PointClickCare writes, “We collaborate with and provide data to numerous parties on the PointClickCare Marketplace, which includes those who offer similar services to Real Time as well as commercially successful competitors who are much larger than Real Time.”
So let’s turn to the mechanism used by Real Time to declare PointClickCare’s behavior illegal (successfully, so far, based on the judge’s preliminary injunction). It’s time to examine the concept of “information blocking” and the new burdens AI is placing on healthcare data in the next article in the series.
No comments:
Post a Comment