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

bug: Visit History's "Results per page" applies only to encounters, not documents #7275

Open
pete-boyd opened this issue Mar 18, 2024 · 4 comments

Comments

@pete-boyd
Copy link

In OpenEMR 7.0.1 (1), in Visit History, if you set "Results per page", it only affects encounters. Any documents uploaded to the patient record are not included in the total figure defined by "Results per page", and appear at the end of the list of encounters.

E.g., set "Results per page: 5" and 5 encounters are listed, but then 8 of "Document:...".

@sjpadgett
Copy link
Sponsor Member

@pete-boyd Yeah I can see how this would be annoying especially for paperless clinics that upload most everything dealing with a patient.
Maybe another range for documents included like the last 5 or latest. Or only docs attached to an encounter. I don't know how much attaching documents to encounters is used in the wild and would need feedback for that.
What would be your recommendation Pete?

@pete-boyd
Copy link
Author

Here's a description of how Visit History is being used:

"Some of the GP's that run our clinic like to see the full history from the EMR for each client (they do not have access to the EMR but our RGN running the clinic does). For this reason we routinely print the list of encounters for each client and that is given to the GP when the client arrives for appointment. So a clinic might have 10 appointments we print 10 pages, the client name and DOB and list of encounters."

In this scenario, I'm imagining that any info on documents is superfluous.

I've made an inquiry with regard to your questions though, and will get back to you.

@ruthkonyn
Copy link
Contributor

ruthkonyn commented Mar 20, 2024

I think there are two issues:

  1. the way the document records are displayed is buggy -
    (a) documents aren't counted when calculating the total number of records in the history e.g. it reports say N results but displays N+M entries, where there are M documents and N encounters.
    (b) when document records are displayed they are not counted in the page length, so e.g. if the limit is 5 records per page and there are 2 documents, then 7 records might be displayed (it depends on chronological order)
    (c) document records are 'dumped' at the end of the history willy nilly, so i've seen the same documents reported as much as 3 times!! i.e. even if the documents were already displayed in the history, they might be displayed again at the end.

In some circumstances, such as the 'ALL' setting for results per page the only problem is (a)

I'm looking at how to fix these bugs so that documents are included in the results counts, and are listed in date order in the history OR at the end - but not both (or is the intended behaviour only to list non encounter attached documents at the end, instead of in date order in the history?)

  1. the other is whether a user would want documents listed at all, in this case enhance with an additional set of document options: 'do not include any documents' 'include only documents attached to an encounter' 'include all documents'

@pete-boyd
Copy link
Author

I received this in relation to documents appearing in Visit History:
"Actually useful for us to see, in visit history, if documents have been attached. For example when an existing/previously seen client presents to triage we check the visit history in the EMR to see if there is a Document xxxxx.pdf (patient id card) and use this as a check in our process."

@adunsulag adunsulag changed the title Visit History's "Results per page" applies only to encounters, not documents bug: Visit History's "Results per page" applies only to encounters, not documents Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants