Applying CoReL to an Excerpt of HIPAA:A Critical Discussion

Marwane El KharbiliUniversity of Luxembourg

Laboratory for Advanced Software SystemsLuxembourg City, Luxembourg

marwane.elkharbili@uni.lu

Abstract—CoReL is a visual business policy modelling lan-guage which was proposed in recent research by the author.In this paper, we make an initial attempt at studying themodeling support that CoReL provides to real-world regulations,in particular, the HIPAA Act.

Index Terms—HIPAA, Compliance, Business Policy, BusinessProcess Management, Alloy.

I. INTRODUCTION

A. Motivation and Rationale

CoReL[1] was designed to tackle a divide in compliancemodelling between two different domains: regulatory and log-ical/software. It is a domain-specific language for modellingbusiness policies, which are postulated as a means for fillingup this domain divide. CoReL relies on the assumption thatcompliance modelling can be reduced to modelling decision-making elements and that these can be represented as businesspolicies. The principle in CoReL models is that every policymodel is the formal representation of a single compliancerequirement as extracted from a regulatory document.CoReL is a domain-specific visual language. In this section,we introduce some of the motivations behind the particulardesign of CoReL and the intended use of it. Some of the mainconcepts in CoReL are the following: Policy, Context, Control,Violation, Recovery. These concepts allow to break downcompliance requirements into reusable elementary componentsthat are destined to be combined to build new compositecompliance requirement models.

B. Research Question

The research which produced CoReL was motivated by thefollowing problem: How to design a compliance modeling andautomated checking solution which would make the work ofregulatory compliance experts easier? For this we selectedone axis of research, rooted in the discipline of softwarelanguage engineering. We target our research at designinga compliance modeling language for these experts, firmlygrounded on the core concepts of the regulatory compliancedomain and following the model-driven engineering paradigm.

C. Approach Users

In this section we explain that the use of CoReL, althoughit is primarily intended for regulatory domain users (i.e., legalexperts such as food and drug legislators, finance lawyers, IT

security legislators, etc.), parts of the CoReL models mustbe created/managed by logicians or computer scientists withformal methods training.First, the visual nature of the language was motivated bythe fact that the intended users of a compliance requirementlanguage are so-called ’business users’, i.e., regulatory domainexperts. These users are not trained in formal methods (e.g.,ASM, ALLOY, B, Z, OCL, VDM, LOTOS, etc.) nor logic,so what they need is a paradigm that lets them model theirrequirements at a higher level of abstraction. That is whereCoReL comes in handy. The policy modeler has to worktogether with a computer scientist or a logician to select theright rule, or to rely on semantic annotations to the rule tohelp with the selection.Secondly, CoReL policies carry elements called rules, whichare formal statements expressing constraints (on elements ofthe enterprise model, but this is out of the scope of this paper).Rules can be reused across multiple policies. However, theselection of the adequate rule for use in a policy is not atrivial matter, it requires that the policy modeler (i.e., businessuser) has the best understanding of the semantics of the ruleand what it means for the enforcement of the policy. This iswhy a joint modeling here is required. The policy modelerhas to work together with a computer scientist or a logicianto select the right rule, or to rely on semantic annotations tothe rule to help with the selection.One last precision, although not of uumost relevance in thispaper, must be added in the context of using CoReL. It isa language for modeling policies on business processes. Assuch, the policy modeler, who is primarily the regulatorydomain expert, is expected to either have a strong knowledgeof the business processes and the enterprise model in orderto accurately define the policies and use the right rules or towork jointly with a business expert.

II. COREL: COMPLIANCE REPRESENTATION LANGUAGE

We give here a very concise outline: compliance require-ments, which are textual excerpts from the regulatory text,are extracted by the policy modeler. These are of variouslevels of granularity, decided upon by the policy modeler.Then, each compliance requirement is represented as a visualCoReL policy model. The formal enforcement semantics ofCoReL policy diagrams have been defined in ALLOY, a formal

978-1-4799-0950-6/13/$31.00 c© 2013 IEEE RELAW 2013, Rio de Janeiro, BrasilExtended Abstract

61

language and a bounded model checking tool which worksunder the small scope hypothesis. This concretely meansthat the CoReL policy models can be checked on businessprocesses at design-time, but also that we have a formal andimplemented simulation machine written in Alloy.CoReL is a domain-specific visual language which maps be-tween the constraint dimension and the decision dimension. Inthe constraint dimension, rules are expressed which may eitherhold or not (i.e., expressed in a formalism which evaluatesrules to either True or False), thereby giving an indication ofthe state of compliance of a process to a regulation.On the other hand, the decision dimension handles the resultsfrom the checking taking place in the constraint dimension, inorder to adapt the execution of the business process accord-ingly. For instance, uncovering a given violation may lead toenforcing some penalty before further resuming the executionof the process. Figure 1 shows the main concepts in theabstract syntax metamodel of the CoReL language and theirrelationships. For lack of space, we cannot illustrate all theseconcepts with example, hence we will focus in the followinglines on the most relevant.

The core modeling concept in CoReL is that of a Policy.A CoReL model always represents (i.e., defines) one policy.A Policy applies to something we call ASE. ASE stands forthe triple Action, Subject, Entity. In this triple, Subject andEntity represent objects of any given system which the policygoverns. A slight difference however is that a Subject can beany system object with the capability of executing Actions onother system objects. Symmetrically, an Entity is any systemobject on which an Action can be undertaken. If we take abusiness process as a system, then the actions would be theprocess tasks, and the Subjects the pools or lanes, or any otherrole with executing power. Finally, the Entities would be anyresource such as a document or a data object. In BPMN (thestandard business process modeling notation by the OMG1) forexample, so called Artifacts may be used to model Entities.ASEs were also proposed in previous research in [2].A policy is made out of a Context, a Control and a Violationparts. A Context describes the conditions under which a policymay be evaluated. The Control describes the constraints thatshould hold when a policy is evaluated. A Violation(s) de-scribes the different kinds of situations which are ’acceptable’but not ideal, i.e., when the Control does not hold. This waywe can describe deviations from ideal behavior. A violation ismapped to a compensation or a handling. A Compensation isa corrective action executed outside of the business process inorder to compensate for the violation occurrence. A Handlingis an action executed in order to account for the violationoccurrence, it can be either a reward or a penalty. An exampleis the delivery of free lunch vouchers to students who used avery limited amount of paper for printing.Also, a policy can have a deontic modality, which modifies theway its evaluation and enforcement is conducted. We definethese semantics formally using state machines. We imple-

1www.bpmn.org

mented these semantics using the Alloy formal language[3].Alloy is a declarative formalism, rooted in relational algebraand equivalent to first order logic extended with transitiveclosure in terms of expressiveness. Alloy is also a boundedmodel checker that works under the small scope hypothesis.This hypothesis states that most errors in code or systems arefound using small examples. We use the Alloy formalizationto conduct analysis of processes modeled in Alloy and conductcompliance checks.CoReL policy models are used for static and dynamic policycompliance checking in business processes. We do this bydefining the semantics on interpretation of a policy usingAlloy. For space reasons, we will not introduce the formalsemantics in this paper. Rather, we evaluate the modelingexpressiveness against an excerpt from a legal text.

III. MODELING ARTICLE 164.512(F) OF HIPAA

The HIPAA (US health Insurance Portability and Account-ability Privacy Rule) is a regulation that governs protectedhealth information in the united states. The modelled regula-tion paragraph (164.512) is a small excerpt from a regulationfrom the healthcare domain on privacy rules2. This regulationdeals with what information on individuals covered entities(health insurance entities) might be disclosed an under whichconditions. The difference between this regulation and theusual examples we use to illustrate CoReL modeling, is thatit is more abstract and does not refer to any concrete processsteps or known enterprise model elements, in particular norbusiness process specification accompanies the regulation.In this section, we shortly evaluate the degree to which themodeling constructs of CoReL allow to cover elements of areal-life regulation. For this, we will not include predicatesin the modeling, and content ourselves with informal textualmodeling to lead the discussion. The obtained CoReL policydiagram is shown in Figure 2.When attempting to model such a regulation one may betempted to start looking at each of the nested statements andtry to represented the using logic or our formal model. UsingCoReL we know we must start by looking at what kinds ofASEs are concerned by each statement. Then we can look athow statements in the regulation applying to this ASE may begrouped in a way that makes sense. We need to do this eventhough we have no business process to check compliance offor the moment. This is one of the advantages of using ASEs.If we start with the CR 164.512, we understand that the contextof the regulation are all covered entities in the united states.Moreover, we deal with several ASEs here. The first ASE isthe covered entity disclosing information about the individualto a third part: (Disclose, Covered Entity, Information aboutthe Individual). The second ASE is the notification of theindividual of this disclosure: (Notify of Disclosure, CoveredEntity, Individual). The third ASE is whether or not theindividual agrees or objects to this disclosure: (Agree/Object,Individual, Disclosure). We may add these two ASEs to the

2http://gaius.isri.cmu.edu/relaw/2013/conv-challenges-excerpt.pdf

62

Fig. 1: The Abstract Syntax metamodel of CoReL

list: (DiscloseOrally, Covered Entity, Individual Information)and (AgreeOrally/ObjectOrally, individual, Disclosure).

When attempting to collect and organize the elements ofthe regulatory text that might help us formally model thecompliance requirements included in the regulation, we en-counter many problems. First, we notice that some metadataabout the Action is needed, particularly about the Target ofthe Action, and its Purpose. Also, more information about theexecution environment in which information about individualsis requested and disclosed is required. For instance, questionshave to be answered such as :

● What types of wounds and physical injuries are meant?● How to judge if the information is relevant to law

enforcement?● What types of information is there and how is it orga-

nized?

Moreover, the regulation refers to exceptions to the rules(CoReL controls) which are specified in separate articlesof the law. CoReL does not support exceptions to a rule.Such an exception must be processed by a knowledgeablelegal expert by hand. Additionally, several elements of theregulation must be interpreted and concretized for a particularexecution environment (e.g., a company, a hospital, a dentistoffice, a health insurer, etc.). All of these make formalizing theregulation at this level of abstraction for the sake of automatedchecking a hard task. Last, most of the useful features inCoReL cannot be applied easily to this regulation beforefurther refinement and concretization. The multiple violationmanagement feature of Alloy is also apparently not useful formodeling the regulatory text. In summary, these challengingaspects are some of the research topics that need to be studiesin future work on CoReL.

IV. REFLECTIONS ON THIS CASE

A. Undemonstrated Benefits of CoReL

CoReL is a language for modeling automated compliancedecision-making, critical for business process management.In this example however, we were not able to show how tomake use of the conceptual separation between contexts andcontrols, and both elements were too abstract to be representedby logical predicates. Another factor is that the used HIPAAexcerpt has not been concretized or a specific organization andconcrete business processes, therefore making showcasing theautomated compliance checking impossible. We propose tofurther this research by using a prototypical case study of ahypothetical enterprise.Also, one of the main features of CoReL is integratingviolation management into the decision-making. In this excerptof HIPAA, we were not able to find information about such anelement of compliance decision-making. We would thereforelike to continue this research by combining modeling theHIPAA excerpt used with a fitting excerpt from another parof the regulation dealing with violation enforcement in [4].

B. Limitations

Conducted validation is limited to the feasibility of thelanguage design and usage for compliance checking, com-pleted with a validation of the expressiveness of the language.We designed case studies which we use to showcase thecapabilities offered by CoReL, which are inspired from realcases but are no real cases from practice. Therefore, one mayrightly object that the our case studies are biased. Also, anotherlimitation is the lack of validation for the claim of enhancedusability for business users. Although we based our work onthe hypothesis that a focused domain-specific language, whose

63

Fig. 2: Informal Proposal to Model Article 164.512(f) of HIPAA

concepts are ontological concepts belonging to the domain ofcompliance decision-making, and which is visual, will increaseusability compared to classical rule or logic languages, we didnot conduct any empirical validation of this.

C. Tool Support

CoReL’s modeling language is accessible through severaldiagrams. the research team implemented several editors whileothers are being implemented. The implemented editors allowcreating: regulation diagrams (structure of a regulation incompliance requirements, and link to policy implementation),policy diagrams (specification of the decision-making embod-ied by a policy), violation diagrams (encompass the violationdecision attached to a policy). We are implementing editorsfor the following diagrams: policy flow diagrams (workflowsof several policies, useful for complex decision-making), com-plex policy diagrams (algebraic policy operators).The tool suite is called MARCO (for MAnaging RegulatoryCOmpliance) after a project of the University of Luxembourg3.The tool suite is build on top of Eclipse EMF/GMF technol-ogy4, a de facto standard for MDE tool development. Thetool suite uses model-to-text model transformations to generate

3Funded by the luxembourgish Fond National de la Recherche (FNR) www.fnr.lu

4www.eclipse.org/modeling/emf and www.eclipse.org/modeling/gmp

Alloy models from the CoReL diagrams, which are used forconducting the compliance checking.

V. CONCLUSION

The main challenge addressed by CoReL is how to makemodeling and automatically verifying regulations accessible to’business users’. We also applied our findings to a case studyfor access control and another one for financial documentprocessing. CoReL takes a new approach towards solvingregulatory compliance management, by tackling the problemfrom the perspective of the real end-users of a solution tothis problem. Its main features are visual domain specificmodeling, coupled with usage of reusable modeling compo-nents as a strategy to deal with the complexity of representingcompliance requirements.

REFERENCES

[1] M. E. Kharbili, Q. Ma, P. Kelsen, and E. Pulvermueller, “CoReL: Policy-based and model-driven regulatory compliance management,” in EDOCProceedings, 2011, pp. 247–256.

[2] T. D. Breaux, “Semantic parameterization: A process for modelingdomain descriptions,” in ACM Transactions on Software EngineeringMethodology (ACM TOSEM), vol. 5, no. 18, November 2008.

[3] D. Jackson, Software Abstractions: Logic, Language, and Analysis. Re-vised Edition. The MIT Press, 2012.

[4] A. M. Association, “http://www.ama-assn.org/ama/pub/physician-resources/solutions-managing-your-practice/coding-billing-insurance/hipaahealth-insurance-portability-accountability-act/hipaa-violations-enforcement.page?”

64