Personnel Management

This model contains some 'placeholder' classes, derived from the Domain Analysis Model and having only minimal attributes at present; these are noted as placeholders below. The PM Committee has derived RMIM's for the Provider and Organization Topics from this DMIM and is currently working on models for the Human Resource and Regulatory Topics. This DMIM also supports all CMETs derived from this domain.

The committee developed this DMIM using several sources of information and input:

• Requirements drawn from v2.5, Chapter 15. Detailed segment mappings were completed between the v2.5 fields and v3.0 attributes in the DMIM. Mappings appear on the DMIM Diagram as attribute notations in parenthesis. For example: Employee.id (STF.2). Mapping details are published on the committee's website.
• The DMIM incorporates the two CMETs E_Organization[Universal] and R_AssignedEntity [Universal] CMETs that were developed prior to this DMIM.
• Requirements drawn from The Netherlands Organization Registry project
• Requirements drawn from the Canadian Provider Registry projects.

This walkthrough of the Personnel Management DMIM begins with a high-level overview of some of the principal features of the model. Following that are descriptions of entry points and interactions that are supported by the model. The overview concludes with an alphabetical listing of class objects in the DMIM and details of their use.

DMIM Overview

The scope of the Personnel Management Committee's domain includes the management of information regarding People, Organizations, Animals and Devices. The "Principal Choice" choice box at the bottom center of the diagram models these entities and the information directly related to them such as demographics, affiliations and language.

Of equal interest to the Committee is management of information regarding the various roles that may be played by these entities and lifecycle changes of the roles themselves.

A central feature of the DMIM is a discrete collection of Roles that are of particular interest in the PM domain and may (with some restrictions) be played by persons, organizations, animals or devices. These roles are present in the choice box entitled "Role Choice", which is also the primary entry point for RMIMs derived from this domain model.

Roles are relationships involving two parties: a player and a scoper. As already noted the player of these 'focal' roles may be different kinds of entities. Conversely, each of these roles is scoped solely by an Organization Entity, which appears just above the RoleChoice box in the diagram.

Lifecycle processes for Roles are described via the classes and associations in the upper left quadrant. The Role Activation act is used to communicate state changes (add/update/terminate) applied to the (subject) roles. Authorship of the activation acts is by the Organization entity that scopes a subject Role. For activations, the Organization is acting in its capacity as a Commissioning Party. The Commissioning Party may also i) furnish administrative 'proofs' (e.g. licenses) as primary performer of CredentialSupply events and ii) grant privileges. Commissioning party tasks may be delegated to an IssuingAgent.

The top right quadrant of the diagram models the acts associated with verifying roles in all their particulars. The collected classes in this portion of the model are still primarily placeholders for future work. The (minimal) structure in the current model shows that Verification can be the task of an independent verification agent (e.g. a Credential Verification Organization) that utilizes data from the actual role scoper or else various trusted sources as informants.

In the upper portion of the model is the Vetting class, another placeholder class that anticipates requirements for many types of observations that precede creation/activation of a role by a regulatory body (aka a Commissioning Party).

Service Delivery Location and service delivery related contact information is modeled in the bottom left corner of the diagram. This portion of the model is especially relevant to an entity playing either a HealthCareProvider or AssignedEntity role and arises from requirements to support Registry operations.

In the lower right quadrant, and linked to the RoleChoice box, are various acts for regulatory and reference information that are commonly tracked for entities playing Employee, HealthCareProvider and AssignedEntity roles. Again, these mainly arise from requirements for Registry operations.

And finally, in the upper middle portion of the diagram is a ControlActEvent with associated participations and observations. This structure is part of a complex protocol for communicating audit information and is designed primarily to support registry operations.

Entry Points and Interactions

R_Assigned Entity CMET (COCT_RM090000)

Entry point to the model is through the R_AssignedEntity role and links to the classes to support the complete description of an Assigned person, organization or device as used by the R_AssignedEntity CMET and its derivations. The committee retrofitted this CMET into the DMIM with minimum changes; however in some cases it was not possible to support the identical CMET structures as it conflicted with current tooling and methodologies. It is the committee's intention to submit change requests for this CMET in a later ballot.

E_Organization CMET (COCT_RM150000)

Entry point to the model is through the Organization Entity class and links to the classes to support the complete description of an organization as used by the E_Organization CMET. The model supports the description of Organizational hierarchies ('partof' and 'contains' roles) and contact information for a person acting as a liaison for the organization. The committee retrofitted this CMET into the DMIM with minimum changes; however in some cases it was not possible to support the identical CMET structures as it conflicted with current tooling and methodologies. It is the committee's intention to submit change requests for this CMET in a later ballot.

Human Resource (Staffing &Assignment) Interactions

Entry point to the model is through the RoleChoice box. The RMIMs for staffing and assignment messages constrain the entry point to one of two focal classes, either AssignedEntity or Employee. The playing Entity for either role supports different kinds of demographic information depending upon whether the subject is a person, organization or animal.

The focal role is scoped by an Organization entity that in turn plays the role of a Commissioning Party responsible for creation and promulgation of the particular focal Role (e.g. an organization that defines a functional role to which a person is assigned). A standard set of scoper demographics are supported; with the exception of scoper for the Citizen role and for Member role, which have unique requirements.

Interactions for managing personnel records, and for some types of registry operations, often encompass a broad spectrum of information about a person. A playing entity may have a multitude of concurrent roles, in addition to the focal one of Employee and/or AssignedEntity. These concurrent roles are 'bound together' via a RoleLink class (relatedTo) that can be seen on the model on the far right of the RoleChoice box. When serialized for a message the model permits multiple walks from the focal role to other related roles for the same playing entity as: an AssignedEntity (functional role in an organization), QualifiedEntity (education & training), HealthCareProvider (licensed practitioner), OtherLicencedEntity (licensed roles other than Provider), Employee (HR classification for payroll / remuneration purposes), Citizen or Member (of a resource group).

An example: an employed physician may hold multiple qualifications (QualifiedEntity roles), some relating to his licensed role of HealthCareProvider and some to his Employee or AssignedEntity roles. The rolelink supports differential association of these roles by binding together those that are dependent.

The current model supports only a limited set of attributes for the aforementioned Roles, their scoping entities, and the subject player. However, the list of supported attributes is increasing with each ballot cycle, as more use cases are incorporated into the domain model. Details about all of the classes can be found in the alphabetical listing at the end of this section. However, two attributes worth particular mention are present on almost all the focal roles: Role.statuscode, for communicating state changes, and Role.CertificateText to support the exchange of human readable certificates (e.g., an image of a License) or fully encoded (machine processable) certificates. (A computable form of certification data is supported elsewhere in the model, in the Vetting act).

Verification Interactions

Although still in development this model is intended to support interactions for ordering and resulting of credential verification activities. Roles represent a credentialed relationship between the scoper and player and the intent of these interactions is to ascertain the veracity of (usually) the player's claim to the competency embodied in that role.

Entry point to the model is through the VerificationRequest and thereafter to the multiple Verification acts by which the request is fulfilled. A verification request is placed in Order mood, and responded to in Promise and Event (fulfillment) moods.

Three participations are supported for the Verification events: the Subject of the activity, identified as one of the focal Roles within the role choice box; the PrimaryPerformer that carries out the verification activity, acting as an agent of a credential verification organization; and one or more Informants that substantiate the asserted competency. Informants are TrustedSource agents of either the organization that scopes the subject role or of a separate agency (e.g., a Practitioner Data Bank) that supplies evidentiary data.

The model also supports the description of Documentation (the Document act) pertinent to the individual Verification acts.

Regulatory (Role Activation) Interactions

Although still in development this model is intended to support interactions between regulatory agencies that scope roles (define and manage them) and organizations that are consumers of such information. Entry point to the model is through a focal role (in the RoleChoice box) with a walk through the subject participation to the RoleActivation control act. The latter communicates pertinent details about the regulatory activities, including state transitions of roles. Two participations are supported: the subject role, as already noted, and the author (CommissioningParty).

The author participation supports detailed information about the scoping organization in its role as the creator/manager of the Role. In both the DMIM and DAM this role is known as that of CommissioningParty.

The RoleActivation trigger event is linked to (is the outcome of) observations that precede the activation of a role. This is the Vetting act, which in this model is a 'collector' of observations: it supports communications about a person's/organization's capabilities, competencies, capacities and etc. Details are encapsulated in the .value attribute of the Act. Vetting activities may include acquiring information from external regulatory bodies. For example, the CommissioningParty is a State Licensing Board which has had the education qualifications of an applicant verified before issuing a license (a role activation) to practice as a HealthCare Provider.) To support the description of these inputs the Vetting act has a 'pertains' relationship to the Verification act and its associated classes.

Regulatory agencies are also sources of credentials and a CredentialSupplyEvent act is included in the model to communicate the issuing of certificates. This Act captures the details of the issuance of a physical or virtual token that attests to Activation of a Role. For example, a diploma (or copy thereof) attesting to the completion of university studies may be issued to a qualified recipient any number of times as requested. This Act is distinct from the original Vetting act or Role Activation.

Provider Registry Interactions

Entry point to the model is through the HealthCareProvider role, which is the focal class for interactions related to Provider Registry messages. Registry interactions use many portions of the model described in the earlier sections. Readers should refer to the class descriptions below as well the RMIMs in the Provider Topic.

Organization Registry Interactions

Entry point to the model is through the AssignedEntityRole role, which is the focal class for interactions related to Organization Registry messages. The player of this role is restricted to a PrincipalOrganization, but otherwise uses many of the same model components as the Provider Registry messages. Readers should refer to the class descriptions below as well the RMIMs in the Organization Topic.

Responsibilities & Privileges

The committee has started work on describing privileges (See Privilege and PrivilegeCategorization class descriptions) and will expand the model in future releases. Structures to support the description and verification of Responsibilities are planned fora future version of the DMIM.

Classes from the DMIM are listed alphabetically within each type (Act, Entity, Role and Other - including Role Link). Associative classes (Participation, Act Relationship) are described in the context of their source and/or target and not listed separately.

Attribute comments have been included with each class description where the committee wished to supply additional clarification and/or usage notes on how the object was being employed in the domain model. The reader should interpret these comments as addenda to the RIM definition.

Roles:

• Affiliate: Player of the Affiliate role has a business/professional relationship with scoper. Player and scoper may be persons or organization. The Affiliate relationship does not imply membership in a group, nor does it exist for resource scheduling purposes. The basis of an affiliate relationship may be a de facto agreement or simply incidental involvement of the two parties. Use case: two persons who are professional/business associates in their other roles as Healthcare providers.

  Attributes:
  • code: coded concepts from AffilateRoleType domain.
  • effectiveTime: The period in which the relationship is in effect. May be future dated.
• AlsoKnownAs: This role is indicative of an Entity (usually a person) that is known by multiple, unresolved demographics. Use case: a registry that records an individual known to several employers by different names, DOB etc.

  Usage: playing and scoping entities must have same classcode, but need not have identical attributes or values.

• Assigned Entity: This role describes an entity's functional role in an organization and is indicative of the kinds of work performed. Not to be confused with 'Employee' role. Though often played concurrently by the same individual these roles are not synonymous.

  An AssignedEntity can have a designated backup that is itself an AssignedEntity role. This is communicated via the recursive rolelink association.

  An AssignedEntity role is typically identified as a component of an organization hierarchy (i.e., it appears on an Org Chart) where it is associated with some larger administrative unit. This hierarchical relationship is described via a RoleLink from AssignedEntity to OrganizationPartOf.

  Attributes:
  • code: There is currently no a code system defined for the AssignedRoleType domain.
  • addr: May be a 'positional' (role-based) address, thus irrespective of the individual playing the role.
  • telecom: May be a 'positional' number, for example, the telephone number of a department manager.
• Birth Place: This role indicates a person's location of birth. It is only applicable to a Person Entity in this model. Note that Citizenship should be modeled through the Citizen Role and not derived from Birth Place. This class is optional; however, the address attribute is mandatory if the birth place is included in a message.

• Citizen: This role describes the citizenship of a Person. The model supports multiple citizenships as business cases for this requirement have been presented to the committee.

  Attributes:
  • certificateText: The CertificateText attribute may be used to communicate a proof of citizenship document such as a passport or citizenship card.
• Commissioning Party: This role is responsible for authoring role activations, granting privileges and supplying credentials.

  Direct Authority Role Link: The Commissioning Party role is always played by an organization (for the focal roles supported in this DMIM); however, this link to the Issuing Agent Role indicates a delegated authority to a specific person, organization or device.

• Contact Party: This role and associated Person Entity describe an administrative contact for an organization.

• Employee: This role describes the formal employment relationship from a "Human Resource" perspective and is the focal role for Human Resource messages.

  Attributes:
  • addr: Contact information (Address, Telecom etc) is related to the employment in general and not specific to any assigned roles that are part of the employment contract.
  • telecom: Contact information (Address, Telecom etc) is related to the employment in general and not specific to any assigned roles that are part of the employment contract.

• Healthcare Provider: An entity role specific to Healthcare providers such as a Physician, Nurse or other type of caregivers. This role class is the focal role for most Provider Registry messaging. The PROV roleclass is a specialization of LIC (Licensed), which is also present on the model. Rather than having a single, specializable object in the model the committee has chosen to expose both role classes in order to better delineate any differences in usage. The model contains a textual constraint on the use of Licensed so that it is not specialized to PROV; instead, implementers are expected to use the PROV object already present in the message hmds.

  Attributes:
  • code: Values for HealthCareProviderRoleType are derived from externally defined taxonomies of Provider types.
  • certificateText: The CertificateText attribute may be used to communicate a certificate (such as a license) that is proof of the existence of this role

• Issuing Agent: The Issuing Agent Role, linked to the Commissioning Party organization is a delegated authority responsible for authoring role activations, granting privileges and supplying credentials.

  Attributes:
  • certificateText: attribute may be used to communicate a certificate (such as an issuing license) that is proof of the authority of this role.
• Licensed Entity: This role describes any licensed role apart from "Healthcare Provider" which is present separately on the model. (see description for HealthCareProvider). PM committee interprets 'licensed' to mean a role whose scoper has some regulatory authority over it. Thus 'licensed' is not limited to roles which carry only legal license (a license in law). Examples of licensed entities include ambulance drivers, security guards and radiology technicians.
• Member: This role describes membership in a Resource Group such as a union, professional organization or social organization.

• Military Person: This role is a specialization of the Employee class. Proposals are pending for vocabulary specializations appropriate to military ranks and positions. Note that the committee has chosen to expose both role classes (EMP and MIL) on the model in order to better delineate any differences in usage.

  Attributes:
  • statusCode: used to designate if the role in the military is active or inactive.
  • jobCode: used to designate the military grade
  • occupationCode: used to designate the occupation using the AOC, AFSC, MOS or AQD coding systems.
• Organization Contains: This role is used to describe an organizational hierarchy and is a mirror of the OrganizationPartOf role. Either or both can be used, depending upon local requirements.
• Organization Part Of: This role is used to describe an organizational hierarchy and is a mirror of the OrganizationContains role. Either or both can be used, depending upon local requirements.

• Qualified Entity: This role describes specific qualifications that may be held by an Entity (Person, Animal or Device) as a result of training or experience, but having no legal force. Example: a medical degree or diploma.

  The current model does not include role attributes such as name, addr and telecom. No known use cases in this domain where this role is 'contactable' - as, for example, is the case with AssignedEntity or Employee roles.
• Role Other: This role is a component of the R_AssignedEntity CMET and was included in the DMIM because it already existed in the E_Organization CMET. It is present in the CMET to support cases in which a scoper issues multiple identifiers for a person, organization or device. These additional identifiers are not synonymous with the primary roles defined in the CMET - AssignedEntity and LicensedEntity - but may be required for record identification.

• Service Delivery Location: The actual work location use by an entity in the role of Assigned Entity when the work location differs from the location information tracked in the Assigned Entity role or when more detail regarding the location is required.

  Attributes:
  • effectiveTime: Time period when the SDLC is in operation.
• Territorial Authority: The DMIM contains a jurisdiction model to describe geopolitical units relevant to a focal role like that of citizen or HealthCareProvider. The domain model asserts that jurisdiction is descended: from role scoper to role player. It is a Territory-of-Authority role scoping the organization that, in its turn, scopes the role of interest. Identification of the actual geopolitical region is done via the playing entity, Jurisdiction. The model supports nested descriptions (e.g. a state territory within a country) through use of the PART rolelink, with separate playing entities (jurisdictions) for each role.
• Trusted Source: An agent role for an entity that supplies information in support of role verification activities.
• Verification Agent: This role is the person who carries out the role verification on behalf of a credential verification organization (CVO).

Acts

• Control Act Event: This act and associated roles and observation classes are PM adaptations of a new methodology for Accountability History that slated for incorporation into Release 2 of the V3 standard.. They are used in conjunction with a proposed new attribute, ControlActReferenceId, that is (will be) a component of the HXIT datatype extension. See Modeling and Methodology paper on "HL7 UpdateMode and Accountability History" for details. When the HXIT extension is enabled for a class or attribute a string value can be entered (in a message instance) for both the ControlActReferenceId and ControlActEvent.id, thereby creating a binding between the two. Audit data relevant to the class or attribute with the HXIT extension can then be carried in the associated AssignedEntity2 and Observation classes that can be seen on the DMIM. Note that the HXIT extension is NOT visible on the graphical model, but can be enabled by a committee for incorporation into a message schema.

  Attributes:
  • id: Identifies the data object(s) being reported upon. Note that the ControlActReferenceId that is reported in this field may have multiple occurrences in the DMIM (to support systems whose internal object model isn't RIM-based)
• Credential Supply Event: (Issuance of a Physical Token) If necessary, a Supply Act may be generated to document the issuance of a physical or virtual 'replica' of a particular credential.

  Primary Performer Participation: The commissioning party organization that is responsible for actually supplying the credential.

  Direct Target Participation: This is the role and associated entity for which the credential token applies.

• Disciplinary Action: The recording of a disciplinary action with respect to a subject Entity by a regulatory or authoritative body with supervisory capacity over that entity.

  Subject Participation: This is the role and associated entity that is the subject of some type of disciplinary action.

  Attributes:
  • id: Identifier of the Disciplinary Action
  • text: Free form text description of the event. Explicit typing of the kind of disciplinary action (via .code attribute) not currently supported.
  • effectiveTime: Start/end dates of the disciplinary action. The period when it is in effect.
  • availabilityTime: period in which information about the Disciplinary event is available for use. May be future dated. An end date in availability time indicates an archive date.
  • confidentialityCode: Indicates via Confidentiality domain codes the extent to which information about the disciplinary action can be divulged.
• Inform Definition: This Act, which is in Definition mood, indicates whether or not information about the participant role is to be communicated. For example, the participation target is the subject of a confidentiality request to support or suppress the distribution of role-related information.

  Subject Participation: this is the role and associated entity that is the subject of the Inform act.

  Attributes:
  • negationInd: When set to 'True' indicates that information about the subject of the participation is not to be divulged. Note: the participation is optional and thus, in the absence of an explicit requirement to assert that the information can be made available, can simply be omitted in lieu of setting negationInd = "False".
  • effectiveTime: time period for which the restriction is in effect.
• InformProvision: an Act describing the provision of corroborating information for a (role) Verification. The model does not include any descriptive attributes for this act, apart from identifying the performer.

• Inform Request: A Contactable Entity (role) is the subject of a request to receive information (i.e., is the intended recipient of said information) of the type identified by this act. A separate Inform Request is required for each instance. For example, the recipient is to receive x-rays.

  Attributes:
  • code: Describes the type of information. In theory could be almost anything, hence defaults to ActCode domain. In practice, this would typically be constrained e.g. to DocumentType.
• Note: This act supports the communication of note text attached to a particular role and the associated entity. This class is used to communicate any free text information attached to the role that is not described elsewhere in the model. Notes are an implementation specific business requirement, the only stipulation being that the content is intended for display or print and must be of type String.

  Subject Participation: this is the role and associated entity that is the subject of the note.

  Attributes:
  • id: Unique identifier for the note
  • text: free text
  • effectiveTime: period in which the note is in effect

• Observation Event: A component of the Audit History methodology. See ControlActEvent. Contains observed audit data in code/value pairs. One observation instance per audit attribute.

  Attributes:
  • code: audit attribute type e.g., database dates, Registry Account Holder ID.
  • value: value for the coded attribute, constrained from ANY datatype as appropriate e.g. IVL_TS for Dbdates.
• Privilege Categorization: Privilege categorization is a generic structure for providing additional information about the associated (subject) Privilege. This is an observation act that is typed via observation.code (i.e., categories are identified by leaf level concepts in the ActPrivilegeCategorization domain) and paired with an observation.value.

  Example: a privilege to issue prescriptions may have a "Stipulation" (a kind of privilege categorization, carried in .code attribute) of "narcotics excluded" (in .value attribute).

  Example: the subject privilege has a Condition upon it, that it requires a Board Approval.

  Attributes:
  • code: identification of the kind of condition or limitation, via the PrivilegeCategorization domain.
  • value: value for the category typed in code. Codified observations required, hence restricted to CD datatype.

• Privilege: An Entity may be conferred certain Privileges that are defined against the performing Role (one of several possible focal roles in the model). Privileges, in the RIM model, are Acts in permission (PERM) or permission request (PERMQ) mood. Since any ACT could, at least in theory, be the subject of a Privilege, the Privilege clone has the simple classcode of "Act" and specification of the particular kind of Act spans the ActCode domain.

  Name will be changed to Granting when GRNT type code is added to RIM.

  Responsible For Participation: This is the role and associated entity that enjoys the privilege being communicated.

  Participant Participation: This is the commissioning party organization that granted the privilege.

  Attributes:
  • NegationInd: This Boolean attribute is used to indicate a negative privilege or restriction i.e., when set to True.
  • text: free text description
  • id: Identifier
  • code: identification of the kind of privilege, via ActCode domain values.
  • effectiveTime: time period in which the privilege is in effect. May be future date.
  • confidentialityCode: Indicates via Confidentiality domain codes the extent to which information about the privilege can be divulged.
• Role Activation: This control act describes the establishing of a relationship (a Role) between a subject and author as well as life cycle changes (creation, activation, termination . . .) of that Role. In the Domain Analysis Model (DAM) this is the Relationship established between the Responsible Party and the Commissioning Party.

  Subject Participation: This is the subject of the Activation act. The role-of-interest selected from the RoleChoice group (e.g. Healthcare Provider) - the DAM equivalent of Responsible Party.

  Author Participation: This is the organization that created (scoped) the role in its capacity as a Commissioning Party. The Author organization is responsible for the information in the role activation.

  Attributes:
  • reasonCode: This is the coded reason why the role activation is occurring.
  • text: a textual description of the role activation.
• Verification Request: The act of requesting that a Verification Act be performed. This describes the verification processing at a global level, as a request or promise. This is the entry point for any Verification related messaging. Attributes:
  • reasonCode: Describes the purpose of the verification - for example to validate privileges.

• Verification: (of a Credential) An act that describes the process whereby a verifying party validates either the existence of the Role attested to by the Credential or the actual Vetting act and its details, i.e. validates the specific details (at whatever level is desired) of the original process which established the competencies, capabilities, and/or capacities that resulted in the activation of the role-of-interest.

  Fulfillment Act Relationship: This relationship associates the individual verification events with the global verification request task.

  Pertinent Information Act Relationship: This links the verification to documentation that supports the verification act.

  Primary Performer Participation: This is the actual person who performs the verification and the organization they represent.

  Support Participation: A verification act can have optional corroborating information (an InformationProvision act) supplied by a performing person, organization or device.

  Subject Participation: This is the role and associated entity that is being verified.

• Vetting: (Assessment of Competency, Capability, Capacity). This is currently a placeholder class in the model. A regulatory-focused act that collects the 'observations' about people or organization's capabilities, competencies and capacities prior to a role being activated.

  Outcome Act Relationship: This relationship links the Vetting act with the Role Activation Act. The Vetting act, at a minimum, involves the participation of the entity that will ultimately be the Responsible Party in the Activation of the Role (the subject of the Role Activation Act) as well as the participation of the commissioning party organization (the author of the Role Activation Act).

  Pertinent Information Act Relationship: role verification may include scrutiny of the data that precedes activation of a role and is collected in this vetting act.

Entities

• AgentChoice: Types of entities that may play the role of agent for a commissioning party. Alternatively, one of these entities may be a trusted source of role information for role Verification activities.
• ContactPerson: This is the person who is the contact for an organization. Note that contact role does not entail the same level of responsibility as an agent. This role is also a component of the LocationLocatedEntity CMET.
• CredentialVerificationOrganization: An organization whose primary function is to verify credentials, typically on behalf of a health care employer.
• Group: A resource group. This entity is a component of the R_AssignedEntityUniversal CMET
• InformantChoice: A trusted source for role verification purposes may be either a credential agency, or the organization which scopes the role of interest.

• Jurisdiction: The DMIM contains a jurisdiction model to describe geopolitical units relevant to a focal role like that of citizen or of a HealthCareProvider. The domain model asserts that jurisdiction is descended: from role scoper to role player. Jurisdiction is a Territory-of-Authority role scoping the organization that, in its turn, scopes the role of interest. Example: the Board having Territorial authority for the state of Maryland licenses physician to practice in that state. The Territory of Authority is played by a place (classcode =<PLC>, which in this model is the Jurisdiction clone. Code for an actual geopolitical region (state, country, province etc) is carried in Jurisdiction.code and can be constrained by specialization of Jurisdiction.classcode.

  Attributes:
  • classcode: Specializable. In a message instance can be used to classify a jurisdiction as a State, Country etc. See EntityClassPlace domain in the RIM.
  • code: Under committee review. Semantics for typing of place are already present in the classcode domain.
• Nation: This is the country to which a person may have a citizenship.
• Organization: This generic organization clone is the entity that scopes the principal (focal) roles defined in the model. Organization hierarchies are supported through the OrganizationContains and OrganizationPartOf roles. This entity is also the entry point for the E_OrganizationUniversal CMET.
• PerformerPerson: The person who performs a role verification.
• Place: a physical location playing the role of an SDLC (service delivery location).
• PrincipalChoice: Entities (person, organization, animal or device) that are the focus of the personnel management messaging and play one or more of the principal roles of interest to the domain.

Other

• Backup (RoleLink): This role link allows for the definition of one role as a backup to another role.
• Indirect Authority (RoleLink): A component of an Organizational hierarchy may have indirect authority over an assigned entity role. For example, AssignedEntity roles are created under departmental divisions or units in a hospital organization as positions in an overall hierarchy of responsibility.
• LanguageCommunication: Language use and capabilities of an entity.
• Part (RoleLink): see TerritorialAuthority
• relatedTo (RoleLink): Indicates a non-specific relationship between source and target roles. In PM domain is used to explicitly indicate a relationship between two or more roles played by the same entity. In a message instance can also differentially associate multiple roles, as illustrated in the following example:

  A Provider Registry query response describes the history of Harold Hippocrates, currently a Physician but at one time a Registered Nurse. Along with these two HealthcareProvider roles the query results contain numerous instances of the QualifiedEntity Role, each instance corresponding to one of Harold's academic achievements. The message model must be able to associate each QualifiedEntity Role instance with the appropriate HealthCareProvider role instance, and does so by binding the roles via the relatedTo role link.

  The rolelink typecode is specializable where there is a requirement to indicate a more explicit relationship. See HL7 RoleLinkType vocabulary domain value set.

  Attributes:
  • effectiveTime: Time at which the relationship between the roles became effective, not the effective time of either of the roles involved.