Re: [Gnumed-devel] Re: Vaccination as a starting point

[richard terry]

PLEASE READ THE WHOLE THING AS COMMENTS ARE INSERTED. KEPT IT ALL TO KEEP THE 
THREAD FOR THOSE NOT YET INVOLVED IN THIS DISCUSSION:

On Monday 22 July 2002 12:30 am, Karsten Hilbert wrote:
> >> For each immun. a timestamp, the immun.type (reason:
> >> prevention, travel, exposure, ...), the exact name of the
> >> vaccine, the charge/lot/batch ID, the injection site/type
> >> should be recorded.
> >
> > +should we have a line for 'reacton' in case patient has a problem with a
> > particular vaccine.
>
> I would say, yes. Question is, where should this reside ? Does
> it belong into "adverse reactions" in the allergies/reactions
> window ? Does it make sense to put a line for that into the
> Vaccination edit area - since most likely we will never yet
> know if there's going to be an adverse reaction to a vaccine
> we are giving right now.

I'd personally put it on vaccines for the following reasons. 

Firstly, as a general concept, one thing I did with my medical records 
program which was very successful was that as you did work in each section, 
the progress notes were compiled as you went. When I presented this back in 
the progress notes, the clinical data was coherently grouped into sections ie 
scripts written, immunisations, referral letters etc. .

Now to be question above. Even though rarely used, it dosn't take up much 
space and we can auto skip over the field in code as a default. Putting it 
there will automatically link it to that episode of vaccination. If it was in 
a general progress notes it would be much harder to link.


>
> > > Certain vaccination types should be able to trigger GNUmed
> > > "request" events (check HepB titer 10 years post vacc., prompt
> > > for boosters/repeat vacc. on multiple base immunisations, alert
> > > for overdue vacc.s)
> >
> > Agree. In my program I linked age to the schedules and did a check when
> > the
>
> I wonder if people caught the subtle hint towards a
> generalized request-delivery framework inside GNUmed.
>
> Scheduling an appointment will file a "request" for "seeing the
> patient" at that date.  etc etc.....

This is a really great idea. No I didn't catch that but it is a beautiful 
concept and full of endless possibilities.
>
> Recording a pregnancy files a request for recording an end of
> pregnancy with outcome (of course, making it easy to link the
> newborn's to its mother's record).
>
> Ordering lab work files a request for completion of lab test
> (if in-house) or reception of results (if offsite). Much the
> same with X-ray, referrals to specialists and the like.
>
> Recording a hypertension will file repeated requests for blood
> pressure checkups.
>
> Recording a diabetes mellitus files requests for regular
> referrals to eye care.
>
> Recording some fracture files a request for an appointment in,
> say, 10 days depending on type of fracture.
>
> Some request-fulfilled records will be kept (X-Ray for
> documentation of due course), some will not (request for
> scheduling an appointment where only the resulting appointment
> will be kept of course). Some will vanish completely (scratch
> pad note request to ask about how the gardening is going).
>
> The possibilities are endless.
>
> > patient was first loaded. The flashed up a sign if immunizations were
> > missing. Got a little messy because of
> > a) Doctors putting vaccines in incorrect schedules
>
> Garbage in, garbage out. Not much, really, we can do about
> this. It should be easy to change previously incorrectly
> recorded vacc. data.
>
> > > Those mechanisms should be based on pluggable guidelines.
> >
> > This raises many issues. In australia we have immunization schedules (as
> > I presume all countries do). The schedules however are constantly being
> > modified e.g we had a situation not long back where kids born prior to
> > 01/05/2000 were on one schedule, and those after 01/05/2000 on another.
> > This
>
> Sure, we just shouldn't try to _force_ people into certain
> schedules. Just make it easy and convenient to comply with
> them (and easy to switch them off).
>
> > is not a problem if you present vaccines as either a schedule or a
> > disease target; eg in my edit area:
> > Target
> > Vaccine
> > Date given
> > Serial no
> > Site
> > (reaction)  - not there but perhaps we should
>
> Looks good.

I've reflected on this overnight. I think we should add a line - schedule.
Sometimes one will trigger the first phrase wheel on the target line eg.
meningococcus, and in some cases the schedule will me absent or a duplicate 
of the target. At others eg aggregated childhood immunization it will be 
different eg: here, the user would start typing in at the schedule line, but 
the target disease would be filled in automatically and that line made 
temporarily read only:

Target                Tetanus, Diptheria, Whooping cough, Hepatitis B   
Schedule            2 month childhood
Vaccine              Infranix Hep B
Date Given        etc
Serial no
Site
Reaction.


> > The Target can be a disease, combinations of diseases or schedules
> >
> > One a schedule is chosen, all the vaccines in this schedule are
> > automatically presented, or or a disease is chosen, here meningococcal,
> > ditto. Hitting enter on a vaccine them puts in a default date(today)
> > which you can change if entering past vaccine information, and the last
> > vaccine_serial number used for this brand of vaccine (which again you can
> > edit).
> >
> > To put in the site, I just enter by hand, but one should have quick
> > abbreviations built into this line eg ld  would autoexpand to left
> > deltoid etc.
>
> A phrase wheel helps, too.  :-)
>
> > > It may be beneficial to be able to "link" vaccinations to
> > > particular lab results.
> >
> > Agreed, but looking into the future here
>
> Agreed, although it nearly naturally flows from the request-result
> mechanism.
>
> > > Recording a vaccination should create an event in the patient
> > > state tracking time line (where major things like hospital
> > > admissions, major diagnoses, off-work, pregnancies, etc. are
> > > linked together to form a coherent picture).
> >
> > Yes, but again we need to walk before we run.
>
> Agreed.
>
> I'll start from your tables and post something for discussion
> soon (hopefully).

Some other things that occurred to me which we have to build in. The problem 
of someone presenting as a new patient to a practice with no electronic or 
paper records of vaccination except so the 'baby book'. It is laborious to 
put them all in by hand. In my program I wrote a 'wizard' which automatically 
created database fields of what they would have had and the approximate date. 
It worked, but I abandoned this as it is not historically accurate, though it 
satisfied the computers need to check for missing immunisations. We will need 
some mechanism to state immunisations are up to date.

Also some patients refuse vaccination. We need a mechanism which links to the 
refusal to a target vaccine or schedule. I can add a checkbox  Refused by 
patient to the edit area as there is plenty of room.

Another thing, each schedule or target will need a generic entry for the 
situation when brands are unknown.
>
> Karsten