Towards HIPAA-compliant Healthcare Systems!!

Ruoyu Wu, Gail-Joon Ahn and Hongxin HuArizona State UniversityTempe, AZ 85287, USA

{ruoyu.wu, gahn, hxhu}@asu.edu

ABSTRACTIn healthcare domain, there is a gap between healthcaresystems and government regulations such as the Health In-surance Portability and Accountability Act (HIPAA). Theviolations of HIPAA not only may cause the disclosure ofpatients’ sensitive information, but also can bring abouttremendous economic loss and reputation damage to health-care providers. Taking e!ective measures to address this gaphas become a critical requirement for all healthcare entities.However, the complexity of HIPAA regulations makes it dif-ficult to achieve this requirement. In this paper, we proposea framework to bridge such a critical gap between healthcaresystems and HIPAA regulations. Our framework supportscompliance-oriented analysis to determine whether a health-care system is complied with HIPAA regulations. We alsodescribe our evaluation results to demonstrate the feasibilityand e!ectiveness of our approach.

Categories and Subject DescriptorsK.4.1 [Computers and Society]: Public Policy Issues -Privacy; K.6.5 [Management of Computing and Infor-mation Systems]: Security and Protection

General TermsSecurity, Management

KeywordsPrivacy Policy, HIPAA regulations, Compliance

1. INTRODUCTIONWe have witnessed several organizations such as hospitals,

financial institutions, and government sectors have been suf-fering from information leakage and policy violations due

!All correspondence should be addressed to Dr. Gail-JoonAhn, POBOX 878809, Tempe, AZ 85287, gahn@asu.edu,http://sefcom.asu.edu.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.IHI’12, January 28–30, 2012, Miami, Florida, USA.Copyright 2012 ACM 978-1-4503-0781-9/12/01 ...$10.00.

to the lack of systematic mechanisms for policy compli-ance and enforcement [5, 11, 23]. For example, Health In-surance Portability and Accountability Act (HIPAA), theGramm-Leach-Bliley Act and the Sarbanes-Oxley Act havebeen approved and enforced for such organizations. How-ever, the opacity of the legal language and the complex-ity of these regulations make it harder for organizations tobe fully complied. The consequence of noncompliance ispriceless, which includes government fines, the cost of courtrepresentation, lost reputation, brand damage, governmentaudits, and workforce training cost. For instance, recentdata breach at ChoicePoint costs more than 27 millon dol-lars [34]. From the studies in The New England Journalof Medicine and American Hospital Association they esti-mate that hospitals budgeted between 360 million and 1.2billion dollars for HIPAA compliance in 2003 [6, 24]. Thisestimate is only for hospitals, and does not consider clin-ical o"ces, health insurance companies, and other entitiesgoverned by HIPAA. Due to the tremendous consequencescaused by noncompliance, it is critical to properly enforceand comply with regulations.

In this paper, we present a compliance analysis frame-work to bridge the gap between healthcare systems andHIPAA regulations. First, we extract policy patterns fromboth HIPAA regulations and policies in healthcare systems,and then a generic policy specification scheme is formulatedto accommodate those identified patterns. In addition, wepropose a two-step transformation approach, in which thefirst step is to transform both HIPAA regulations and sys-tem policies specified in a natural language into a formalrepresentation and the second step is to further transformthe formal policy representation into a logic-based repre-sentation. In addition, we discuss our compliance analysismethod, which ensures policies in healthcare systems arein compliance with HIPAA regulations by leveraging logic-based reasoning techniques. We also discuss a case studywith policy sets from a practical healthcare system to showshow feasible and e!ective our framework is.

The rest of this paper is organized as follows. We give anoverview of HIPAA regulations and Answer Set Program-ming in Section 2. In Section 3, we present a complianceanalysis framework for bridging the gap between healthcaresystems and HIPAA regulations followed by a case studyin Section 4. Section 5 describes the implementation andevaluation of our approach. We discuss the related workin Section 6. Finally, Section 7 concludes this paper anddiscusses our future direction.

593

2. BACKGROUND TECHNOLOGIESIn this section, we describe HIPAA regulations as well

as provide an overview of Answer Set Programming (ASP),which is a declarative programming paradigm oriented to-wards combinatorial search problems and knowledge inten-sive applications.

2.1 HIPAA regulationsThe U.S. HIPAA title II [1] was enacted in 1996 for nu-

merous reasons which include the need for increased pro-tection of patient medical records against unauthorized useand disclosure. The HIPAA requires the U.S. Departmentof Health and Human Services (HHS) to develop, enact andenforce regulations governing electronically managed patientinformation in the healthcare industry. As a result, a specialcommittee in HHS prepared several recommendations basedupon extensive expert witness testimony from academia, in-dustry and government, deriving the following conclusions:

The Privacy Rule requires implementing policies and pro-cedures to provides federal protections for personal healthinformation held by covered entities and gives patients anarray of rights with respect to that information.

The Security Rule specifies a series of administrative, phys-ical, and technical safeguards for covered entities to assurethe confidentiality, integrity, and availability of electronicprotected health information.

The Enforcement Rule states the actions that must betaken by HHS to ensure compliance and accountability un-der the HIPAA, including the process for reviewing com-plaints and assessing fines.

The full description of the principles can be found at theU.S. Department of HHS’s website [3]. In this paper, wefocus on the section §164 of HIPAA, which regulates thesecurity and privacy issues in the health care industry. Itcovers general provisions, security standards for the protec-tion of electronic health information, and privacy of indi-vidually identifiable health information. We are especiallyconcerned with the subsection §164.506, which covers theuse and disclosure of electronic health information in carry-ing out treatment, payment, or health care operations.

2.2 Answer Set ProgrammingASP [28, 31] is a recent form of declarative programming

that has emerged from the interaction between two lines ofresearch—nonmonotonic semantics of negation in logic pro-gramming and applications of satisfiability solvers to searchproblems. The idea of ASP is to represent the search prob-lem we are interested in as a logic program whose intendedmodels, called “stable models (a.k.a. answer sets),” corre-spond to the solutions of the problem, and then find thesemodels using an answer set solver—a system for computingstable models. Like other declarative computing paradigms,such as SAT (Satisfiability Checking) and CP (ConstraintProgramming), ASP provides a common basis for formaliz-ing and solving various problems, but is distinct from oth-ers such that it focuses on knowledge representation andreasoning: its language is an expressive nonmonotonic lan-guage based on logic programs under the stable model se-mantics [16, 17], which allows elegant representation of sev-eral aspects of knowledge such as causality, defaults, andincomplete information, and provides compact encoding ofcomplex problems that cannot be translated into SAT andCP [29]. As the mathematical foundation of answer set pro-

gramming, the stable model semantics was originated fromunderstanding the meaning of negation as failure in Prolog,which has the rules of the form

a1 ! a2, · · · , am,notam+1, · · · ,not an (1)

where all ai are atoms and not is a symbol for negationas failure, also known as default negation. Intuitively, underthe stable model semantics, rule (1) means that if you havegenerated a2, · · · , am and it is impossible to generate anyof am+1, · · · , an then you may generate a1. This explana-tion seems to contain a vicious cycle, but the semantics arecarefully defined in terms of fixpoint.

While it is known that the transitive closure (e.g., reach-ability) cannot be expressed in first-order logic, it can behandled in the stable model semantics. Given the fixed ex-tent of edge relation, the extent of reachable is the transitiveclosure of edge.

reachable(X, Y ) ! edge(X, Y )reachable(X, Y ) ! reachable(X, Z), reachable(Z, Y )

Several extensions were made over the last twenty years.The addition of cardinality constraints turns out to be usefulin knowledge representation. A cardinality constraint is ofthe form lower{l1, . . . , n}upper where l1, . . . , ln are literalsand lower and upper are numbers. A cardinality constraintis satisfied if the number of satisfied literals in l1, . . . , ln isin between lower and upper. It is also allowed to containvariables in cardinality constraints. For instance,

more than one edge(X) ! 2{edge(X, Y ) : vertex(Y )}.

means that more than one edge(X) is true if there are atleast two edges connect X with other vertices.

The language also has useful constructs, such as strongnegations, weak constraints, and preferences. What dis-tinguishes ASP from other nonmonotonic formalisms is theavailability of several e"cient implementations, answer setsolvers, such as smodels1, cmodels2, clasp3, which ledto practical nonmonotonic reasoning that can be applied toindustrial level applications.

3. COMPLIANCEANALYSIS FRAMEWORKIn this section, we present a compliance analysis frame-

work which enables to bridge the gap between healthcaresystems and HIPAA regulations, as shown in Fig. 1. Theinputs of this framework are high-level HIPAA regulationsand policies in healthcare systems. The policy translatormodule transforms both high-level HIPAA regulations andhealthcare systems’ policies into a generic policy represen-tation. The logic translator module further transforms thegeneric representations of HIPAA regulations and health-care systems’ policies into logic programs. Then, the logicalreasoning module provides compliance analysis service.

The reasons why we introduce a layer of generic policyrepresentation instead of directly transforming policies intothe logical representation in our framework are as follows:First, the generic policy representation facilitates the processof compliance analysis since both HIPAA regulations andhealthcare systems’ policies are uniformly represented by us-ing the same policy scheme; Second, the generic policy rep-resentation improves the interoperability, consistency, and1http://www.tcs.hut.fi/Software/smodels .2http://www.cs.utexas.edu/users/tag/cmodels.html .3http://potassco.sourceforge.net .

594

Figure 1: Compliance Analysis Framework

reusability of the policies from di!erent organizations andresources. Third, di!erent policy reasoning techniques canbe adopted upon our generic policy representation. Hence,the compliance analysis in our framework will not be limitedto any specific reasoning technique.

3.1 Extracting Policy PatternTo conduct compliance analysis, both HIPAA regulations

and healthcare systems’ policies should be transformed intoa generic policy representation. In order to define a uniformpolicy scheme, general policy patterns should be identified.We present an approach to achieve such a goal as shown inFig. 2. First, we identify keywords from HIPAA regulationsand healthcare systems’ policies. Then, we categorize iden-tified keywords into di!erent classes and give a label to eachclass. Regarding any new HIPAA regulation, we map eachkeyword from the regulation to a class. The composition ofdi!erent labels constructs a structured pattern. After ana-lyzing all identified policy patterns, we formulate a genericpolicy scheme to facilitate a uniform representation of bothHIPAA regulations and healthcare systems’ policies. Notethat our approach is a general approach which is able to beapplied to all HIPAA regulations as well as various health-care systems’ policies. Figure 2 demonstrates an examplefor extracting policy patterns from one section of HIPAAregulations.

Table 1 shows the keyword dictionary we extracted fromsection §164.506. It contains six classes and each class isassociated with a label and several keywords. Based onthis keywords dictionary, we analyze all rules from section§164.506. Rule examples and corresponding policy patternsare partially given as follows:

• 164.506(a) Except with respect to uses or disclosuresthat require an authorization, a covered entity may useor disclose protected health information for treatment,

Figure 2: Approach for Policy Pattern Extraction

payment, or health care operations.Extracted Pattern: <condition> <actor> <modal-ity> <action> <object> for <purpose>

• 164.506(b)(1) A covered entity may obtain consent ofthe individual to use or disclose protected health in-formation to carry out treatment, payment, or healthcare operations.Extracted Pattern: <actor> <modality> <action><object> to <action> <object> for <purpose>

• 164.506(c)(1) A covered entity may use or disclose pro-tected health information for its own treatment, pay-ment, or health care operations.Extracted Pattern: <actor> <modality> <action><object> for <purpose>

• 164.506(c)(2) A covered entity may disclose protectedhealth information for treatment activities of a healthcare provider.Extracted Pattern: <actor> <modality> <action><object> for <purpose>

3.2 Formulating Policy SpecificationTo enable compliance analysis of policies, it is essential

to put a generic and uniform policy specification in place.Our policy specification scheme is built upon the identifiedpolicy patterns based on the approach addressed earlier andshown as follows:

Definition 1. [Generic Policy Specification] A genericpolicy is represented as a 8-tuple p = <actor, modality, ac-tion, object, purpose, condition, id, e!ect>, where

• actor = < D, R, O > is a 3-tuple, where D, R and Orepresent disseminator, receiver, and owner, respec-tively;

• modality depends on the implication that a policy ex-presses. For instance, if the policy expresses the con-cept of obligation, the corresponding modality can bemust; if the policy expresses the concept of privilege,the corresponding modality can be may;

• action is a particular action defined by a policy, suchas use, disclose, share, and so on;

• object is a protected healthcare resource, such as pa-tient demographic details, medical histories, labora-tory test results, radiology images (X-rays, CTs), andso on;

• purpose is the reason for an actor to perform an actionon an object;

595

Table 1: Key Word Dictionary

Class ID Class Label Key WordsClass 1 Actor covered entity(CE), healthcare provider, individual, patientClass 2 Action use, disclose, require, obtain, carry out, permit, has, had, pertains, participateClass 3 Purpose treatment, payment, health care operations, health care fraud, abuse detection, complianceClass 4 Object phi, consentClass 5 Modality mayClass 6 Conditions except, if, when

• condition = < CD, CR, CO, CCON > is a 4-tuple, whereCD, CR, CO, and CCON indicate conditions on dissem-inator, receiver, owner and context, respectively;

• id is the citation to the portion of HIPAA regulationsto which a policy refers to; and

• e!ect " {permit, deny} is the authorization e!ect of apolicy.

3.3 Transformation ApproachIn this section, we discuss our two-step transformation ap-

proach. In the first step, we transform both HIPAA regula-tions and healthcare systems’ policies into a uniform formalrepresentation. In the second step, we transform the formalrepresentation into a logical representation. The first stepin our transformation is shown in Fig. 3. It mainly containsfour sub-procedures: Establishing Word Dictionary, NaturalLanguage Processing, Matching and Removing Disjunction.We address the details of each procedure as follows:

1. Establishing Word Dictionary. We identify key-words from the given text and categorize identifiedkeywords into di!erent classes. We then assign a labelto each class. This procedure is to utilize the extractedgeneric policy patterns.

2. Natural Language Processing. We divide eachrule in syntactically correlated parts of keywords byleveraging the capability of NLP techniques [30, 27],such as sentence detection, tokenization, pos-tagging,and chunking.

3. Matching. We identify each element of the policy.More specifically, based on the results of previous pro-cedures, we compare each correlated word with dic-tionary words and return the label if matched. Thenbased on the label, the placement of the word in thegeneric policy representation is determined.

4. Removing Disjunction. To remove disjunction fromthe rules, each rule may need to be split into severalseparate rules. Since the elements of receiver, actionand purpose in a rule may have multiple instances, wefurther split a given rule based on those instances.

The following example demonstrates how our transforma-tion approach works with HIPAA rules in a natural lan-guage:

• Input: 164.506(c)(1) A covered entity may use or dis-close protected health information for its own treat-ment, payment, or health care operations.

• Output: (<CE, CE, CE>, may, use, phi, treatment,N/A, 164.506(c)(1), allow)(<CE, CE, CE>, may, use, phi, payment, N/A,164.506(c)(1), allow)(<CE, CE, CE>, may, use, phi, healthcare operation,N/A, 164.506(c)(1), allow)(<CE, CE, CE>, may, disclose, phi, treatment, N/A,164.506(c)(1), allow)(<CE, CE, CE>, may, disclose, phi, payment, N/A,164.506(c)(1), allow)(<CE, CE, CE>, may, disclose, phi, healthcare operation,N/A, 164.506(c)(1), allow)

In this example, we can notice two actions: use and dis-close and three purposes: treatment, payment, and healthcare operations in the HIPAA rule represented in a nat-ural language. Based on the combination of actions andpurposes, we obtain six sub-rules during the transformationprocess.

The second step of our transformation approach is totransform the generic representation of policies into a logicalrepresentation for conducting policy reasoning analysis. Weadopt ASP as the underlying logic programming. This pro-cedure interprets the semantics of the generic policy spec-ification in terms of the Answer Set semantics. Based oneach element of the generic policy definition, we define fol-lowing ASP predicates: decision(ID, EFFECT) where ID isa policy id variable and EFFECT is a policy authorizationdecision variable; actor(D, R, O) where D, R and O arevariables respectively for disseminator, receiver, and owner;modality(M); action(A); object(OBJ); purpose(P) and con-dition(C). We consider decision(ID, EFFECT) as the ASPrule head and the rest predicates as the ASP rule body.Hence, an ASP representation of generic policy is expressedas follows:

• decision(ID, EFFECT) :- actor(D, R, O), modality(M),action(A), object(OBJ), purpose(P), condition(C).

The following example shows how our transformation con-verts a generic policy representation into an ASP represen-tation:

• Generic representation of a HIPAA regulation:(<CE, CE, CE>, may, use, PHI, treatment, N/A,164.506(c)(1)(1), permit)

• ASP representation: decision(164506c11, permit):- actor(ce, ce, ce), modality(may), action(use), ob-ject(phi), purpose(treatment), condition(na).

3.4 Compliance-oriented AnalysisA policy is in compliance with another policy if the same

e!ects are obtained when those policies are applied to the

596

Figure 3: Transformation Flow

same request; Otherwise, the policy is in non-compliancewith the other policy. To apply this proposition to HIPAAanalysis, we further make this intuition more precise bydefining the notion of non-compliance. With respect to thesame policy variables, if the e!ect of healthcare systems’ pol-icy is allow while the e!ect of HIPAA regulations is deny,we call this non-compliance case as less-constrained non-compliance. If the e!ect of healthcare system is deny whilethe e!ect of HIPAA regulations is allow, we call this caseas over-constrained non-compliance. Policy makers of thehealthcare systems should strengthen the control of the pol-icy if less-constrained non-compliance is detected or loosenthe control of the policy if over-constrained non-complianceis detected. The compliance definition can be also extendedto analyze the compliance relations between a policy anda policy set or between two policy sets. In practice, bothhealthcare systems’ policies and HIPAA regulations containmultiple sub-policies. If the healthcare systems’ policiesdon’t comply with HIPAA regulations, our approach canidentify the counterexamples for compliance analysis.

After the two-step transformation, we have both ASP rep-resentations of HIPAA regulations and local healthcare sys-tems’ policies. Consider the ASP representation of HIPAAregulations as privacy/security property program F and theASP representation of the local healthcare systems’ policiesas program G. Then the problem of compliance checking canbe cast into the problem of checking whether the program

G # F # H

has no answer set using ASP solver, where H is the pro-

gram expressing program G and program F has conflictingdecision results. If no answer is found, it implies that the pri-vacy/security property F is verified. Otherwise, an answerset returned by an ASP solver serves as a counterexamplethat indicates why the program G does not entail F [4].

4. CASE STUDYIn this section, we discuss a case study to demonstrate the

feasibility of our approach.

4.1 Policy TransformationIn [19], Grandison et al. studied 20 healthcare related ser-

vice providers and gave their policy locations. The one wechose from their study is OSF Healthcare which is ownedand operated by The Sisters of the Third Order of St. Fran-cis, Peoria, Illinois. The OSF Healthcare System consists ofseven hospitals and medical centers, one long-term care fa-cility, and two colleges of nursing. Federal law requires OSFHealthcare System and its related health care providers andhealth plans to maintain the privacy of individually identifi-able health information and to provide patients with noticeof their legal duties and privacy practices with respect tosuch information. Accordingly, OSF Healthcare System is-sues HIPAA Privacy Practices Notice which describes howmedical information about patients will be protected, howit may be used and disclosed, and how patients can get ac-cess to the information. Even though OSF Healthcare Sys-tem claims that the privacy notice they issue complies withHIPAA regulations, it is still necessary to conduct system-atic approach for further compliance evaluation. Due to

597

the page limitation, our discussion will not cover all poli-cies defined in the OSF Healthcare System’s privacy notice.We only select one policy as an example to demonstratehow our approach can check whether their privacy notice isin compliance with HIPAA regulations. Other policies canbe examined in the same way with our compliance analysisframework.

• Local Healthcare System Policy: OSF may shareyour information with your doctors, hospitals or otherhealth care providers to help them provide medicalcare to you.

Using our transformation approach, the above local healt-care system policy can be transformed into following threesub-rules represented in our policy specification scheme:

• (<OSF, doctor, patient>, may, share, information, treat-ment, N/A, l11, permit)

• (<OSF, hospitals , patient>, may, share, information,treatment, N/A, l12, permit)

• (<OSF, health care providers , patient>, may, share,information, treatment, N/A, l13, permit)

Furthermore, the above three sub-rules can be transformedinto corresponding ASP rules as follows:

• decision(l11, permit) :- actor(osf, doctor, patient),modality(may), action(share), object(information), pur-pose(treatment), condition(na).

• decision(l12, permit) :- actor(osf, hospitals, patient),modality(may), action(share), object(information), pur-pose(treatment), condition(na).

• decision(l13, permit) :- actor(osf, hcp, patient),modality(may), action(share), object(information), pur-pose(treatment), condition(na).

Table 2: Terminology Mapping

OSF Terminology HIPAA TerminologyOSF covered entity

doctor covered entityhospital covered entity

health care provider covered entityinformation PHI

share discloseprovide medical care to you treatment

4.2 Terminology MappingIn order to conduct compliance analysis, terminology map-

ping is an essential activity, which entails mapping the natu-ral language phrases in healthcare systems’ policies onto theterminology used in HIPAA regulations. Ideally, terminol-ogy should be mapped early during the phase system policiesbeing made, since regulation-based compliance requirementsshould be considered later on. However, for practical rea-son, we are dealing with existing healthcare systems whosepolicies have been specified. These policies may be definedbefore the regulations, or based on an older version of the

Figure 4: ASP Representation of the Case Study

regulations, or specified without consideration of the regu-lations at all. A prerequisite of the terminology mapping isto properly define two terminologies: regulation terminol-ogy and healthcare system policy terminology. In this casestudy, the regulation terminology is based on a keywords dic-tionary extracted from the section §164.506 in HIPAA, andthe local healthcare system’s policy terminology is based onthe analysis of the policy we chose in the OSF Healthcaresystem. The terminology mapping table for the case studyis shown in Table 2.

4.3 Compliance CheckingTo make this case study more concise, we choose one

HIPAA rule(§164.506(1)) to evaluate the local healthcaresystem’s policy. In practice, our approach can be applied tothe whole HIPAA regulations to construct a knowledge basefor compliance analysis. Fig. 4 shows ASP representation forour case study. After we run this program, no answer setis found, which means the local healthcare policy complieswith the HIPAA regulations. Suppose we have the followinglocal healthcare system’s policy with a policy ID of l12:

598

• decision local(l12, deny) :- actor(osf, hospitals , pa-tient), modality(may), action(share), object(information),purpose(treatment), condition(na).

The ASP solver can find out one answer set as follows:

• modality(may) action(share) action(use) object(information)object(phi) purpose(treatment) condition(na)actor(osf,hospitals,patient) actor(ce,ce,ce)decision local(l12,deny) decision hipaa(c11,permit)

The above answer set indicates a counterexample explain-ing the violation of HIPAA regulations. According to themodified version of local policy l12, the request for OSF toshare the patients’ information with hospitals for the pur-pose of treatment will be denied. However, HIPAA regula-tions will allow the request. Hence, the local policy l12 doesnot comply with HIPAA regulations.

5. IMPLEMENTATIONANDEVALUATIONWe have implemented a transformation tool using C#,

which has two major functionalities for policy transforma-tion. The first functionality is developed based on OpenNLP [2].It transforms any HIPAA regulations or healthcare systems’policies specified in natural language into the generic policyrepresentation. OpenNLP is an open source natural lan-guage processing project and hosts a variety of java-basedNLP tools. Some functions of our tool, such as sentence-detecting, tokenization, postagging, and chunking, were im-plemented based on OpenNLP’s APIs. The sentencedetectingcan detect that a punctuation character marks the end ofa sentence or not. In other words, a sentence is defined asthe longest white space trimmed character sequence betweentwo punctuation marks. The tokenization segments an inputcharacter sequence into tokens. The postagging uses a prob-ability model to predict the correct pos tag out of the tagset. The chunking divides a text in syntactically correlatedparts of words, like noun groups, verb groups. The secondfunctionality of our tool is to transform the generic policyrepresentation into ASP programs for the purpose of logic-based policy reasoning. Fig. 5(a) shows an example of howour tool transforms HIPAA regulations defined with a natu-ral language into the generic policy representation. Fig. 5(b)demonstrates how our tool transforms HIPAA regulationswith the generic policy representation into ASP programs.

As HIPAA regulations are typically complex and lengthy,the e"ciency and scalability are two critical metrics for eval-uating our transformation tool. We conducted experimentson a computer with Intel Core2 Duo CPU 3.00 GHz 3.25 GBRAM. More specifically, we measured the time consumed byeach transformation step. The rules to be transformed in ourexperiment are randomly selected from HIPAA regulationssection §164.506. Due to the limited number of rules in thatsection, rules may repeatedly appear in the transformationinput. Note that the repeated rules are still valid inputssince we focus on the time consumed by the transforma-tion process. Fig. 6 shows performance measurements onpolicy transformation and ASP transformation. It indicatesthat policy transformation (from HIPAA regulations to thegeneric policy representation) constantly consumed the timealong with the increase of HIPAA rules while ASP transfor-mation was quite stably performed. Also, we further evalu-ated the performance on each sub-task under policy trans-formation as discussed in Section 3.3: Natural Language

Figure 6: Transformation Time

Table 3: Reasoning Time

# of Policies: 10 20 30 40 50Time (sec.): 0.0128 0.0421 0.1045 0.3056 0.9171

Processing (sub 2) and Matching & Removing Disjunction(sub 3 & 4). We observed that Natural Language Process-ing consumed on average 85% of the total transformationtime. 4

Also, we measured the time consumed by ASP solver witha static number of HIPAA rules as a knowledge base to checka local healthcare system’s policies with the linear increaseof rule size from the same healthcare system mentioned inour case study. We chose 9 rules of HIPAA regulations fromthe section §164.506 as a compliance knowledge base. Thenumber of healthcare system’s policies to be checked wasincreased from 10 to 50. As shown in Table 3, our experi-ments showed that the reasoning performance was minimallya!ected by the increased number of healthcare system’s poli-cies.

6. RELATEDWORKWe discuss the related work from three aspects: formal-

ization e!orts for regulations, logics for specifying policiesand regulations and requirement analysis.

Formalization E!orts for Regulations: De Young etal. [14] proposed PrivacyLFP, which is an extension of Logicof Privacy and Utility (LPU) [7, 8]. Lam et al. [25] haveformalized §164.502, §164.506, and §164.510 of HIPAA in afragment of stratified Datalog with one alternation of nega-tion, and built a prototype tool to check the lawfulness of atransmission. May et al. [33] presented privacy APIs, whichextends the traditional matrix model of access control, andused them to formalize two versions of HIPAA §164.506.

Logics for Specifying Policies and Regulations: Hilty

4The enhancement of Natural Language Processing proce-dure remains for future work since it is beyond the scope ofthis paper.

599

(a) Generic Policy Representation Transformation (b) ASP Representation Transformation

Figure 5: Transformation Tool

et al. [22] have shown how to specify future obligationsfrom data protection policies in Distributed Temporal Logic(DTL). They used distributed event structures to model in-teractions between multiple parties involved in data accessand distribution. Basin et al.[10] used an extension of LTL,Metric First-Order Temporal Logic (MFOTL) for specify-ing security properties. Dinesh et al. [15] have developed alogic for reasoning about conditions and exceptions in pri-vacy laws.

Requirement Analysis: Researchers have investigatedmethods to analyze security requirements using aspects [36],goals [18, 35], problem frames [9], trust assumptions [20] andstructured argumentation [21]. More recent work focusedon the rigorous extraction of requirements from security-related policies and regulations [13, 26]. To support thesoftware engineering e!ort to derive security requirementsfrom regulations, Breaux et al. [12] presented a methodologyto extract access rights and obligations directly from regu-lation texts. They applied this methodology specifically toHIPAA Privacy Rule. Maxwell et al. [32] presented a pro-duction rule framework that software engineers can use tospecify compliance requirements for software. They appliedthe framework to check iTrust, an open source electronicmedical records system, for compliance with the HIPAA Se-curity Rule. This is the closet work to this paper in term ofmotivation. However, compared with our work, their workhas some limitations: first, they formalized HIPAA regu-lations based on production rule models. Thus, their for-malization is constrained by a specific logic programmingtechnique. In contrast, our formalization of HIPAA reg-ulations is based on a generic policy specification scheme,which can be then utilized by various logic-based reason-ing techniques. Second, in their work, users need to pre-pare a canonical list of compliance requirements for com-pliance analysis through selecting all related preconditionsand then querying the production rule model. The compli-ance requirements generated by less-knowledge users maybe not comprehensive enough, which can further a!ect thecredibility of compliance analysis results. However, our ap-proach can automatically transforms HIPAA regulations asa knowledge base. Third, their compliance analysis processcannot be conducted automatically. For each requirement inthe compliance requirements, they checked every existing re-quirement represented by a template to examine whether italready operationalizes the canonical requirement by replac-

ing legal text definitions with the appropriate and equivalentdefinitions used in the existing requirement specification. Inour work, we transform both HIPAA regulations and health-care systems’ policies into ASP representation as an inputfor ASP solver to carry out compliance analysis automati-cally. Finally, the lack of evaluation of their approach leavesbehind the ambiguities of their solution.

7. CONCLUSION AND FUTUREWORKIn this paper, we have presented a framework which facil-

itates compliance analysis between healthcare systems andlegal regulations, such as HIPAA regulations. We first ex-tracted policy patterns from both HIPAA regulations andhealthcare systems’ policies, along with a generic policy spec-ification scheme. Then, we discussed our transformationand compliance analysis methods to determine whether ahealthcare system is in compliance with HIPAA regulationsby leveraging logic-based reasoning techniques. Our evalua-tion clearly demonstrated the e"ciency and e!ectiveness ofour methodology.

As part of our future work, we would further investigatehow cross-referenced policies can be analyzed in our frame-work. Also, we would attempt to refine and enhance ourframework to deal with most sections of HIPAA regulations.In addition, we are planning to conduct extensive evaluationof our approach with real-life healthcare systems. Moreover,we would study a comprehensive policy enforcement archi-tecture for distributed healthcare systems in clouds, withthe consideration of HIPAA compliance.

8. REFERENCES[1] HIPAA-General Information.

http://www.cms.gov/HIPAAGenInfo/.[2] openNLP. http://incubator.apache.org/opennlp/.[3] U.S. Department of Health and Human Services.

Health Insurance Portability and Accountability Act(HIPAA). http://www.hhs.gov/ocr/privacy/.

[4] G. Ahn, H. Hu, J. Lee, and Y. Meng. Representingand reasoning about web access control policies. In2010 34th Annual IEEE Computer Software andApplications Conference, pages 137–146. IEEE, 2010.

[5] E. Allman. Complying with compliance. Queue,4(7):18–21, 2006.

600

[6] A. H. Association. Aha hospital statistics. HealthForum LLC, 2009.

[7] A. Barth, A. Datta, J. Mitchell, and H. Nissenbaum.Privacy and contextual integrity: Framework andapplications. In Security and Privacy, 2006 IEEESymposium on, pages 15–pp. IEEE Computer Society,2006.

[8] A. Barth, A. Datta, J. C. Mitchell, and sharadasundaram. Privacy and utility in business processes. InProc. of 20th IEEE Computer Security FoundationsSymposium, July 2007.

[9] L. Bashar, B. Nuseibeh, D. Ince, M. Jackson, andJ. Mo!ett. Introducing abuse frames for analysingsecurity requirements. In In Proc. of 11th IEEEInternational Requirements Engineering Conference(RE’03. Citeseer, 2003.

[10] D. Basin, F. Klaedtke, and S. Muller. Monitoringsecurity policies with metric first-order temporal logic.In Proceeding of the 15th ACM symposium on Accesscontrol models and technologies, pages 23–34. ACM,2010.

[11] E. Bertino, E. Ferrari, and A. Squicciarini. Trustnegotiations: concepts, systems, and languages.Computing in Science and Engineering, pages 27–34,2004.

[12] T. Breaux and A. Anton. Analyzing regulatory rulesfor privacy and security requirements. IEEEtransactions on software engineering, pages 5–20,2007.

[13] T. Breaux, M. Vail, and A. Anton. Towards regulatorycompliance: Extracting rights and obligations to alignrequirements with regulations. In In: Proc. of the 14thIEEE International Requirements EngineeringConference. (2006, pages 46–55. IEEE ComputerSociety, 2006.

[14] H. DeYoung, D. Garg, D. Kaynar, and A. Datta.Logical specification of the GLBA and HIPAA privacylaws. CyLab, page 72, 2010.

[15] N. Dinesh, A. Joshi, I. Lee, and O. Sokolsky.Reasoning about conditions and exceptions to laws inregulatory conformance checking. Deontic Logic inComputer Science, pages 110–124, 2008.

[16] P. Ferraris, J. Lee, and V. Lifschitz. Stable models andcircumscription. Artificial Intelligence, 2010.

[17] M. Gelfond and V. Lifschitz. The stable modelsemantics for logic programming. In Proc. of the FifthInternational Conference on Logic Programming,pages 1070–1080, 1988.

[18] P. Giorgini, F. Massacci, J. Mylopoulos, andN. Zannone. Modeling security requirements throughownership, permission and delegation. In In Proc. ofRE’05, pages 167–176. IEEE Press, 2005.

[19] T. Grandison and R. Bhatti. HIPAA Compliance andPatient Privacy Protection. Studies In HealthTechnology And Informatics, 160(Pt 2):884–888, 2010.

[20] C. Haley, R. Laney, J. Mo!ett, and B. Nuseibeh. Thee!ect of trust assumptions on the elaboration ofsecurity requirements. In Proc. of the 12thInternational Requirements Engineering Conference(RE’04). Kyoto Japan, IEEE Computer, pages102–111. Society Press, 2004.

[21] C. Haley, J. Mo!ett, R. Laney, and B. Nuseibeh.

Arguing security: Validating security requirementsusing structured argumentation. In in Proc. of theThird Symposium on Requirements Engineering forInformation Security (SREIS’05), co-located with the13th International Requirements EngineeringConference (RE’05, 2005.

[22] M. Hilty, D. Basin, and E. Pretschner. On obligations.In In: Proc. ESORICS. (2005), pages 98–117, 2005.

[23] M. Kanovich, P. Rowe, and A. Scedrov. Policycompliance in collaborative systems. In 2009 22ndIEEE Computer Security Foundations Symposium,pages 218–233. IEEE, 2009.

[24] P. Kilbridge. The cost of hipaa compliance. NewEngland Journal of Medicine, 348(15):1423–1477,2003.

[25] P. Lam, J. Mitchell, and S. Sundaram. A formalizationof HIPAA for a medical messaging system. Trust,Privacy and Security in Digital Business, pages 73–85,2009.

[26] S. Lee, R. Gandhi, D. Muthurajan, D. Yavagal, andG. Ahn. Building problem domain ontology fromsecurity requirements in regulatory documents. InProc. of the 2006 international workshop on Softwareengineering for secure systems, pages 43–50. ACM,2006.

[27] D. Lewis and K. Jones. Natural language processingfor information retrieval. Communications of theACM, 39(1):92–101, 1996.

[28] V. Lifschitz. What is answer set programming. InProc. of the AAAI Conference on ArtificialIntelligence, pages 1594–1597, 2008.

[29] V. Lifschitz and A. Razborov. Why are there so manyloop formulas? ACM Transactions on ComputationalLogic (TOCL), 7(2):261–268, 2006.

[30] C. Manning, H. Schutze, and MITCogNet.Foundations of statistical natural language processing,volume 59. MIT Press, 1999.

[31] V. W. Marek. Stable models and an alternative logicprogramming paradigm. In In The Logic ProgrammingParadigm: a 25-Year Perspective, pages 375–398.Springer-Verlag, 1999.

[32] J. Maxwell and A. Anton. The production ruleframework: developing a canonical set of softwarerequirements for compliance with law. In Proc. of the1st ACM International Health InformaticsSymposium, pages 629–636. ACM, 2010.

[33] M. May, C. Gunter, and I. Lee. Privacy apis: Accesscontrol techniques to analyze and verify legal privacypolicies. In In CSFW’06, pages 85–97. IEEE, 2006.

[34] P. Otto, A. Anton, and D. Baumer. The choicepointdilemma: How data brokers should handle the privacyof personal information. IEEE Security & Privacy,pages 15–23, 2007.

[35] A. Van Lamsweerde. Elaborating securityrequirements by construction of intentionalanti-models. 2004.

[36] D. Xu, V. Goel, and K. Nygard. An aspect-orientedapproach to security requirements analysis. InComputer Software and Applications Conference,2006. COMPSAC’06. 30th Annual International,volume 2, pages 79–82. IEEE, 2006.

601