Feature: patient registration report #481
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jniles
force-pushed
the
feature-patient-registration-report
branch
from
4fee710
to
6faf8e2
Compare
|
@sfount, in the spirit of living in the moment, this PR was made a moment ago, and the review should only take a moment. Could I get one? |
| @@ -44,7 +45,7 @@ function ReceiptModal(Modal, Receipts) { | |||
| notifyCreated : notifyCreated | |||
| }; | |||
|
|
|||
| var invoiceRequest = Receipts.invoice(uuid, { render : options.renderer }); | |||
| var invoiceRequest = Receipts.invoice(uuid, { renderer : options.renderer }); | |||
|
@jniles This has been reviewed. If you could remove any code re-introducing logVisit/ visiit on the server patient controller this can be merged anytime! |
|
@sfount changes have landed. |
This commit refactors the patients search functionality in the following ways: 1. Expose a programmatic API via `find()` to the query engine. 2. Make `patients/search/?` use `find()` internally. 3. Rename `detail` to `detailed`. 4. Remove `fields` support. Now any query parameter will be used to filter the columns from the database. This provides a much richer API for searching for patients on both the client and the server.
This commit refactors the server side to complete the PDF report implementation. Some notable improvements: 1. Automatically template in the filters. This should be improved with varied colorschemes (IMA colors, for example). 2. Adds `timestamp` helper to handlebars for more detailed time templates. 3. Adds initial bare-bones clients structure for PDF printing modal.
This commit implements the client PDF report using the Receipt service created by @sfount. Because the client-side filters do not have a good data model, printing with filtering has been left for later. There are several prominent TODOs in this commit: 1. Filtering on the client should be additive, and use a key:value model, so that each filter takes in one parameter. For example, `name:jniles` would be stored in the JSON `{ name : 'jniles' }`, and be sent to the server as `?name=jniles`. 2. The Receipt Service is now overloaded with reports. We need to cleanly separate Receipts as a subset of reports, and ensure that the modal and controllers are appropriately named.
This commit removes the logVisit functionality accidentally re-introduced in a failed rebase. The `logVisit` functionality has been superseded by patient checkins.
jniles
force-pushed
the
feature-patient-registration-report
branch
from
a72265f
to
ef077b4
Compare
|
@sfount, rebased. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request implements the patient registration report as a PDF report on the client. It is opened by default via a "print" button on the patient registry page. The report is available as JSON, HTML, and PDF using the renderers implemented by @sfount.
Screenshots
[Fig 1]: HTML Report
[Fig 2]: PDF Report
This is a very rough PR, and should not be considered final. Here are some TODOs:
name:jnileswould be stored in the JSON{ name : 'jniles' }, and be sent to the server as?name=jniles.These should be tackled in a subsequent PR.
Closes #470.
Thank you for contributing!
Before submitting this pull request, please verify that you have:
For a more detailed checklist, see the official review checklist that this PR will be evaluated against.
Ensuring that the above checkboxes are completed will help speed the review process and help build a stronger application. Thanks!