[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: Vaccination as a starting point
From: |
richard terry |
Subject: |
Re: [Gnumed-devel] Re: Vaccination as a starting point |
Date: |
Mon, 22 Jul 2002 08:55:54 +1000 |
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
- Re: [Gnumed-devel] Re-kindling the debate on the database structure, (continued)
Re: [Gnumed-devel] Re-kindling the debate on the database structure, Karsten Hilbert, 2002/07/17
Re: [Gnumed-devel] Re-kindling the debate on the database structure, Elizabeth Dodd, 2002/07/17
Message not available
Re: [Gnumed-devel] Re-kindling the debate on the database structure, Karsten Hilbert, 2002/07/21