(feat) Retrieve scheduled appointments in clinical forms workspace by jnsereko · Pull Request #471 · openmrs/openmrs-esm-form-engine-lib

jnsereko · 2025-02-27T08:43:35Z

Requirements

This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
My work includes tests or is validated by existing tests.

Summary

This PR adds ability to

preview scheduled appointments in the appointments workspace back to the clinical form
adds the current encounter to the appointment created with the clinical form
previews recent appointments associated to a specific encounter.

Requirements

cc-ing @vasharma05 @pirupius @ibacher @denniskigen

Screenshots

Screen.Recording.2025-02-27.at.16.10.27.mov

Related Issue

[should be created]

Other

pirupius · 2025-02-27T09:59:44Z

@jnsereko please update the description and add some screenshots or video to provide more context for the reviewers

pirupius · 2025-02-27T15:57:25Z

The CI seems run endlessly so i've cancelled it

denniskigen · 2025-02-28T06:30:17Z

src/types/domain.ts

+  appointmentKind: string;
+  appointmentNumber: string;
+  comments: string;
+  endDateTime: Date | number;


It looks like this property is a Date on the backend. Why are we typing it as Date | number?

Actually, it returns the number, neither the ISO string, nor a Date object

denniskigen · 2025-02-28T06:34:37Z

src/api/index.ts

+  const filteredAppointments = appointments.filter((appointment) => {
+    return !appointment.fulfillingEncounters.includes(encounterUuid);
+  });
+  return filteredAppointments.map((appointment) => {
+    return updateAppointment(url, appointment, encounterUuid, abortController);
+  });


nit: This code would be more concise and easier to read without the explicit return statements

denniskigen · 2025-02-28T06:35:58Z

src/api/index.ts

+    appointmentKind: appointment.appointmentKind,
+    status: appointment.status,
+    startDateTime: appointment.startDateTime,
+    endDateTime: appointment.endDateTime.toString(),


Why do we need toString() here? If it's a timestamp, isn't it preferable to convert it to a date string using something like toIsoString or a dayjs utility function instead?

denniskigen · 2025-02-28T06:36:51Z

src/api/index.ts

+    uuid: appointment.uuid
+  };
+
+  return openmrsFetch(`${url}`, {


Suggested change

return openmrsFetch(`${url}`, {

return openmrsFetch(url, {

denniskigen · 2025-02-28T06:38:44Z

src/api/index.ts

+export const getPatientAppointment = (appointmentUuid: string) => {
+  return openmrsFetch(
+    `${restBaseUrl}/appointments/${appointmentUuid}`,
+  ).then(({ data }) => {
+    if (data) {
+      return data;
+    }
+    return null;
+  });
+};


Would it be useful to have some kind of error handling here? Something along the lines of:

Suggested change

export const getPatientAppointment = (appointmentUuid: string) => {

return openmrsFetch(

`${restBaseUrl}/appointments/${appointmentUuid}`,

).then(({ data }) => {

if (data) {

return data;

}

return null;

});

};

export const getPatientAppointment = async (appointmentUuid: string) => {

try {

const response = await openmrsFetch(`${restBaseUrl}/appointments/${appointmentUuid}`);

return response.data || null;

} catch (error) {

console.error('Error fetching appointment:', error);

throw error; // Re-throw to allow caller to handle the error

}

};

denniskigen · 2025-02-28T06:55:53Z

src/hooks/usePatientCheckedInAppointments.ts

+import { openmrsFetch, restBaseUrl, useOpenmrsSWR } from '@openmrs/esm-framework';
+import dayjs from 'dayjs';
+import useSWR, { mutate, SWRResponse } from 'swr';
+import { type AppointmentsResponse } from '../types';
+import { useCallback, useMemo, useState } from 'react';


It looks like we're not using openmrsFetch and the SWR imports here. Can we remove them?

Yes @denniskigen, working on it!
Thanks for the catch!

denniskigen · 2025-02-28T07:03:12Z

src/processors/encounter/encounter-form-processor.ts

      }
+      // handle appointments
+      try {
+        const {appointments: myAppointments} = context


Looks like we're not using this code

denniskigen · 2025-02-28T07:06:16Z

src/processors/encounter/encounter-form-processor.ts

+        const appointmentsResponse = await Promise.all(addFulfillingEncounters(abortController, appointments, savedEncounter.uuid));
+        if (appointmentsResponse?.length) {
+          showSnackbar({
+            title: translateFn('appointmentsSaved', 'Appointment(s) saved successfully'),
+            kind: 'success',
+            isLowContrast: true,
+          });
+        }


Should we modify this so that we only proceed if there are appointments?

if (appointments && appointments.length > 0) { // ... }

denniskigen · 2025-02-28T07:13:33Z

src/processors/encounter/encounter-form-processor.ts

+        const appointmentsResponse = await Promise.all(addFulfillingEncounters(abortController, appointments, savedEncounter.uuid));
+        if (appointmentsResponse?.length) {
+          showSnackbar({
+            title: translateFn('appointmentsSaved', 'Appointment(s) saved successfully'),


Does translateFrom handle pluralization? If not, I think we could just default it to plural:

Suggested change

title: translateFn('appointmentsSaved', 'Appointment(s) saved successfully'),

title: translateFn('appointmentsSaved', 'Appointments saved successfully'),

denniskigen · 2025-02-28T07:13:48Z

src/processors/encounter/encounter-form-processor.ts

+      } catch (error) {
+        const errorMessages = Array.isArray(error) ? error.map((err) => err.message) : [error.message];
+        return Promise.reject({
+          title: translateFn('errorSavingAppointments', 'Error saving appointment(s)'),


Suggested change

title: translateFn('errorSavingAppointments', 'Error saving appointment(s)'),

title: translateFn('errorSavingAppointments', 'Error saving appointments'),

vasharma05 · 2025-02-28T07:25:39Z

src/components/inputs/workspace-launcher/workspace-launcher.component.tsx

+    }
+  };
+
+  const AppointmentsTable = ({ appointments }) => {


@jnsereko , never create a component inside another component.

src/api/index.ts

vasharma05 · 2025-02-28T07:53:16Z

src/api/index.ts

+  const updatedAppointment: AppointmentsPayload = {
+    fulfillingEncounters: updatedFulfillingEncounters,
+    serviceUuid: appointment.service.uuid,
+    locationUuid: appointment.location.uuid,
+    patientUuid: appointment.patient.uuid,
+    dateAppointmentScheduled: appointment.startDateTime,
+    appointmentKind: appointment.appointmentKind,
+    status: appointment.status,
+    startDateTime: appointment.startDateTime,
+    endDateTime: toOmrsIsoString(appointment.endDateTime),
+    providers: [{ uuid: appointment.providers[0]?.uuid }],
+    comments: appointment.comments,
+    uuid: appointment.uuid,


Isn't this weird that for updating 1 value of the appointment, we need to pass the whole object?

Can this be worked on?
CC: @denniskigen @jnsereko @ibacher @mogoodrich

Can this be worked on?

Agree with you @vasharma05. A nice improvement to do in the backend

@jnsereko , can you create a Backend Ticket for this?

Agree... we should likely have a REST endpoint just for adding a fulfilling encounter to an appointment.

vasharma05 · 2025-02-28T07:54:45Z

src/components/inputs/workspace-launcher/workspace-launcher.component.tsx

      });
    }
-    launchWorkspace();
+    if (field.meta?.handleAppointmentCreation) {


@pirupius @jnsereko, instead of having the check by the workspace name, since workspace names can be changed, I added a check by adding new prop handleAppointmentCreation in the field meta

@pirupius @jnsereko, instead of having the check by the workspace name, since workspace names can be changed, I added a check by adding new prop handleAppointmentCreation in the field meta

Should it really be optional though @vasharma05

@pirupius , did you have a look here?

vasharma05 · 2025-02-28T07:59:48Z

src/types/domain.ts

+  appointmentKind: string;
+  appointmentNumber: string;
+  comments: string;
+  endDateTime: Date | number;


Actually, it returns the number, neither the ISO string, nor a Date object

denniskigen · 2025-02-28T13:30:57Z

Whilst we’re still editing, maybe “(feat) Retrieve scheduled appointments in clinical forms workspace” reads better?

mogoodrich

So I added one comment but didn't review fully yet. This functionality looks really good! But, unfortunately, if I'm following this correctly I think there's a fundamental problem with it. It looks like this sets the "fulfillingEncounter" is set to the encounter when the appointment was scheduled? Is this what is happening? The "fulfillingEncounters" are meant to be set to any encounters that fulfill the encounter... ie, in this case, it should be the encounter that gets created on March 8th 2025 if/when the patient returns that day. It's not used to store the encounter when the appointment was created. See: https://bahmni.atlassian.net/browse/BAH-3239

Am I understanding this correctly?

fyi @jnsereko

mogoodrich · 2025-02-28T15:36:39Z

src/api/index.ts

+  const updatedAppointment: AppointmentsPayload = {
+    fulfillingEncounters: updatedFulfillingEncounters,
+    serviceUuid: appointment.service.uuid,
+    locationUuid: appointment.location.uuid,
+    patientUuid: appointment.patient.uuid,
+    dateAppointmentScheduled: appointment.startDateTime,
+    appointmentKind: appointment.appointmentKind,
+    status: appointment.status,
+    startDateTime: appointment.startDateTime,
+    endDateTime: toOmrsIsoString(appointment.endDateTime),
+    providers: [{ uuid: appointment.providers[0]?.uuid }],
+    comments: appointment.comments,
+    uuid: appointment.uuid,


Agree... we should likely have a REST endpoint just for adding a fulfilling encounter to an appointment.

jnsereko · 2025-03-05T12:36:41Z

So I added one comment but didn't review fully yet. This functionality looks really good! But, unfortunately, if I'm following this correctly I think there's a fundamental problem with it. It looks like this sets the "fulfillingEncounter" is set to the encounter when the appointment was scheduled? Is this what is happening? The "fulfillingEncounters" are meant to be set to any encounters that fulfill the encounter... ie, in this case, it should be the encounter that gets created on March 8th 2025 if/when the patient returns that day. It's not used to store the encounter when the appointment was created. See: https://bahmni.atlassian.net/browse/BAH-3239

Am I understanding this correctly?

fyi @jnsereko

Thank you @mogoodrich. You are understanding this correctly. IMO, we might need another field for the scheduling encounter or something like that. I have created a talk post on this for further discussion.

ibacher · 2025-03-05T16:25:34Z

@jnsereko Please create a Jira ticket explaining why we're putting this change in and what the goals are.

Retrieve appointment scheduled in workspace in forms

bf00f56

pirupius requested review from denniskigen, ibacher, pirupius, samuelmale and vasharma05 February 27, 2025 09:58

jnsereko mentioned this pull request Feb 27, 2025

BAH-3847: Appointments: Add REST support for 'fulfilling encounters' Bahmni/openmrs-module-appointments#168

Draft

remove the state mutate function

5f84c8b

Improved the workflow for displaying newly created appointments

a9331be

denniskigen reviewed Feb 28, 2025

View reviewed changes

vasharma05 reviewed Feb 28, 2025

View reviewed changes

vasharma05 added 4 commits February 28, 2025 13:21

Improvement in the whole appointment creation flow

61de4ea

Clean up

93b8b9d

Update JS Doc

0098d6e

Fix translation strings

5d79f3d

vasharma05 reviewed Feb 28, 2025

View reviewed changes

pirupius changed the title ~~Retrieve appointment scheduled in workspace in forms~~ (feat) Retrieve appointment scheduled from workspace in forms Feb 28, 2025

pirupius changed the title ~~(feat) Retrieve appointment scheduled from workspace in forms~~ (feat) Retrieve scheduled appointments in clinical forms workspace Feb 28, 2025

mogoodrich reviewed Feb 28, 2025

View reviewed changes

	title: translateFn('appointmentsSaved', 'Appointment(s) saved successfully'),
	title: translateFn('appointmentsSaved', 'Appointments saved successfully'),

	title: translateFn('errorSavingAppointments', 'Error saving appointment(s)'),
	title: translateFn('errorSavingAppointments', 'Error saving appointments'),

Conversation

jnsereko commented Feb 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Requirements

Summary

Requirements

Screenshots

Related Issue

Other

Uh oh!

pirupius commented Feb 27, 2025

Uh oh!

pirupius commented Feb 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

denniskigen commented Feb 28, 2025

Uh oh!

mogoodrich left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jnsereko commented Mar 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ibacher commented Mar 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

jnsereko commented Feb 27, 2025 •

edited

Loading

pirupius commented Feb 27, 2025 •

edited

Loading

mogoodrich left a comment •

edited

Loading

jnsereko commented Mar 5, 2025 •

edited

Loading