CCHIT - Messages

bradymiller wrote on Tuesday, February 02, 2010:

code review of Thomas’s cchit messages patch #7 here:
http://sourceforge.net/tracker/?func=detail&aid=2928938&group_id=60081&atid=1245239

Likely need to consider adding a status option selector in the note editor linked to the patient summary screen; or migrate this function to the Messages screen (with a patient auto selected).

messages 7:
interface/main/authorizations/authorizations.php

  • Why not wait until authorization code is actually functional somewhere else before removing it? Possibly better to just yank the patient note stuff and leave the authorization stuff there for now.

interface/main/left_nav.php

  • ok

interface/main/messages/messages.php

  • (SUGGESTED THIS IN LAST REVIEW) line 507 replace : $myrow
    with : generate_display_field(array(‘data_type’=>‘1’,‘list_id’=>‘note_type’),$myrow)
  • (SUGGESTED THIS IN LAST REVIEW) line 509 replace : $myrow
    with : generate_display_field(array(‘data_type’=>‘1’,‘list_id’=>‘messsage_status’),$myrow)
  • (SUGGESTED THIS IN A PREVIOUS REVIEW) -Change ‘Re’ to ‘Patient’ here alert(’<?php xl(‘Please choose a value for Re!’, ‘e’) ?>’);

library/options.inc.php

  • ok

library/pnotes.inc

  • ok

sql/3_2_0-to-3_3_0_upgrade.sql
-MISPELLING -> messsage_status-> message_status
-MISPELLING -> Messsage Status-> Message Status

  • (SUGGESTED THIS IN LAST REVIEW) Set ‘seq’ for ‘Lab Results’, ‘New Orders’ and ‘Patient Reminders’ all to ‘4’

sql/database.sql
-MISPELLING -> messsage_status-> message_status
-MISPELLING -> Messsage Status-> Message Status

Thomas,
Overall, the repeating of code error issues (not applying our suggested fixes or at least providing reasoning why not applying the fixes) is becoming a real resource drain on my end. Ensure your programmers look at our suggestions and apply them or explain why not. And after they make the patch, then look at it again to make sure all of our previous suggestions have been dealt with. If you guys don’t get your act together over there regarding these issues, then you’ll find that my free code reviews of your material will be getting much less frequent.  It would also be advantageous for your programmers to get sourceforge id’s and communicate here directly, since it seems like a lot of stuff is getting lost in translation.

-brady

bradymiller wrote on Tuesday, February 02, 2010:

To clarify above note, broke into two parts,

code review part 1 of Thomas’s cchit messages patch #7 here:
http://sourceforge.net/tracker/?func=detail&aid=2928938&group_id=60081&atid=1245239

Likely need to consider adding a status option selector in the note editor linked to the patient summary screen; or migrate this function to the Messages screen (with a patient auto selected).

messages 7:
interface/main/authorizations/authorizations.php

  • Why not wait until authorization code is actually functional somewhere else before removing it? Possibly better to just yank the patient note stuff and leave the authorization stuff there for now.

interface/main/left_nav.php

  • ok

interface/main/messages/messages.php

  • (SUGGESTED THIS IN LAST REVIEW) line 507 replace : $myrow with : generate_display_field(array(‘data_type’=>‘1’,‘list_id’=>‘note_type’),$myrow)
  • (SUGGESTED THIS IN LAST REVIEW) line 509 replace : $myrow with : generate_display_field(array(‘data_type’=>‘1’,‘list_id’=>‘messsage_status’),$myrow)

bradymiller wrote on Tuesday, February 02, 2010:

Here is second part of review,

interface/main/messages/messages.php:
-(SUGGESTED THIS IN LAST REVIEW)Change ‘Re’ to ‘Patient’ in the alert ‘Please choose a value for Re!’

library/options.inc.php

  • ok

library/pnotes.inc

  • ok

sql/3_2_0-to-3_3_0_upgrade.sql
-MISPELLING -> messsage_status-> message_status
-MISPELLING -> Messsage Status-> Message Status

  • (SUGGESTED THIS IN LAST REVIEW) Set ‘seq’ for ‘Lab Results’, ‘New Orders’ and ‘Patient Reminders’ all to ‘4’

sql/database.sql
-MISPELLING -> messsage_status-> message_status
-MISPELLING -> Messsage Status-> Message Status

Thomas, Overall, the repeating of code error issues (not applying our suggested fixes or at least providing reasoning why not applying the fixes) is becoming a real resource drain on my end. Ensure your programmers look at our suggestions and apply them or explain why not. And after they make the patch, then look at it again to make sure all of our previous suggestions have been dealt with. If you guys don’t get your act together over there regarding these issues, then you’ll find that my free code reviews of your material will be getting much less frequent. It would also be advantageous for your programmers to get sourceforge id’s and communicate here directly, since it seems like a lot of stuff is getting lost in translation.

-brady

anonymous wrote on Tuesday, February 02, 2010:

Hmm, this seems to be a patch file issue again. The programmers have documented and made change on every one of your requests. I always let you know if there is any question or disagreement. I can show you the patch that did have the changes.

The challenge we have right now is to constantly pull the codes apart because we are working on multiple MUs at the same time. As you know, I have done it multiple times on my own. It’s easier when it’s 1 person managing multiple instances. Here we have 4 people managing 3-4 instances each that also cross over into other instances.

I will send you a new patch file shortly.

anonymous wrote on Wednesday, February 03, 2010:

I resent you patch 6 (sent on 1/25) that has the above changes. This kind of patch issue will be greatly reduced as we start using multiple instances efficiently. We expect some issues during the transition period. The extra junk lines that you saw in another patch file came from no where. We have resolved that one too but still don’t know what’s causing it.