Reports with multiple subject IDs

I have a workflow which apparently works only if reports have two subject IDs:

  1. A place_id - referencing the top level CHW’s area
  2. A patient_uuid - pointing to a household member down at the bottom of the hierarchy

Is this practice generally considered safe and supported?

I’m seeking clarity on how this report will behave in other scenarios. How will this report replicate? Where will it show in the UI? Is this documented somewhere clearly?

1 Like

Noticing some seemingly inconsistent behavior in code…

The rules engine uses both registrationUtils.getSubjectIds like here when dealing with contacts. But it uses registrationUtils.subjectId in other places like here which would look only at the first subject ID on reports. This would suggest that contacts can have multiple subjects but reports cannot?

When we look at the single subject ID for reports – places like ddocs/medic-db/medic/views/doc_summaries_by_id use the patient_uuid before the place_id which is consistent with registrationUtils.getSubjectIds. But in places like ddocs/medic-db/medic/views/docs_by_replication_key, we use the place_id before the patient_uuid. Seems that if a report set a patient_id and place_id, its output for docs_to_replication_key would be different vs patient_uuid and place_id. Basically, its replication would be controlled via the patient in the former scenario and place_id in the latter?

Would anybody regard functionality which relies on multiple subject IDs safe for eCHIS Kenya production?

1 Like

Hi @kenn

We would not consider a report having multiple subjects as safe, as only one subject is considered.
Thanks for pointing out the inconsistency between registrationUtils.subjectId and docs_by_replication_key view. I’m not sure which one is correct, I would lean into any patient related info to be more important than place info, so would say that docs_by_replication_key needs changing to prioritize patient_uuid over place_id - only because we primarily have patient based workflows and we added place based workflows quite recently.

So my answer is … no, a workflow should not depend on having multiple subject ids. It can have them, but this might lead to weird behavior as you’ve just noted.

Is there a reason why the reserved field place_id is used in this case?

1 Like

Thanks for the feedback Diana. The use-case entails computing CHP performance metrics at area level from patient reports. How would you recommend accessing patient reports from area level without having the area as the report subject?

How would you recommend accessing patient reports from area level without having the area as the report subject?

Can you please add more details about what this means? In which context do you want to access patient reports?

The hierarchy is: CHW Area (place), Household (place), Client (person)

  1. Create a report X with patient_id set to a client’s id
  2. View the contact summary for the CHW area above the client. Log the value of reports passed into the contact summary.
  3. reports does not include report X
  4. Update report X to have a second subject id by setting place_id set to the id of the CHW area
  5. Look at the value passed to the CHW area’s contact summary again
  6. reports now includes report X

Looks like you can also just change patient_id: '123' to patient_uuid: '123' and it also appears in the skip-level contact summary…

Perhaps this isn’t exactly about duplicate subject IDs… Maybe there is just a problem with patient_id? Or this is an expected difference somehow?

I opened Reports with subject_id set via patient_id are not exposed at skip-level contact summary · Issue #9253 · medic/cht-core · GitHub

I see. Clearly we need to be consistent about this. Thanks for flagging and opening the issue.