I’ve made some changes to the immunization form. I’ve added a few fields and will create a shot record also. I’ll check these in sometime this week. I’ll also add a script to convert the current immunization info to the new info (copy the records from the list table to the new immunization table). The reason for the change is to record info that is required by some state health agencies. The change will minimally affect existing users as far as functionality, i.e. you’ll go to the same place to enter the data, the form will just look different.
BTW the fields are:
Vaccine/Immunization
Vaccine Administered Date
Vaccine Manufacturer
Lot Number
Administered By
Patient Education Given Date
Note
First, it sounds like each immunization will be associated with exactly one encounter. So I’m wondering if this would be better implemented as an encounter form. My impression is that things in the lists table are commonly associated with multiple encounters - which is why they are not encounter forms.
Second, if you really want to put on the same screen with medical problems, surgeries, etc. then you should touch base with Mark Leeds. He also has a small addition to this area that I’ve been working with him on and was planning to check in for him next week.
I have no problem with a separate form for immunizations. I agree that there is more important information to track than just the name of the vaccine. Many practitioners will want or need to be able to track their level of compliance with the recommended immunizations schedules for their patient population.
This really applies to the other list items too. There is more than just a name to record so you end up with info in two places, an encounter form and the list table.
I agree with Rod that it should be implemented as an encounter form. You will need to be able to enter more than one immunization per encounter though because the patient might get several shots per visit and the patient may bring past immunization records with them that you may want to enter into the database.
The problem with entering data in an encounter form is that you need a good way to view the data. The view of the data can be built into the form in the report.php file, but there has to be a better way to get to it.
The fact is that we need to concentrate on writing some great forms. They can have complex table structures and cgi interactivity on both ends, entering and viewing. There is really a lot of great things that could potentially be done within a form. A great set of forms may even outlast OpenEMR.
There is indeed more to an immunization than the current level of documentation such as:
Immunization
lot number
date
route
location (if by injection)
person performing the injection
Having this in the encounter area will solve a lot of problems including the need to frequently print and fax this to other entities. State health organization, schools, summer programs, etc.
However, the current printing of encounters would like case this to fall randomly as a generic "encounter" at the bottom of the list. The immunization record should be listed high in the persistent part of the printing area (with the rest of the problem list: problems, medications, allergies, surgeries)
But it is still nice to have a summary (name:date) displayed in the summary page as part of the "Problem List".
Regarding printing and easy access to immunization records: if the info is in the database, it’s relatively easy to create reports. You can even add simple reports to the Reports page in OpenEMR using the Database Reporting section without having to write any PHP code.
In my view the important thing is to get the database structure right. My issues-and-encounters tool will provide the ability to manually link things to encounters, but that should not be necessary for things like immunizations which already have a direct relationship to one encounter.
I will initially keep it where it is in the summary section since that’s what I have coded thus far, then later create a encounter form. That way there will be minimal “retraining” required. The other choice is to not put it in cvs until I code it as an encounter form, but that may take a little while as I have a couple other “requirements” to finish (namely, a beefed up referral form and a growth chart). Then on to the encounter forms…
By the way, what do you do about immunizations that the patient had done elsewhere, but that you want to track so you’ll know when they need their tetanus booster or whatever?
This also brings up the need for a reminder system.
offsite immunizations: why not enter them in the same way with a field (checkbox) to document that the shot was given elsewhere? It is very common to have patient’s come in from other doctors with immunization records. With managed care, patient’s move from one doctor to another frequently.
The administered_by field will be implemented as a select field where the values for the list are taken from the valid users of the system. Now, this imiplies that only users of the system can give shots, of course, one could add dummy users such as "External Facility" or whatever to cover the case where the shot was given elsewhere. But, perhaps another table altogether should be used??? Not sure what would be best. I could of course leave it as a text box, but then everytime one would need to type in the user.
The external-facility case is fundamentally different. In that case the information is not encounter data, and you are not responsible for (and will probably not know) many of the details such as lot numbers and who administered the service.
Services rendered at your clinic should be part of the encounter (though as you already mentioned, the encounter form version will happen later). Otherwise it should be (conceptually) a piece of history information, like the "lists" table tracks now.
This is not to say that you can’t use the same table for all shots and immunizations - nothing wrong with that. It’s just that your software needs to present a suitable interface.
One possibility might be to have a checkbox to indicate that the shot/immunization was administered elsewhere. In that case your list of users and some other input fields can be greyed out (using a little bit of JavaScript).
For in-house services, don’t you want the person administering them to enter the information? So you may not need the list at all. Or if you do, restrict it according to user permissions.
So now we get to talk about permissions - i.e. who is authorized to enter and view those services. Take a look at library/acl.inc. It may be a good idea to create a couple of extra ACOs in the Encounters section, something like this:
nurse - nursing tasks
nurse_a - nursing tasks on behalf of others
If you do that you may have some questions; feel free to ask me anything.