I’ve been trying to modify the Graphic Pain Map form to my own purposes. Specifically, I’d like to have several such forms with maps of the anatomic areas of interest to me. As an ENT, these would logically include the eardrum, the oral cavity, the larynx, the nodal areas of the neck and things of that nature, to name a few. This has been successful, to a point - but only if I have only one such map per encounter. Please examine the attached examples.
1_neck.png demonstrates a neck graphic with two example data points. They both save and are displayed appropriately.
2_oralcavity.png demonstrates an oral cavity graphic, this time with only one data index but nevertheless it still saves and displays as entered.
The problems begin with 3_both.png. In this example I have arranged to have two separate graphic maps linked to the same encounter. It is not at all inconceivable that I might wish to do this, for example, if a patient were to have an oral cancer and several noteworthy metastatic cervical nodes. The data saves correctly (confirmed by reviewing the entries in the form_neckmap and form_oralcavitymap tables) but doesn’t display correctly. In examining 3_both.png, you will note that the legend for the first entered graphic (the neck) displays as desired (1 mandible, 2 thyroid cartilage) but that the map indices (1 and 2) don’t display on the neck graphic. Rather, they display on the upper oral cavity graphic in positions that would be correct if only they were translocated downward on the page to the same relative position on the lower graphic. Also, note that the oral cavity indices are not displayed at all and that the oral cavity legend is merely a duplicate of the neck map legend. It’s as if the neck map data is overwriting the display of the oral cavity map information. Curiously, however, if I then delete the “Graphical Neck Map” (by pressing the delete button pictured on the encounter interface) all becomes well with the world once again (both the index and the legend for the oral cavity map appear as expected).
Any ideas? I suppose that I could get around this by simply having one “super graphic” page with all conceivable anatomic sketches but I’d really wish to avoid it. Thank you.
It does seem that only one .png & one set of annotations are permitted per form.
If a single composite .png is not acceptable, openemr/interface/patient_file/encounter/load_form.php?formname=painmap will need to be changed accommodating multiple sets.
MI-Squared authored the form. While waiting for them to respond, peruse the script.
This addition is still under construction, but it shows a great opportunity for other forms of this type. If you could help to explore and give indication of what else is possible even better!
Tnx in advance for your support. This is a long time wish from my side.
“2104”? Wow, we’re advancing technology by leaps and bounds! I hadn’t been aware of that and will have to look at it. It would actually be useful to draw something rather than simply but a label index on it. Much better for mapping out tumor extent and things of that ilk.
This is probably the wrong place for this question. Please redirect me if necessary. I’d like to download the eye_mag code and experiment with it without polluting the development environment for everyone else. As such, I’ve downloaded the contents of the eye_mag folder and placed in in my interface/forms folder. I’ve then registered the form, installed the database and done everything I usually do when installing a new form. I know something is working because I don’t get a “white screen” when I attempt to open a new “eye_mag” screen in an encounter. Unfortunately, now I get a “yellow screen” (my default OEMR color) and nothing else displays. What to do? Where/how can I get a direct copy of the code used in the demo? What do I do with it when I get it? Inquiring minds want to know. My usual brute force development method of tweaking and retweaking until I get something that works implies that it has to work at least at a baseline level at the start.
Ah yes, but my ultimate goal is to pilfer/adapt the code for my own evil (otolaryngologic) purposes. Unless I have my own local code to tinker with I would imagine that if I play with the “public” code by inserting my own graphics, etc., I will down the opportunity for everyone else to look and see at least for the remainder of the day. That is, unless I can somehow fork the code and experiment only on my own branch. I would imagine that’s how github is supposed to work but I have little direct experience with it (hence I like to experiment on my own machine locally).
Please take just a little bit of your time to read the WIKI on Github for Dummies in OpenEMR.
They encourage you to make the connection and download the part you are working on to your local machine. If it works, bring it back into Github.
It is not my favorite software, but it works once understood. The Deoms are great, but not to experiment with new parts in Forms of whatever kind. For that you need to do some works in the software behind the scenes.