Patient Updates Tab, Structured responses filter by Encounter #10329
Conversation
WalkthroughThe pull request introduces modifications across multiple components to enhance patient data handling and questionnaire response management. The key changes involve making the Changes
Possibly related PRs
Suggested Labels
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Deploying care-fe with
|
| Latest commit: |
7dc4d66
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://764238d5.care-fe.pages.dev |
| Branch Preview URL: | https://minor-fixes-questionnaire-pa.care-fe.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
src/components/Questionnaire/QuestionTypes/SymptomQuestion.tsx (1)
Line range hint
290-297: Consider adding error handling for the API call.While the encounter filtering is correctly implemented, the component could benefit from error handling for failed API calls to improve user experience.
Consider adding error handling:
const { data: patientSymptoms } = useQuery({ queryKey: ["symptoms", patientId], queryFn: query(symptomApi.listSymptoms, { pathParams: { patientId }, queryParams: { limit: 100, encounter: encounterId, }, }), + onError: (error) => { + // Handle error appropriately (e.g., show toast notification) + console.error('Failed to fetch symptoms:', error); + } });src/components/Questionnaire/QuestionTypes/MedicationRequestQuestion.tsx (3)
Line range hint
1-1000: Consider adding error handling for API failures.The component uses
useQueryfor data fetching but doesn't handle potential API failures that could occur when retrieving medication requests.Add error handling to gracefully handle API failures:
const { data: patientMedications } = useQuery({ queryKey: ["medication_requests", patientId], queryFn: query(medicationRequestApi.list, { pathParams: { patientId }, queryParams: { encounter: encounterId, limit: 100, }, }), + onError: (error) => { + // Handle error appropriately (e.g., show toast notification) + console.error('Failed to fetch medication requests:', error); + } });
Line range hint
94-102: Consider adding loading state handling.The component doesn't handle the loading state while fetching medication requests, which could lead to a jarring user experience.
Add loading state handling:
- const { data: patientMedications } = useQuery({ + const { data: patientMedications, isLoading } = useQuery({ queryKey: ["medication_requests", patientId], queryFn: query(medicationRequestApi.list, { pathParams: { patientId }, queryParams: { encounter: encounterId, limit: 100, }, }), }); + // Add loading indicator + if (isLoading) { + return <div>Loading medication requests...</div>; + }
Line range hint
104-112: Consider adding a cleanup function to the useEffect hook.The
useEffecthook updates the questionnaire response but doesn't clean up when the component unmounts.Add a cleanup function to prevent potential memory leaks:
useEffect(() => { + let isSubscribed = true; if (patientMedications?.results) { + if (isSubscribed) { updateQuestionnaireResponseCB( [{ type: "medication_request", value: patientMedications.results }], questionnaireResponse.question_id, ); + } } + return () => { + isSubscribed = false; + }; }, [patientMedications]);src/components/Questionnaire/QuestionTypes/QuestionInput.tsx (1)
118-161: Consider reducing repetition in encounterId checks.The current implementation repeats the encounterId check pattern multiple times. Consider extracting a helper function to reduce repetition.
+ const renderStructuredQuestion = ( + Component: React.ComponentType<any>, + props: any + ) => { + if (!encounterId) return null; + return <Component {...props} encounterId={encounterId} />; + }; case "structured": switch (question.structured_type) { case "medication_request": - if (encounterId) { - return ( - <MedicationRequestQuestion - {...commonProps} - encounterId={encounterId} - /> - ); - } - return null; + return renderStructuredQuestion(MedicationRequestQuestion, commonProps); case "medication_statement": - if (encounterId) { - return ( - <MedicationStatementQuestion - {...commonProps} - encounterId={encounterId} - /> - ); - } - return null; + return renderStructuredQuestion(MedicationStatementQuestion, commonProps);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx(2 hunks)src/components/Patient/PatientDetailsTab/index.tsx(2 hunks)src/components/Patient/PatientHome.tsx(1 hunks)src/components/Questionnaire/QuestionTypes/AllergyQuestion.tsx(3 hunks)src/components/Questionnaire/QuestionTypes/DiagnosisQuestion.tsx(3 hunks)src/components/Questionnaire/QuestionTypes/MedicationRequestQuestion.tsx(2 hunks)src/components/Questionnaire/QuestionTypes/MedicationStatementQuestion.tsx(3 hunks)src/components/Questionnaire/QuestionTypes/QuestionInput.tsx(1 hunks)src/components/Questionnaire/QuestionTypes/SymptomQuestion.tsx(3 hunks)src/pages/Encounters/tabs/EncounterUpdatesTab.tsx(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: cypress-run (1)
- GitHub Check: Cloudflare Pages: care-fe
🔇 Additional comments (16)
src/components/Questionnaire/QuestionTypes/SymptomQuestion.tsx (2)
50-50: LGTM! Interface change aligns with PR objectives.The addition of the required
encounterIdprop is well-typed and consistent with the component's purpose of filtering symptoms by encounter.
285-285: LGTM! Prop destructuring is consistent.The
encounterIdprop is correctly destructured and used within the component.src/components/Questionnaire/QuestionTypes/MedicationRequestQuestion.tsx (2)
81-81: LGTM! Interface update aligns with PR objectives.The addition of the
encounterIdprop toMedicationRequestQuestionPropsinterface correctly supports the requirement to filter structured responses by Encounter.Also applies to: 89-89
99-99: LGTM! Query parameter update correctly implements encounter filtering.The
encounterparameter is properly added to the query params, enabling filtering of medication requests by the specific encounter.src/components/Questionnaire/QuestionTypes/DiagnosisQuestion.tsx (3)
49-49: LGTM! Adding encounterId as a required prop.The addition of
encounterIdas a required string property aligns with the PR objective of filtering structured responses by encounter.
88-88: LGTM! Consistent parameter addition.The
encounterIdparameter is correctly added and destructured from props.
101-101: Verify consistent encounter filtering across components.The encounter filtering is correctly implemented. Let's verify that this pattern is consistently applied across other similar components.
✅ Verification successful
Encounter filtering is consistently implemented across components
The
encounterparameter is correctly and consistently used across all medical record components (DiagnosisQuestion, SymptomQuestion, MedicationRequestQuestion, MedicationStatementQuestion, and AllergyQuestion) with the same parameter name and filtering pattern.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if other question components implement encounter filtering similarly # Search for other question components using encounter in queries echo "Checking other question components for encounter filtering..." rg -l "encounter.*queryParams" "src/components/Questionnaire/QuestionTypes/" # Check the specific usage pattern echo -e "\nChecking the specific usage pattern..." ast-grep --pattern 'useQuery({ $$$ queryParams: { $$$ encounter: $_, $$$ } $$$ })'Length of output: 408
Script:
#!/bin/bash # First, list all question type components echo "Files in QuestionTypes directory:" fd . "src/components/Questionnaire/QuestionTypes/" -e tsx # Search for useQuery patterns with broader context echo -e "\nSearching for useQuery patterns:" rg "useQuery.*queryParams" "src/components/Questionnaire/QuestionTypes/" -B 2 -A 5 # Search for any encounter-related patterns echo -e "\nSearching for encounter-related patterns:" rg "encounter" "src/components/Questionnaire/QuestionTypes/" -B 2 -A 2Length of output: 39058
src/components/Patient/PatientDetailsTab/index.tsx (1)
70-70: Verify required props for QuestionnaireResponsesList.The QuestionnaireResponsesList component requires a
patientIdprop, but it's not clear how this prop is being passed when used in the tab configuration.✅ Verification successful
Props are correctly passed to QuestionnaireResponsesList through PatientHome component
The QuestionnaireResponsesList component receives its required
patientIdprop from the PatientHome component, which fetches and provides the patient data. The props are implicitly passed through the tab rendering system.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for the parent component that renders these tabs to verify prop passing ast-grep --pattern 'function $_(props: PatientProps) { $$$ facilityPatientTabs $$$ }'Length of output: 93
Script:
#!/bin/bash # Find QuestionnaireResponsesList component definition ast-grep --pattern 'interface $QuestionnaireResponsesListProps { $$$ }' # Find the component definition ast-grep --pattern 'const QuestionnaireResponsesList = ($props: $_) => { $$$ }' # Find where it's used in tab configurations rg -l "QuestionnaireResponsesList" --type typescriptLength of output: 247
Script:
#!/bin/bash # Find files containing QuestionnaireResponsesList rg -l "QuestionnaireResponsesList" -g "*.ts" -g "*.tsx" # Show content around QuestionnaireResponsesList occurrences rg -C 5 "QuestionnaireResponsesList" -g "*.ts" -g "*.tsx" # Try a more flexible pattern for component definition ast-grep --pattern 'QuestionnaireResponsesList'Length of output: 5163
Script:
#!/bin/bash # Get the full content of PatientDetailsTab/index.tsx to understand tab rendering cat src/components/Patient/PatientDetailsTab/index.tsx # Search for any TabPanel or similar component that might be rendering these tabs rg -C 5 "TabPanel|renderTab" -g "*.tsx"Length of output: 1966
Script:
#!/bin/bash # Find files importing the tab configurations rg -C 5 "import.*patientTabs|import.*facilityPatientTabs" -g "*.tsx" # Find where these tab arrays are used rg -C 10 "facilityPatientTabs|patientTabs" -g "*.tsx" --no-filenameLength of output: 6681
src/pages/Encounters/tabs/EncounterUpdatesTab.tsx (1)
49-52: LGTM! Props are correctly passed.The implementation properly passes both
encounterandpatientIdprops to the QuestionnaireResponsesList component, enabling proper filtering of responses.src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx (1)
17-18: LGTM! Props and API integration are well implemented.The changes make the component more flexible by:
- Making the encounter prop optional while requiring patientId
- Correctly handling the optional encounter in the API query parameters
Also applies to: 128-131, 138-141
src/components/Questionnaire/QuestionTypes/QuestionInput.tsx (1)
118-161: LGTM! Added safety checks for encounterId.The implementation correctly ensures that structured questions are only rendered when encounterId is available, preventing potential runtime errors.
src/components/Patient/PatientHome.tsx (1)
138-138: LGTM!The
patientIdprop is correctly passed to theTabcomponent, enabling proper patient context in child components.src/components/Questionnaire/QuestionTypes/MedicationStatementQuestion.tsx (2)
64-64: LGTM!The
encounterIdprop is correctly added to theMedicationStatementQuestionPropsinterface.
94-94: LGTM!The
encounterIdis correctly destructured from props and properly used in the query parameters to filter medication statements by encounter.Also applies to: 115-115
src/components/Questionnaire/QuestionTypes/AllergyQuestion.tsx (2)
64-64: LGTM!The
encounterIdprop is correctly added to theAllergyQuestionPropsinterface.
120-120: LGTM!The
encounterIdis correctly destructured from props and properly used in the query parameters to filter allergies by encounter.Also applies to: 131-131
CARE
|
||||||||||||||||||||||||||||
| Project |
CARE
|
| Branch Review |
minor-fixes-questionnaire-patient
|
| Run status |
|
| Run duration | 06m 13s |
| Commit |
|
| Committer | Amjith Titus |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
0
|
Pending
|
0
|
Skipped
|
0
|
Passing
|
10
|
| View all changes introduced in this branch ↗︎ | |
src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx
Show resolved
Hide resolved
|
…nsesList.tsx Co-authored-by: Rithvik Nishad <[email protected]>
…minor-fixes-questionnaire-patient
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/components/Questionnaire/QuestionTypes/QuestionInput.tsx(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: cypress-run (1)
- GitHub Check: Cloudflare Pages: care-fe
🔇 Additional comments (2)
src/components/Questionnaire/QuestionTypes/QuestionInput.tsx (2)
118-156: LGTM! Consistent conditional rendering pattern.The conditional rendering pattern for structured questions is well-implemented:
- Each structured question component is rendered only when
encounterIdis provided- The
encounterIdprop is correctly passed to each component- The pattern is consistently applied across medication requests, medication statements, symptoms, and diagnoses
This change ensures that structured responses are properly filtered by encounter.
140-149: Verify the necessity of patientId prop.The
SymptomQuestioncomponent receives bothencounterIdandpatientIdprops, while other structured question components only receiveencounterId. This inconsistency might indicate:
- Other components might need
patientIdfor proper filteringSymptomQuestionmight not needpatientIdif the encounter context is sufficientLet's analyze the usage of these props in the components:
✅ Verification successful
The patientId prop is necessary and correctly implemented
The
patientIdprop is required inSymptomQuestionas it's used to fetch patient-specific symptoms via the API. This follows a consistent pattern across all medical-related question components (Symptoms, Diagnoses, Medications) where bothpatientIdandencounterIdare used for proper data filtering.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check how patientId and encounterId are used in structured question components # Search for patientId usage in SymptomQuestion echo "Checking patientId usage in SymptomQuestion:" rg -A 5 "patientId.*SymptomQuestion" || echo "No matches found" # Search for useQuery hooks in structured question components to compare filtering patterns echo -e "\nChecking query patterns in structured components:" ast-grep --pattern 'useQuery($_, { $$ })'Length of output: 339
Script:
#!/bin/bash # Find SymptomQuestion component and other question components echo "Locating SymptomQuestion component:" fd "SymptomQuestion" --type f echo -e "\nChecking SymptomQuestion implementation:" rg -A 10 "SymptomQuestion.*=.*{" || rg -A 10 "class SymptomQuestion" echo -e "\nFinding other question components:" fd "Question" --type f echo -e "\nChecking patientId usage in all components:" rg "patientId.*props" || rg "props.*patientId"Length of output: 3040
Script:
#!/bin/bash # Check implementations of medical-related question components echo "SymptomQuestion implementation:" cat src/components/Questionnaire/QuestionTypes/SymptomQuestion.tsx || echo "File not found" echo -e "\nChecking similar components:" echo "DiagnosisQuestion:" cat src/components/Questionnaire/QuestionTypes/DiagnosisQuestion.tsx || echo "File not found" echo -e "\nMedicationRequestQuestion:" cat src/components/Questionnaire/QuestionTypes/MedicationRequestQuestion.tsx || echo "File not found" echo -e "\nSearching for API calls in these components:" rg "useQuery|useMutation" src/components/Questionnaire/QuestionTypes/Length of output: 57606
|
|
|
LGTM |
nihal467
added
tested
reviewed
|
change the date to DD/mm/yyyy format |
…m/ohcnetwork/care_fe into minor-fixes-questionnaire-patient
…minor-fixes-questionnaire-patient
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx (2)
18-35: LGTM! Consider adding JSDoc comments.The Props and QuestionResponseProps interfaces are well-structured and provide good type safety. The optional encounter prop aligns with the PR objectives for filtering responses.
Consider adding JSDoc comments to document the purpose of these interfaces and their properties, especially for complex types like QuestionResponseProps.
141-167: Consider extracting color mapping to a constant.The StructuredResponseBadge component is well-implemented, but the colors object could be moved outside the component to prevent recreation on each render.
+const RESPONSE_TYPE_COLORS = { + symptom: "bg-yellow-100 text-yellow-800", + diagnosis: "bg-blue-100 text-blue-800", + medication_request: "bg-green-100 text-green-800", + medication_statement: "bg-purple-100 text-purple-800", + follow_up_appointment: "bg-pink-100 text-pink-800", +} as const; function StructuredResponseBadge({ type, submitType, }: { type: string; submitType: string; }) { - const colors = { - symptom: "bg-yellow-100 text-yellow-800", - diagnosis: "bg-blue-100 text-blue-800", - medication_request: "bg-green-100 text-green-800", - medication_statement: "bg-purple-100 text-purple-800", - follow_up_appointment: "bg-pink-100 text-pink-800", - }; return ( <Badge variant="outline" className={`${ - colors[type as keyof typeof colors] || "bg-gray-100 text-gray-800" + RESPONSE_TYPE_COLORS[type as keyof typeof RESPONSE_TYPE_COLORS] || "bg-gray-100 text-gray-800" } border-none`} >
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: cypress-run (1)
- GitHub Check: Cloudflare Pages: care-fe
🔇 Additional comments (4)
src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx (4)
37-50: LGTM! Comprehensive type handling.The formatValue function properly handles all value types and consistently returns strings.
169-237: LGTM! Well-structured response card implementation.The ResponseCard component effectively handles both structured and non-structured responses with proper type checking and conditional rendering.
Line range hint
239-283: LGTM! Clean implementation of encounter filtering.The QuestionnaireResponsesList component properly handles optional encounter filtering and pagination, aligning with the PR objectives.
249-252: Verify encounter-specific allergies filtering.Based on the PR comments, there are reports of allergies being shared between encounters. Let's verify the filtering logic:
✅ Verification successful
Encounter-specific allergy filtering is correctly implemented
The implementation properly maintains encounter-specific allergies through:
- Encounter ID filtering in questionnaire responses
- Proper association of allergies with encounters in the data model
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for allergy-related questionnaire responses and their encounter filtering # Search for allergy-related structured responses rg -A 5 "structured_responses.*allerg" # Search for allergy filtering logic in the codebase rg -A 5 "encounter.*allerg"Length of output: 1084
Script:
#!/bin/bash # Check complete implementation of allergy handling # Get AllergyQuestion component implementation ast-grep --pattern 'export function AllergyQuestion($_) { $$$ }' # Check questionnaire response filtering implementation ast-grep --pattern 'function $_($_) { $$$ questionnaire$_ $$$ }' # Look for allergy filtering logic rg -A 10 "filterQuestionnaireResponses|filterAllerg"Length of output: 35557
|
LGTM |
|
👋 Hi, @amjithtitus09, |
…minor-fixes-questionnaire-patient
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx (1)
283-286: Consider using optional chaining for cleaner code.The encounter ID inclusion in query parameters could be written more elegantly.
- ...(encounter && { encounter: encounter.id }), + encounter: encounter?.id,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (58)
public/locale/en.json(1 hunks)src/components/Common/Charts/ObservationChart.tsx(2 hunks)src/components/Common/Charts/ObservationHistoryTable.tsx(2 hunks)src/components/Common/ComboboxQuantityInput.tsx(1 hunks)src/components/Common/SearchByMultipleFields.tsx(1 hunks)src/components/Encounter/CreateEncounterForm.tsx(1 hunks)src/components/Facility/ConsultationDetails/ObservationsList.tsx(4 hunks)src/components/Facility/ConsultationDetails/QuestionnaireResponseView.tsx(3 hunks)src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx(4 hunks)src/components/Facility/FacilityForm.tsx(1 hunks)src/components/Facility/FacilityHome.tsx(1 hunks)src/components/Medicine/MedicationRequestTable/index.tsx(2 hunks)src/components/Medicine/MedicationsTable.tsx(1 hunks)src/components/Patient/LinkDepartmentsSheet.tsx(2 hunks)src/components/Patient/MedicationStatementList.tsx(1 hunks)src/components/Patient/PatientDetailsTab/Appointments.tsx(2 hunks)src/components/Patient/PatientDetailsTab/Demography.tsx(2 hunks)src/components/Patient/PatientDetailsTab/EncounterHistory.tsx(2 hunks)src/components/Patient/PatientDetailsTab/HealthProfileSummary.tsx(2 hunks)src/components/Patient/PatientDetailsTab/PatientUsers.tsx(2 hunks)src/components/Patient/PatientDetailsTab/ResourceRequests.tsx(1 hunks)src/components/Patient/PatientDetailsTab/index.tsx(3 hunks)src/components/Patient/PatientDetailsTab/patientUpdates.tsx(4 hunks)src/components/Patient/PatientHome.tsx(1 hunks)src/components/Patient/PatientIndex.tsx(2 hunks)src/components/Patient/PatientInfoCard.tsx(5 hunks)src/components/Patient/allergy/AllergyTable.tsx(1 hunks)src/components/Patient/allergy/list.tsx(1 hunks)src/components/Patient/diagnosis/list.tsx(1 hunks)src/components/Patient/symptoms/list.tsx(1 hunks)src/components/Questionnaire/CloneQuestionnaireSheet.tsx(2 hunks)src/components/Questionnaire/ManageQuestionnaireOrganizationsSheet.tsx(2 hunks)src/components/Questionnaire/ManageQuestionnaireTagsSheet.tsx(1 hunks)src/components/Questionnaire/QuestionTypes/AppointmentQuestion.tsx(1 hunks)src/components/Questionnaire/QuestionTypes/DateTimeQuestion.tsx(1 hunks)src/components/Questionnaire/QuestionTypes/QuestionGroup.tsx(1 hunks)src/components/Questionnaire/QuestionnaireEditor.tsx(7 hunks)src/components/Questionnaire/QuestionnaireForm.tsx(2 hunks)src/components/Questionnaire/QuestionnaireSearch.tsx(2 hunks)src/components/Resource/ResourceCreate.tsx(3 hunks)src/components/Resource/ResourceDetails.tsx(7 hunks)src/components/ui/chart.tsx(1 hunks)src/components/ui/date-picker.tsx(1 hunks)src/components/ui/date-range-picker.tsx(1 hunks)src/components/ui/date-time-picker.tsx(1 hunks)src/components/ui/textarea.tsx(1 hunks)src/pages/Encounters/EncounterList.tsx(1 hunks)src/pages/Encounters/PrintPrescription.tsx(2 hunks)src/pages/Facility/FacilitiesPage.tsx(1 hunks)src/pages/Facility/FacilityDetailsPage.tsx(1 hunks)src/pages/Facility/components/FacilityCard.tsx(1 hunks)src/pages/Facility/components/UserCard.tsx(1 hunks)src/pages/Facility/settings/organizations/FacilityOrganizationIndex.tsx(1 hunks)src/pages/Organization/OrganizationIndex.tsx(1 hunks)src/pages/Patients/VerifyPatient.tsx(2 hunks)src/pages/PublicAppointments/PatientSelect.tsx(1 hunks)src/pages/PublicAppointments/Schedule.tsx(1 hunks)src/pages/UserDashboard.tsx(3 hunks)
✅ Files skipped from review due to trivial changes (43)
- src/components/Patient/MedicationStatementList.tsx
- src/pages/PublicAppointments/PatientSelect.tsx
- src/pages/Facility/FacilitiesPage.tsx
- src/components/Questionnaire/QuestionnaireForm.tsx
- src/components/Facility/ConsultationDetails/ObservationsList.tsx
- src/components/ui/date-range-picker.tsx
- src/pages/Facility/components/FacilityCard.tsx
- src/pages/Facility/components/UserCard.tsx
- src/pages/Encounters/EncounterList.tsx
- src/components/Common/Charts/ObservationHistoryTable.tsx
- src/components/Questionnaire/QuestionTypes/AppointmentQuestion.tsx
- src/pages/Facility/settings/organizations/FacilityOrganizationIndex.tsx
- src/components/ui/date-time-picker.tsx
- src/components/ui/date-picker.tsx
- src/components/Common/ComboboxQuantityInput.tsx
- src/components/Patient/LinkDepartmentsSheet.tsx
- src/components/Resource/ResourceDetails.tsx
- src/components/Patient/PatientInfoCard.tsx
- src/components/Patient/allergy/AllergyTable.tsx
- src/components/Facility/FacilityHome.tsx
- src/components/Questionnaire/CloneQuestionnaireSheet.tsx
- src/components/Questionnaire/QuestionnaireSearch.tsx
- src/components/Medicine/MedicationsTable.tsx
- src/pages/PublicAppointments/Schedule.tsx
- src/components/Questionnaire/QuestionTypes/QuestionGroup.tsx
- src/components/Questionnaire/ManageQuestionnaireTagsSheet.tsx
- src/components/ui/textarea.tsx
- src/components/Facility/ConsultationDetails/QuestionnaireResponseView.tsx
- src/components/Questionnaire/QuestionnaireEditor.tsx
- src/components/Encounter/CreateEncounterForm.tsx
- src/components/ui/chart.tsx
- src/components/Common/Charts/ObservationChart.tsx
- src/pages/Organization/OrganizationIndex.tsx
- src/components/Facility/FacilityForm.tsx
- src/pages/Facility/FacilityDetailsPage.tsx
- src/components/Patient/PatientIndex.tsx
- src/pages/Encounters/PrintPrescription.tsx
- src/pages/UserDashboard.tsx
- src/components/Common/SearchByMultipleFields.tsx
- src/components/Resource/ResourceCreate.tsx
- src/components/Questionnaire/QuestionTypes/DateTimeQuestion.tsx
- src/components/Questionnaire/ManageQuestionnaireOrganizationsSheet.tsx
- src/pages/Patients/VerifyPatient.tsx
🚧 Files skipped from review as they are similar to previous changes (4)
- src/components/Patient/PatientHome.tsx
- src/components/Patient/allergy/list.tsx
- src/components/Patient/diagnosis/list.tsx
- src/components/Patient/symptoms/list.tsx
🔇 Additional comments (15)
src/components/Patient/PatientDetailsTab/HealthProfileSummary.tsx (1)
25-25:⚠️ Potential issueAdd encounterId prop to filter data by encounter.
Based on the PR objectives and reported issues, allergies and other health data are being shared between encounters. Consider adding an
encounterIdprop to filter the data appropriately.Apply this diff to add encounter filtering:
- <MedicationStatementList patientId={patientId} /> + <MedicationStatementList patientId={patientId} encounterId={encounterId} /> - <AllergyList patientId={patientId} /> + <AllergyList patientId={patientId} encounterId={encounterId} /> - <SymptomsList patientId={patientId} /> + <SymptomsList patientId={patientId} encounterId={encounterId} /> - <DiagnosisList patientId={patientId} /> + <DiagnosisList patientId={patientId} encounterId={encounterId} />Also applies to: 29-29, 33-33, 37-37
src/components/Patient/PatientDetailsTab/EncounterHistory.tsx (1)
17-17: LGTM! Property renaming is consistent.The changes correctly update the property name from
idtopatientIdacross props and query parameters.Also applies to: 24-24, 40-40
src/components/Patient/PatientDetailsTab/patientUpdates.tsx (1)
Line range hint
57-85: Prevent duplicate cards for structured questions.Based on PR comments, multiple cards are being created for each structured question. Consider grouping responses by questionnaire to prevent duplication.
Additionally, add encounter filtering to ensure responses are properly scoped:
<PaginatedList route={routes.getQuestionnaireResponses} - pathParams={{ patientId }} + pathParams={{ patientId, encounterId }} >src/components/Patient/PatientDetailsTab/ResourceRequests.tsx (1)
32-38: Consider adding encounter context to resource requests.While the property renaming is correct, consider whether resource requests should be filtered by encounter to maintain data isolation between encounters.
src/components/Patient/PatientDetailsTab/index.tsx (2)
1-1: LGTM! Import of QuestionnaireResponsesList aligns with PR objectives.The addition of QuestionnaireResponsesList component supports the enhancement of the Patient Updates tab.
70-70: Verify the component replacement impact.The replacement of Updates with QuestionnaireResponsesList in facilityPatientTabs is a significant change. Please ensure that:
- All required props are passed correctly
- The component handles the same use cases as the previous Updates component
✅ Verification successful
Component replacement is appropriate and safe ✅
The QuestionnaireResponsesList component is a suitable replacement for Updates as it:
- Uses the same data source and API endpoint
- Accepts the required props (patientId)
- Provides enhanced functionality with more detailed response displays
- Maintains core features while adding improved structured response handling
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the Updates component usage and props # Check for any remaining references to the old Updates component rg -l "Updates" --type ts --type tsx # Check QuestionnaireResponsesList props and usage ast-grep --pattern 'QuestionnaireResponsesList $$$'Length of output: 118
Script:
#!/bin/bash # Add tsx support and search for both components rg --type-add 'tsx:*.{tsx,ts}' -l 'Updates|QuestionnaireResponsesList' --type tsx # Find component definitions and props ast-grep --pattern 'interface $_{Props|Properties} { $$$ }' # Find component usage patterns ast-grep --pattern '<QuestionnaireResponsesList $$$ />' # Find imports of both components rg --type-add 'tsx:*.{tsx,ts}' '^import.*(?:Updates|QuestionnaireResponsesList).*from' --type tsxLength of output: 1568
Script:
#!/bin/bash # Get QuestionnaireResponsesList implementation cat src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx # Get Updates component implementation cat src/components/Patient/PatientDetailsTab/patientUpdates.tsx # Find any related types or interfaces rg --type-add 'tsx:*.{tsx,ts}' -A 5 'interface.*(?:Updates|QuestionnaireResponses)' --type tsxLength of output: 13670
src/components/Patient/PatientDetailsTab/Appointments.tsx (2)
26-26: LGTM! Consistent prop and query parameter updates.The changes maintain consistency in using patientId throughout the component.
Also applies to: 30-33
68-68: LGTM! Link href updated correctly.The appointment booking link correctly uses the new patientId prop.
src/components/Patient/PatientDetailsTab/Demography.tsx (1)
23-23: LGTM! Navigation paths updated consistently.The changes maintain consistency in using patientId for navigation paths.
Also applies to: 42-45
src/components/Patient/PatientDetailsTab/PatientUsers.tsx (2)
206-206: LGTM! API interactions updated consistently.The changes maintain consistency in using patientId for API interactions and query invalidation.
Also applies to: 210-212, 219-224
316-316: LGTM! AddUserSheet component updated correctly.The AddUserSheet component correctly receives the new patientId prop.
src/components/Medicine/MedicationRequestTable/index.tsx (1)
65-65: LGTM! Consistent color scheme updates.The color class changes from
text-muted-foregroundtotext-gray-500maintain visual consistency across the application.Also applies to: 71-71, 108-108, 114-114, 120-120
src/components/Facility/ConsultationDetails/QuestionnaireResponsesList.tsx (3)
25-26: LGTM! Props interface update aligns with requirements.Making
encounteroptional and adding requiredpatientIdimproves component flexibility and aligns with the PR objective of filtering structured responses by encounter.
29-54: LGTM! Enhanced type safety with comprehensive type definitions.The new
ResponseValueTypeandQuestionResponsePropsinterfaces provide better type safety and clearer contract for response handling.
56-80: LGTM! Improved value formatting with type safety.The enhanced
formatValuefunction now properly handles various response value types with proper type checking.
| @@ -1047,6 +1047,7 @@ | |||
| "has_domestic_healthcare_support": "Has domestic healthcare support?", | |||
| "has_sari": "Has SARI (Severe Acute Respiratory illness)?", | |||
| "health-profile": "Health Profile", | |||
| "health_profile": "Health Profile", | |||
There was a problem hiding this comment.
💡 Codebase verification
Remove unused health-profile translation key
The health-profile key exists in translation files but isn't used anywhere in the codebase. The new health_profile key is actively used in HealthProfileSummary.tsx. Please remove the unused health-profile key from the locale files.
- Remove
"health-profile"frompublic/locale/en.json - Remove
"health-profile"frompublic/locale/ml.json
🔗 Analysis chain
Verify the need for duplicate health profile translation keys.
The new key health_profile seems redundant with the existing health-profile key. Please verify if both keys are necessary or if we should standardize on one format.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check usage of both health profile translation keys
echo "Checking usage of 'health-profile' key:"
rg "t\([\"']health-profile[\"']\)" -A 2
echo -e "\nChecking usage of 'health_profile' key:"
rg "t\([\"']health_profile[\"']\)" -A 2
Length of output: 557
Script:
#!/bin/bash
# Check if health-profile key exists in locale files
echo "Checking for 'health-profile' in locale files:"
rg '"health-profile"' public/locale/
Length of output: 267
|
@amjithtitus09 Your efforts have helped advance digital healthcare and TeleICU systems. 🚀 Thank you for taking the time out to make CARE better. We hope you continue to innovate and contribute; your impact is immense! 🙌 |
@ohcnetwork/care-fe-code-reviewers
Merge Checklist
Summary by CodeRabbit
Release Notes
New Features
patientIdprop to improve data context in patient-related views.Improvements
The updates provide more granular and context-aware data handling across patient and encounter-related components.