Introduction

Within our current system of law and public policy, natural language functions as the standard method to express rules and regulations. Indeed, natural language governs the legal options, relationships, and constraints that define both everyday interactions and complex transactions. However, because this kind of natural language is often in obtuse legalese, the law is often prone to incompleteness, ambiguity, and inaccurate interpretation that may negatively affect the relevant parties.^[1] Additionally, it is difficult for most people, even trained lawyers, to read and process long legal texts or statutes, accurately track complex conditions, and derive the appropriate legal options.

Translating legal relationships from natural language to formal logic language can potentially reduce ambiguity and increase the efficiency and accuracy of legal interpretation. Instead of human interpreters, computers navigate these legal relationships. To test this method, we modeled the Privacy Rule in the Health Insurance Portability and Accountability Act (“HIPAA”) in a way that computers can automatically reason over the different rules and conditions. This overall act is a set of complex regulations that governs the legal relationships among various parties in various stages. We argue that because HIPAA is a multi-party, multi-state dynamic regulatory regime, computational law can be useful in mapping these complex legal interactions.

Background and Problem Statement

Congress enacted HIPAA in 1996.^[2] The Act itself is massive in breadth and detail, embodied in five titles. The HIPAA Privacy Rule is particularly important because it addresses security and data privacy issues for health care providers, patients, and other parties. Yet even within this one section, the regulations span over forty pages and interact with other parts of HIPAA.

All types of healthcare providers and related organizations, collectively known as “covered entities,” are the main subjects of regulation and must comply with the Privacy Rule’s provisions. The Rule’s complexity can hinder compliance and lead to potentially huge penalties for parties that violate HIPAA. For example, the Department of Health and Human Services (“HHS”) investigated New York Presbyterian Hospital and Columbia University Medical Center for failing to enact security measures regarding data breaches.^[3] As a result, these parties settled charges for $4.8 million.^[4] To provide clarity regarding the Privacy Rule, we can use computational law and model how HIPAA affects relevant parties. In doing so, our product can help Covered Entities prevent potential violations and confirm that their practices comply with HIPAA.

Additionally, HHS receives a growing number of HIPAA-related complaints each year,^[5] which strains HHS’s ability to investigate and resolve violations in a timely manner. Anyone can file a complaint online, and the number of complaints has skyrocketed from 1,516 in 2003 to 14,300 in 2013.^[6] Yet many of these complaints are illegitimate—HHS found that 90,883 out of 114,421 complaints could not be enforced.^[7] Often, these claims are unsuccessful for definitional reasons: a certain party did not constitute a “covered entity,” or the alleged actions did not actually violate HIPAA.^[8] To address this problem, our computational product can illustrate when there are valid claims for HHS and potential claimants. Thus, computational law can help HHS more efficiently processing future claims, reduce the associated administrative cost, minimize illegitimate claims, and focus on complaints that deserve further investigation.

Methodology

In order to model the logical relationships among different parties in the privacy rules with HIPAA, we used System Description Language (SDL). SDL is a non-Markov version of Game Description Language (GDL), where SDL adds a “step” argument to its structure, so a given rule can be described in the context of conditions in one step that leads to (or fails to lead) a condition in the succeeding step. SDL’s other structural relationships mimic that of GDL.^[9]

What makes SDL powerful and useful when mapping the privacy rules of HIPAA is that within the HIPAA framework, many actors are involved, and the range of legal options of a covered entity—the main subject of these privacy regulations—changes according to certain conditions or the actions taken by other actors.

For example, in state M, a patient has not granted permission for her healthcare provider to use her Protected Health Information (PHI), the type of information that the HIPAA Privacy Rules protects. In this state, the healthcare provider can only exercise “professional judgment” in disclosing the patient’s PHI: would it would be beneficial to the patient to disclose this information, and to whom should the healthcare provider give this information? However, if in state M a patient does grant permission, the range of the healthcare provider’s options in the next state, N, will expand to immediate disclosure to family, friends, or other people involved in the treatment, as well as third-party marketers, depending on the substance of the actual permission.

SDL allows us to capture these dynamic constraints and accurately map the legal options available to a healthcare provider in a given state, depending on the actions taken by the other actors involved. Applying this feature of SDL to the rest of our rule-mapping allows us to formalize different relationships among multiple parties. By transforming the legislative language of HIPAA into formal logic using SDL, we are able to pass the rules through a pre-existing inference engine, which computes the contractual relationships that the rules govern.

Product

Our product maps out the vast majority of the regulations and constraints within HIPAA, which has been the source of many litigations between covered entities and the Department of Health and Human Services, which is the designated federal agency that enforces HIPAA privacy compliances. Below we will describe two hypothetical scenarios to show how our product works.

Scenario 1: Options Expanded

In this scenario, the three actors are Zack (the patient), Kantor (Zack’s health provider), and Athena (a third party, health-tech startup). Kantor wants to disclose Zack’s age, which is a type of PHI specified in HIPAA, to Athena for marketing purposes. In order for Kantor to do this legally, Zack must provide written authorization to Kantor, permitting this disclosure. (Note: non-written permission would not work.) Thus, in state 0, the beginning, when Kantor has not obtained Zack’s written permission, Kantor’s options do not include “marketing”.

Figure 1: State 0 – No Marketing Option

However, if Zack does provide written authorization in state 0 (in our product, you would select Zack in the patient box, select the “writtenauth” option under Zack, then click “Perform Selected Actions”), it will move things to state 1, the next state, and Kantor will have the marketing option available to disclose to a third party, like Athena.

Figure 2: State 1–Marketing Option Available

Scenario 2: Options Limited

This scenario is between Kantor and HHS. In HIPAA, when HHS requests PHI from a covered entity like Kantor, for example, if HHS received complaints by patients regarding potential HIPAA violations and wanted to investigate Kantor, Kantor is required to disclose the requested information to HHS, which limits Kantor’s legal options. Here in state 2, HHS is requesting Kantor to disclose Zack’s age as a part of its investigation.

Figure 3: State 2–HHS requests Zack’s Age

After HHS performs this request, we move to state 3, where Kantor is legally obligated to disclose Zack’s age to HHS. If Kantor does not disclose and instead chooses to commit another action, it is considered illegal; therefore, our system will show an alert stating that PHI must be disclosed and will not move on to the next state until Kantor commits the correct, legally required action.

Figure 4: State 3–Kantor Must Disclose PHI

Limitations

There are certain limitations to our product and computational law when we translate natural language into formal logic. First, we assume that legal concepts have a static meaning, but in reality, these concepts can change according to societal norms and court decisions. As a set of regulations, HIPAA is more static in meaning than case law, but definitions of concepts can still change. Thus, our product only models the Privacy Rule according to the current text and definitions.

Second, some natural language terms in HIPAA are ambiguous and require human interpretation outside of computational law. For example, in certain situations, a provider can exercise professional judgment to disclose PHI, but what constitutes “professional judgment”? The regulations do not define this term and leave this term open to interpretation. Likewise, our product models interactions between parties under the notion that the user decides whether or not a certain situation warrants “professional judgment.”

These issues can lead to different outcomes depending on the user’s interpretation of “professional judgment,” both in terms of HIPAA and healthcare externalities like doctor-patient relationships. For example, as Bernard Lo et al. have discussed, legally risk-averse interpretations of “professional judgment” could potentially hinder essential communications and patient care.^[10] The definition-flexibility and user discretion issues highlight the general limitations in moving from natural language to formal logic.

Next Steps

In light of these issues for computational law, we recommend focusing on regulations that are self-defined and rule-oriented rather than regulations that rely on flexible standards. Additionally, computational law would more accurately apply to regulations where word-ambiguity is minimal, or where these ambiguities are not important to the parties’ outcomes.

Future developments in computational law regarding HIPAA could include real use-cases. For example, we could envision embedded computational contracts in healthcare databases that would alert a healthcare provider when she must request a patient’s consent. In doing so, the system could generate a patient consent agreement and send it to the patient.

Finally, in terms of our product, we could create variations when computing the Privacy Rule according to differing interpretations and their legal risk levels for the involved parties. This would help structure ambiguity in a way that is meaningful to users from a legal perspective.

Acknowledgement

We would like to express our gratitude for Sudhir Agarwal of the Stanford University Computer Science Department for guiding us through the modeling process of the privacy rules using SDL and helping us put together an user interface to demonstrate the product. We would also like to thank Professor Michael Genesereth of the Stanford University Computer Science Department for giving us the inspiration for this project and introducing us to Sudhir.

^[1] Oliver R. Goodenough & Mark D. Flood, Contract as Automaton: The Computational Representation of Financial Agreements, Dep’t Treasury Off. Fin. Res. 1, 9 (2015).

^[2] Health Insurance Portability and Accountability Act (HIPAA). Pub. L. No. 104-91, 110 Stat. 1936 (1996) (codified at 42 U.S.C. §§ 300gg, 1320d et seq., 29 U.S.C. § 1181 et seq.).

^[3] HHS, Data Breach Results in $4.8 Million HIPAA Settlements, U.S. Dep’t Health Hum. Servs., (May 7, 2014) http://www.hhs.gov/news/press/2014pres/05/20140507b.html.

^[4] Id.

^[5] HHS, Health Information Complaints Received by Calendar Year, U.S. Dep’t Health Hum. Servs.,

http://www.hhs.gov/ocr/privacy/hipaa/enforcement/data/complaintsyear.html (last visited June 24, 2015).

^[6] HHS, Enforcement Results by Year, U.S. Dep’t Health Hum. Servs., http://www.hhs.gov/ocr/privacy/hipaa/enforcement/data/historicalnumbers.html (last visited June 24, 2015).

^[7] HHS, Enforcement Highlights, U.S. Dep’t Health Hum. Servs., http://www.hhs.gov/ocr/privacy/hipaa/enforcement/highlights/index.html (last visited June 24, 2015).

^[8] Id.

^[9] Michael Genesereth, Games with Historical Constraints, http://logic.stanford.edu/ggp/chapters/chapter_18.html, (last visited June 12, 2015).

^[10] Bernard Lo, Laurie Durband, & Nancy N. Dubler, HIPAA and Patient Care: The Role of Professional Judgment, 293 Am. Med. Ass’n 1766, 1766 (2005) (using “risk” as related to the risk of violating HIPAA).