This is the base class for a variety of individual policy types, and may be used to instantiate specific policies. These policies may exist on their own, or may be combined together in a composition of atomic policies. ISO 22600-2 specifies a Security Policy as plan or course of action adopted for providing computer security. This class is derived from ISO 22600-2 and HL7 DAM, where this concept is called Basic Policy. The FHIM calls this Atomic Policy to emphasize that they may be combined into composites.

An authentication token is a packaged collection of data used to authenticate the Initiator’s identity. [NIST SP 800-63-2]

The Organization (or other Entity) that issued or is otherwise responsible for the policy. This may be the provider organization that "owns" the patient record, or a jurisdiction that regulates how privacy is to be handled within its territory. This is the authority that grants authorization described in the privacy policy. This class is consistent with the “Security Authority” specified by the ISO/IEC 15816 standard as “The entity accountable for the administration of a security policy within a security domain”. "Entity or Organization having regulatory jurisdiction or accountability for enforcing policies pertaining to Consent Directives." - HL7 FHIR, Consent.policy.authority

Authorization Policy is a specialization of a Basic Policy and is used to describe an authorization policy that may be exchanged across domains. An instance of Authorization Policy specifies permitted actions per ISO 22600-2. A positive (or negative) Authorization Policy defines the actions (Operation Type) that a subject is permitted (or forbidden) to perform on a target. Actions encoded using the Operation Type class represents the operations defined in the interface of a target object. [HL7 DAM] This class is derived from ISO 22600-2 and HL7 DAM.

Initiator-bound Access Control Information (ACI) that can be compared with security labels of Resources. Examples of clearance are Normal, Restricted, and Very Restricted. [HL7 PASS SLS] and [HL7 HCS] (Note that there used to be a class called User Role, which has since been merged into this Clearance class. The definition of the User Role Class was: "Specifies the role of a user of a computer system. The role is typically associated with the Information Requester and specifies what capabilities are available to a specific type of computer user (i.e., in the Windows operating system, a user may have the role of Administrator which enables the capability to add new users).")

If one considers what are commonly called "clearance" and "classification" as initiator-bound ACI and target-bound ACI, respectively, under an appropriate access control policy, one obtains what is essentially a label-based scheme. [ISO 10181-3] In this case, there is a policy to bind clearance to Initiators (e.g., persons who work with blood need HIV clearance) and policy for Resources (e.g., Human Immunodeficiency Virus information is considered "sensitive" and has code "HIV"). Accordingly, Clearance Policy falls under the Initiator Based Policy class, the Clearance Policy class equates to the ISO 10181-3 label-based scheme. Initiator-bound clearance ACI can be compared with security labels of Resources. Examples of clearance ACI are Normal, Restricted, and Very Restricted. [HL7 PASS SLS]

This class (sometimes referred to as Protected Condition) is used to represent the health conditions associated with the policy. Conditions, when specified, are coded concepts expressed in a standard vocabulary (e.g., Logical Observation Identifiers Names and Codes [LOINC], Systematized Nomenclature of Medicine – Clinical Terms [SNOMED – CT]). These may include indications of "substance abuse" or "HIV-related" illnesses, etc.

Composite Policy class is the integration point between Security and Privacy perspectives. It contains a set of basic policies that work together to enforce a privacy policy, organizational standard operating procedure, or a privacy consent directive. Its basic characteristic is that it contains other policies. An instance of a Composite Policy may include several Authorization, Delegation, Refrain, or Obligation policies. A Composite Policy is specialization of the abstract Policy class and inherits all its attributes and associations. In addition to the attributes it inherits from its base class (“Policy”), this type of class contains additional associations and attributes. [HL7 DAM] This class is derived from ISO 22600-2 and HL7 DAM.

This class represents a set of privacy consent directives issued by a consenter on behalf of self or someone else. [HL7 DAM] A Consent Directive is a record of a Subject of Care’s health information privacy policy. A Consent Directive grants or withholds authorization to collect, access, use, or disclose individually identifiable health information about the client. [HL7 CDA] Note: There used to be a class called "PublishedConsent" the definition of which was: "This specialization of the ConsentDirective class is used to describe a consent directive published to a registry. If a client s consent directive is published, a URL/URI is made available for reference. The client may use this URI to allow providers access to the consent directive created by the consenter." We have moved the uri property to this class and deleted the Published Consent class.

A Role played by a Person (or occasionally, an Organization) granting certain privileges to another person or Organization. Note that this Role in turn uses an Attribution (inherited from Grantor), which captures any digital signatures as well as pointing to the individual person, practitioner, related person, or organization that is playing this role.

A limitation on an access control rule.

Contextual Policy defines control of access according to its context. Contextual Policy can modify Initiator-based Policy or Resource-based Policy. Context rules may define the entire policy in effect. Contextual information is information about or derived from the context in which an access request is made (e.g., time of attempted access, location of the accessor, route of access). Rules concerning contextual information are most often used in conjunction with other access control schemes (e.g., label-based scheme, capability scheme, ACL scheme), but they may be used alone to create a context-based access control scheme. [ISO 10181-3]

A Delegation Policy is intended to assign access rights to a specific individual or organization (a grantee). ISO 22600-2 defines delegation as "conveyance of privilege from one entity that holds such privilege, to another entity." A Delegation Policy "defines what authorizations can be delegated to whom." [HL7 DAM] This class is derived from ISO 22600-2 and HL7 DAM.

Functional roles reflect functional aspects of relationships between entities. Functional roles are bound to the realization/performance of acts, where actions might be concatenated to an activity or even to a process. [ISO 22600-2] Functional Roles can be grouped according to their authorization to access Protected Information and perform various operations on protected information. For example, a healthcare provider in Organization A is authorized to access Protected Information from Organization B (when Organization A and B have entered into a trusted relationship) if that provider is associated with the Functional Group whose permissions grant access per that Functional Role. In summary, the functional role defines the access control decision. A functional role is bound to a policy. [HL7 DAM]

A Role in which a Person, Related Person, Practitioner, or Organization has been delegated a specific right or responsibility from another entity. For example, in the case of substance abuse related information, under certain conditions the authority to grant, withhold, or withdraw consent to the disclosure of the information, is granted to the client (aka patient). In another example, a Clearinghouse may act an agent or proxy for a provider organization as an intermediary and therefore can be a grantee as well. Note that this Role in turn uses an Attribution, which captures any digital signatures as well as pointing to the individual entity that is playing this role.

A Role in which a Person, Related Person, Practitioner, or Organization is granting privileges to another entity. Note that this Role in turn uses an Attribution, which captures any digital signatures as well as pointing to the individual entity that is playing this role.

Group Policy defines a scope for related policies to which a set of constraints can apply. [ISO 22600-2] A group is a set of initiators whose members are considered equivalent when a particular access control policy is enforced. Groups allow access to particular targets by a set of initiators without the necessity of including the identity of individual initiators in a target’s ACI, and without explicitly allocating the same ACI to each initiator. The composition of a group is determined by a management action; the ability to create or modify groups must be subject to access control. Audit of access requests by the group without distinguishing the members may or may not be required. [ISO 10181-3] If one considers an initiator identity as initiator-bound ACI, and a set of (initiator identity, operation type) pairs as target-bound ACI, under an appropriate access control policy, one obtains what is essentially an access control list (ACL) scheme [ISO 10181-3]. Accordingly, the Group Policy class equates to the ISO 10181-3 ACL scheme. This class is derived from ISO 22600-2, HL7 DAM, and ISO 10181-3.

This class represents a reference to specific type of information object that may be referenced by a policy. This information specifies the types of objects that may be used in a permission (e.g., a category of laboratory orders, document types). [HL7 DAM]

A Resource (sometimes referred to as data, target, system, or information) is an entity to which access may be attempted. [ISO 10181-3] (renamed from InformationReference 11/2014 as part of high-level refactoring). Was InformationTarget for a while. Renamed to InformationResource on 4/30/17)

An Initiator is an entity (e.g., human user, computer-based entity such as a software application or process, physical device) that attempts to access other entities. [ISO 10181-3]

Two categories of security policy, rule-based and identity-based, are identified in International Telegraph and Telephone Consultative Committee (CCITT) Rec. X.800 | ISO 7498-2. [ISO 10181-3] Initiator-based access control policies are based on rules specific to an individual initiator, a group of initiators, entities acting on behalf of initiators, or originators acting in a specific role. Access control policies stated in terms of groups of initiators or in terms of initiators acting in specific roles are types of initiator-based policies. [ISO 10181-3] This class is derived from ISO 10181-3 and CCITT Rec. X.800 | ISO 7498-2.

An Obligation Policy may be used to specify additional privacy preferences specified by a Subject of Care. An Obligation Policy may be specified in addition to a Refrain Policy to fully describe a client’s access control preferences. In some cases, an Obligation Policy may be used to indicate that the receiver of an information object may not be allowed to re-disclose or persist that information object indefinitely. Per ISO 22600-2, Obligation Policy instances "are event-triggered and define actions to be performed by manager agent." [HL7 DAM] An obligation is an operation specified in a policy or policy set performed in conjunction with the enforcement of an authorization decision. [XACML] In short, obligations are actions to be performed. [ISO 22600-2] This class is derived from ISO 22600-2 and HL7 DAM.

Represents the action that a person or process may perform on an information resource. Historically, "security operations" have been thought of as being related to a single file, record, or object: Create, Read, Update, Delete, Execute, e.g., Susan may Read but not Update or Delete this file. "Privacy operations" on the other hand have been thought of more broadly, often operating on a set of related files, records or objects: Access, Disclosure, Collection, Use, e.g., Susan may Access but not Disclose Patient Doe’s medical records. This class combines the intent of both kinds of operations, and the two sets of vocabulary are merged, although one could argue that Read is the same thing as Access.

This class corresponds to a Role-Based Access Control (RBAC) permission. It specifies an information object and action/operation allowed on that object. A permission contains one operation and precisely one information reference. [HL7 DAM]

The permission catalog specifies a set of standard permissions. [HL7 DAM] The permission catalog is the subject of separate HL7 standards. This reference is intended to show it relates to the rest of the information classes required to support the use cases.

This is the abstract class from which all concrete policy classes in this policy information model are derived and instantiated. Because this class is abstract, it cannot be instantiated as a security policy for healthcare. However, it specifies the properties reused by all policies. [HL7 DAM] A policy is a “set of legal, political, organizational, functional and technical obligations for communication and cooperation.” Policy governs the behavior of a system. [ISO 22600-2] Policy encompasses jurisdictional, organizational, and Subject of Care (patient) policies. Organization and jurisdictional polices are instantiated as Basic Policy in both the security policy and privacy policy contexts. Basic Policy is discussed further later in this document. It should also be noted that privacy policy is controlled by the Subject of Care. This class is derived from ISO 22600-2 and HL7 DAM. "The references to the policies that are included in this consent scope. Policies may be organizational, but are often defined jurisdictionally, or in law." - HL7 FHIR, Consent.policy

Specifies the source of payment for the healthcare services documented by electronic health records. To meet specific privacy policy needs, it is necessary to specify if the information protected by the rule was produced through public healthcare services or other type of insurance. [HL7 DAM] Note that the HL7 DAM contains two subclasses (Private Insurance and Public Services) to illustrate the type of security/privacy policies that are inherent from the healthcare payment source. Those two subclasses are examples of many potential kinds of policies, and would be fleshed out in the terminology referenced by the policyCategory code. The FHIM therefore does not model Private Insurance and Public Services as separate classes.