This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Care Transfer Topic"

From HL7Wiki
Jump to navigation Jump to search
 
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[  Patient Care Normative Ballot Content ]]
 
[[  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 or Reject===
 +
 +
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 or Reject is an announcement of the acceptance of taking on the responsibility of Care Provision as stated in the fulfilled request, or the rejection with a reason given. The reject will be indicated with the negation indicator to the Promise.
 +
 +
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 or rejection 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. Similarly, minimum information is given for a reject.
 +
 +
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.
 +
 +
'''Act Relationships'''
 +
 +
 +
'''reason:''' a relationship to recorded Clinical Statement as the reason for the acceptance or rejection of the Care Provision Request Promise. 
 +
 +
'''InFulfillmentOf:''' a Care Transfer Promise is associated with the Care Transfer Request being accepted, that is the Care Transfer Request that the promise fulfills. Only the id attribute is provided to link the request to the promise.
 +
 +
'''component:''' links the Care Provision Promise 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.

Latest revision as of 12:12, 21 February 2012

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 or Reject

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 or Reject is an announcement of the acceptance of taking on the responsibility of Care Provision as stated in the fulfilled request, or the rejection with a reason given. The reject will be indicated with the negation indicator to the Promise.

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 or rejection 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. Similarly, minimum information is given for a reject.

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.

Act Relationships


reason: a relationship to recorded Clinical Statement as the reason for the acceptance or rejection of the Care Provision Request Promise.

InFulfillmentOf: a Care Transfer Promise is associated with the Care Transfer Request being accepted, that is the Care Transfer Request that the promise fulfills. Only the id attribute is provided to link the request to the promise.

component: links the Care Provision Promise 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.