BN-75 | Display Diagnosis on the patient dashboard #26
Conversation
…s display control
… Diagnoses control
| sections.forEach((section) => { | ||
| if (!sectionRefs.current[section.id]) { | ||
| sectionRefs.current[section.id] = React.createRef<HTMLDivElement>(); | ||
| if (!sectionRefs.current[section.name]) { |
There was a problem hiding this comment.
@devsingh05298,
It appears that the sidenav scroll is broken following the changes introduced in this commit. Could you please re-test and verify if these modifications were intentional?
If the changes do not serve a specific purpose, kindly revert them. However, if they are required, please revise the implementation to ensure that the existing scroll behavior remains unaffected.
|
|
||
| //TODO: Refactor this to depend on Controls configuration | ||
| const renderSectionContent = (section: DashboardSectionConfig) => { | ||
| if (section.controls && section.controls.length > 0) { |
There was a problem hiding this comment.
@devsingh05298 There's a redundant fallback switch on section.name if section.controls is absent, which duplicates logic.
Impact: Creates dual sources of truth for rendering controls.
| <div> | ||
| {dateGroup.diagnoses.map((diagnosis, diagnosisIndex) => ( | ||
| <DiagnosisItem | ||
| key={diagnosis.id || diagnosisIndex} |
There was a problem hiding this comment.
Lack of Unique key for DiagnosisItem
Fallback to diagnosisIndex when diagnosis.id is missing could lead to rendering issues if the list updates dynamically. Each diagnosis should ideally have a stable, unique identifier.
| <div> | ||
| <strong>{diagnosis.display}</strong>{' '} | ||
| <Tag type={getTagType(diagnosis.certainty)} style={{marginLeft: '8px'}}> | ||
| {t(`CERTAINITY_${diagnosis.certainty.toUpperCase()}`)} |
There was a problem hiding this comment.
The translation key prefix CERTAINITY_ appears misspelled; it should likely be CERTAINTY_. Please do fix this.
| }; | ||
|
|
||
| return ( | ||
| <Table size="sm" useZebraStyles={false}> |
There was a problem hiding this comment.
Rendering a full <Table> and <TableBody> per individual diagnosis item is inefficient and semantically incorrect. Typically, one <Table> should wrap multiple <TableRow>s, not be created repeatedly for each row. This can cause layout and accessibility issues.
There was a problem hiding this comment.
Please rename the test file as "*.snapshot.test.tsx" for consistency.
There was a problem hiding this comment.
Hardcoded Color Values Instead of Tokens: Colors like #ffffff, #f4f4f4, #e0e0e0, and #161616 are hardcoded instead of using Carbon's design tokens (e.g., $layer-01, $text-primary). This reduces theme compatibility and visual consistency across the app. Refer: https://carbondesignsystem.com/elements/color/tokens/
Lack of Responsive Styling: No media queries or responsive considerations are present. Fixed widths (180px, 200px) and lack of flex-basis control can cause layout issues on smaller screens. Refer: https://carbondesignsystem.com/elements/spacing/overview/
There was a problem hiding this comment.
Could we consider reusing the existing approach of loading controls by name to maintain compatibility, rather than introducing a new method midway through the implementation?
| /** | ||
| * Interface for FHIR Condition resource specific to diagnoses | ||
| */ | ||
| export interface FhirDiagnosis { |
There was a problem hiding this comment.
It is better not to define a new type for fhir, please use import { Condition } from 'fhir/r4'; instead.
| ) : ( | ||
| <> | ||
| {/* Table Header */} | ||
| <div className={styles.tableHeader}> |
There was a problem hiding this comment.
Instead of relying on <div> and <span>, consider using the Grid and Column components from the Carbon Design System. This ensures better responsiveness and aligns the implementation with Carbon’s design principles.
|
Closing the PR as the changes added are already addressed in #30. |
JIRA → BN-75
Description
As a healthcare provider, I want to view diagnoses for a patient on the patient dashboard, so that I can provide appropriate care based on their current diagnoses and historical conditions.
This story involves implementing a diagnoses display control on the patient dashboard that presents all recorded patient diagnoses in a clear, organized table format. The display control should show relevant details including diagnosis date, certainty and the user who added the diagnoses. This will enable healthcare providers to quickly assess a patient's medical history and current health status during care.
Key Features
Implementation Details
UI Components
Diagnoses Item and Diagnoses Control is added as a Display control
State Management
Custom Hooks
Hooks - useDiagnoses for fetching Diagnoses information
API Integration
API used - https://localhost/openmrs/ws/fhir2/R4/Condition?category=encounter-diagnosis&patient=deac8976-2ef5-4549-b72b-56c92416e5c6
Internationalisation
Accessibility
Testing & Type Definitions
Unit Tests
Integration Tests
Type Definitions
Screenshots