-
Notifications
You must be signed in to change notification settings - Fork 143
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
EA-188 - Improve Java and Rest API for retrieving inpatient admission requests #233
+816
−69
Merged
Changes from 12 commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
eb5a4dd
In progress
mseaton 9ec13f1
Merge branch 'master' into EA-188
mseaton b2606aa
Add initial set of unit tests
mseaton 7adca3b
Additional unit tests
mseaton aae9f3e
Javadoc
mseaton 5727a3d
Add initial REST controller and add some fixes for performance and to…
mseaton a059657
Add additional constraint to ensure the disposition used is the lates…
mseaton 1e153da
Cover edge case where multiple dispositions have the exact same datet…
mseaton 066a948
For consistency with other controllers, don't limit to v1
mseaton 69d555b
Only consider requests fullfilled if adt encounter occurs after them …
mseaton 2165c36
Formatting
mseaton bea208d
Set the default representation to DEFAULT
mseaton a6623a2
Merge branch 'master' into EA-188
mseaton d58090b
Re-organize and add additional unit tests, add ability to search for …
mseaton fd9edf8
Remove specific inpatient request methods from inpatient visits contr…
mseaton 6dae3e2
Change default representation of inpatient request to ref for all pro…
mseaton e2d0123
Change default representation of inpatient request to ref for all pro…
mseaton File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
26 changes: 26 additions & 0 deletions
26
api/src/main/java/org/openmrs/module/emrapi/adt/InpatientRequest.java
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
package org.openmrs.module.emrapi.adt; | ||
|
||
import lombok.Data; | ||
import org.openmrs.Concept; | ||
import org.openmrs.Encounter; | ||
import org.openmrs.Location; | ||
import org.openmrs.Obs; | ||
import org.openmrs.Patient; | ||
import org.openmrs.Visit; | ||
import org.openmrs.module.emrapi.disposition.DispositionType; | ||
|
||
import java.util.Date; | ||
|
||
/** | ||
* Represents and Admission, Discharge, or Transfer request | ||
*/ | ||
@Data | ||
public class InpatientRequest { | ||
private Visit visit; | ||
private Patient patient; | ||
private DispositionType dispositionType; | ||
private Encounter dispositionEncounter; | ||
private Obs dispositionObsGroup; | ||
private Concept disposition; | ||
private Location dispositionLocation; | ||
} |
34 changes: 34 additions & 0 deletions
34
api/src/main/java/org/openmrs/module/emrapi/adt/InpatientRequestSearchCriteria.java
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
package org.openmrs.module.emrapi.adt; | ||
|
||
import lombok.Data; | ||
import org.openmrs.Location; | ||
import org.openmrs.module.emrapi.disposition.DispositionType; | ||
|
||
import java.util.ArrayList; | ||
import java.util.List; | ||
|
||
/** | ||
* Represents criteria for searching for AdtRequests | ||
* Currently the assumption is that all requests returned are active, and this will be the default regardless | ||
*/ | ||
@Data | ||
public class InpatientRequestSearchCriteria { | ||
mseaton marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
private Location visitLocation; | ||
private List<Location> dispositionLocations; | ||
private List<DispositionType> dispositionTypes; | ||
|
||
public void addDispositionLocation(Location location) { | ||
if (dispositionLocations == null) { | ||
dispositionLocations = new ArrayList<>(); | ||
} | ||
dispositionLocations.add(location); | ||
} | ||
|
||
public void addDispositionType(DispositionType dispositionType) { | ||
if (dispositionTypes == null) { | ||
dispositionTypes = new ArrayList<>(); | ||
} | ||
dispositionTypes.add(dispositionType); | ||
} | ||
} |
61 changes: 61 additions & 0 deletions
61
api/src/main/resources/hql/inpatient_request_dispositions.hql
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
select | ||
visit, | ||
dispoEncounter.patient, | ||
dispoEncounter, | ||
dispo.obsGroup, | ||
dispo, | ||
(select o from Obs o where o.obsGroup = dispo.obsGroup and o.voided = 0 and o.concept = :admitLocationConcept) as admitLocation, | ||
(select o from Obs o where o.obsGroup = dispo.obsGroup and o.voided = 0 and o.concept = :transferLocationConcept) as transferLocation | ||
from | ||
Obs as dispo | ||
inner join dispo.encounter as dispoEncounter | ||
inner join dispoEncounter.visit as visit | ||
inner join dispo.person as person | ||
where | ||
dispo.voided = false | ||
and dispoEncounter.voided = false | ||
and visit.voided = false | ||
and dispo.concept = :dispositionConcept | ||
and dispo.valueCoded in :dispositionValues | ||
and (:visitLocation is null or visit.location = :visitLocation) | ||
and person.dead = false | ||
and visit.stopDatetime is null | ||
and ( | ||
select count(*) | ||
from Obs as laterDispoObs | ||
where laterDispoObs.encounter.visit = visit | ||
and laterDispoObs.voided = false | ||
and laterDispoObs.concept = :dispositionConcept | ||
and ( | ||
laterDispoObs.obsDatetime > dispo.obsDatetime or | ||
(laterDispoObs.obsDatetime = dispo.obsDatetime and laterDispoObs.obsId > dispo.obsId) | ||
) | ||
) = 0 | ||
and ( | ||
select count(*) | ||
from Encounter as adtEncounter | ||
where adtEncounter.visit = visit | ||
and adtEncounter.voided = false | ||
and adtEncounter.encounterType in (:adtEncounterTypes) | ||
and adtEncounter.encounterDatetime >= dispo.obsDatetime | ||
) = 0 | ||
mseaton marked this conversation as resolved.
Show resolved
Hide resolved
|
||
and ( | ||
select count(*) | ||
from Obs as adtDecision | ||
inner join adtDecision.encounter as encounterInVisit | ||
where encounterInVisit.visit = visit | ||
and encounterInVisit.voided = false | ||
and adtDecision.voided = false | ||
and adtDecision.concept = :adtDecisionConcept | ||
and adtDecision.valueCoded = :denyConcept | ||
and encounterInVisit.encounterDatetime > dispoEncounter.encounterDatetime | ||
) = 0 | ||
and ( | ||
:dispositionLocationIds is null or ( | ||
select count(*) | ||
from Obs as locationObs | ||
where locationObs.obsGroup = dispo.obsGroup | ||
and locationObs.valueText in (:dispositionLocationIds) | ||
) > 0 | ||
) | ||
order by dispo.obsId |
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
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is kind of a question mark for me @mogoodrich . The way I coded this up, if you ask for only ADMIT requests, then only Admission Encounters will be checked as those that might render them fulfilled. Same with TRANSFER and DISCHARGE. If we think that an admit disposition followed by a transfer or discharge encounter should lead to that admit request being fulfilled, then we may want to rethink this logic here, and just add all 3 encounter types in all cases. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More of a business logic thing but doubtful will get a answer, but my general thought is a request is "active" if 1) it is the most recent disposition in the visit, and 2) there hasn't been any successive "ADT encounter type" (so to your direct question, I would add all three encounter types) and 3) there is no successive "deny admission" obs (if the disposition is admit)
Thoughts? Am I missing anything? At the end of the day, since a lot of the stuff is edge cases, probably best to just come up with the most succinct description/logic?
FWIW we could come up with a better name than "active", but I think is better than "fulfilled"... ie in your above example (admit disposition followed by transfer or discharge), I don't think the request has been been "fulfilled", but it is no longer active, which is what we care about there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would tend to agree, hence why I asked the question, but this is not what has been in place for all of these years. The existing functionality only looks at Admission Encounters. It does not concern itself with transfer or discharge encounters at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this isn't getting a fair amount/any use outside of PIH, so I think it's fine to change if we think it's more correct...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the interest in getting this committed, let's ticket this separately and decide what to do, since it affects both existing and new code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ticketed separately here @mogoodrich : https://openmrs.atlassian.net/browse/EA-195