(Feature) Patient Check In #477
Conversation
This commit introduces the patient check in ui elements and controller. It also demonstrates the basic pattern for using a named nest ui-view within a template. This can be contrasted with units as components.
This commit introduces the server structure for patient check ins, allowing a request for all patient visits. It also introduces the initial files and methods for testing the API.
This commmit introduces the end point to write to the patient_visit table along with integration tests.
* Introduced client side check in service as a child of the `PatientService` * ?limit querystring for /patients/:uuid/visits to limit the number of responses
This commit adds business logic that determines if the patient has recently bene checked in and ensures the view displays the correct warnings.
| .state('patientRecord.details', { | ||
| url : '', | ||
| views : { | ||
| 'checkin@patientRecord' : { |
There was a problem hiding this comment.
Do you need the @patientRecord part of the view definition?
There was a problem hiding this comment.
I was playing around with absolute vs. relative names to see how specific these routes could get - as this is a fairly simple heirachy this will work just using the checkin namespace.
|
@sfount, finshed a review. Code generally looks good, the screenshots look excellent! It's not clear whether a component or a ui-view is better for embedding these panels. I do not see an immediate benefit to either - except that components are more familiar to developers. Do you have any thoughts? I'll give you a chance to respond to the feedback here, and then will merge or wait for fixes. Nothing blocking in this PR. |
|
@jniles all of your suggestions have been incorperated. Regarding ui-view vs. components I don't think there's a clear choice. <div ui-view="checkin"></div>
<div ui-view="documents"></div>
<div ui-view="latestBill"></div>However this would look similar with components. One advantage of components may also be the standardisation of writing unit tests for components. I didn't come up with a clear way to unit test this sub module. Either method makes sense to me, it may become clearer after we have more examples. |
* End to end tests for checkin functionality * Complete check in request client side * Update view with latest check ins * Reduce space between list elements on patient overview * Remove references to previous patient visit implementations
|
LGTM and tests pass! |
This pull request implements the first iteration on the 2.x check in feature.
This allows a patient to be checked in and provides information on a patients hospital visit status. It is integrated in the the Patient Record page and is implemented as a nested view.
@IMA-WorldHealth/local-contributors This method of using a nested view should be contrasted with developing sub modules as components #452. Once we have established the benefits and limits we can select one for going forward.
Patient recently visited
Patient never visited
Patient visited previously but not recently
Patient checking in
Note that this pull request updates the
bh-loading-buttoncomponent to allow the button style to be overriden if required by the controller. In the future this can be done with a default transclude however for now it is set through the optionalbutton-classattribute (defaultbtn-primary).Closes #464
Closes #469