feat(O3-2953): Implemented Edit and Delete Actions for Vitals and Biometrics forms

[senthil-athiban]

Requirements

• [x] 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.
• [x] My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
• [x] My work includes tests or is validated by existing tests.

Summary

• [x] Enabled Edit and Delete functionality for vitals and biometrics forms. Form data is retrieved by using the encounter ID, and the same is used for making edit and delete requests.

Screenshots

https://www.loom.com/share/b47c4ddf00724b6d97c17d71513d37c8?sid=19a6b632-fea9-4c09-9c84-03e41a7f6847

Related Issue

https://openmrs.atlassian.net/browse/O3-2953

[denniskigen]

pulling @denniskigen @ibacher @vasharma05 , as due to register workspace deprecated in this PR. The workspace doesn't seem to work for me from my side. is that same on your side as well, couldn't access the workspace?

Rebasing against main and then doing a hard reload in your browser should fix this.

[senthil-athiban]

thanks @denniskigen. Working as expected!

[denniskigen]

@senthil-k8s so one of the main things to take care of here is that deleting vitals and biometrics data should void the observations instead of deleting the encounter.

[denniskigen]

@ibacher so what's the ideal approach for @senthil-k8s to pursue w.r.t to voiding the observations using the Delete action?

[senthil-athiban]

@denniskigen When editing vitals and biometrics (i.e., updating existing observations), my current approach results in creating a new observation each time a user edits the vitals. Is there a better approach to edit the vitals without creating new observations every time?

[denniskigen]

@samuelmale do you mind clarifying what the approach should look like?

[ibacher]

I think this is where EMR API could actually be helpful, but I'm not sure what the specific API to use there is. Otherwise, yes, I think the only real option is a request-per-obs.

[samuelmale]

I think we just have to grep and group obs by a derived category ie. "vitals" vs "biometrics" and then simply mark them as voided:

function getVitalsObs(encounter: Encounter): Array<OpenmrsResource> {
   // return vitals specific observations
}

function deleteVitals(encounter: Encounter) {
   const vitalsToBeVoided = getVitalsObs(encounter).map(obs => ({ uuid: obs.uuid, voided: true }));
   // You can either save them all at once as part of the encounter OR save them individually using the Obs endpoint.
}

I prefer saving all the voided obs apart of the encounter object in a single shot.

[senthil-athiban]

@samuelmale, @denniskigen, could you please let me know if my approach makes sense?

https://www.loom.com/share/c85f115c1e8b417a9f920b2f3b93e8b5

[denniskigen]

@senthil-k8s I've squashed your commits into a single one to ensure a cleaner commit history. This should simplify future rebasing and merges.

Thank you for your understanding and contributions!

[denniskigen]

Ok, thanks, guys! Looks like this is good to go!