THISIS FAQ - Co-Infection Management
The coinfection functionality is locking users out of their events. DO NOT USE COINFECTION until further notice.
For people with co-infections, you will first need to make sure an event exists for each disease associated with the person. You do not need to enter information for each event. Once an event for each disease has been created, open the event dashboard for one of the events. Within that event, open the Co-infection Management question package located in the Event Data tab.
In the dropdown menu, select the disease for which there is a co-infection. Then click the ‘Create Coinfection’ link. A pop-up window may appear, click OK to proceed.
This will create a NEW co-infection event for the person. From now on, enter all conjoint data in that new THISIS event. When the individual disease events become associated with a co-infection, the common question packages will lock. The user must enter their investigation outcomes in the co-infection event. In the image below, you can see the new coinfection event appears in the results when searching for the person in THISIS.
Also, if you are in the event dashboard for one of the diseases associated with the co-infection for that person, you'll be able to see and access the co-infection event under the notifications section of the Basic Information box. See the image below.
Users can add all of the diseases involved in the investigation, There will no longer be a limit to “Disease 1” and “Disease 2” as there was in STD*MIS (legacy data management system). If there are more than two diseases involved in a person’s co-infection, you will follow all the steps as described above. But when you are in the Coinfection Management question package, after you enter the first disease, click the “Add New” link to the right of the dropdown menu.
Another ‘Select coinfected cases’ field will appear. Select the appropriate disease. Continue the process until you add all associated diseases. When you finish, select the ‘Create Coinfection’ link to create the new coinfection event.
Once the user has updated the co-infection event, those updates will automatically be copied to the associated individual disease events. For example, in a co-infection event that involves syphilis, HIV, and gonorrhea, if the user enters a disposition for syphilis but not for HIV or gonorrhea, the field record disposition in the syphilis event will be automatically updated. The field record dispositions in the HIV and gonorrhea events will be blank until updated in the appropriate question package within the co-infection event.
When doing a syphilis field record, it requires HIV results to be added to the lab section. The system does not allow an HIV lab to be added to a syphilis event. A negative HIV event can be created that can be cross-referenced, but multiple question packages need to be answered off of a negative test. Is this the correct way to do it? Will there always be multiple question packages to answer for a negative HIV event?
In this scenario, although the question packages are available for the user, the user does not need to fill them out in the HIV event with the negative lab.
When I am in some of the question packages for a disease event that is associated with a co-infection (not when I am in the actual coinfection event), I see a question/field that says, “Prevents this answer block from being joined if the current case is joined.” What does this mean?
When a coinfection event is created, some question packages will overlap with the associated individual disease events (e.g., Case Assignment/Field Record, Follow-Up Activity, Risk Factors, Partners/Clusters, Venues). All data associated with the coinfection should be entered in this coinfection event. The information will automatically appear in the respective question package within the associated individual disease events. But, there will be instances in which information is only relevant for one of the diseases and not the coinfection. That data will need to be entered into a question package for an individual disease event. When users are entering this information in any of the overlapping question packages (mentioned above), they will see the field/question that reads, “Prevents this answer block from being joined if the current case is joined.” It will show towards the bottom of the page or section in which they are entering new data.
Currently, this field has an asterisk, meaning it is a required field. When THISIS is updated, it will no longer be a required question.
The purpose of this ‘prevent join’ question is to allow users to enter information for a disease event without it being joined/copied into the coinfection event. In other words, if you select “Yes” as the answer to the question, “Prevents this answer block from being joined if the current case is joined,” the information in that section/block will stay only within that disease event and will not be copied to a coinfection event.
For example, you could have a specific contact attempt with a person that was only applicable to their gonorrhea event, but not their HIV event. Or, you have an HIV-gonorrhea coinfection, but some of the venues identified are only applicable to the HIV event and not the gonorrhea event. In these situations, when you are entering data in the respective question packages, you would select ‘Yes’ when you get to the field that asks, “Prevent this answer block from being joined if the current case is joined.” This way, that information will only exist as part of the appropriate disease event.
This seems to be an issue with the roles having access to the “product” of co-infection. There have been issues identified with editing partners and printing reports from the co-infection. We are currently working on this issue so that sites will have full access to the coinfection functionality.
Currently, sites must create field records for all diseases until we can get this resolved. This is a high-priority item.
In several of the question packages, you will see a selection option of “Prevent Join.” This is an option if you want to be sure that this particular assignment, for example, is not linked to a coinfection event. This will be particularly useful for existing HIV events if you do not want to join that iteration of the new investigation.