If you are having an encounter with someone, they should be(come) a patient.
If you are gathering data from a patient about other contacts and want to connect those data with the contact, then use person for the contact and create obs connected to that person (which could be stored uniquely or could be derived/copied from obs in the patient encounter).
This is an important distinction, because the directionality of the OBS changes. If I am the patient and recording observations about the contact I had, then it might be that the contact is my mother. However, if the mother is a patient and the OBS is stored on her record, then her contact is with her son. We should be clear that who the reference is when we record the data.
Using this approach, how can we avoid creating as a person a contact who has not been successfully traced? Our experience with contact listing and followup for clients who turn HIV positive is that more than half of those listed are never successfully traced (this may be unique to Kenya and HIV program though). This could be due to many reasons including inadequate locator information provided or just non-cooperation by the contacts when reached out to. Storing information of such contacts in the person’s model may unnecessarily fill the table with data that will never be used. It is due to these reasons that we thought it wise to have a separate model for listing contacts and only promote a contact to a patient upon successful followup when the full information for registration is collected and validated.
@aojwang I believe I had a similar conversation with @jdick recently. For sure we do not want to clog the patient table to not affect the experience of clinicians within the EMR. But it should not matter to create many persons in the person table, or is your experience otherwise?
Of course I’m assuming that contacts would be recorded as persons (not patients).
My thought was that by using Person model to record contacts you basically will use PersonName, PersonAddress, etc models which are shared between a patient and a person models. You can look at it from a patient search process where the results are basically from Person related models i.e. name and attributes. I think @jdick or @nkimaina can share what their experience is with patient search on a large database.
Yes that seems to make a lot of sense indeed. The performance issues would come from bloating person_name, which will be a consequence of recording many contacts as persons.
Unless… multiple Lucene caches can be configured, as in:
No idea whether this can be done, I haven’t done the minimal Googling yet 