I am encountering an issue while attempting to import metadata for the HIV Case Surveillance program into our DHIS2 instance (version: 2.38).
Problem Description:
I tested the import of my JSON metadata file for the HIV Case Surveillance program in “Test” mode, and no errors were reported.
However, when I try to initiate the actual import, I receive the following error:
TypeError: Cannot read properties of undefined (reading 'imported')
This error appears in the user interface, even though the test import completed successfully without any conflicts or errors.
Actions Already Taken:
Cleared the browser cache and tried using a different browser.
Checked compatibility between the DHIS2 version and the metadata JSON file.
Could you please advise on steps to resolve this error or suggest any additional checks I should perform?
Thank you in advance for your assistance. I am available to provide further information if needed.
Hi @elmoujarrade. I don’t know if you are able to share the json (in order to see in detail). Do you have optionSets in the metadata? Could you review the sort of the options?
Can you confirm that youve seen the HIV CS installation guide and taken all necessary steps?
When importing a package into an existing instance, there are some changes to the metadata file that need to be done manually. For example, the UID of the default category combination is not the same across all dhis2 instances; if you import a package with a different default catcombo UID, you will get an error.
The same should be done for Tracked Entity Type and Indicator Type
This is usually not an issue with importing into a blank instance.
Thank you for your support and guidance. I wanted to inform you that I am starting to develop the HIV Case Surveillance program from scratch on my DHIS2 instance (version 2.38). I am aiming to implement the components of the Package version 2.0.1.
To facilitate this setup, I would like to ask if there is any possibility of accessing a demo version with full access to the metadata and configuration settings for this package. Having a demo reference would greatly help in implementing it accurately on my instance.
We have not released a version 2.0.1 of the HIV CS package that is compatible with DHIS2 version 2.38. We also don’t have a demo of this system available on 2.38.
I can however suggest the following:
Download the 2.0.1 package. Within the zip file, you will find a excel sheet with a “flat file” of the metadata. This is not an installable file, but rather lists all metadata objects of the package (data elements, indicators, program rules, etc) in different tabs to give an overview of its contents.
The HIV CS 2.0.1 metadata is available on the hmis demo . If you log in as a demo user, you will be able to view the program in Capture and dashboards. To view the metadata in more detail, I recommend you use the API, for example: DHIS 2 gives you the parameters for the HIV CS program.
Lastly, you may want to download the metadata for 2.40 and install it in a blank version 40 local instance, to explore the metadata with the maintenance app. For that, please see again the Installation guide.
Thank you for your response and suggestions. I followed the option you proposed, specifically downloading the metadata for version 2.40 and installing it in a local blank instance of version 40 to explore the metadata with the maintenance app. This is working perfectly, and I’ve been able to view the metadata in detail. I am now in the process of adapting the model to our context.
I do have a few questions regarding the model, particularly about the “Visit” stage. I’m curious why, under “patient status,” the options include “Death” or “lost to follow-up,” even though the stage is “Visit,” which implies an actual encounter with the patient. Could you explain the logic behind these options?
Glad to hear you are able to view the metadata now!
For design clarification, I really recommend you also explore the toolkit System Design Guide, which describes such decisions in detail.
To your question, the repeatable “Visit” Stage is the main stage that collects all longitudinal data required on patient services and patient status in the same place. It is very important for calculating the core program indicators to keep those data elements within the same stage.
.
As described in this section of the guide, when the patient is reported as PLHIV in a visit stage, program rules also open up other sections related to service provision; if the patient has died or is LTFU, then those are hidden.
The follow up stage is to document facility attempts at outreach (like phone calls) if the patient is LTFU, rather than to document patient status or visits.
Thank you for the clarification and for recommending the System Design Guide. After reviewing your explanation, the logic behind the design is much clearer now, especially the importance of keeping all core program indicators in the same ‘Visit’ stage for longitudinal data collection. I also appreciate the detailed breakdown of how program rules manage visibility based on patient status.
Thanks again for the guidance; it’s been really helpful!
