View
41
Download
0
Category
Tags:
Preview:
DESCRIPTION
Purpose of Use (POU) Vocabulary Work in Progress. HL7 Security WG Presentation Kathleen Connor for Mike Davis, VA December 2011. Issues from Mike’s POU Paper. Issue - PowerPoint PPT Presentation
Citation preview
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
Recommended