Re: [Gnumed-devel] Clinical record functional requirements

[Karsten Hilbert]

> So far *guiding* the gnumed project we have
> 
> - white papers at gnumed.net which, though labeled "GUI White 
> - white papers (Richard's)  defining gui concepts and screen design 
> - health record structure discussion initiated at gnumed.org by Tony

> We are laboring to build clinical function onto the schema. We have 
> some *very general* goals on the home page at gnumed.org, but AFAICT 
> it's not been defined further
It would be excellent if someone stepped up and wrote a better
mission statement.

> 1 easy and accurate identification of *individual* patients
Yes.

> 2 painless and efficient import, input, modification and export 
> (sharing) of patient data
Yes, but. Data transfer is never painless except under the
most controlled circumstances. It is also hard to make
efficient. But we want it to be *possible* right from the
beginning.

> - - painless might relate in good part to the GUI (on top of 
> computing performance)
Yes.

> - - efficient might relate to the logic and schema: smart data 
> conduits, data multi-purposing etc
Yes. What are smart data conduits ?

> 3 contextually presented patient data to properly *enable* assessment 
> and treatment needs
Yes. To make "getting to know the case" more efficient.

> 4 contextual overlay of reference resources to properly *guide* 
> improved assessment and treatment
Yes. Post-0.1, surely.

> 5 workflow tools to help assure that what should happen, does happen
I harbour that hope, yes.

> 6 later: practice analysis tools to apply to groups of patients for 
> QA/QI purposes
Due to the normalization efforts on the schema and storing
data in a stock RDBMS we already have that. But we don't have
a slick GUI. Which may, perhaps, better be left to "report
generators".

> 1 and 2 IMO are key to how we manage data in the correct patient records
> 3 and 4 IMO are key to getting ADDED VALUE from the electronic record 
> i.e. if we do not do this well, we are really not gaining  much - if 
> anything! - over a well-managed paper record.
Added value is actually the driving force behind those parts
of GnuMed that already work.

> So I would ask: what contextual relatedness / structuring of the 
> patient data are we really after?
> IOW what are the contexts?
You tell me the use case and we'll see how it fits into the
structure and whether that structure needs to be made more
generic.

> i) capturing information eg within an encounter
I would really like that and at least one real vendor has
expressly told me they would consider using our encounter
entry interface where we to offer one.

> - here we want to avoid redundancy and efficiently enter what is new 
> or changed, hence
> - - see if said data is already known, in which case maybe all we 
> want to do is confirm that it is still correct, and / or remains 
> active
> - - if the information is new or captures a change in status, make 
> these entries efficiently
This is achieved by the very integratedness of original
Richard-space. You see what's already there and you add on to
it with the old data in view.

> ii) making assessments and plans
> - here perhaps we want to take a step back? maybe look at a bit more 
> of what exists in the record, so as to not avoidable miss - duh! - 
> obvious connections among parts of a patient's record
We need to at least have the current/previous therapy in view
along with why they were done.

> - might the functional requirements be a bit different depending e.g.
> a) whether you are inside the encounter, dealing with the patient's 
> concerns versus
Yes, in there *I* would like to be supported in *entering*
data quickly.

> b) reviewing the chart in order to ensure you are adequately dealing 
> with the whole patient
Here I need to get a comprehensive yet manageable data
presentation.

> here, might b) occur as part of preparing to see the patient i.e. 
Yes.

> before getting into the thick of the encounter, maybe guided by 
> entries in Richard's scratch pad area.
I'd think that area is more for personal notes of the sort
"ask about seemingly troubling plan to buy new car"

> We might want start at a view 
> that lets us scope out the patient, maybe we decide issue B has not 
> gotten enough attention (and maybe drug C will need to be re-ordered) 
> so we switch into a view of what has been planned for the encounter 
> that is about to happen. We could note that the patient is coming for 
> issue A, but as we just decided issue B needs attention, too and drug 
> C needs re-ordering so it would be very helpful to "activate" issue B 
> and Drug C into some kind of list of things to be dealt with in the 
> encounter. Anyway this is a bit what I am thinking how a doctor may 
> want to shift among some related yet different views, as the 
> context/purpose from which they are seeing/managing things shifts.
The views sound useful. I think, however, it would only be
useful to have front-desk staff (if acceptable) bubble to the
top episodes to be dealt with this encounter. Other than that
sorting youngest-first should catch most needs related to
quick access to episodes from a simple list of all of them.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346