Modeling Patient handover/monitoring remarks

I work for a company that has a medical dossier product for elderly care.
We are making a start with replacing our current SOAP interfaces with a new FHIR API. So although we have a lot of integration experience, we are FHIR newbie’s.
I would really appreciate some advice on the following situation.

In our system we have an optional ‘remark’ for each patient that the regular doctors can make on a medical record for the team that will cover the ‘on-call’ in the weekend. These on-call doctors can then at the beginning of their shift have a look at this list to know what situations they need to be aware of, or what patients to give extra attention (its a kind of temporary handover/monitoring).

Some of our customers use a 3rd party company to cover these weekend shifts: they have their own system and their own doctors. We want to make these remarks available to them in our FHIR interface so they can show the list in their own system.

Done so far
We had some trouble modeling this information into proper FHIR.
We think the ‘communication’ resource is the best fit for this type of remark. We also want to supply the patient name, organisation name, location and ward name, and then the remark. It looks like this means we have to provide the ‘Patient’, ‘Location’, ‘Organisation’, ‘Encounter’ and the ‘Communication’ resource.

We can go from Patient to the ‘managingOrganisation’, From the ward we can use the ‘partOf’ to get the actual ‘location’ where the ward is situated (so 2 location resources). And with the Encounter we can link the patient to the ward he/she is staying at the moment.

1: Are these the correct resources? Or did we misinterpreted how they are supposed to be used?
2: Is it correct that the ‘encounter’ is the only way to link a patient to a location/ward, or are there other ways?
3: This is quite a involved process for the company to retrieve this data from us: that company will have to do a lot of calls (4 or 5 calls for every patient in the list) to gather all this together while all they want is a simple list.
Would you recommend making a ‘Composition’ resource to combine all the information into one bundle/list? We spend a bit of time with the Hapi Java library, but we are not sure that is how this done and if this is how you are supposed to use this resource.

Any advice or feedback on our approach is most welcome.



  1. Communication is one possibility. Observation would be the other. Observation is appropriate if the note is part of the medical record and might reasonably be reviewed by multiple multiple people over time. Communication is if the information is targeted, read once and then tossed. The others sound right.

Patient.managingOrganization isn’t necessarily what you want. Encounter.serviceProvider is probably better. Patient.managingOrganization is “who owns the patient record”. Encounter.serviceProvider is “what organization is responsible for the encounter being reported on”.

  1. Yes. Patient is tied to location only in the scope of an Encounter

  2. Check out the _include search parameter. If you search on Communication/Observation, you can _include the Encounter, Location, Patient, etc. Also note that the reference element can convey a name (Reference.display) and identifier (Reference.reference / Reference.identifier), so if that’s all you need, there might not be a need to retrieve the resources targeted by the reference.

Composition imposes a reasonable amount of overhead, adds extra work to get systems to conform, and requires specific behavior around how the information is rendered/attested to. If you need the full characteristics of a document, that’s fine. But don’t impose it just because you care about multiple resources. (In FHIR you usually care about multiple resources, but you can still use plain REST.) Read up on the for more about what this would mean.

For specific questions related to HAPI, suggest reaching out on the associated Google group or on the HAPI stream on

Very much appreciated. Will look into your suggestions first thing tomorrow morning.