The product team working on Connect thus far has been trying to limit the scope of what use cases it covers, because Hub and Spoke approach mentioned here is a better solution for some of these in the long run, and we don’t want to be supporting too many ways of doing the same thing.
But @mksd your limited use case is very interesting, and it does sound like a possibly-feasible way to add business value (a) without massive dev effort, and (b) without violating the principle that we can’t have p2p sync between offline devices.
Hopefully someone who has worked directly on the Connect codebase can give a quick estimate of the effort/feasibility of
- a special “create shell patient” workflow that can only be enabled on Connect
- it should sets a new person_attribute like
shellPatient=true - this reminds me of the “register unknown patient” feature in the OpenMRS Reference Application
- introducing an automatic merge step on the server side that finds corresponding the real patient records corresponding to shell patients and merges these
- enhanced visit/encounter merging algorithm to handle the case where “separate devices start an OPD visit for the same patient with conflicting start date/time”
- screen for viewing the status of these shell patient (e.g. how many are waiting around unmerged?)
- documentation!
(Actually only the first and last bullet points require specific knowledge of Connect.)
@mksd does your team have some dev cycles to contribute to this?