Conversation
|
This is actually the entire source code for the app that I demoed this week during the One PIH EMR meetup. More details about how it works, including a video is in the JIRA ticket. Thanks! |
| * @return the matching observations | ||
| */ | ||
| @SuppressWarnings("unchecked") | ||
| public List<Obs> getObsByAuditUser(User createdBy, User voidedBy, Date fromDate, Date toDate, Integer startIndex, |
There was a problem hiding this comment.
The more recent pattern we should follow is to create a getObs method that takes in an ObsSearchCriteria, which can start out by including just criteria based on audit info but which could be expanded however we need in the future, without requiring us to have lots of difficult to use and brittle methods that take in lots of different combinations of parameters.
Note that this may also require us to be more explicit with the names of the date parameters so it is clear what these are filtering on.
| public List<Obs> getObsByAuditUser(User createdBy, User voidedBy, Date fromDate, Date toDate, Integer startIndex, | ||
| Integer limit) { | ||
| Query query = sessionFactory.getCurrentSession().createQuery("select o from Obs o " | ||
| + auditWhereClause(createdBy, voidedBy, fromDate, toDate) + auditOrderByClause(voidedBy)); |
There was a problem hiding this comment.
Generally I think it's better if we use the criteria API rather than concatenating an HQL string. Direct this to look at the way I implemented Order searching service and DAO methods in the pihapps module and see if we can follow the same pattern. We also would be better off moving this functionality into pihapps rather than pihcore, if it is something that could be leveraged by non-pihemr implementations like rwanda and malawi.
| * @return the matching encounters | ||
| */ | ||
| @SuppressWarnings("unchecked") | ||
| public List<Encounter> getEncountersByAuditUser(User createdBy, User changedBy, User voidedBy, Provider provider, |
| * parameter, and shaping an error the same way. Kept together so the two endpoints cannot drift | ||
| * apart on what `endDate=2026-09-30` means. | ||
| */ | ||
| final class AuditRestSupport { |
There was a problem hiding this comment.
I don't really understand the need for this class or where it came from. Why are we needing to do something here that is different from normal date handling in REST?
| @RequestParam(value = "provider", required = false) String provider, | ||
| @RequestParam(value = "encounterType", required = false) String encounterType, | ||
| @RequestParam(value = "startDate", required = false) String startDate, | ||
| @RequestParam(value = "endDate", required = false) String endDate) { |
There was a problem hiding this comment.
These should not generally be string parameters, but typed parameters. See the LabOrderRestController in the pihapps module. Would be good to stay consistent with this pattern, and probably move this over to pihapps if it is generally useful outside of the pihemr.
Same with the ObsAuditRestController.
2 participants
Just added a couple REST end points to be able to search encounters and obs by users who modified the data.