By: Liron Shahar-Atia

Sometimes, when a patient is discharged from a hospital, he receives a referral with recommendations and guidelines for further treatment in the community. The referral form will include recommendations for treatment after discharge from the hospital such as physiotherapy, orthopedics, and general surgery.

We have chosen to represent the referral from the hospital to community-care with the CarePlan Resource - whose structure is very detailed and suitable to contain all the variety of types of information we need and all the connections to Resources and other elements.

Now, a new challenge remains for us: how to represent the recommendations for community actors?

We are faced with a number of possible alternatives, and we need to find the most suitable one. Common to them all is that in each of them one can use a Snomed-CT code to represent the type of recommendation, and complementary properties can be added, such as status, period, reason etc., so that all of them seem to fit the recommendation.

And yet, each of the alternatives has a slightly different nature, which should be considered when making the choice:

• Task 

 A Resource used for a "dynamic" recommendation that is updated at each stage of the process.

Once the recommendation is created, the information can be updated regularly, such as performing a step from the specific recommendation, status of progress, priority, and more.

Designed for systems that support workflow and enable both data transmission and reception of updates.

For example, a referral for blood tests: At the initial entry, the status will be "accepted". After taking the blood the nurse will update the status to "in-progress". After receiving the results, the nurse will update to "completed" and can refer to the test results by updating the information in the output element.

It can be created in the following path: CarePlan.activity.reference

• ServiceRequest 

This is a Resource that represents referrals of various types such as referral for examination, diagnosis, treatment, medical accessory and more.

It is very extensive, and has many types of elements for information of a referral and in addition it maintains relationships with a wide range of Resources.

In our case the structure of the ServiceRequest does not cover all the types of information included in the referral for treatment after discharge from the hospital, but it can be used for a specific recommendation from the complete referral form.

It is suitable for use as a referral to an activity, where the recommendation is defined as drive to action, that is, when the recommendation is automatically identified and immediately creates a relevant event in the system. For example - a recommendation for sick days that will be automatically identified and will create an action applying the practitioner to approve these days.

In such cases it would be best to create a ServiceRequest referral that would be linked to CarePlan.

It can be created in the following path: CarePlan.activity.reference

• Activity

An element within the CarePlan that allows you to manage activities in the treatment plan, including recommendations.

As shown in the sections above, it can be assigned to other Resources, but another option is to set the recommendation in the activity itself without referring to another resource.

This option is suitable for a case where there is a system whose function is only to receive the recommendation data and transfer it to another Legacy system, without further intervention in the information. Data such as status and statusReason can be updated, but the process itself does not support a regulated workflow, and the customer does not expect to receive up-to-date information about each step in the process from the activity properties.

In this case, it is mainly a matter of data entry - documenting the recommendation as received upon release.

It can be created in the following path: CarePlan.activity.detail

Therefore, when we are asked to create a recommendation for further treatment after discharge from hospital, we must consider a number of factors.

For each of the following points one must understand what the current situation is in the current process, and at the same time understand what future plans the organization aspires to.

• Does the organization that receives the referral want to have a dialogue with the referring organization so that they will receive updates about the recommendations and their implementation?
• Is it necessary to set feedback for certain actions, such as starting treatment according to a particular recommendation or changing status to completed?
• Does the organization request to send spot updates to certain parties in the organization? For example to send an update to the attending physician according to the topic of the recommendation.
• Is there an element of prioritization between different recommendations?
• Is there a dependency between the recommendations? If so, you can also use the RequestGroup Resource.

Taken together, these will help one to arrive at the best model, as well as prepare for future processes.

Hopefully this information will help you in the future in making this kind of decision