Update: On August 19, 2024, PointClickCare filed a Motion to Expedite Appeal with the United States Court of Appeals for the Fourth Circuit. A copy of the Motion can be downloaded here.
A federal district judge has granted preliminary injunctive relief to Real Time Medical Systems, Inc. (“Real Time”) barring the defendant, PointClickCare (“PCC”), from deploying unsolvable CAPTCHAs that interfered with Real Time’s ability to access the data of its skilled nursing facility customers that utilized PCC. As Judge Xinis wrote in the opinion,
“No evidence supports that PCC had any legitimate good faith use for wholly inscrutable CAPTCHAs which, by definition, blocked Real Time from getting the very records it needs to exist….But even more damning is the timing of such deployments, which support that PCC used those CAPTCHAs as a device to hamstring or eliminate Real Time as a competitor.
Real Time filed suit against PCC in the US District Court for the District of Maryland back in January 2024, alleging information blocking and other practices that substantially interfered with Real Time’s business operations and harmed its facility customers. Real Time argued that PCC’s conduct violated the Information Blocking Rules promulgated under the 21st Century Cures Act, and alleged tortious interference with business relations, unfair competition and breach of contract as a third-party beneficiary claims under Maryland law, entitling it to the preliminary injunctive relief it requested.
To better understand this tale of two competitors and how it can serve as a lesson learned for actors subject to the information blocking provisions of the 21st Century Cures Act (the “Information Blocking Rules”), you’ll need to bear with me as I delve into the history between Real Time and PCC and facts that gave rise to PCC’s deployment of unsolvable CAPTCHAs.
The Players
The plaintiff, Real Time, is a skilled nursing facility analytics vendor with approximately 1,700 skilled nursing facility (“SNFs”) customers. It contracts with SNFs to monitor patient care and alert patient health care teams for medical intervention and preventative care. In order to provide these services, Real Time requires access to patient records maintained by the SNFs’ electronic medical record (“EMR”) vendors, which it gathers using long-standing proprietary automated software.
The defendant, PCC, is a long-term care EMR behemoth that, according to the opinion, holds the records of approximately 1.6 million patients and serves over 27,000 customer facilities. PCC also contracts with SNFs and other post-acute care providers to provide EMR services, including transitions of care and related services that allow PCC customers to share information for referral and treatment purposes. PCC also contractually prohibits its customers from accessing its systems using automated or other process such as screen scraping, by using robots, webcrawlers, spiders or any other sort of bot or tool, in order to extract data. Approximately 80% of Real Time’s SNF customers utilize PCC as a vendor.
The Facts on Record
PCC forayed into the patient analytics market beginning in 2020. It acquired two of Real Time’s competitors and also lost out on a large contract with Maryland’s regional health information exchange, “CRISP”, that Real Time was awarded.
Approximately one year later, PCC approached Real Time with the possibility of a potential merger. The parties entered into an NDA and Real Time opened its books to PCC, disclosing its proprietary business and automated software processes to PCC as a result. PCC apparently ceased negotiations shortly after this without explanation.
For the twelve plus years Real Time had been in business, Real Time operated its analytics service utilizing user credentials issued by its customer facilities. The customer would contract with PCC or another vendor and receive credentials for the customer’s users to access the data maintained in the customer’s EMR by PCC or another vendor. Utilizing its automated software functionality and a single user credential issued by a customer facility, Real Time could automate and streamline its medical record collection process, essentially utilizing its software to do the work of 450 users working 24/7. Once it had collected the data, Real Time could analyze the data for its customer facilities.
Without warning, PCC began to deploy CAPTCHAs[i] on some of Real Time’s user IDs. CAPTCHAs are security devices which typically utilize letters that are designed to be solved only by a human. Such devices are commonly used to prevent automated software or “bots” from accessing an online platform, such as those used by scalpers to purchase sports or concert tickets in bulk online for resale. At first, Real Time was able to utilize its staff to solve the CAPTCHAs for the automated software. However, CAPTCHAs started to become unsolvable even by its staff, resulting in complete downtime for the affected customer facilities and Real Time’s business operations. Although Real Time attempted to explore alternative mechanisms for obtaining the data from PCC after experiencing these shutdowns, PCC ultimately walked away from the table and the unsolvable CAPTCHAs increased.
With several hundred customers affected and Real Time’s operations at a standstill for hundreds of its customers, Real Time subsequently filed suit against PCC on January 9, 2024, alleging multiple causes of action, including unfair competition and tortious interference. Several months later, the unsolvable CAPTCHAs again increased. In its briefs and in hearings, PCC attempted to argue that security and performance concerns prompted its use of the unsolvable CAPTCHAs and that the high number of queries by Real Time using its automated software degraded its systems and essentially functioned like denial of service attacks. However, Judge Paula Xinis was highly critical of PCC’s arguments here, citing the case as the “ugly underbelly” of electronic access to patient health records and blasting PCC for providing no credible evidence or explanation for its assertions that the use of the unsolvable CAPTCHAs was for security and performance concerns. Instead, Judge Xinis found that PCC acted to further its own competitive edge in the market and to damage Real Time’s competitive business, and blocked Real Time’s access to patient medical records in violation of the Information Blocking Rules.
PCC’s Unsupported Defenses to Information Blocking
Real Time argued that the unsolvable CAPTCHAs directly interfered with Real Time’s access to its SNFs’ data. As a health IT developer of certified health IT (one of the covered “actors” subject to the Information Blocking Rules[ii]), PCC is prohibited from engaging in any practice that is likely to interfere with access, exchange or use of electronic health information (“EHI”). For PCC, the standard is that it must know, or should know, that such practice is likely to interfere with access, exchange, or use of the EHI. The only exceptions to this are where the practice is either required by law or covered by an exception under the Information Blocking Rules. If an actor does not adhere specifically to all of the requirements of an available exception, it cannot avail itself of the exception’s protections and may be at risk of being found to have engaged in information blocking as a result.
Here, PCC attempted to rely upon three common exceptions under the Information Blocking Rules in defense of Real Time’s information blocking allegations. It argued there were security risks and performance problems that the unsolvable CAPTCHAs were specifically designed to address, however, at the end of the day, Judge Xinis found that PCC had no reliable evidence or explanation to support its reliance on any of these exceptions and held that PCC’s use of the unsolvable CAPTCHAs violated the Information Blocking Rules.
- Health IT Performance Exception.
Under the Health IT Performance Exception[iii], a practice that is likely to interfere with access, exchange or use of EHI will not be deemed information blocking if the developer or other actor subject to the Information Blocking Rules implemented such to maintain or improve health IT performance, and can demonstrate the following:
- The practice is temporary in order to perform maintenance or improvements to the health IT;
- The practice is implemented for a period of time no longer than necessary to complete the maintenance or improvements for which the health IT was made unavailable or the health IT’s performance degraded;
- The practice is implemented in a consistent and non-discriminatory manner;
- If the actor is a health IT developer (or health information exchange/health information network), the practice must be also consistent with existing service level agreements.
Additionally, if a third party application is negatively impacting the health IT’s performance, the actor may also take action, provided that the practice is:
- for a period of no longer than necessary to resolve any negative impacts;
- implemented in a consistent and non-discriminatory manner; and
- consistent with existing service level agreements, where applicable.
PCC had argued there were many instances of performance degradation and outages which necessitated it taking action through the unsolvable CAPTCHAs. However, Judge Xinis highlighted that PCC could provide no documentation in support of this degradation other than one isolated instance on one day where data retrieval at a single facility was slow – even though PCC supposedly maintained detailed incident reports and tracked such incidents. PCC could also provide no support for how Real Time’s automated software affected its available server space, another argument PCC attempted to make. Additionally, PCC’s use of the unsolvable CAPTCHAs was not temporary – once it was triggered for Real Time, its use eventually became permanent. Finally, it appeared from the record that while Real Time had received unsolvable CAPTCHAs, other users flagged for similar patterns of “high use” received CAPTCHAs capable of being solved by humans (their very purpose!) and therefore, Judge Xinis could not conclude PCC applied the CAPTCHAs in a consistent and non-discriminatory manner.
- Security Exception.
Under the Security Exception,[iv] a practice that is likely to interfere with access, exchange or use of EHI will not be deemed information blocking if and only if:
(a) The practice is directly related to safeguarding the confidentiality, integrity, and availability of electronic health information.
(b) The practice is tailored to the specific security risk being addressed.
(c) The practice is implemented in a consistent and non-discriminatory manner.
Under the Security Exception, an actor can choose to implement the practice through either an organizational security policy or a case-by-case determination. If implementing an organizational security policy, which was the case with PCC, the policy must be prepared on the basis of, and be directly responsive to, the security risks that were identified and assessed by the actor. The policy must also align with consensus-based standards or best practice guidance and provide objective timeframes and other parameters for identifying, responding to and addressing security incidents.
Although PCC held out a “bot” policy that it had implemented, Judge Xinis found that, not only did it appear the policy wasn’t even followed, PCC’s senior vice president couldn’t even point to who was responsible within the organization for implementing it. PCC also had professed concern for security breaches but couldn’t demonstrate whether or how such risks would be present in connection with Real Time’s practices or otherwise, nor how unsolvable CAPTCHAs mitigated any such risks. Further, PCC did not deploy the unsolvable CAPTCHAs consistently or in a non-discriminatory manner, and appeared to be targeting primarily Real Time.
- Manner Exception.
The last exception PCC attempted to rely upon is the Manner Exception. Under the Manner Exception,[v] an actor must fulfill a request for EHI in any manner requested, UNLESS the actor is technically unable to fulfill the request OR cannot reach agreeable terms with the requestor to fulfill the request in the manner requested. If the actor is unable to do so, the actor must fulfill the request in an alternative manner:
- Without unnecessary delay in the following order of priority: (i) using certified technology, (ii) using certain content and transport standards; or (iii) alternative machine-readable format, including the means to interpret the EHI, agreed upon with the requestor;
- If any fees are charged, they must satisfy the Fee Exception at 45 C.F.R. 171.302; and
- Any license of interoperability meets the Licensing Exception at 45 C.F.R. 171.303.
But PCC failed to persuade Judge Xinis here as well. PCC contended that it had given Real Time several alternatives to obtain the data it needed instead of via the user credentials and Real Time’s automated software. However, Judge Xinis found that PCC offered no evidence to demonstrate it was technically unable to provide the data in the manner requested by Real Time (its initial method of access and multiple attempts to obtain through alternative methods). Likewise, Judge Xinis was highly skeptical that PCC was unable to find agreeable terms with Real Time, given the parties had worked extensively towards finding a solution which PCC ultimately abandoned. Instead, Judge Xinis wrote, “PCC offered Real Time an array of business ‘solutions’ that were no solutions at all.”
Lessons to be Learned from PCC
The decision is an unfortunate lesson that highlights common pitfalls actors may stumble into when implementing practices that affect access, exchange or use EHI. Although the Information Blocking Rules do not require per se that an actor’s practices fit within one of the available exceptions, actors can be better assured that a practice will not be viewed as information blocking where the practice fits squarely into an available exception. At the end of the day, PCC appears to have attempted to back its way into available exceptions, after-the-fact, and to no avail. Therefore, even if PCC could have had legitimate security risks and performance degradation concerns about Real Time’s automated software and data pulls, the opinion highlights PCCs failures to adequately assess and document these concerns and narrowly tailor its responses and practices accordingly.
Although no enforcement action has been publicized yet against an actor at the federal level, the Information Blocking Rules remain fully enforceable and in effect for all actors.[vi] The Real Time suit and temporary injunctive relief granted in the opinion highlight the additional risks actors are presented with related to potential information blocking practices. Therefore, it is important for actors to re-assess their information blocking compliance processes and documentation, keeping in mind the following:
- Consider utilizing checklists and decision-tree templates to evaluate practices and requests before action is taken and whether a practice or action conforms with an Exception under the Information Blocking Rules or could be construed as prohibited information blocking.
- Implement policies and processes for responding to routine and non-routine requests for access, use or exchange of EHI. For example, evaluating non-routine requests for access by an application developer to certified health IT maintained by the developer, or establishing routine processes for access to EHI by participants in an HIE/HIN.
- Determine which departments/positions are responsible for reviewing and signing off on practices and actions which have the potential to interfere with access, use or exchange of PHI, including security protols or in responding to requests for EHI.
- All of an applicable Exception’s requirements must be satisfied in order for protection to apply to a practice under the Information Blocking Rules. No deviations are permitted.
- Document. Document. Document. If there are legitimate performance or security issues, for example, records of server logs demonstrating slow performance, multi-factor authentication requirements supported by industry standards or best practices, or if a requestor would not be permitted under applicable laws to have access in the manner requested, the organization must document this. All security risks, recommendations and other considerations which a practice or action is taken in response to, including reliance upon an Exception, should be clearly identified and retained by the actor.
- If relying upon the Health IT Performance Exception to deny a request for access to EHI or to implement a particular practice, ask yourself the following questions:
- Is the practice necessary for maintenance or improvement of health IT performance?
- Is the practice or action temporary and implemented for no longer than necessary to make such improvements or maintenance?
- Is the practice or action implemented consistently and in a non-discriminatory manner, in accordance with any applicable service level agreements or agreements with a requestor?
- If relying upon the Security Exception to deny a request for access to EHI or to implement a particular practice, ask yourself the following questions:
- Is the practice or action based on a written Organizational Policy?
- Does the Organizational Policy establish the specific security risks that it is intended to directly address, including reliance upon applicable industry standards or guidance?
- Does the Organizational Policy provide clear direction, objective timeframes and other parameters around security incidents?
- Does the Organizational Policy directly relate to safeguards for confidentiality, availability and integrity of EHI?
- Is the Organizational Policy tailored to be responsive to these identified security risks and safeguards?
- Is the Organizational Policy followed consistently and in a non-discriminatory manner?
- Have employees been trained on the Organizational Policy and understand their responsibilities?
- If the practice or action is not based on a written organizational policy, is the practice or action evaluated on a case-by-case basis giving consideration to all of the facts and circumstances, the unique security risks that the practice or action would directly address, and consideration given to reasonable and appropriate alternatives to address the security risk?
- If relying upon the Manner Exception to deny a request for access to EHI or propose alternative mechanisms of access, ask yourself the following questions:
- Do the technical capabilities exist to fulfill the request exactly in the manner asked for by the requestor?
- Can mutually agreeable terms for fulfilling the request be decided upon with the requestor after good faith negotiations?
- If the request cannot be fulfilled because the organization cannot technically do so, or mutually agreeable terms cannot be achieved with the requestor, has the organization attempted to fulfill the request in the order of priorities required (i.e., offer access with those technical capabilities for which the health IT is certified to, recognized content and transport standards or alternative machine-readable format?)
- If the request cannot be fulfilled in the manner asked for by the requestor, has the organization evaluated any fees or license conditions which would be required of the requestor for compliance with the Fee Exception and License Exception?
[i] CAPTCHA stands for “Completely Automated Public Turing Test to Tell Computers and Humans Apart.”
[ii] Other actors include health care providers and health information exchanges/health information networks. 45 C.F.R. 171.102.
[iii] 45 C.F.R. 171.205.
[iv] 45 C.F.R. 171.203.
[v] 45 C.F.R. 171.301
[vi] United States Office of the Inspector General, Grants, Contracts, and Other Agreements: Fraud and Abuse; Information Blocking; Office of Inspector General’s Civil Money Penalty Rules, 88 F.R. 42820 (July 3, 2023); United States Centers for Medicare & Medicaid Services, 21st Century Cures Act: Establishment of Disincentives for Health Care Providers That Have Committed Information Blocking, 88 F.R. 54662 (July 1, 2024).
