[Gnumed-devel] Clinical record functional requirements

[J Busser]

So far *guiding* the gnumed project we have

- white papers at gnumed.net which, though labeled "GUI White 
Papers",  more define the _computing_ design on which the GUI must be 
built

- white papers (Richard's)  defining gui concepts and screen design 
to _maximize user ease of use and productivity --- presumably 
enjoyment, too_

- health record structure discussion initiated at gnumed.org by Tony
http://www.gnumed.org/documentation/develop/discussion/ehr.html
supplemented by various recent threads on the list

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 Are we aiming at the following, in 
respect to *clinical* functional design?

Goals in support of patient *clinical* management
-------------------------------------------
1 easy and accurate identification of *individual* patients
2 painless and efficient import, input, modification and export 
(sharing) of patient data
- - painless might relate in good part to the GUI (on top of 
computing performance)
- - efficient might relate to the logic and schema: smart data 
conduits, data multi-purposing etc
3 contextually presented patient data to properly *enable* assessment 
and treatment needs
4 contextual overlay of reference resources to properly *guide* 
improved assessment and treatment
5 workflow tools to help assure that what should happen, does happen
6 later: practice analysis tools to apply to groups of patients for 
QA/QI purposes

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.

So I would ask: what contextual relatedness / structuring of the 
patient data are we really after?
IOW what are the contexts?

i) capturing information eg within an encounter
- 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

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
- 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
b) reviewing the chart in order to ensure you are adequately dealing 
with the whole patient

here, might b) occur as part of preparing to see the patient i.e. 
before getting into the thick of the encounter, maybe guided by 
entries in Richard's scratch pad area. 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.