TLDR: See the bottom of the post for a proposed data model for contact tracing and contact cohorts in OpenMRS.
So as part of OpenMRS’s work on a response to COVID-19, there’s been an emerging consensus that we should be aiming to develop some reusable concepts, forms, reports and other components related to helping trace public health emergencies. Of course, our immediate target for this work is helping with the current COVID-19 pandemic, but, as recent history has unfortunately shown with, for example, SARS, MERS, the 2013 and 2017 Ebola outbreaks, Zika, etc. this category of problem is likely something that is going to remain with us and that global goods like OpenMRS should seek to have tools to address.
One component of this that may be useful to have are data structures to assist with contact tracing. While there are tools that are better suited to a mobile workforce (e.g., CommCare and OpenSRP, tools better suited to aggregate reporting, such as DHIS2 and even tools built precisely for this kind of surveillance, such as SORMAS), there does seem to be some role for OpenMRS to play in contact tracing, particularly in countries with wide-spread OpenMRS adoption.
The idea here wouldn’t be to turn OpenMRS into a full-blown syndromic surveillance tool, but rather to allow the capture of contact data for later follow-up and possibly recording attempts at follow-up. The vision here is to have an interface familiar to staff involved in usual point of care to capture these data for reporting upstream sources (MoHs / DHIS2 / SORMAS) for aggregation and reporting or export downstream (CommCare / OpenSRP) tools for individual follow-up.
Importantly for the design of this, a “contact” will usually contain much less information than a full patient record and those data may be less trust-worthy than those recorded for a patient (since these data are likely to be derived from patient reports rather than direct contact with the individuals in question at the point of data entry).
In some ways, it’s easy to extend the OpenMRS data model to accomodate Contacts. Pretty much all the data we would want to represent about a Contact is already representable via the Person domain. However, there are a couple of things that we may want to do that are harder to represent:
- Cohorts (which, for our purposes are just lists of contacts with some metadata). OpenMRS, of course, has a concept of “Cohorts” in core and a Cohort module that provides a much richer data model for interacting with cohorts. Both of these Cohort models, however, are limited to representing cohorts of Patients.
- While its possible to map Obs to Person objects, which seems to have been envisioned as a way of tracking HIV contacts, this use-case has not actually materialized, and so, for example, it is impossible to map an Encounter to a Person. Yes, this is a perhaps weird use of Encounter, but the idea would be to capture interactions with a person prior to that person becoming an actual patient, e.g., attempts (successful or otherwise) to contact a person for follow-up on possible infection.
Regarding Cohorts, I think there are two ways forward:
Create a new ContactCohort that represents a Cohort of Contacts, similar, but not identical to the other OpenMRS contacts.
I’m a little unsure about how to properly handle the contact encounter case.
In any case, here is a proposed UML diagram for a Contact object with its own type of Cohort:
Thoughts? Questions? Objections?