Hi @burke, @ibacher and @jdick, we had a call this morning with @mddubey and @vasanth2019 and we came up with a couple findings and conclusions, see below.
1. Immunizations belong at the patient level
For the sake of this first iteration in OpenMRS 3.0, immunizations are simply represented as being at the patient level (like allergies or conditions). In short the UX is such that the user views/creates/edits immunizations from the patient summary, without really being concerned as to which visit or encounter those immunizations are linked to.
It doesn’t mean that they are not linked to an encounter, they are behind the scenes, but that’s largely not relevant in the upcoming UX and should therefore not be of much concern to the user. The way those immunizations are linked to a visit and an encounter is handled by our specific implementation of the FHIR resource (that is still to come btw):
When creating a new immunization, it is linked to the visit that was set for the patient summary. By default it should be the current visit if there is such a unique thing. Our idea anyway is that the POST content must actually provide the visit UUID as the
What happens next is really internal cuisine based on a backend config:
- Either a new immunization encounter is created each time as part of that specified visit,
- Or a single immunization encounter is reused as part of that specified visit.
- If the visit UUID points to a past visit then that’s how retrospective data entry is done. But again, the user might not even realise that they are doing so since from a UX standpoint all this looks like it’s happening at the patient level anyway.
Editing an immunization is straightforward, we go right to it through its UUID and edit it (the original obs group is voided and a new one is attached to the original encounter). By the way that means that the FHIR immunization UUID is in fact the UUID of the OpenMRS obs construct saved behind the scenes.
Viewing immunizations is an action that answers the question: “give me all the immunizations for this patient”. The only search parameter that the FHIR resource will support is thus a patient reference.
2. Immunizations sequences definitions as a front-end config (for v1 at least)
- The config will point to a concept set that lists all vaccines that should be part of the immunizations UX.
- The config will also provide a way to define immunization sequences for each vaccine, such as for example:
"sequenceLabel": "Dose 1",
"sequenceLabel": "Dose 2",
"sequenceLabel": "Booster 1",
Following the above config, all vaccines from CIEL:984 would be used and a specific sequence is defined only for ‘POLIO VACCINATION, ORAL’ (820BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB).
Cc @bistenes @ddesimone