All,
I'd like to offer a view on this topic. While I have an, as yet, brief
involvement into this field of health informatics, I have been involved in
'informatics' outside of health for many years, although that term is not
used much outside of healthcare it is a very similar practice. So I'd like
to inject some thinking from 'outside' into this conversation. I seek your
forgiveness in advance if I make some newbie faux pas
---
>From my own research, I recognise most of the technical semantics used in
this conversation so far (null_flavour etc)
I fear that implied in this discussion is the design restriction that all
possible answers to a particular line of questioning must be captured by one
data element. In classic information analysis, this is flawed thinking.
Reading the dialogue so far, I believe there is in fact a clinical dialogue
about which we need to know and that dialogue has many elements that need
recording.
For example: (and this alone is debatable, but one example of the dialogue
that might be occurring)
*Q1: Does the patient have diabetes? (possible answers are yes/no/don't
know)*
A: don't know
*
*
*Q2: Have you previously sought this knowledge? (possible answer are
(yes/no)*
A: yes
*
*
*Q3: How did you seek this knowledge? (myriad possibilities, determined by
clinical knowledge. eg patient question, path test, etc))*
A: Patient Question.
*Q4: Why do you not if the patient has diabetes? (aka: describe the nature
of the patients response to this questioning) (huge range of possible
answer)* (<= this is what null flavour tries to do - I think)
A: Patient unsure -or- Patient refused to answer -or- ...
In the typical use case, a boolean answer to Q1 is sufficient, if the answer
is "don't know" then we want to know some more. If the answer to Q2 is "no"
then we might go talk to the patient. The actions taken depend on what we
know (and don't know) , hence the additional line of questioning. But there
may be other scenarios where, even if we have a boolean answer to Q1, we
still want to know answers to Q2-4
----
After all that, the preceeding conversations are all predicated on the
decision to capture all of the information available in the above dialogue
into one data element. WOW, No wonder this is a lengthy discussion, its
discussing information requirements within the confines of a solution
pattern/approach. Our ability to express requirements seems to be
constrained by design patterns.
My approach to this requirements conversation is to apply the rules of
normalisation, not because we're going to a relational solution, but because
it effectively teases out and separates the many requirements.
In this scenario, I think the only valid answers to Q1 are (yes/no/don't
know)
Using null flavour in place of don't know is overloading the data element.
Null flavour suggests that Q2-4 are only relevant when A1 = "don't know". I
challenge that assertion. When clinical decisions are under review (legal
or otherwise) is it not important to also know the basis of the data that
informed the action? Assuming 'yes' then there must surely be a problem?
As we only capture this information when A1 = 'don't know' Alternately, we
should always capture the answer to Q1 AND how we got to that conclusion.
Back in the good ol' days of pen and paper, I'll bet someone wrote down on
the registration/admission questionaire: "yes" in response to the written
question: "Q1: Is patient diabetic?". Through the use of the questionaire
form (meta data) and the notes captured therein (data), we can answer all 4
questions regardless of the answer to Q1. This is so much more informative
than yes/no/don't know{null_flavour}.
So it seems there is a need to at least record data representing answers to
Q1, 3 & 4. The answer to Q2 may possibly be derived by analysing the
answers to Q3 & 4. Similarly, the dialogue will differ if the asnwer to Q3
is "pathology test".
My point is that these scenarios (requirements) ought to thought through
independent of the tools available to meet the requirement in order to
properly understand the requirement and avoid the risk of overlooking
important requirements because of the difficulty of expressing them within
the confines of our available tools.
Regards
Russell
On Thu, Feb 10, 2011 at 4:12 AM, Ian McNicoll <
Ian.McNicoll at oceaninformatics.com> wrote:
> I should have added that this is not an openEHR issue but applies to
> the whole of health informatics and would, IMO, make an excellent
> subject for a PhD. We badly need the kind of academic analysis
> equivalent to Alan Rector's work on the 'clinical statement' pattern
> which underpins most of SNOMED, openEHR, 13606 and HL7 semantics.
>
> Ian
>
> Dr Ian McNicoll
> office +44 (0)1536 414994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
> Clinical analyst, Ocean Informatics, UK
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care www.phcsg.org
>
>
>
>
> On 9 February 2011 17:29, Thomas Beale
> <thomas.beale at oceaninformatics.com> wrote:
> > On 09/02/2011 15:05, pablo pazos wrote:
> >
> > I agree with you Thomas but there's always some implicit semantics, I
> mean:
> > when there is no data, it is taken as false, but what happen if the
> person
> > who do the questionnaire do not try to make this question false? May be
> > he/her didn't want to answer, and this false could have value/semantics
> in
> > clinical or legal fields.
> >
> > Hi Pablo,
> >
> > my point is that in some cases, researchers construct questionnaires for
> > healthcare use that will have some purely boolean answers, and they
> simply
> > won't use responses containing missing answers, i.e. they will only use
> > clean data. A question like 'have you ever had children' for example in
> such
> > a questionnaire can be modelled as Boolean if the researcher wants simply
> to
> > divide the population into two - women who gave birth, and women who
> never
> > did. Any response like 'don't know' would be discarded in such a study. I
> am
> > not saying that this is good study design, or anything else (it isn't my
> > area), but we can't prevent medical researchers from creating
> questionnaires
> > with purely boolean answers, if that is what their statistical computing
> > model requires.
> >
> > - thomas
> >
> >
> >
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
> >
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110210/1d30d2f0/attachment.html>
