Access Control for HL7 and the Health Care industry

Joffry Ferrater   ·   Tuesday, March 8th, 2016

Discover how a typical HL7 access control policy can be created using the Abbreviated Language for Authorization (ALFA) and what that would mean for your development team.

What is HL7?

Founded in 1987, Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services – the vision for HL7 is to create a world in which everyone can securely access and use the right health data when and where they need it. See HL7.org for more info.

HL7 Standards

HL7 has published a set of standards that define how clinical data should be transferred between healthcare applications and vendors. As the name implies, the standard focuses on the application layer (7th layer) in the OSI model.

The standards define a set of guidelines outlining how data should be formatted in a consistent manner to simplify data sharing between clinical applications.

An HL7 use case example

The Security and Privacy Ontology Use Cases are amongst the more interesting HL7 use cases to look at from an Access Control perspective. They focus on access control of an EHR system at Shady Grove Hospital. From a high level perspective the uses cases are:

1. Access Control Based on Category of Action

2. Access Control Based on Category of Object

3. Access Control Based on Category of Structural Role

4. Access Control Based on Category of Functional Role

5. Access Control Based on Multiple Role Values

6. Enable Design of Access Control System

7. Facilitate an Automated Decision Function

8. More details on these can be found here:

http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology

As an example, let’s analyze the 2nd use case in more detail: Access Control Based on Category of Object. The title of the use case suggests that it is going to be centered on the object itself. The object here is the same as a resource, and in this specific case an assessment. We can read in the Analysis of the uses case that “Shady Grove Hospital’s security policy grants the primary physician access to create a patient’s assessment. The initial assessment is categorized by the system as an assessment thus granting the primary physician the privilege to create an initial assessment on the patient.”

If we rephrase this statement to an access policy it would look something like this.

A primary physician is allowed to create a patient’s assessment.

From this statement, it is easy to pick out the attributes that can be used in an Attribute Based Access Control (ABAC) modeled authorization policy. Physician is a role attribute, and the fact that the physician is a primary physician is a care relationship that notes that there is a relationship between a specific physician and a patient. This is an important building block as it is very easy to model in ABAC but essentially impossible to model in a Role Based Access Control (RBAC) system. Create is the action attribute and patient’s assessment is the resource that the action is performed on.

If defined in Abbreviated Language for Authorization (ALFA) code, the policy implementation would look something like this.

policyset assessment{
   target clause objectType=="assessment"
   apply first Applicable 
 
   policy physician{
   target clause user.role=="physician"
   apply firstApplicable 
 
   rule create{
      target clause action=="create"
      condition patient.primaryPhysician==user.requestorId
      permit
    }
    }
}

Note, how simple the implementation of the condition is. It defines that the requesting user (a physician) is in fact the patient’s primary physician. It is implemented by comparing the values of two attributes where one value could come from the authorization request sent to the authorization service policy decision point (PDP), and the other resolved by the authorization services at runtime.

Conclusion

Many of the stated HL7 use cases and examples are very closely aligned with how we typically model policies in an ABAC world. We have looked at one example above and the others are very similar, but with slight variations. Leveraging ABAC to implement these policies works well as policies can be made action-, resource-, or subject-centric.

Note: ALFA was used in this blog post to exemplify the policy implementation – if you’d like to get your version of ALFA, please visit us here. This could, however, just as easily be modeled using the graphical Policy Editor within Axiomatics Services Manager.

The Axiomatics Customer Relations team has modeled many more HL7 uses cases and has sample policies available. Please reach out to us if these are of interest, webinfo@axiomatics.com.

Read more about access control for the Health Care industry.