Purpose of Use (POU) VocabularyWork in Progress

HL7 Security WG PresentationKathleen Connor for Mike Davis, VA

December 2011

Issues from Mike’s POU PaperIssue• 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 objectsBackground • 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

Problem with POU Code SystemsCurrent 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

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

POU Harmonization Approach

• Map all POU Code Systems• Determine criteria for selection• Determine Gaps• Create consistent definition template

POU Harmonization ProposalTreatment / Payment

Parent Children DefinitionHead Code: Purpose of Use

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.

Treatment To perform one or more operations on information for provision of health care. Care Management

TreatmentTo perform one or more operations on information for provision of health care coordination.

Clinical Trial Treatment To perform one or more operations on information for provision of health care within a clinical trial.

Emergency Treatment To perform one or more operations on information for provision of immediately needed health care for an emergent condition.

Population Health Treatment

To perform one or more operations on information for provision of health care to a population of living subjects.

Payment To perform one or more operations on information for conducting financial, or contractual activities related to payment for provision of health care.

Eligibility Determination

To perform one or more operations on information used for conducting eligibility determination for coverage in a program or policy.

Claims Attachment To perform one or more operations on information for provision of additional clinical evidence in support of a request for coverage or payment for health services.

Coverage Authorization To perform one or more operations on information for conducting prior authorization or predetermination of coverage for services.

Remittance Advice To perform one or more operations on information about the amount remitted for a health care claim.

Parent Children DefinitionHealthcare Business Operations

To perform one or more operations on information used for conducting administrative and contractual activities related to the provision of health care

Accreditation To perform one or more operations on information for conducting activities related to meeting accreditation criteria.

Compliance To perform one or more operations on information used for conducting activities required to meet a mandate.

Deceased To perform one or more operations on information used for handling deceased patient matters.

Directory To perform one or more operation operations on information used for facility patient directories.

Donation To perform one or more operations on information used for cadaveric organ, eye or tissue donation

Fraud To perform one or more operations on information used for fraud detection and prevention processes.

Government To perform one or more operations on information used within government processes.

Member Administration To perform one or more operations on information to administer health care coverage to an enrollee under a policy or program.

Legal To perform one or more operations on information for conducting activities required by legal proceeding.

Outcome Measure To perform one or more operations on information used for assessing results and comparative effectiveness achieved by health care practices and interventions.

Patient Administration To perform one or more operations on information used for operational activities conducted to administer the delivery of health care to a patient.

Performance Measure To perform one or more operations on information used for monitoring performance of recommended health care practices and interventions.

Program Reporting To performance or more operations on information used for conducting activities to meet program accounting requirements.

Quality Improvement To perform one or more operations on information used for conducting administrative activities to improve health care quality.

Records Management To perform one or more operations on information used within the health records management process.

System Administrator To perform one or more operations on information to administer the electronic systems used for the delivery of health care

Training To perform one or more operations on information used in training and education.

Healthcare Business Operations

Parent Children DefinitionMarketing

To perform one or more operations on information for marketing services and products related to health care.

Public Health

To perform one or more operations on information for conducting population health activities, such as the reporting of notifiable conditions.

Disaster To perform one or more operations on information used for provision of immediately needed health care to a population of living subjects located in a disaster zone.

Patient Safety To perform one or more operations on information in processes related to ensuring the safety of health care.

Threat To perform one or more operations on information used to prevent injury or disease to living subjects who may be the target of violence.

Research To perform one or more operations on information for conducting scientific investigations to obtain health care knowledge.

Clinical Trial Research To perform one or more operations on information for conducting scientific investigations in accordance with clinical trial protocols to obtain health care knowledge.

Patient Request

To perform one or more operations on information in response to a patient's request.

Family To perform one or more operations on information in response to a request by a family member authorized by the patient.

Power of Attorney To perform one or more operations on information in response to a request by a person appointed as the patient's legal representative.

Support network To perform one or more operations on information in response to a request by a person authorized by the patient.

Marketing, Public Health, Research, Patient Request

Parent Children Definition

Override To perform one or more operations on information to which the patient has not consented as deemed necessary by authorized entities for providing care in the best interest of the patient; providing immediately needed health care for an emergent condition; or for protecting public or third party safety.

Emergency Treatment Override

To perform one or more operations on information to which the patient has not consented by authorized entities for treating a condition which poses an immediate threat to the patient's health and which requires immediate medical intervention.

Professional Judgment Override

To perform one or more operations on information for providing health care to which the patient has not consented. Discussion: The patient, while able to give consent, has not. However the provider believes it is in the patient's interest to access the record without patient consent. Example: Psychiatric patient.

Public Safety Override To perform one or more operations on information for providing health care to which the patient has not consented. Discussion: The patient, while able to give consent, has not. However, the provider believes that access to masked patient information is justified because of concerns related to public safety.

Third Party Safety Override

To perform one or more operations on information for providing health care to which the patient has not consented. Discussion: The patient, while able to give consent, has not. However, the provider believes that access to masked patient information is justified because of concerns related to the health and safety of one or more third parties.

Override

POU CODE SYSTEMS

Current Enumerations of POU Codes – Not Defined, Comprehensive, or Consistent

DAM POU XSPA SAML Profile POU

TREATMENT, PAYMENT, OPERATIONS, EMERGENCY, MARKETING, RESEARCH, REQUEST, PUBLICHEALTH

XSPA XACML Profile POU

HL7 POU Code SystemActHealthInformationPrivacyReason Note - Needs a

Value SetThe 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.

Treatment – Specializable Concept TREAT Provision of healthcare to a subject of care

Emergency Treatment ETREAT Provision of emergency healthcare

Population Health POPHLTH Provision of healthcare for populationsCare Management CAREMGT Coordination of care provision typically overseen by a healthcare payer

Clinical Trial CLINTRL Healthcare provided or withheld in the course of conducting research

Healthcare Payment– Specializable Concept

HPAYMT Administrative, financial, and contractual processes related to payment for the provision of healthcare

Healthcare Operations– Specializable Concept

HOPERAT Administrative and contractual processes required to support the provision of healthcare

Quality Improvement

HQUALIMP Operational activities conducted for the purposes of improving healthcare quality

Outcome Measure

HOUTCOMS Operational activities conducted for the purposes of assessing the results of healthcare

Compliance HCOMPL Operational activities required to meet a mandate

Legal HLEGAL Operational activities required by legal proceedings

Program Reporting

HPRGRP Operational activities conducted to meet program accounting requirements

Accreditation HACCRED Operational activities conducted for the purposes of meeting of criteria defined by an accrediting entity

Patient Administration

PATADMIN Operational activities conducted to administer the delivery of healthcare to a patient

Member Administration

MEMADMIN Operational activities conducted to administer healthcare coverage to an enrollee under a policy or program

System Administration

HSYSADMIN Operational activities conducted to administer the electronic systems used for the delivery of healthcare

Patient Safety PATSFTY Operational activities conducted for the purposes of increasing the safety of healthcare

PopulationHealth - Specializable Concept POPHLTH Activities conducted for the purposes of population health, such as the reporting of notifiable conditions

Healthcare Research– Specializable Concept

HRESCH Activities conducted for the purposes of obtaining healthcare knowledge

Healthcare Marketing– Specializable Concept

HMARKT Activities conducted for the purposes of marketing services and products that are typically related to healthcare

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

Code Classification Term Description (Informative)

1Clinical care provision to an individual subject of care

To inform persons or processes responsible for providing health care services to the subject of care

2Emergency care provision to an individual subject of care

To inform persons needing to provide health care services to the subject of care urgently, possibly requiring consent and over-ride policies distinct from those pertaining to Purpose 1 above

3Support of care activities within the provider organisation for an individual subject of care

To inform persons or processes enabling others to provide health care services to the subject of care, by coordinating activities and/or facilities

4Enabling the payment of care provision to an individual subject of care

To inform persons or processes responsible for enabling the availability of funds and/or permissions from a paying party for providing health care services to the subject of care

5Health service management and quality assurance

To inform persons or processes responsible for determining the availability, quality, safety, equity and cost-effectiveness of health care services

6 Education To support the learning and professional development of health care professionals

7Public Health Surveillance, Disease Control

To inform persons or processes with responsibility to monitor populations or sub-populations for significant health events and then intervene to provide health care or preventive care services to relevant individuals

8 Public safety emergencyTo inform persons with responsibility for the protection of the public in a situation in which there is considered to be a significant risk to members of the public., possibly requiring consent and over-ride policies distinct from those pertaining to Purpose 7 above.

9 Population health managementTo inform persons or processes with responsibility to monitor populations or sub-populations for health events, trends or outcomes in order to inform relevant strategy and policy

10 Research To support the discovery of generalisable knowledge

11 Market Studies To support the discovery of product or organization specific knowledge

12 Legal ProcedureTo inform persons or processes responsible for enforcing legislation, or undertaking legally authorized criminal, civil or regulatory investigation

13 Subject of Care UsesTo inform the subject of care or his or her legally authorized agent in support of the subject of care’s own interests or in the case of the deceased to support the care of a family member.

14 UnspecifiedDisclosure on the basis of authorizations not requiring a purpose to be declared or purposes for which the other categories in this clause do not apply

ISO/TS 14265 POU

NHIN Authorization Framework Specification v 2.03.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 .

HL7 ActReason Code System XSPA DAM NHIN ISO 14625ActHealthInformationPrivacyReason Note -

Needs a Value Set

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.

Treatment – Specializable Concept TREAT Provision of healthcare to a subject of care TREATMENT TREATMENT TREATMENT Clinical care provision to an individual subject of care

Emergency Treatment ETREAT Provision of emergency healthcare EMERGENCY EMERGENCY EMERGENCY Emergency care provision to an individual subject of care

Population Health POPHLTH Provision of healthcare for populations Population health managementCare Management CAREMGT Coordination of care provision typically overseen by a

healthcare payer Support of care activities within the provider organisation for an individual subject of care

Clinical Trial CLINTRL Healthcare provided or withheld in the course of conducting research

RESEARCH RESEARCH RESEARCH

Healthcare Payment– Specializable Concept

HPAYMT Administrative, financial, and contractual processes related to payment for the provision of healthcare

PAYMENT PAYMENT PAYMENT Enabling the payment of care provision to an individual subject of care

Healthcare Operations– Specializable Concept

HOPERAT Administrative and contractual processes required to support the provision of healthcare

OPERATIONSOPERATIONS OPERATIONS

Quality Improvement

HQUALIMP Operational activities conducted for the purposes of improving healthcare quality

QualitySystem Health service management and quality assurance

Outcome Measure

HOUTCOMS

Operational activities conducted for the purposes of assessing the results of healthcare

Compliance HCOMPL Operational activities required to meet a mandate RegulatoryCompliance LAWLegal Procedure

Legal HLEGAL Operational activities required by legal proceedings JUDICIAL / LEGALLegal Procedure

Program Reporting

HPRGRP Operational activities conducted to meet program accounting requirements

OVERSIGHT

Accreditation HACCRED Operational activities conducted for the purposes of meeting of criteria defined by an accrediting entity

Patient Administration

PATADMIN Operational activities conducted to administer the delivery of healthcare to a patient

Member Administration

MEMADMIN

Operational activities conducted to administer healthcare coverage to an enrollee under a policy or program

System Administration

HSYSADMIN

Operational activities conducted to administer the electronic systems used for the delivery of healthcare

SYSADMIN SYSADMIN SYSADMIN

Patient Safety PATSFTY Operational activities conducted for the purposes of increasing the safety of healthcare

THREAT Public safety emergency

PopulationHealth - Specializable Concept

POPHLTH Activities conducted for the purposes of population health, such as the reporting of notifiable conditions

PUBLICHEALTH

PUBLICHEALTH PUBLICHEALTH Public Health Surveillance, Disease Control

Healthcare Research– Specializable Concept

HRESCH Activities conducted for the purposes of obtaining healthcare knowledge

RESEARCH RESEARCH RESEARCH Research

Healthcare Marketing– Specializable Concept

HMARKT Activities conducted for the purposes of marketing services and products that are typically related to healthcare

MARKETING MARKETING MARKETINGMarket Studies

REQUEST RequestOfIndividual REQUESTSubject of Care Uses

POU Code System MAP

Gaps to HL7 POU Code SystemDAM NHIN ISO 14625 Comments

Records Management

Should be included in Security POU under Healthcare Operations

Unspecified No need for this- POU is not a required attributeABUSE Privacy POU - information sensitivity policyCOVERAGE Privacy POU related to Payment: authorized disclosure type - for purpose of a policy/contract

DECEASED Privacy POU - information sensitivity policyDIRECTORY Privacy POU - information sensitivity policyDISASTER Should be included as Security POU under Population Health- need examples to differentiate

from Threat

DONATION Privacy POU - information sensitivity policyFAMILY Subject of Care

UsesPrivacy POU - information sensitivity policy

FRAUD Should be included in Security POU under Healthcare OperationsGOVERNMENT Should be included in Security POU under Healthcare OperationsPRESENT Privacy POU - information sensitivity policyPSYCHOTHERAPY Privacy POU - information sensitivity policy

TRAINING Education Should be included in Security POU under Healthcare OperationsTHREAT Should be included as Security POU under Population Health- need examples to differentiate

from patient safety, population health, emergency treatment and Disaster - e.g., terrorism or pandemic

WORKERSCOMP Privacy POU related to Payment: authorized disclosure type - for purpose of a policy/contract

Possible POU Concept Domain DefinitionKC: 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.

POU IN THE DAM

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

Basic Policy POU Attribute

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

DAM Privacy Rule POU Attribute

Class: PrivacyRule

• 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.

For a specific

POU

DAM «subsystem»Information Provider• 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.

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

Refrain policies define actions the subjects must refrain from performing

subject (except in roles), action

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.

BACKGROUND

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.

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.

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

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.

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

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.

IHE Access Control Whitepaper4.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

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.

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.

IHE Access Control Whitepaper

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.

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.

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

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

• 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.

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)

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

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