Changes between Version 59 and Version 60 of Deployments/Ebola

10/19/14 09:14:46 (10 years ago)
Fran Boon

+Background on Workflow of existing app


  • Deployments/Ebola

    v59 v60  
    4343==== Needs ====
    4544* Identify and digitize a suitable case investigation form
    4645* Review and incorporate Nigerian tracing methodology
     47The "contact_tracing" table records time and place (or alternatively "cirumstances" if no particular place can be given, e.g. when the infected person was travelling) where there might have been contacts - if you are not yet able to identify these contacts.
     49These records are organized by place and time, rather by case - because time and place are the primary connection between the case and the contacts. So in the investigation, you're looking for people who have been e.g. on that same market at the same time, or on the same flight.
     51That's what the Nigerians did - proximity scan. Who lives, works or visits regularily the places where an infected person has been staying - then follow up on these people. That's how they generated about 26,000 follow-ups out of 19 cases.
     53The WHO standard procedure is though to record just the people who are known to have had close contact with the case, e.g. family members, health personnel, friends.
     55Those contacts are of course recorded directly under the case - on the contact tab. No "contact_tracing" record is required for that.
     57In /any/ case of contact, the exact circumstances and exposure risk level for each known contact person are recorded in the contact_person record. Any high-risk exposure should automatically create a new case for the contact person as "at risk", and set its monitoring level to "routine monitoring". But this is actually a business rule and hence needs to be configurable (at least per disease, but maybe also per country).
     59When a new contact is submitted under a "tracing" record, it should of course inherit the case_id (this isn't yet implemented) - and for that reason, the case_id field should not appear on the "contact persons" tab of a tracing.
     61This is the kind of stuff that still needs to be completed.
     63It would also need some help texts/tooltips here and there, and of course there needs to be access control. No way that such information can be publicly accessible - we would put people's lives at risk.
     65By the way, this sort of "circumstantial tracing" is not only relevant to find contact persons, but also to identify contaminated places and things, e.g. medical equipment, which need to be decontaminated or incinerated (highly important /within/ medical facilities, and for first occurences).
     67But then, it is not suitable for all diseases - HIV or HCV for example do not require it as there is no indirect transmission mode. However, for airborne pathogens or anything that can be indirectly transmitted (like Ebola, or MRSA) this can be very relevant.
     69If you for example unknowingly treated an Ebola patient in an emergency unit without suitable protection equipment, then you may need to treat all staff and all subsequent patients in the same unit for the following 12 hours as possible contacts. However, since you didn't know, you may have sent away the patient, either to a more specialized hospital, or (as it happened) back home with some pain killers.
     71At the time when somebody then registers the case (which could be at a different hospital many miles away), they may not be able to identify those contacts. Instead they would record the situation, the time and the location - which ideally would send out (or at least trigger) an alert to your ER where you first treated the patient, both allowing you to decontaminate the place, and to start to identify and report any possible contact persons back to the case file.
     73That is why it is split into direct "contacts", and "tracing".
     75Ultimately, when you have identified all circumstantial contacts, you can close the "tracing" record (it has a status flag).
     77Note that "exposure" and "contact_person" are de facto the same thing - just from two different angles. "Exposure" means backwards - i.e. /this/ person had been exposed to a known case. "Contact" is forward - i.e. a person was exposed to /this/ case.
     79Thus, when you register a contact person for a case, the case automatically appears under "exposure" for that person - allowing you to trace backwards. And vice-versa: when you register an exposure, it would automatically appear as contact under the case this person was exposed to, allowing you to trace forward.
     81...from my previous description it should have become clear that ideally you should not need to register a new case under the "Exposure" tab - the source case should already be in the system by the time the current case is reported (how else would you know that it was an exposure?).
     83When a case is first registered under "Exposure", then something has gone wrong - and it will become complicated. Because: it means that somewhere there information flow was disrupted, and now we need to trace that original case and find its data (e.g. current status, diagnosis etc.).
     85So, in an ideal world, there should not be an !AddResourceLink for a new case on the Exposure tab. But practically, I think it can and it will happen that cases are known but not registered, especially when people cross borders.
     87As you can imagine, this kind of "loose links" needs a solution - IMHO it must actually automatically search through all known databases for the data (especially the case number, but also status and diagnosis information) of the source case, and also report back the new case as contact.
    4889==== Problems ====