...
Test Description | Step No. | Step Description | Expected Results |
As an end user, I want to test the functionality of Diagnosis Search and Save from SNOMED CT server, so that I can ensure the Bahmni-SNOMED integration is working as expected | OpenMRS Configuration Setup | Login to the OpenMRS Global Properties form https://qa.snomed.mybahmni.in/openmrs/admin/maintenance/globalProps.form | Global Properties page should be displayed. |
In the properties form, Verify that the Global Property bahmni.lookupExternalTerminologyServer in OpenMRS is set to TRUE in order to search diagnosis terms from the SNOMED CT server | bahmni.lookupExternalTerminologyServer should be set to True to fetch results from SNOMED server. | ||
In the properties form, Verify that the Global Property ts.fhir.baseurl field is set to https://snowstorm.snomed.mybahmni.in/fhir/ | ts.fhir.baseurl field should be set to https://snowstorm.snomed.mybahmni.in/fhir/ | ||
In the properties form, Verify that ts.fhir.valueset.urltemplate field is set as ValueSet/$expand?url={0}&filter={1}&count={2}&displayLanguage={3}&includeDesignations={4} | ts.fhir.valueset.urltemplate field should be set to ValueSet/$expand?url={0}&filter={1}&count={2}&displayLanguage={3}&includeDesignations={4} | ||
1 | Login to Bahmni application as user | User should be logged in | |
2 | Navigate to Clinical module and open an 'active' patient | The patient dashboard should be displayed | |
3 | Click on 'Consultation' button and then click on Diagnoses tab | Diagnoses page should be displayed | |
4 | Enter a search term on Diagnoses search field and validate that the Bahmni system returns search results from SNOMED CT Terminology server | The search results should be fetched from SNOMED CT Terminology server. The search results can be verified from SNOMED CT browser by providing the same search term | |
5 | User Enters less than 3 characters in the diagnosis search field, validate that Bahmni system displays message | No search results will be displayed for less than 3 characters | |
6 |
| "There was an unexpected issue on the server. Please try again" | |
7 |
| "There was an unexpected issue on the server. Please try again" | |
8 |
Validate that Bahmni system displays appropriate error message on the diagnosis screen | "There was an unexpected issue on the server. Please try again" | |
9 | Validate that the search results return the preferred terms of Disorders from SNOMED CT TS (This can be checked by searching the term in SNOMED CT Browser and checking for the preferred term, filtered by disorder) | System displays only the preferred term of the searched word from the SNOMED CT server | |
10 | Verify that system also returns the descendants of the search term in the search result | The search results should be fetched from SNOMED CT Terminology server and result can be verified from SNOMED CT browser | |
11 | Select a value from search result, select the 'Order', 'Certainty', and 'Status' | The selected values for 'Order', Certainty and Status are highlighted and selected term should be displayed on diagnoses field | |
12 | Click on 'save' button and validate success message is displayed | Success message should be displayed | |
13 | Verify that the value is saved in OpenMRS application | The value is saved in OpenMRS. The dictionary term should be available on OpenMRS and details as 'same as' SNOMED CT browser. | |
14 | Verify the saved diagnosis is displayed on patient dashboard | The saved diagnoses should be displayed on patient dashboard. | |
As an end user, I want to test the functionality of Conditions Search and Save from SNOMED CT server, so that I can ensure the Bahmni-SNOMED integration is working as expected | 1 | Login to Bahmni application as user | User should be logged in |
2 | Navigate to Clinical module and open an 'active' patient | The patient dashboard should be displayed | |
3 | Click on 'Consultation' button and then click on Diagnoses tab | Diagnoses page should be displayed | |
4 | Enter a search term on 'Conditions' search field and validate that the Bahmni system returns search results from SNOMED CT Terminology server | The search results should be fetched from SNOMED CT Terminology server. The search results can be verified from SNOMED CT browser by providing the same search term | |
5 | Repeat Steps 5 to 14 above for conditions search | The expected results should match the corresponding results for step 5 to 14 | |
As a user, I want to Validate that no new ID is created for the same saved Diagnosis term in OpenMRS, when more than 1 patient has been recorded with same diagnosis | 1 | Select a new patient and navigate to Diagnosis Tab | Diagnoses page should be displayed |
2 | Select and save the same diagnosis term that was saved in step#13 | Success message should be displayed | |
3 | Validate that the same diagnosis value is saved for this patient, meaning, no new concept ID is created for the existing diagnosis in OpenMRS | No new concept ID should be created if the existing concept is used to record patient data |
Test Scenario for Diagnosis Report By Gender
...
Test Description
...
Step No.
...
Step Description
...
Expected Results
As an end user, I want to test the E2E journey of Diagnosis Count Report for Asthma and Malaria, so that I can ensure the report is providing accurate count of diagnosis
Step No. | Step Description | Expected Results |
1 | Login to Bahmni application as user | User should be logged in |
2 | Navigate to report module and open report dashboard | The report dashboard should be displayed with list of different reports |
3 | Validate "Diagnosis Count Report for Malaria" and "Diagnosis Count Report for Asthma" are available in the list of reports | System should display the below 2 reports in the list |
4 | Select Start and End date from the calendar for "Diagnosis Count Report for Malaria" | The selected date should be displayed in given format ‘dd/mm/yyyy’ |
5 | For the format, click on HTML from the format drop down list | HTML should be selected as format for report |
6 | Clicks on "RUN NOW" button for the report | The report for diagnosis count of patients for Malaria should be displayed based total count of patients for each diagnosis |
7 | Verify that the generated report is displayed in a Tabular format, with Malaria as diagnosis and the total count | Report should be shown in tabular format with generated date and time and selected duration (start date to end date) with Malaria diagnosis and the count of patients |
8 | Verify that the generated report also has count based on Gender | The report for diagnosis count should include columns Male, Female, Other, Not disclosed, and Total |
9 | Verify that all the descendants of Malaria that are saved in OpenMRS are shown in the report in separate line item Below is the configuration which is found in https://github.com/Bahmni/default-config/blob/<BRANCH>/openmrs/apps/reports/reports.json "diagnosisCountMalaria": { | The verification of descendant output can be done with the help of given link, where we can cross verify the diagnosis https://browser.ihtsdotools.org/?perspective=full&conceptId1=8186001&edition=MAIN/2023-01-31&release=&languages=en |
10 | Check initial count of the Malaria diagnosis, then add the same malaria diagnosis for a new patient and re-run the report. | The total count of the Malaria diagnosis should be incremented by 1 |
11 | Select a patient, save diagnosis as 'heart block', goto the reports and run the diagnosis count report for Malaria | The total count of the Malaria diagnosis should remain the same |
12 | For validation for Diagnosis count report for Asthma, repeat steps 2 to 10 with below configuration Below is the configuration which is found in https://github.com/Bahmni/default-config/blob/<BRANCH>/openmrs/apps/reports/reports.json "diagnosisCountAsthma": { | |
13 |
| System should display error message |
Test Scenario for CDSS Alerts
As an end user, I want to test the functionality of all the types of CDSS alerts so that I can ensure the feature is working as expected
...
Test Scenario for Ordering Procedures
...
Test Description
...
Step No.
...
Step Description
...
Expected Results
As an end user, I want to test the functionality of SNOMED CT procedures for body-sites
...
Step No. | Step Description | Expected Results |
Configuration Setup | To upload the procedures in Bahmni application, follow the steps mention here | Procedures should be uploaded in Bahmni |
1 | Login to Bahmni application as user | User should be logged in |
2 | Navigate to clinical module and open an active patient | The patient dashboard should be displayed |
3 | Click on consultation button and then click on orders tab | Orders page should be displayed |
4 | In Orders Tab, click on Procedures on the left panel | List of body sites should be displayed |
5 | Select Head from the body site | System should display the list of SNOMED procedures for 'Head' |
6 | Select a procedure from the list | System should highlight the selected procedure |
7 | Click on Save | System should save the procedure in OpenMRS |
8 | Click on patient dashboard | The selected procedure should be displayed in the procedure card |
...
As an end user, I want to test the functionality of bulk FHIR export of patient data from Bahmni, so that I can ensure correct patient information is downloaded for further analytics and research
Step No. | Step Description | Expected Results |
Users and Roles setup
| Login to OpenMRS with below credentials | User should be logged in |
Navigate to Settings under Administration Tab | ||
Non-Anonymised
| System should save the role with the assigned privileges and create the user and assign the role to the user | |
Anonymised
| System should save the role with the assigned privileges and create the user and assign the role to the user | |
Non Export
| System should save the role with the assigned privileges and create the user and assign the role to the user | |
Configuration Setup | Login to OpenMRS with below credentials | User should be logged in |
Navigate to Settings under Administration Tab | ||
Under Settings, navigate to FHIR Link | System should display the global properties on the right hand side | |
Value of "Export Files Directory" should be set to /openmrs/data/fhirExports | ||
Set value of 'Export Anonymise Config Path' as /openmrs/data/fhir-export-anonymise |
-config.json | This configuration determines which attributes of the resources will be exported, redacted, randomized, etc | |
Click on Save button | System should save the configuration | |
Non-Anonymised FHIR Export of Patient Data | Login to |
Bahmni application as user | ||
Provide the below credentials | User should be logged in | |
Goto the Admin module and click on FHIR Export | System should display FHIR Export page, table is loaded by default for privileged users | |
The Start Date and End Date should be provided by default (End Date = Current Date, Start Date = 30 days prior) | ||
The 'Anonymise' check box should be selected by default and is editable | ||
Scenario 1: User does not provide start date and end date and 'Anonymise' check box is unchecked, and then clicks on Export button | System should display success message in the toast "Request submitted. Please click on 'Refresh' to check status of report | |
Click on the Refresh button to reload the table | An entry is created in a table with the below columns: | |
The status column in the table can have 3 values: Accepted, Completed, Rejected | ||
Status column displays accepted | Download column should be blank, as the system is still processing the export | |
Status column displays rejected | Download column should be blank, as the system could not process the request. User should contact administrator for support | |
Status column displays completed | Download link should be displayed in the download column | |
Click on Download link in the 'download' column | A zip file containing clinical and personal data of all the patients in Bahmni should get downloaded in the selected location (since no start date and end date is provided, system exports all the data) | |
Navigate to the location where the file is downloaded and unzip the file | Zip file should contain all, any, or none of the following NDJSON resources. The data should contain non-anonymised information, including personal identifiable information | |
Patient attributes NJDSON - resourceType, identifier, active, name, gender, birthDate, deceasedBoolean, deceasedDateTime, address Condition Attributes NDJSON - resourceType, clinicalStatus, category, code, subject, encounter, onsetDateTime, recordedDate, recorder Medication Attribute NDJSON - resourceType, status, intent, priority, medication, subject, encounter, authoredOn, requester, dosageInstruction, dispenseRequest.validityPeriod, dispenseRequest.numberOfRepeatsAllowed, dispenseRequest.quantity ServiceRequest Attribute NDJSON - resourceType, status, category, code, subject, encounter | ||
Scenario 2: User provides start date and end date and 'Anonymise' check box is not selected and clicks on Export | System should display success message in the toast "Request submitted. Please click on 'Refresh' to check status of report | |
Click on the Refresh button to reload the table | An entry is created in a table with the below columns: | |
Status column displays accepted | Download column should be blank, as the system is still processing the export | |
Status column displays rejected | Download column should be blank, as the system could not process the request. User should contact administrator for support | |
Status column displays completed | Download link should be displayed in the download column | |
Click on Download link in the 'download' column | A zip file containing clinical and/or personal data of the patients in Bahmni modified during the dates provided should get downloaded in the selected location | |
Zip file should contain all, any, or none of the following NDJSON resources. The data should contain non-anonymised information, including personal identifiable information | ||
Patient attributes NJDSON - resourceType, identifier, active, name, gender, birthDate, deceasedBoolean, deceasedDateTime, address Condition Attributes NDJSON - resourceType, clinicalStatus, category, code, subject, encounter, onsetDateTime, recordedDate, recorder Medication Attribute NDJSON - resourceType, status, intent, priority, medication, subject, encounter, authoredOn, requester, dosageInstruction, dispenseRequest.validityPeriod, dispenseRequest.numberOfRepeatsAllowed, dispenseRequest.quantity ServiceRequest Attribute NDJSON - resourceType, status, category, code, subject, encounter | ||
Provide start date > end date and click on 'Send' button | System should display error message "End date [yyyy-mm-dd] should be on or after start date [yyyy-mm-dd]" | |
Anonymised Bulk FHIR Export | Login to Bahmni application as user with below credentials | User should be logged in |
Goto the Admin module and click on FHIR Export | System should display FHIR Export page. Table is loaded by default for privileged users | |
The Start Date and End Date should be provided by default (End Date = Current Date, Start Date = 30 days prior) | ||
The 'Anonymise' check box should be selected by default and should be non-editable | ||
Click on the 'Export' button | System should display success message in the toast "Request submitted. Please click on 'Refresh' to check status of report | |
Click on the Refresh button to reload the table | An entry is created in a table with the below columns: | |
Status column displays accepted | Download column should be blank, as the system is still processing the export | |
Status column displays rejected | Download column should be blank, as the system could not process the request. User should contact administrator for support | |
Status column displays completed | Download link should be displayed in the download column | |
Click on Download link in the 'download' column | A zip file containing clinical and/or personal data of the patients in Bahmni modified during the dates provided should get downloaded in the selected location | |
Navigate to the location where the file is downloaded and unzip the file | Zip file should contain all, any, or none of the following NDJSON resources. The data should be anonymised, meaning, no personal identifiable information should be exported | |
Patient attributes NJDSON - resourceType, active, gender, birthDate (set to 1st January of the birth year), deceasedBoolean, deceasedDateTime (set to 1st January of the death year) Condition Attributes NDJSON - resourceType, clinicalStatus, category, code, subject (an obfuscated handle to correlate to patient), onsetDateTime Medication Attribute NDJSON - resourceType, status, intent, medication, subject (an obfuscated handle to correlate to patient), dispenseRequest.validityPeriod, dispenseRequest.numberOfRepeatsAllowed, dispenseRequest.quantity ServiceRequest Attribute NDJSON - resourceType, status, category, code, subject (an obfuscated handle to correlate to patient) | ||
Authorization error when exporting Non-Anonymised Data | Login to Bahmni application as user | User should be logged in |
Under Authorization, provide the below credentials | ||
Goto the Admin module and click on FHIR Export | System should display FHIR Export page | |
On the FHIR export page system should display a note "You do not have sufficient privilege to export data" | ||
User should not be able to take any action on the page. i.e., all the buttons are disabled, also table is not loaded for non-privileged users | ||
Audit Log | After the export of patient data, user navigates to Audit Log page | System displays the audit log page with the entries |
System should display an entry for the bulk fhir export with the following message: | ||
The other columns in the audit log should be: | ||
Viewing previously downloaded resources | Goto the Admin module and click on FHIR Export | System should display FHIR Export page |
System should display the list of previously triggered exports in the same table which is mentioned in above scenarios | ||
System should display the date and time of the export trigger along with the start date (if provided), end date (if provided), anonymised?, user, status, and the download column | ||
System should allow the users to download the previously exported files upon clicking the download link | ||
The previous download links will download the same file as it was used to download, when the link was most recent | ||
Anonymised Bulk FHIR Export - Random Value | Login to OpenMRS | User should be logged in |
Navigate to Settings under Administration Tab | ||
Under Settings, navigate to FHIR Link | System should display the global properties on the right hand side |
The configuration file inside OpenMRS container needs to be updated for the fields which needs a random value. The file is available at |
| System should save the configuration | |
Export patient data using FHIR Export module | The Patient JNDSON should display the Address and Contact attributes as random characters | |
All other attributes remain the same in Patient resource and in other resources | ||
Anonymised Bulk FHIR Export - Fixed Value | Login to OpenMRS | User should be logged in |
Navigate to Settings under Administration Tab | ||
Under Settings, navigate to FHIR Link | System should display the global properties on the right hand side |
The configuration file inside OpenMRS container needs to be updated for the fields which needs a fixed value. The file is available at |
| System should save the configuration | |
Export patient data using FHIR Export module | The Patient JNDSON should display the Address and Contact attributes as "fixedvalue" | |
All other attributes remain the same in Patient resource and other resources | ||
Anonymised Bulk FHIR Export - Redact | Login to OpenMRS | User should be logged in |
Navigate to Settings under Administration Tab | ||
Under Settings, navigate to FHIR Link | System should display the global properties on the right hand side | |
Value of "Export Anonymise Config Path" should be set to /openmrs/data/fhir-export-anonymise-config.json | System should save the configuration | |
Export patient data using FHIR Export module | The export happens with personal identifiable information of the patient removed from all the resources (Patient, condition, medication request, and service request) | |
All other attributes remain the same in all the resources |