[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Appointments, records of care, and the capture and ev

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Appointments, records of care, and the capture and eventual storage of services as billable items
Date: Sun, 9 Dec 2007 01:05:36 +0100
User-agent: Mutt/1.5.17 (2007-11-01)

On Sun, Oct 07, 2007 at 11:39:34AM -0700, James Busser wrote:

> I am doing a bit of a mental walk-through as one goes from an appointment, 
Going along with the flow of thoughts:

I have been thinking on and off about how to "ideally" "do
appointments". I have eventually come up with nearly the
same conclusions as you do namely that ...

> I am thinking that appointments are not themselves clinical... they are 
> really just "reservations" for encounters,
... a large part of a patient-doctor-appointment is non-clinical while ...

> and some information about what 
> needs to happen in the encounter may already exist because of leftover 
> items (or a plan) from a previous encounter, or may exist as a result of 
> other information that was received about a patient (i.e. would be an 
> action item arising out of a non-patient contact encounter) plus any things 
> newly wanted by a patient.
... there are clinical things that they may need to be
augmented by.

> Appointments (reservations) would be for:,
> - one or more patients
> - one or more providers
> - we note that a multi-patient (and/or multi-provider) visit type could 
> expect multi-bookings
> - a specific date
> - a specific time (start time) -- except if the time is left blank pending 
> a "fit-in"
> - often, a planned duration (which is translatable to an end time)
> - a location (because the doctor may see a patient at the patient's home or 
> other locations)
> - a particular exam room may also need to be specified

All of which a well done appointment/scheduling solution
provides for.

> Now here comes the trickier part. The appointment will be for one or more 
> things to be assessed and/or treated. The appointment must expect (and may 
> have to facilitate) one or multiple professional services (evaluations, 
> procedures and treatments) and may also require that certain equipment or 
> supplies (things like PAP smear or microbiologic specimen swabs or 
> vaccines) be available.
IOW, the medical record should have the ability to specify
"plan" (and other) items and link them to external
appointments. KOrganizer, for example, provides an
externally accessible (with, eg, konsolekalender) ID unique
for a certain appointment.

Separation of Concerns is at work here, coding-wise.

> - the nature of the one or more things that need to be evaluated or done 
> will determine the total length of time and other dependencies needed for 
> all items to be fully completed
Some requirements can be factored into the scheduler setup
(lenght of specific appointment types, needed
rooms/equipment/personnel) while other things may still
influence the expected duration of *individual*
appointments. Those need to be in-the-face of the scheduling
staff at scheduling time which asks for good GUI design.

> - what *was* completed should be captured in or at least *with* (or linked 
> to) the encounter.
We don't record yet "did or did not show up for
appointment". We do, however, associate all data with a
(GNUmed-level) encounter.

> How might this relate to the sOaP parts of the note? A 
> certain type of physical exam like a Folstein mini-mental exam and/or a 
> sigmoidoscopic exam or a pelvic exam with speculum and PAP test could be 
> coded to the sOap row
Yes, to a subclassed sOap row.

> --- though we do not yet provide for this
There are some backend provisions for that but the frontend
doesn't use it yet.

> treatment like a vaccination or the fact the counselling or education was 
> done and/or consent obtained into the soaP (Plan) row --- but again we do 
> not yet provide for this.
We do have code/widgets for vaccination handling - although
they aren't officially released yet.

> The schema so far provides only for:
> ... types (like history, family history) to be linked to soap rows and
> ... diagnostic codes to be able to be linked to soap rows of type "A" 
> (soAp)
No, it provides much more - for one thing the type is
entirely arbitrary and can be used to extend GNUmed clinical
narrative in an EAV/OpenMRS concept dictionary way. One the
other hand we have a bunch of soap-subclassing tables (like
vaccination or allergy) which greatly extend the narrative
in item specific ways.

> but if we agree it is useful to be able to see or figure out or query 
> whether and when certain things had last been done, how is that best 
> structured?
> I know that we planned that if a prescription were written, the 
> clinical note would capture some representation even though the 
> prescription itself gets built from rows in a medication table.
Yes. Or rather, the "narrative" representation of the
prescription is a textual *view* onto the specific
medication/prescription rows joined into the total_narrative

> So should 
> "things" that have been done to patients, such as a major or minor 
> consultation, various kinds of examinations and office procedures, be 
> stored in a "what was done" table?
That table is a "view" in database terms and joins all kinds
of things into a textual representation thereof. The power
of inheritance allows for simplification thereof.

> There does exist an "operations" table 
> but maybe it is not intended that office procedures be included, and maybe 
> some should, for example an office vasectomy.
Sure, why not ?

> - there is also what was *planned* (in previous notes) or *wanted* by the 
> patient to be done, but was not completed at this encounter, and will have 
> to be completed later, along with any newly-added plans 
Such things will either be captured in narrative or in
dedicated "planned_things" tables (think Managed Care plans).

>> from the current encounter, and these things therefore need to be 
> able to exist and be managed in a way that helps them to get actioned 
> without the future appointment having yet been made
Yep, that's why there's administrative and clinical side to
appointments and what they stand for each being catered to
by a scheduling application and associated clinical data
capture respectively.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]