Skip to content
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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

Omoshlawi
Copy link
Contributor

@Omoshlawi Omoshlawi commented Nov 18, 2024

Requirements

  • This PR has a title that briefly describes the work done, including the ticket number if there is a ticket.
  • My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
  • My work includes tests or is validated by existing tests.

Summary

As discused in slack and based

  • Added Configurable patient active conditions (Disabled by default)
  • Made patient Visit Diagnoses configurable (disabled by default)
  • Added extra patient information tab in vertical tab menu whose content is a slot allowing different implementors to plug in any extra information required
  • The tab is also configurable and disabled by default

Screenshots

patient-diagnoses-conditions-cmpressed.mp4

Related Issue

https://openmrs.atlassian.net/browse/O3-4206

Other

Copy link
Member

@mogoodrich mogoodrich left a 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')}</>
Copy link
Member

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?

Copy link
Contributor Author

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.

Screenshot 2024-11-19 at 09 06 25

@mogoodrich mogoodrich requested a review from ibacher November 18, 2024 17:20
@mogoodrich
Copy link
Member

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!

@denniskigen
Copy link
Member

@mogoodrich Ping @paulsonder @ciaranduffy

@Omoshlawi
Copy link
Contributor Author

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

@paulsonder
Copy link

@Omoshlawi I left some comments in the Jira ticket here.

@Omoshlawi Omoshlawi changed the title (feat)O3-4206-Add ability to view patient diagnoses alongside prescribed drugs and allergies (feat)O3-4206-Add ability to view patient diagnoses and active conditions Nov 25, 2024
Copy link
Member

@mogoodrich mogoodrich left a 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,
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

@ibacher ibacher left a 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 = {
Copy link
Member

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;
Copy link
Member

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;
Copy link
Member

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`;
Copy link
Member

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: {
Copy link
Member

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>
Copy link
Member

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})`}
Copy link
Member

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",
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants