-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(feat)O3-4206-Add ability to view patient diagnoses and active conditions #123
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much @Omoshlawi .... will generally defer to others on this, with some thoughts:
- Looks like this only displays the diagnoses records in the visit, which likely makes sense, but would be good for others to weigh in
- I don't love the way the diagnoses are displayed in the screen capture, but will defer to the UX team if we are following display standards correctly
- In my opinion, we should hide the diagnoses display if no diagnoses are found (instead of displaying "no diagnoses found")
I will add some others to the reviewers.
))} | ||
</> | ||
) : ( | ||
<>{t('noDiagnoses', 'No diagnoses found')}</> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would go with just displaying nothing at all if no diagnoses are found? This is would make it more somewhat more compatible with implementations that are not yet storing diagnoses using the "encounter diagnosis" module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @mogoodrich , fixed to display nothing if there are no diagnoses for the visit, for the UI I'll wait for the UX team output.
Are Paul and/or Ciaran on Github and can they be flagged here to review the UI? Otherwise, @Omoshlawi can you add the screen capture you collected to the linked ticket and flag them there for review? thanks! |
Okay, sure |
@Omoshlawi I left some comments in the Jira ticket here. |
This PR fixes warnings for `exhaustive-deps` and `rules-of-hooks` in the codebase flagged by the ESLint react hooks plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much, this is looking really good!
So I added one question/comment. Beyond that:
-
eventually we want to be able to pull in the conditions and diagnoses via a standard resource provided by core or the patient chart instead of having to recreate a resource in each app that we want to display conditions/diagnoses in, but I don't want to be a blocker in getting this merged in if we aren't there yet. Thoughts @ibacher @denniskigen ?
-
Also, overall, it would be good for someone else to get eyes on this with more O3 experience that me
showExtraPatientInformationSlot: { | ||
_type: Type.Boolean, | ||
_description: 'Enable or disable viewing of patient extra information slot diagnoses', | ||
_default: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense that rather than having a separate parameter for this we determine whether to display this based on "showDiagnosesFromVisit || showPatientConditions"? I guess the downside would be that someone couldn't separately enable this slot to just to insert there own extensions?
If we do keep it like this, we should make note in the "_descriptions" of the "showDiagnosesFromVisit" and "showPatientConditions" that this slot needs to be enabled in order for diagnoses/conditions to be visible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In all honesty, I don't like hiding extension slots behind some sort of configuration. Extension slots should just be rendered on the screen and content added to them according to the implementation config. I don't see any value (and I think it just makes the configuration more confusing) to to things like this. Please remove this option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more technical comments that what I've put on Slack.
import { Report } from '@carbon/react/icons'; | ||
import styles from './empty-state.scss'; | ||
|
||
type EmptyState = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need a whole component for this. Empty states should match the design of the thing that they are the empty state for. Generic empty states are only useful in contexts where we have many similar widgets.
display: flex; | ||
align-items: center; | ||
justify-content: space-between; | ||
row-gap: 1.5rem; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use Carbon spacing tokens for spacing in SCSS row-gap
, width
, etc.
width: 2rem; | ||
border-bottom: 0.375rem solid var(--brand-03); | ||
position: absolute; | ||
bottom: -0.75rem; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a hack. Why do we need this here?
|
||
export const usePatientConditions = (patientUuid: string) => { | ||
const { showPatientConditions } = useConfig<PharmacyConfig>(); | ||
const url = `${fhirBaseUrl}/Condition?patient=${patientUuid}&_count=100&_summary=data`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if there are more than 100? Shouldn't we have some sort of paging here?
_description: 'Enable or disable viewing of patient extra information slot diagnoses', | ||
_default: false, | ||
}, | ||
showPatientConditions: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also don't need configuration options where things are exposed as extensions. Please remove these.
</StructuredListHead> | ||
<StructuredListBody> | ||
{diagnoses.map(({ certainty, text }) => ( | ||
<StructuredListRow> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any time you call map()
in a React component, the component must have a key.
<StructuredListHead> | ||
<StructuredListRow head> | ||
<StructuredListCell head> | ||
{t('diagnoses', 'Diagnoses')} {`(${diagnoses.length})`} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is diagnoses.length
something that anyone asked for here? Why aren't we just using a data table or something?
@@ -19,6 +19,20 @@ | |||
"online": true, | |||
"offline": true | |||
}, | |||
{ | |||
"name": "patient-diagnoses", | |||
"slot": "extra-patient-information-slot", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These extensions should not be bound to any slot by default. That way, they are already able to be enabled or disabled by configuration.
"slot": "extra-patient-information-slot", | ||
"component": "patientDiagnoses", | ||
"online": true, | ||
"offline": true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I'd probably just leave offline
alone.
Requirements
Summary
As discused in slack and based
Screenshots
patient-diagnoses-conditions-cmpressed.mp4
Related Issue
https://openmrs.atlassian.net/browse/O3-4206
Other