Care Transfer Topic
Patient Care Normative Ballot Content
Care Transfer Request
The Care Transfer Request RMIM captures the data and associations that are needed when a care transfer is requested. This model, and its accompanying diagram, is very similar to the Care Provision DMIM but uses "local CMETs" to abstract the complexity of the care structures associated with the Care Provision Request Act. The reader should refer to the DMIM discussion before reviewing the RMIM followed by the discussion for each care structure. The discussion of this model takes up features that do not explicitly exist in the DMIM, and were not directly addressed in the review of that model.
Care Provision Request Focal Class
As noted in the discussion of the DMIM, a Care Provision Request is a request to transfer the responsibility of Care Provision or more simply a Care Transfer Request. Typically the request is made by a clinician within an application and transmitted to the performing party via a messaging interface.
All the participations encountered in this model have already been addressed in the discussion of the DMIM.
Associations
The following associations are defined for a Care Provision Request. Each association captures the relationship between the Care Provision Request and an entity or act that plays a significant part in the Care Transfer.
Participations
The first is that the care provision points to the SubjectChoice. In the choicebox the following relations are presented:
recordTarget: the record target is the entity for which the Care Provision Request is handled. There can only be one record target for a Care Provision Request. The target entity information is captured within the R_Patient CMET or R_CaredEntity local CMET. Refer to the respective CMETs for further description.
subject: the subject or subjects are the target(s) of the care provision being recorded when the subject is not the record target. The subject information is captured within the R_Patient CMET or R_CaredEntity local CMET. Refer to the respective CMETs for further description.
location: to indicate the intended or desired to take place after acceptance of the Care Provision Request.
dataEnterer: the transcriptionist who enters the information of the Care Provision Request. The data enterer information is captured within the R_AssignedPerson CMET.
author: the party that produces the Care Provision Request. This may be an assigned person or organization (R_AssignedParty) such as a healthcare provider, a related party (R_RelatedParty) such as a family member or a non-healthcare organization, or the patient (R_Patient) themselves. Refer to the respective CMETs for further description.
participant: for anyone else involved in Care Provision and or contributing to the Care Record. It is expected that implementations constrain this to the specific set of participations needed.
verifier: the supervisor who verifies the Care Provision Request. There is support for more than one level of verification. The verifying party information is captured within the R_AssignedPerson CMET.
performer: the intended parties who may take part in actually carrying out the Care Provision Event being requested. There may be multiple performers because several parties may collaborate in performance of Care Provision. These parties may be an assigned person or organization (R_AssignedParty) such as a healthcare provider, a related party (R_RelatedParty) such as a family member or a non-healthcare organization, or the patient (R_Patient) themselves. Refer to the respective CMETs for further description.
InformationRecipient: the parties who is intended to receive the Care Provision Request. The recipient is usually the author of the associated care transfer request or the primary care provider. These may be represented by an assigned person or organization (R_AssignedParty), a related party (R_RelatedParty) such as a family member or court, or the patient (R_Patient) themselves. Refer to the respective CMETs for further description.
Act Relationships
pertinentInformation2: links the Care Provision Event to a set of pertinent clinical statements provided as part of the information supplied in the Care Provision Request.
reason: a relationship to recorded Clinical Statement as the reason for the Care Provision Request. A problem, not specifically a diagnosis, which is the primary reason for the Care Provision can also be presented using this relationship.
ReplacementOf: a link to a reference of a Care Provision Request that has been replaced by this request. The Care Provision Request being the target of this act relationship becomes.
Reference2: a reference to a Care Record that contains relevant information for this Care Transfer Request.
Reference1: a reference to the Encounter in which the decision for this Care Transfer Request was made.
component2: links the Care Provision Event to the care plan which is carried out as part of the Care Provision. Refer to Care Plan Topic for further description of this local CMET.
pertinentInformation1: links the Care Provision Event to the care plan which is informative in the context of the care provision but not directly relevant to this Care Record. Refer to Care Plan Topic for further description this local CMET.
authorization: This allows a patient to consent to the Care Record, information exchange, care plan and so on.
Care Transfer Promise
Care Transfer Promise RMIM Overview
This model captures the data and associations that are needed when a Care Transfer is promised or accepted.
CareProvisionPromise Focal Class
A Care Provision Promise is an announcement of the acceptance of taking on the responsibility of Care Provision as stated in the fulfilled request. Typically the assigned person responsible for performing the Care Provision fulfilled by the request is the author of the Care Transfer Promise. It is assumed the request is recorded within an application and transmitted to the performing party via a messaging interface; in which case the promise is sent as a acceptance to that request. Only the minimum information required to promise to fulfill the request is provided in the current model, as it was seen to be not necessary to replicate the request detail in the case where requests were not received electronically.
The Care Transfer Promise RMIM can be used to accept/promise or reject/refuse a previously directed request for care provision.
Associations
The following associations are defined for a Care Provision Request. Each association captures the relationship between the Care Provision Request and an entity or act that plays a significant part in the Care Transfer.
Participations
The first is that the care provision points to the SubjectChoice. In the choicebox the following relations are presented:
recordTarget: the record target is the entity for which the Care Provision Request is handled. There can only be one record target for a Care Provision Request. The target entity information is captured within the R_Patient CMET or R_CaredEntity local CMET. Refer to the respective CMETs for further description.
subject: the subject or subjects are the target(s) of the care provision being recorded when the subject is not the record target. The subject information is captured within the R_Patient CMET or R_CaredEntity local CMET. Refer to the respective CMETs for further description.
author: the party that produces the Care Provision Promise. This may be an assigned person or organization (R_AssignedParty) such as a healthcare provider, a related party (R_RelatedParty) such as a family member or a non-healthcare organization, or the patient (R_Patient) themselves. Refer to the respective CMETs for further description.
performer: the intended parties who may take part in actually carrying out the Care Provision Event being promised. There may be multiple performers because several parties may collaborate in performance of Care Provision. These parties may be an assigned person or organization (R_AssignedParty) such as a healthcare provider, a related party (R_RelatedParty) such as a family member or a non-healthcare organization, or the patient (R_Patient) themselves. Refer to the respective CMETs for further description.
