Make a PersonAttribute searchable

Hi all,

In the process of a bulk data import, I am storing the legacy system ID as a PersonAttribute. Later on I would like to allow searching through this legacy ID.

(Q.) Is there any precaution I should take beforehand when storing them?

I’m asking because I can see that when creating a new PersonAttributeType there is a .setForeignKey(int) method available. Note that it doesn’t have to be stored as a PersonAttribute, if there is a better practice, please let me know.

Any hints and tips would be welcome, in order for us to not regret later some misteps that we may make now.


system_id is already a field in the users’ table and is searchable out of the box, why would you consider converting it into a person attribute?

@mksd, if these are patients you could store this as a PatientIdentifier. Otherwise, PersonAttribute is correct. The foreign key thing in PersonAttributeType is for the scenario where the person attribute has a datatype that is backed by a DB table, e.g. if the PersonAttributeType is an OpenMRS Location. I forget the exact details but it isn’t relevant for you.

(@wyclif, I presume that “legacy system id” means the system ID in a legacy system, not the OpenMRS users.system_id.)

I see, thanks Darius! Then i guess storing it as a person attribute would be correct

Hi @darius

Yes, using PatientIdentifier is indeed better! I just tried and I am then allowed to search through both legacy and OpenMRS identifiers after saving the patients, which is exactly what I needed.

I’m doing this right now:

patient = registrationService.registerPatient(patient, null, null, registrationDesk);
patient.addIdentifier( new PatientIdentifier(legacyId, legacyIdentifierType, registrationDesk) );
patient = patientService.savePatient(patient);

I don’t know how to generate an OpenMRS ID other than by using RegistrationService. As a consequence I’m saving the patient twice which is probably stupid. Would you have another suggestion?

To autogenerate a patient identifier you’d use the idgen module. (RegistrationService probably uses this under the hood.)

Thanks Darius, we went along with registrationcore but I’m sure we will have to come back to this in the future anyway.