that works for me, assuming 9:30 pm IST.
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
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:
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.
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 User Stories - Appt Module - Google Docs
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
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.