Affects Version/s: None
Fix Version/s: OpenMRS 2.2
Sprint:Registration Sprint 1
As a member of the admin team for an Emergency Department:
I need to be able to register a patient who cannot be identified (i.e. if they are unconscious, or it is too time consuming to register a patient – such as in a mass trauma situation) so that I can track the tests and treatments ordered for them.
Once I'm able to identify a previously unknown patient, I might find that:
- a registration record already exists for the previously unknown patient in the system
- there is no existing registration record for the previously unknown patient in the system
Where there is no other registration record in the system for a previously unknown patient, I want to be able to update their unknown patient registration to add the rest of their registration details (i.e. name, address, date of birth) and turn it into a “full”/”permanent” registration record.
Where a registration record exists in the system for a previously unknown patient, I want to update their existing registration record with any encounters and observations that took place while they were “unknown”.
Also, the unknown records should be assigned an identifier in such a way that it is apparent that it is a temporary record. e.g. it should start with an "X" or something.
This option should be added in such a way that it doesn't impede the normal patient registration workflow. A button should be added to the first page of registration (Name) to register an unknown patient (similar to the button added for RA-476). If this button is clicked, the user should be brought into this Unknown patient registration flow. This flow should only require specifying the Gender of the patient. Nothing else should be prompted for.
Although this ticket talks about Merge functionality, that is actually covered in
1. The user is logged into the system and has rights to capture registrations
2. The user is logged into the system and has rights to merge records and capture encounters
3. Paper records showing the “unknown” registration details are likely to have been produced, so any ID numbers allocated when the patient was registered as “unknown” will be present in hard copy files.
1. Must be able to create a registration record with only gender detail. All other registration fields should be able to be left blank - and the System should not prompt Users to provide any other details.
2. The UI must ensure patients registered as “unknown” should be visually distinct (compared with patients registered with full registration details) so that it is obvious when users view the patient record that they were registered as unknown
3. Registration admin staff must be able to easily generate a list of all “unknown” patient registrations.
4. “Unknown” registration records must be able to be updated with additional registration details (i.e. name, address, date of birth) and be converted to a “full”/”permanent” registration record.
5. “Unknown” registration records must be able to be merged into existing registration records. After merging an “Unknown” registration with an existing “full” registration record, all Encounters and Observations recorded against an “Unknown” registration are linked to the “full” registration record.
6. After merging an “Unknown” registration with an existing “full” registration record, all data that existed on the “full” registration record is retained. (Data in the “full” registration record should not be lost as a result of this merging).
7. After an “Unknown” registration has been merged with a “full” registration record, Users must be able to find the full registration record by searching for the “unknown” registration id/number/barcode. (This is intended to cater for situations where staff are reading printed records (such as lab test requests) that show the “unknown” registration id, and want to update the patients' record.)
8. When viewing a patient's record user must be able to identify if it was merged with an “unknown” registration record and the “unknown” registration record.
9. The "unknown" record should have an identifier that is distinct from identifiers of permanent records.
10. This flow should be implemented in such a way that it is unobtrusive to the basic patient registration flow.
- The emrapi module defines support for an "is unknown patient" PersonAttributeType via org.openmrs.module.emrapi.EmrApiProperties#getUnknownPatientPersonAttributeType
- The emrapi module has a method we should use when merging an unknown patient into their known replacement record: AdtService.mergePatients and this calls org.openmrs.module.emrapi.adt.AdtServiceImpl#removeAttributeOfUnknownPatient