New Appointments UI within microfrontend framework

Hi @jdick the slot is available

Regards Cynthia

Just wanted to post this discussion thread from Bahmni regarding this ongoing topic

Definitely seems like parallel initiatives here between the new Appointments UI microfrontend and the plan to rework the Bahmni Appointments UI, worth discussing if there can be some collaboration here… @c.antwi @jdick @angshuonline

2 Likes

Happy to discuss. Btw, its not just the UI thats different, the server side model is different too!

We are fairly open to anything. The downside would be that we recently spent a good amount of time updating the stardard appointments backend. However, as we are yet to implement, it would not be a headache to change the backend from that perspective.

Angshu, is there interest on the bahmni side to create the ui as a microfrontend?

many aspects to that question

  • future architectural alignment - yes.

However, there needs to be fair amount of refactoring to be done - front and backend modules, along with conceptual/design level agreements.

  • given our current capacity - thats a really tall ask :frowning:

Could we schedule a Design Forum to discuss next steps around this? Next Monday’s slot is available.

@jdick @angshuonline @jecihjoy @mogoodrich @eachillah @mksd

that works for me, assuming 9:30 pm IST.

Hi @angshuonline that call is usually at 4pm UTC which is 9pm IST :slight_smile:

@jdick and @gschmidt

I should be able to do next Monday.

From a PIH perspective, it would be better for us if we stayed with the existing Appointment Scheduling module backend, as we currently use that…

That means 7.00pm EAT. That’s fine with me

IST is UTC+530. So, its 9:30 pm IST, unless the call is half an hour earlier.

2 Likes

@angshuonline We have started the call on https://www.uberconference.com/openmrs

Hey everyone!

Here’s a nice summary of Monday’s meeting that Greg posted on Slack for those who missed it:

Summary from call today:

  1. The backend of Bahmni is too different from that which PIH/AMPATH uses and therefore at this time it will be easier for PIH/AMPATH to collaberate on this, rather than trying to also merge the two different backend business logic and data models.

  2. We encourage everyone to add to the user requirements and document over the next few days. Starting near the end of this week this will be turned into mockups https://docs.google.com/document/d/1CuU73_z72kpzGeOu5NLNk0fqhJk4secSU0j8bnRsDH0/edit?usp=sharing

  3. We will use the new Tool Figma to enable everyone to comment and view mockups as they are releasedSUMMARY OF INTENDED US AMPATH - will look at deploying this into outpatient HIV and HTN/DM / Oncology settings PHI - will consider deploying this into Liberia or Sierra Leanne for eg. Mental Health, and NCDDevices: will need to work across desktop, laptop, and tablet

NEXT UPDATES: Mid next week anticipate earliest mockups from Greg. At that stage we will encourage more people who were involved to add further feedback to these first drafts

I am sorry that I couldn’t attend the call as I had to travel on urgency.

I am sure you would have done the investigation, but may I know “conceptually” (and not db table/column wise) - what the group deemed is different?

OpenMRS older appointment module did provider based appointment, but in Bahmni, we had requirement of more service based appointments, where provider is optional. (and you can have multiple providers for an appointment).

@angshuonline I believe this decision was based entirely on the difficultly of the backend integration… I believe that Bahmni doesn’t use the main OpenMRS Appointment Scheduling module, but another OpenMRS module (https://github.com/Bahmni/openmrs-module-appointments)… if this is incorrect, let us know, because it would change the equation.

I don’t think any analysis was down from the BA perspective of the functional/conceptual differences between the two, and I could see this being valuable to do.

Take care, Mark

@mogoodrich yes you’re correct Bahmni uses another backend and it is the one you pointed to.

Thats correct. The backend is different because the conceptual model of appointments is different. (Service vs provider). IMO, if the functionality is same desirable as that of Bahmni, then we can think of automated migration of data (should be easy to do so). However, it would not matter, if the conceptual model of appointments is different.

Hi, it looks like appointments will become a module within the new microfrontend architecture, and so the UX bit for that will hold off until we have some of the earlier components like login / patient landing page / dashboard / are up and running.

That way the module will be able to leverage both the technologies and the design of the new frontend system.

This also gives us more time to figure out if its a good opportunity to merge the business logic btwn Bahmni & PIH/AMPATH.

Just throwing this out there…but it would be great if the business logic ran completely off the FHIR resources for scheduling. eg.

https://www.hl7.org/fhir/appointment.html

https://www.hl7.org/fhir/schedule.html

https://www.hl7.org/fhir/slot.html

https://www.hl7.org/fhir/appointmentresponse.html

https://www.hl7.org/fhir/encounter.html

A self contained, FHIR first, appointment module sounds like something that in general should just exist.

1 Like

It would be great to better understand the Bahmni model. We would be open to a move if we could gain consensus.

I agree with Greg though - the ideal would be to make this a fhir first approach if at all possible.