This was a really helpful discussion. Thank you for stewarding these calls @buvaneswariarun and @angshuonline, it’s a pleasure to attend.
The feeling is mutual @grace - Regular discussions between both the communities will benefit the product a lot. Thanks for attending.
Hi @buvaneswariarun and @angshuonline, I promised to get back to you and the PAT with some answers, so here they are - sorry I won’t be able to join this week’s PAT call as I’m on vacation (actually, I meant to send these much sooner, but haven’t had internet the last few days).
I hope this helps, and happy to discuss any and all of these in more detail! @jdick and @mksd I hope you’ll help correct me anywhere I’m off track.
Questions from PAT about ongoing Micro Frontend squad work:
Is anything else angular being converted to react? Status or plan to go from angular to fully react? Any issues expected with angular and react combined? A: We don’t use angular in MFE; it’s 100% react. (Angular conversion was done for one particular sub project due to Ampath’s custom form engine). SingleSpa is framework agnostic so that enabled the Ampath forms to be integrated even though angular.
There’s only one PR in appointments, hasn’t been resolved. So are they using appointments or have they forked it…? A: On the front end side, there is no PR or work that we know about. (@mksd anything to add?)
Any updates re. APIs: Trying to be FHIR first so where possible will hit the OMRS FHIR module for data and write back to it. In places where this not supported, we fall back on the REST API.
- Does the PAT have questions specifically about using the fhir appointments API?
- For which FHIR resources we’re supporting, we need to defer to @ibacher and @corneliouzbett
Is there something fundamental at the framework level that Bahmni can start harvesting from, or looking at? Any demos coming up?
A: Yes and yes, please check out the following helpful links. We’d love to hear feedback on these, especially the ongoing and new extensions work, which we’ll also be demo-ing at the next monthly OMRS Squad Showcase on Oct 1 at 7:30pm IST. Links:
Extensions: Extensions Implementation Plan: https://github.com/openmrs/openmrs-rfc-frontend/pull/27
Extensions visual overview of how it all comes together: https://docs.google.com/presentation/d/1ParNFdehbBexycC_XzdvpPNXBCea-4GYwAuoPFtvYIY/edit#slide=id.g921ee92cfb_0_2
Frontend Implementer Documentation: This needs a review but is apparently still fairly accurate https://wiki.openmrs.org/display/projects/Frontend+Implementer+Documentation
Form 2 Integration / MF-izing update from Florian: Since the board was created he hasn’t managed to work on this because he had to shift his forucs to Domain Decomposition and other topics. But it’s on the agenda - first we need to get DD (esp. esm-core and patient chart) working fine, and Florian is working with Manuel on getting Drug Orders done promptly for a customer. But the appointment work is definitely not forgottten; in fact, it’s a direct technical deliverable for Florian to make MF-izing Forms 2 happen before year end. Both PIH and Mekom intend to support HFE within OpenMRS 3.0 for all the obvious reasons, but not as the default forms engine. So it’s a strategic priority as well.
Let me know if any of this didn’t make sense, and again, apologies for the delay in replying. I’m back to solid internet in about 5 days Looking forward to the next PAT call.
So the general policy statement here is that the FHIR2 module will support any resources for which there is an identified need and which can be populated using data from OpenMRS core. We also intend to provide a mechanism so that any OpenMRS module can provide new FHIR resources that are not a part of the the FHIR2 module and have those be made available through the FHIR2 module FHIR server. Modules can already override the default behaviour of any FHIR resources provided by the FHIR2 module. Eventually all of this will be documented on the OpenMRS Wiki.
From a pure FHIR perspective, the relevant resources for appointment scheduling are Appointment, Schedule, and Slot, depending on the data that the module needs to represent. The Appointment resource, in particular, has a number of details on the workflow for which it’s intended to be used. If this doesn’t meet the needs of the appointment module, we can always look into whether or not the Appointment resource, possibly with extensions, can be used to meet the use-case of the Bahmni appointment module. The Schedule and Slot resources I referred to above are primarily about representing a Practitioner or Practices schedule and can be used to tie appointments to schedules.