-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Openemr fix 5508 ccd date ranges #5525
Openemr fix 5508 ccd date ranges #5525
Conversation
Changes g9 $docref to be a POST api since we generate a new document every time. Fixes ISO8601 date problems with php since php's date constant is incorrect. Switch to ATOM constant. Got the start and end date working from the g9 but we are failing in some instances in the ccda generator because its excluding encounters that some of the data elements rely upon. Fixed the ORDataObject saving incorrectly on some database instance types due to the timezone and microsecond formatting. Added __clone helper methods to the search field classes so we can copy them and modify properties w/o modifying the references.
Added brief, terse documentation for g9 generation with docref. Needs to be fleshed out in the fhir readme file. Updated the swagger file to point to the g9 documentation. Removed the remote xsl stuff as I found out chrome actively blocks remote xsl's from rendering unless everything is in the same folder, port, origin, and schema. Changed up the filtering as careplan was still breaking due to its requirement on an encounter. Changed up the filtering to be encounter based so that any of the sections related to an encounter are filtered for the CCD. I left non-ccd document types alone since g9 only requires the ccd filtering. Removed unused referral pieces in the care plan section as they were all being skipped due to the missing required codes in the transactions table. node side was skipping it as well so I left it off.
@sjpadgett and @bradymiller when you get a chance if you can look this over and let me know what you think? I'll run through more test scenarios tomorrow but I wanted to get this out there for the two of you to look at it. |
@@ -18,6 +18,7 @@ | |||
use Application\Listener\Listener; | |||
use Application\Model\ApplicationTable; | |||
use Carecoordination\Model\CarecoordinationTable; | |||
use Couchbase\SearchQuery; |
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.
Just realized this was here, not sure how it got in here. I'll remove it tomorrow.
@adunsulag , Looks great! I will have time over next couple days to expand on the documentation. |
if (!empty($options['date_start'])) { | ||
$searchFromDate = strtotime($options['date_start']); |
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 concerns me a bit. Should this be coalesced to null. May be okay as I think $options is qualified before here unless there is another path calling this class from elsewhere, portal maybe.
Dates always get me a flutter but I trust you and will help test them once merged.
Looks good to me and thanks for the tedious work. Oh to be young again!:)
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.
It gets set to null at the top of the function.
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.
Thanks Stephen. I still want to take another look at referral note and clinical notes.
I think there should be an encounter pointing at transaction to be definitive that the transaction is the referral for the document and not the latest referral. Or should all referral history be shown in an organizer. This is one of those items my gut tells me to pay attention.
We can still branch after this merge if you want or do tomorrow after some testing today.
@sjpadgett Right now we don't track in the database any linkage between the encounter and the referral do we? I think we were debating adding a direct linkage back when we did CQM but we decided to not do that if I recall. As far as branching, I'd like to do it soon, but if we need to hold off until tomorrow I think that's fine. I'd like to have a backup demo machine just in case something catastrophic goes on with my local environment and we'll need to give @bradymiller enough time to do that. |
The preview button for ccda was failing
Okay to branch as soon as you want. |
Fixes #5508
Fixes #5517
Changes g9 $docref to be a POST api since we generate a new document
every time.
Fixes ISO8601 date problems with php since php's date constant is
incorrect. Switch to ATOM constant.
Fixed the ORDataObject saving incorrectly on some database instance
types due to the timezone and microsecond formatting.
Added __clone helper methods to the search field classes so we can copy
them and modify properties w/o modifying the references.
Added brief, terse documentation for g9 generation with docref. Needs
to be fleshed out in the fhir readme file.
Updated the swagger file to point to the g9 documentation.
Removed the remote xsl stuff as I found out chrome actively blocks
remote xsl's from rendering unless everything is in the same folder,
port, origin, and schema.
Changed up the filtering as careplan was still breaking due to its
requirement on an encounter. Changed up the filtering to be encounter
based so that any of the sections related to an encounter are filtered
for the CCD. I left non-ccd document types alone since g9 only requires
the ccd filtering.
Removed unused referral pieces in the care plan section as they were all
being skipped due to the missing required codes in the transactions
table. node side was skipping it as well so I left it off.