Purpose of Use (POU) Vocabulary Work in Progress

1. Purpose of Use (POU) VocabularyWork in Progress HL7 Security WG Presentation Kathleen Connor for Mike Davis, VA December 2011

2. Issues from Mike’s POU Paper Issue • Mechanisms must be available to ensure that access to protected information objects is only granted to properly authorized users under a specific and unambiguous security policy • To enforce security policies, the PDP must determine that: • A user has rights to the information objects • The context in which these rights are asserted is the correct one • For example, the security policy may require that clinical users access data within a clinical context where clinical application security policies apply, rather than under an administrative role which may not have these constraints (allowing enforcement of separation of duties) • In general, this problem is referred to as "Purpose of Use" • Purpose of use defines the policy set to be used in situations where multiple (potentially conflicting) contextually sensitive policies exist for identical users and identical information objects Background • As a topic, purpose of use has recently reemerged (e.g., in S&I Data Segmentation Initiative) • Originally, purpose of use was envisioned as a means of partitioning healthcare policy for the purpose of general rulemaking • Recently the topic has come up again, as a means of partitioning security policy needed for data sharing between organizations within business partner or Data Use and Reciprocal Support (DURSA) agreements • Healthcare oriented Standards Development Organizations have begun the process of codifying purpose of use as a standard

3. Problem with POU Code Systems Current POU Code Systems are not comprehensive, or consistent • HL7 Vocabulary ActHealthInformationPrivacyReason Codes • Contains most of the other concepts and fair definitions • HL7 DAM POU • Contains same concepts as XSPA and many from ISO, but not well defined • XSPA SAML and XACML Profile POU • No definitions • ISO 14265 • POU codes were not developed for purpose of categorizing security policies • NHIN Authorization • NHIN Authorization Framework Specification v 2.0 POU codes are very granular and some are about policy not POU • As a result, these POU codes are not interoperable • Yet POU is a critical concept in many privacy and security standards

4. Difference in POU Concept Codes • POU code systems typically describe the activity that is the rationale from the perspective of users rather than the rationale for executing an operation on information • ISO: POU code system provides “a framework for classifying the various specific purposes that can be defined and used by individual policy domains” • ASTM-1986-98 (2005) POU establishes the context and conditions of data use at a specific point in time, and within a specific setting • POU is the rationale for executing operation on sensitive information

5. POU Harmonization Approach • Map all POU Code Systems • Determine criteria for selection • Determine Gaps • Create consistent definition template

6. POU Harmonization ProposalTreatment / Payment

7. Healthcare Business Operations

8. Marketing, Public Health, Research, Patient Request

9. Override

10. POU Code Systems

11. Current Enumerations of POU Codes – Not Defined, Comprehensive, or Consistent DAM POU XSPA SAML Profile POU XSPA XACML Profile POU TREATMENT, PAYMENT, OPERATIONS, EMERGENCY, MARKETING, RESEARCH, REQUEST, PUBLICHEALTH

12. HL7 POU Code System

13. ISO/TS 14265 Purpose for POU • ISO/TS 14265:2011 Health Informatics - Classification of purposes for processing personal health information defines a set of high-level categories of purposes for which personal health information can be processed • This is in order to provide a framework for classifying the various specific purposes that can be defined and used by individual policy domains (e.g. healthcare organizations, regional health authorities, jurisdictions, countries) as an aid to the consistent management of information in the delivery of health care services and for the communication of electronic health records across organizational and jurisdictional boundaries • The scope of application of ISO/TS 14265:2011 is limited to Personal Health Information as defined in ISO 27799, information about an identifiable person that relates to the physical or mental health of the individual, or to provision of health services to the individual

14. ISO/TS 14265 POU

15. NHIN Authorization Framework Specification v 2.0 3.3.2.6 Purpose of Use Attribute This <Attribute> element shall have the Name attribute set to “urn:oasis:names:tc:xspa:1.0:subject:purposeofuse”7. The value of the <AttributeValue> element is a child element, “PurposeOfUse”, in the namespace “urn:hl7-org:v3”, whose content is defined by the “CE” (coded element) data type from the HL7 version 3 specification. The PurposeOfUse element shall contain the coded representation of the Purpose for Use that is in effect for the request. An example of the syntax of this element is as follows: <saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse"> <saml:AttributeValue> <PurposeForUse xmlns="urn:hl7-org:v3" xsi:type="CE" code="OPERATIONS" codeSystem="2.16.840.1.113883.3.18.7.1" codeSystemName="nhin-purpose" displayName="Healthcare Operations"/> </saml:AttributeValue> </saml:Attribute> Codes are assigned as below. The codeSystem is defined to be “2.16.840.1.113883.3.18.7.1”. The codeSystemName is defined to be “nhin-purpose”. The value of the Purpose of Use attribute shall be a urn:hl7-org:v3:CE element, specifying the coded value representing the user's purpose in issuing the request, choosing from the value set listed in this specification. The codeSystem attribute of this element must be present, and must specify the OID of the "Purpose of Use" code system created by the NHIN Cooperative, 2.16.840.1.113883.3.18.7.1 .

17. POU Code System MAP

18. Gaps to HL7 POU Code System

19. Possible POU Concept Domain Definition KC: POU Definition • Reason for performing one or more operations on information permitted by source system’s security policy, which may be in accordance with one or more privacy policies and consent directives. • POU is the rationale for executing operation on sensitive information Mike’s POU Definition • The policy set to be used in situations where multiple (potentially conflicting) contextually sensitive policies exist for identical users and identical information objects. • Definition: Reason for perform one or more operations on information, which may be permitted by source system’s security policy in accordance with one or more privacy policies and consent directives. • Description: The rationale or purpose for an act relating to the management of personal health information, such as collecting personal health information for research or public health purposes. • Usage Note: The policy set to be used in situations where multiple (potentially conflicting) contextually sensitive policies exist for identical users and identical information objects.

20. POU in the DAM

21. DAM Security and Privacy Rule Class POU Attributes DAM has two views of POU: • Attribute 'BasicPolicy.purposeOfUse' of type ' PurposeCode' with cardinality of [0..1] • This attribute is used to specify the purpose to permit a specific type of action/operation according to the policy • The vocabulary analysis section provides additional illustrative values for the concept embodied by this attribute • Attribute 'PrivacyRule.purposeOfUse' of type ' PurposeCode' with cardinality of [0..1] • This attribute is used to specify the purpose to permit a specific type of action/operation according to the policy • Some examples include: Treatment, Payment, Public Health, Research

22. Basic Policy POU Attribute

23. DAM Basic Policy POU Attribute • This is the base class for a variety of policy types. It extends the abstract Policy class and • provides additional attributes • This class may be used to instantiate specific policies. ISO-22600-2 specifies a Security Policy as 'plan or course of action adopted for providing computer security' • BasicPolicy is a specialization of the abstract Policy class and inherits all its attributes. It also defines • additional attributes and associations: • Association 'BasicPolicy.informationReference' of type ' InformationReference' with cardinality of [*] • This association references the attributes of the information referenced in the policy. • Association 'BasicPolicy.operationType' of type ' OperationType' with cardinality of [*] • This association refers to the operation associated with the policy. • Attribute 'BasicPolicy.purposeOfUse' of type ' PurposeCode' with cardinality of [0..1] • This attribute is used to specify the purpose to permit a specific type of action/operation • according to the policy • The vocabulary analysis section provides additional illustrative values for the concept embodied by this attribute

24. DAM Privacy Rule POU Attribute

25. Class: PrivacyRule For a specific POU • A PrivacyRule specifies the permission allowed to a user type by the consenter for a specific type of information • The person consenting may be either the subject of the record (the client) or the client's designated Substitute Decision Maker • One or more PrivacyRule instances comprise a privacy Consent Directive or PrivacyPolicy • A PrivacyRule is equivalent to a BasicPolicy • A specific individual’s privacy consent directive consists of several rules that map to BasicPolicy instances • A PrivacyRule, from the Privacy viewpoint perspective, is equivalent to a BasicPolicy from a Security viewpoint perspective. • BasicPolicy instances comprise a CompositePolicy and PrivacyRule instances are grouped together to form a ConsentDirective.

26. DAM «subsystem»InformationProvider • This conceptual system represents any system that responds to requests for information from other systems and provides only that information allowed to be disclosed according to access control polices. • Information Provider: operations • requestInformation • (objectType : <Enumeration> ObjectCode [In] • purposeOfUse: <Enumeration> PurposeCode [In] • structuralRole: <Enumeration> StructuralRoleCode [In] • functionalRole : <Enumeration> FunctionalRoleCode[In] • requestedInfo: [Return] ) • This operation is invoked by when a user requests information from the system that stores/manages PI • Operation Parameters Details: • purposeOfUse : <Enumeration> PurposeCode ( In parameter) • This parameter specifies the purpose of use asserted by the information requester.

27. Class: RefrainPolicy • DAM: A refrain policy is used to indicate that a specific action is prohibited based on specific access control attributes (e.g., purpose of use, information type, user role, etc.) • It is a specialization of the “BasicPolicy” class • It does not have any additional attributes but implies different behavior. ISO 22600-2 species that a RefrainPolicy 'defines actions the subjects must refrain from performing‘ • PMAC does not mention POU in definition of Refrain Policy

28. PMAC Policy Model – Where is POU? Unlike DAM – no POU attribute on Basic Policy & no attribute on Refrain. Event code on Obligation w/o explanation other than workflow oriented.

29. Background

30. IHE ITI Access Control White • Purpose of use: constraints derived from the intended use of a certain healthcare system that mediates (or even initiates) access to a protected resource • A patient privacy consent should always be based on the purpose of use of such a system. • The purpose of use can be translated into a resource behavior policy. This policy defines how certain subjects might act on certain objects that are managed by the healthcare system. Depending on the purpose of use and its implications, the patient might even influence the permissions expressed by this policy (configuration). For instance, the patient restricts the types of data that might be processed by the healthcare system.

31. IHE IT Infrastructure Technical Framework White Paper – Access Control • Another major part of patient privacy consent is the authorization of certain individuals, organizations, and/or rules to use the healthcare system with respect to the agreed purpose of use. • Translated into a policy, this part of the consent may be characterized as the resource access policy. • This policy controls who is able to access a protected resource through the entry point (point of service application) of a healthcare system. • The notion of an entry point is especially important, if there are multiple of them (e. g. one entry point for medical staff and one for system administrators) that are safeguarded by different policies that define different expectations on the objectives and behavior of the respective user groups.

32. IHE 4.1.1 Compliance: Resource Security • The policy concerns of an enterprise’s IT compliance is quite similar to the concerns of the purpose of use since it clearly is a source for roles, tasks, and authorizations derived from restrictions on role-task assignments: • The medical business activities of the enterprise are defined by tasks and scenarios, which in turn determine the purposes of use for medical data processing activities • The enterprise defines roles – assigned to tasks - that reflect the enterprise’s organization of labor • Compliance ensures that the assignment of roles to tasks and the assignment of people to roles are fully aligned to the legal framing and the rules of governance of the enterprise • Behavior policies for resource protection can directly be derived from the organization of labor: • Everybody, who is allowed to perform a certain task, must also be allowed to perform all data processing that is required for performing this task

33. IHE “Need to Know” and POU • Need-to-know principle is a collection of roles and assigned permissions through a role-engineering process • Healthcare organizations, such as HL7 and VA, propose a scenario-based approach • In this approach typical procedures are excerpts of medical actors that are illustrated and described in a narrative • Each step in a scenario incorporates the operations that are executed onto the medical or administrative objects. In order to successfully perform those operations, the required permissions are combined into catalogues and assigned to profiles • Inversely, scenarios are combined to tasks on a higher, conceptual level. • The outcome is a structured catalogue that illustrates what permissions (operations on resources) are needed in order to fulfill the particular scenarios. In a second step, the identified actors are integrated, creating a matrix manifesting the roles and their required permissions.

34. HL7 RBAC Catalog • HL7 specified a detailed permission catalog for healthcare environments using role based access control • Core RBAC elements (users, roles, objects, operations, and permissions) are transferred into operation and object definitions that can be adopted • To each subject of a healthcare enterprise several (one or many) roles may be assigned, depending on the current work context and the daily schedule. In order to follow the design principle of least privilege, the ACS must ensure that each person’s current

35. IHE 4.1.2 Purpose of Use and Policies • The purpose of use determines the answer to questions such as: • What tasks can be performed using the underlying software application/systems? • What are the scenarios where these tasks are performed? • Which tasks are performed by the same groups of users? How can these groups be characterized? • What data is processed by the software application/system? What operations are defined on this data? • In the previous section the need-to-know principle was introduced as a n:m relationship between a subject (e.g., a physician) and a protected resource • As any access to protected resources is mediated through software applications/systems, this single “logical” relationship is split into two “physical” relationships: • A “need-to-use” relationship • “mediates access” relationship (Figure 9). The current roles are determined by calculating the intersection of the user's theoretically assignable roles (all roles administrated for him in the subject domain) and the roles required to act in the current context. The activation (identification) of the current context is usually an implicit side effect caused by actions such as switching software applications and dialogs. Such an action might be when an administrative person of a hospital opens the “admission” software application or when he selects the “admission” dialog in the hospital information system. Then the current context is “patient admission” which might lead to an activation of this person’s “admission personnel” role.

36. IHE Access Control Whitepaper 4.1.1 Compliance: Resource Security • The policy concerns of an enterprise’s IT compliance is quite similar to the concerns of the purpose of use since it clearly is a source for roles, tasks, and authorizations derived from restrictions on role-task assignments: • The medical business activities of the enterprise are defined by tasks and scenarios, which in 765 turn determine the purposes of use for medical data processing activities • The enterprise defines roles – assigned to tasks - that reflect the enterprise’s organization of labor

37. IHE Access Control Whitepaper • Compliance ensures that the assignment of roles to tasks and the assignment of people to roles are fully aligned to the legal framing and the rules of governance of the enterprise. Behavior policies for resource protection can directly be derived from the organization of labor: • Everybody, who is allowed to perform a certain task, must also be allowed to perform all data processing that is required for performing this task. E.g., everybody who is allowed to do a surgery must be granted permissions to read relevant examination reports and to write a surgery report. • Baseline for resource security that follows this need-to-know principle is a collection of roles and assigned permissions through a role-engineering process. Healthcare organizations, such as HL7 and VA, propose a scenario-based approach. In this approach typical procedures are excerpts of medical actors that are illustrated and described in a narrative. Each step in a scenario incorporates the operations that are executed onto the medical or administrative objects. In order to successfully perform those operations, the required permissions are combined into catalogues and assigned to profiles. Inversely, scenarios are combined to tasks on a higher, conceptual level.

38. IHE Access Control Whitepaper • The outcome is a structured catalogue that illustrates what permissions (operations on resources) are needed in order to fulfill the particular scenarios. In a second step, the identified actors are integrated, creating a matrix manifesting the roles and their required permissions.5 • To each subject of a healthcare enterprise several (one or many) roles may be assigned, depending on the current work context and the daily schedule. • In order to follow the design principle of least privilege, the ACS must ensure that each person’s current roles are only those roles that correspond to this person’s current (medical) activities.

39. IHE Access Control Whitepaper

40. IHE Access Control Whitepaper 4.1.2 Purpose of Use and Policies • The purpose of use determines the answer to questions such as: • What tasks can be performed using the underlying software application/systems? What are the scenarios where these tasks are performed? • Which tasks are performed by the same groups of users? How can these groups be characterized? • What data is processed by the software application/system? What operations are defined on this data? • In the previous section the need-to-know principle was introduced as a n:m relationship between a subject (e.g., a physician) and a protected resource.

41. IHE Access Control Whitepaper • As any access to protected resources is mediated through software applications/systems, this single “logical” relationship is split into two “physical” relationships: A “need-to-use” relationship and a “mediates access” relationship (Figure 9). • A proper software application/system design has to ensure that the set of all valid sequences of a “need-to-use” and “mediates access” relationship is semantically identical with all valid “need-to-know” relationships that reflect the purpose of use.

42. IHE POU and Policy Figure 9: “Need-to-use” and Mediation of Access A proper software application/system design has to ensure that the set of all valid sequences of a “need-to-use” and “mediates access” relationship is semantically

43. IHE – POU Scenario • Patient consents to a list of individuals who might access his medical data (protected resource) for a certain purpose of use by means of a software application/system (e.g., an EHR or a medication record) • Software application/system handles all requests of authorized subjects further to the resource managing systems • Forwarded requests are intercepted (by a PEP) and their legitimacy is decided with respect to a compliance-driven resource behavior policy

44. Figure 8: Role Activation • The current roles are determined by calculating the intersection of the user's theoretically assignable roles (all roles administrated for him in the subject domain) and the roles required to act in the current context. The activation (identification) of the current context is usually an implicit side effect caused by actions such as switching software applications and dialogs. Such an action might be when an administrative person of a hospital opens the “admission” software application or when he selects the “admission” dialog in the hospital information system. Then the current context is “patient admission” which might lead to an activation of this person’s “admission personnel” role.

45. IHE – Complex POU Scenario • Complex scenario: Patient grants access to organizations • Compliance-driven resource behavior policy controls what individual/role is allowed to instantiate the organization’s permission (e.g., is an oncologist at hospital A, allowed to open a cardiologic EHR for which the patient has declared hospital A as an authorized user)

47. Discussed at Dec. 13 Security WG Call • Verify whether ISO/TS 14265 suffices as a POU terminology • If so, reference in the DAM and recommend that the XSPA profiles do so as well • If not • Ask XSPA Committee to create a standard vocabulary with definitions and OID • Collaborate with XSPA to create an HL7 POU code system

48. Next Security WG Call – Possible Next Steps • Map all POU code systems • Add all enumerations to DAM model in EA for consideration • Determine criteria for inclusion in HL7 POU concept domain, code system, and value set • E.g., if a code does not meet the definition of POU and should be conveyed differently, remove • Harmonize codes and definitions • Develop HL7 POU Harmonization Proposal for March