Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Design) Patients Registry #336

Closed
sfount opened this issue Apr 20, 2016 · 1 comment
Closed

(Design) Patients Registry #336

sfount opened this issue Apr 20, 2016 · 1 comment

Comments

@sfount
Copy link
Contributor

sfount commented Apr 20, 2016

This issue describes the patient registry module proposed/ described in #278.

The patients registry (records) will be the central place in BHIMA to search for a patient, it will be a tool that can be used to check in a returning patient or looking up any patient that has been registered in the past.

These proposed designs show a complex final state - the core of this module should load patient records and allow filtering on columns.

Options to search for patients:

  • When was the patient registered? - from date, to date
  • When was the patients last bill? - from date, to date
  • How old is the patient? - from age, to age
  • Gender of the patient?
  • Origin location?
  • Current location?
  • Searches on names

If there are any additional ideas on parameters to search for patients they can be commented and added here.

Patient Registry Core
patient registry

I propose that this module uses a UI Grid that allows sorting/ filtering on the current patient records search. On the initial page load the grid will show the most recently registered or visiting patients.

Patient Registry Search
patient registry search

A modal search service will be used to refine the results - this will make a new request to the server for patient records based on the search parameters. It should also provide basic form validation.

Patient Registry Search View
patient registry filtered

The current search parameters should be shown to the user somehow. This mockup shows a filter bar that could be used across a number of modules like this. How filters/ searches are shown should be discussed.

@jniles
Copy link
Collaborator

jniles commented Apr 21, 2016

Looks good to me.

More parameters to search on (in the most complex case):

  • Last Visit - from date, to date
  • Hospital Number
  • Reference

For this to work, we need a really well crafted /patients/search/ API. Currently, there are at least three routes that exist (/patients/search/, /patients/search/reference/, /patients/search/fuzzy/). Someone should begin by either removing the unused routes or unifying them into the same route and testing that server API.

jniles referenced this issue in jniles/bhima Jun 17, 2016
This commit improves the filters ui again by introducing the following
upgrades:
 1. The server uses `moment` to parse dates in the date filters.  The
 code on the server for rendering the filters is very similar to the
 clientside codebase, which is unavoidable.  There might be an
 optimisation down the road to reduce this replication, but I think this
 is acceptable for now.

 2. The filters are now passed into the filter form and preset there.
 That way, when you go to filter a second time, all the data is
 preserved.

 3. A weird bug with caching filters was fixed.  The detailed flag no
 longer shows up as a potential filter, and refreshing the page after
 printing no longer breaks the browser.

 4. The date rendering has been improved in the handlebar's date helper
 function.  If an invalid date occurs, it will simply render the empty
 string.

 5. The `$uibModal` handler now implements the behavior described in
 #506.

Closes #492.  Closes #336.
@jniles jniles mentioned this issue Jun 17, 2016
4 tasks
jniles referenced this issue in jniles/bhima Jun 21, 2016
This commit improves the filters ui again by introducing the following
upgrades:
 1. The server uses `moment` to parse dates in the date filters.  The
 code on the server for rendering the filters is very similar to the
 clientside codebase, which is unavoidable.  There might be an
 optimisation down the road to reduce this replication, but I think this
 is acceptable for now.

 2. The filters are now passed into the filter form and preset there.
 That way, when you go to filter a second time, all the data is
 preserved.

 3. A weird bug with caching filters was fixed.  The detailed flag no
 longer shows up as a potential filter, and refreshing the page after
 printing no longer breaks the browser.

 4. The date rendering has been improved in the handlebar's date helper
 function.  If an invalid date occurs, it will simply render the empty
 string.

 5. The `$uibModal` handler now implements the behavior described in
 #506.

Closes #492.  Closes #336.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants