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?
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.
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.