Re: [Gnumed-devel] ?Master .xls file needed for opinions on SOAP

[Karsten Hilbert]

> It has occurred to me with the ongoing data-input debate that we really 
> should 
> have a spreadsheet with columns for each developer and summary of each of the 
> potential SOAP etc lines so we can fully understand the needs we all have. 
> Jim seems to be good at synthesizing stuff - I wonder if perhaps he could do 
> this? Personally I find it impossible to keep in my mind all the different 
> threads that have gone before.
This sounds useful and is easily done with a table in the
Wiki.

I think, however, we need to cleanly separate two things:
intrinsic vs extrinsic types of clinical data.

Intrinsic:

I consider those to be like datatypes, eg. float, int, string,
timestamp. Mappend to our domain these are S/O/A/P.

Eg. everything that we are collecting as non-rationalized
opiniated bits of information out of the void is of datatype
"subjective". This can be my as well as the patient's ideas on
things. For observation those often include conjectures and
gut-feeling judgements etc. In literary terms this is a novel
about a car ride.

Other bits of data that are obtained by (supposedly) objective
means are of datatype "Subjective". Those may be measurements,
clinical findings. Their foremost characteristic is that they
should be void of attached judgement and verifiable as much as
possible. Again, these needn't only be my "professional"
physicals findings. In literary terms this is an essay on
driving.

Note how I don't say Subjective = patient, Objective =
provider.

Pieces of data that I note down for expressing what I *make*
of Subjective and Objective to form a more or less coherent
picture is of data type Assessment. Such stuff should
preferably be substantial and trustworthy in being about
right. This is a mechanics' note on what's wrong with my car.

What is (intended to be) done about things is of data type
Plan. This is the plan of proposed fixes I need to clear
before the repair shop can proceed.

For structured capturing of clinical information this has
served very well. It doesn't matter whether one invents a cast
of thousand names for Subjective. Call it Purpose, RFE,
Intent, Patient Goal, you name it. It is fine to have several
differently labelled input lines for such things. It is also
fine to tag such input more finely grained than SOAP *only*.
Nevertheless, one needs to make sure to tag them with SOAP, too.
It does not help very much to know that a particular jumble of
bits is about Mrs. Smith' view of her gallstone troubles.
What is needed first is that that jumble of bits is an 8-bit
Latin1 encoded 0-terminated string. This is needed for knowing
how to turn those bits into something a doctor can make sense
of. By simply reading the doctor will know what that string is
*about*.

Now, in any case is it very useful to tag data in any number
of ways. If someone decides (or a group decides to push that
onto their members) that they not only need to split S and O
but also need to able to tell apart S-RFE from S-HxTaken -- so
be it ! Let them tag that to their hearts content ! We already
fully support that in the backend. Any clinical item can have
any number of types associated with it.

> It seems to be there is some intransigence on some parties parts - 
> politically 
> I can't remember who, but I seem to remember statements like 'I won't 
> compromise on that...' - methinks it was perhaps Karsten
I am quite sure that was me. The phrase seems correctly
remembered. If you unearth the post I'll answer on why. In all
likelihood I was not ready to compromise on concepts. Little I
care about how one labels things. Also, it likely was that I
was unwilling to sacrificing proper structure in favour of more
conveniently accomodating *content*. However, I have never
been opposed to acting on strong evidence to the contrary of
my own beliefs.

> Also This whole process yet again shows me the severe flaws in back-end 
> database design before an accepted functionality has been reached.
Functionality-driven database design will get you *somewhere*
faster. But you won't be going anywhere else from there. You
need to analyze what types of data you want to store, then
store that, *then* worry about display problems. Functionality
as in display means assembling normalized data. Functionality
as in computation usually calls for *better*/more rather than
less normalization.

> There have 
> been comments such as 'would require a major database re-design in that area'
Either the current design in that area wasn't Good Enough. Or
it was and someone wanted to change basic concepts. Other
reasons for redesign aren't worth considering in any case.

> It may be that yet again the have different per-country requirements which 
> are 
> insurmountable.
Nope. Data is data. It doesn't care about politicians' dim
wits.

> Karsten - I wonder from reading some of your stuff - is part 
> of it that if you don't stick to the proposed skeletal SOAP lines, that you 
> can't import data from existing german medical records systems?
Not a whit do I care about that. The more properly designed
that database is the better our chances are. Nevertheless some
entangling with German structures may have slipped in here or
there simply from working from those requirements and not being
able to appreciate the unknown full range of requirements
worldwide. I ahve always encouraged comments and criticism on
that part.

> There are other considerations such as research considerations, where 
> splitting up to lines greater than the SOAP number could be usefull (eg 
> Patient History) in looking at issues in general practice which could later 
> lead to research to investigate an hypothysis.
Again, GnuMed allows you to classify clinical items till you
drop. Arbitrary limits only.

> Anyway, I think we need to continue to thrash this debate to death until we 
> come up with something that works and is acceptable to the majority of us.
Surely so.

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