Pei and Tim - Good questions.

The bottom line is that OPQRST is the algorithm that every clinician uses
to characterize the history of a sign, symptom or constellation of
symptoms. Each letter has multiple meanings, but generally they're grouped.
O for onset, was it quick or slow in onset, P for palliative or provoking
phenomenon, that is, does tylenol make it better? Does it feel better when
you lean forward? Is it worse with standing? Q is the quality, generally,
though I could give more examples of each Ill keep it brief from here, R is
generally region or radiation of the pain and or sign, S is the severity,
and T is the time course, is it intermittent? When it happens, how long
does it last for? I could send documents used to teach new clinicians to
better comprehend for anyone interested.

OPQRST, while most residents would assume it is only for teaching new
clinicians, as Tim said, is a useful tool at all levels. Great clinicians,
and I work with some great senior folks, use this everyday. The idea that
it is only for teaching is founded on two things: one, that it doubles as a
structured mnemonic for characterizing signs and symptoms and two, that
everyone so far ingrains this into their clinical skill set, unless they
are geared toward teaching, they, after the basic level, never think about
it again! Caveat: many good clinicians will tell you to keep it algorithmic
so that you're systematic and do not overlook details.

What is it's application to ML? Obviously the furthest desired end-state
for NLP like cTakes would be understanding a clinical encounter to such a
nuanced level that detailed diagnoses could be considered along with
treatment plans. While I only know what I've read in Artificial
Intelligence: A Modern Approach and picked up from friends over the years
who were good knowledgeable in this field, I feel that OPQRST would be a
huge benefit toward beginning to outline the problem of more rigorous ML
characterization of the clinical narrative.

The utility of OPQRST may not still be entirely clear to those who have
never been presented with a clinical encounter. Let me try one more stab:
Take the classic example of chest pain. A man comes to the ER with chest
pain. Is the onset quick? Yes doc, it was all of a sudden. This might
support a diagnosis of, say, MI, aortic dissection, pulmonary embolism, but
less likely someone would call GERD sudden. Palliative or provoking
features? Well, when I take 8 antacids it gets better (GERD), or, When I
take my wifes nitroglycerine it got better for a little while (angina), or,
when I took my wifes nitroglycerine it did nothing (pericarditis?).
Quality: Is it stabbing? Ya doc, its stabbing (less likely MI). Is it
crushing? Like an elephant on your chest? Ya doc, that's it. (more likely
MI), and so on.

Now of course, cTakes could be used for a real life encounter like this
(middleware) at some point, but likely it would be taking a history and
proposing a diagnosis (middleware again Tim, yes). But the point is, the
first steps toward knowing what were dealing with at the historical level
is centered around OPQRST, and it just occurred to me to ask what we
thought about the feasibility of something like that.

In retrospect, it may be too tough, but at some point it would need done,
just as much as a clinician must learn it.

One final point: problem lists. These are absolutely essential to any
clinician in making a diagnosis. Again, often times, they dont think about
it, but they use them. When writing the above it occurred to me: much of a
problem list definition may already be contained to varying degrees in
existing cTakes databases. It would be an interesting and worthwhile paper,
I think, to see how well cTakes compiled problem lists matched Medical
Students, Residents, and Attending physician's problem lists. If anyone is
interested in this line of thought, I would be interested in collaborating.
It would be very easy, and the data may actually already exist to compare.
Forgive me if its already been done, but, if it hasnt, then it would go a
long way toward proving cTakes efficacy in regards to high-order processes.
And if it hasnt been done and someone does it at a later date, please, send
me an email to the paper!

JG


On Wed, Oct 30, 2013 at 10:08 AM, Tim Miller <
timothy.mil...@childrens.harvard.edu> wrote:

> Thanks for bumping this Pei, it reminds me I meant to respond to it.
>
> The OPQRST does sound like a great ML project. At a glance I might think a
> sequence model over sentences (like a CRF) would be a good model.
> But I'm wondering what the end use case is? Is it for teaching OPQRST to
> new clinicians? Or maybe as a sort of middleware for other projects where
> it might be a useful feature? Without a physician's intuition I sometimes
> suffer from a failure of imagination on these things.
>
> Tim
>
>
>
> On 10/30/2013 09:59 AM, Chen, Pei wrote:
>
>> Hi John,
>> I was away for a little bit and finally got a chance to catch up on
>> emails...
>>
>>  2) I work for the DoD and have latched on to several IRB approved
>>> projects
>>> within that community where Ill be using cTakes, though minimally at
>>> first.
>>> This is just a statement, a bug in the ear of the community of what
>>> people
>>> are up to.
>>>
>> This is really news!  Looking forward to hearing more...
>>
>>  has anyone considered (and maybe the components already do this in some
>>> way I
>>> haven't explored yet - time is ever limited) adding an OPQRST classifier?
>>>
>> I'm not too familiar on how OPQRST would be determined from the patient's
>> record.
>> Just curious, how is it currently determined manually now?  Is it a
>> single score determined by a formula/rule(s)?
>> Seems like another good use case for cTAKES output-- clinically focused.
>> --Pei
>>
>
>

Reply via email to