Please excuse if you know most or all of the following, I am posting mostly for others who might read this thread.
It is important to realize that an exported clinical kit is not a valid form for editing and always should be audited and cleaned up prior to reimporting. Some background might explain it.
The EMR 'creates' a form in the system using multiple files:
- XLW - Watcher expressions and functions
- XLT - Translations and some functions
- EFM - Specifications for drawing the form on screen and some MEL coding. Additional tabs use EF2, EF3, etc.
- PEF - Printed form content
When using an editor, such as VFE, a SOURCE CODE file is created. It houses additional information needed by the editor to present items in their assigned locations. Because the EMR cannot interpret this file nor does it have a need for it, it is not imported with the clinical kit and likewise cannot be exported either.
So why does VFE permit opening an exported kit? This functionality was added for an emergency recovery when the source code has been lost or damaged. As mentioned when opening a clinical kit, it is not to be used to recreate/modify copyrighted material.
When recreating a form for editing from a clinical kit, a few things need to be considered:
1) The recreated form uses the files mentioned above to approximate what design the form originally had. It won't be exact every time and more complex forms will require some degree of clean up.
2) All translations are grouped in a single element and should be restored into their proper locations for ease of downstream revisions. Another reason this step should be performed is that it affords the opportunity to audit the code to ensure it is clean (very important).
3) All MEL code that was not associated with a form item will be presented in the right window of VFE (MEL window). This is the only way this can be done since VFE cannot determine where it existed previously given it is all stored in the XLW and XLT files and no indicator of the original position is included when importing.
4) Document Variable names may be altered to include a workstation ID plus date/time stamp to ensure uniqueness in the system. The same form saved at two different times may have different variable names as a result.
5) Obsterms are given unique function references (OBSNOW is actually a function) to ensure uniqueness. These references should be removed when present so that VFE can create new ones (part of the audit).
6) Some functions/data symbols are replaced with a unique function reference, similar to obsterms, especially when associated with action buttons. These too should be addressed in the audit.
Suffice to say, unless one has extensive experience with and knowledge of MEL and encounter forms, they should seek assistance when recreating a form from a clinical kit - there is a lot that can go wrong and unless a MEL trace is run while every aspect of the form is tested, much of it can remain hidden from view or make it appear that a different form is experiencing issues.
With regard to your specific inquiry:
Those characters are not standard in MEL syntax as presented. It would be difficult to suggest that the 'stray characters' are safe to delete without reviewing the exported clinical kit, but I would think that they could be. You will also note that the function name is a series of numbers, potentially indicating that was originally linked to a button. It might be that the unconventional character use caused VFE to 'misplace' the code and insert it into the translation instead of the associated button (in other words, it may have been in the XLW file). You might consider renaming this and restoring it if that was the case to make future editing easier.
I hope this helps.
Posted : November 19, 2020 4:39 pm
