Re: [Gnumed-devel] Past History and Operations (was: please, we need feedback)

[Richard Terry]

I think problem list should be previous significant inactive + previous 
significant inactive problems.

Current or relatively current clinical consultation problems shouldn't be 
added automatically to the problem list, unless the doctor wants them to be 
added.

In a screen dump which I posted some time ago I showed visually this concept.  
I enclose it again.

Perhaps this is what you all mean. 

To be honest I've not touched the computer much since my last flurry of 
activity in an attempt to pursade some rationality of design, but I've given 
up all that and have currently lost interest, hence not reading the mailing 
list that much, and as I cannot get gnumed running at all because of 
segfaults, empty log files generated during attempts to trace this, I've just 
about given gnumed up.

Off on holidays for 10 days, perhaps I'll find myself refreshed.

Regards

richard


On Sat, 16 Apr 2005 02:13 am, J Busser wrote:
> At 10:39 AM +0200 4/15/05, Karsten Hilbert wrote:
> >"alternate name for past history could be 'problem list'"
> >- good :-)
>
> A problem list, beyond "past history"that is being carried
> forward, includes anything new at the current encounter.
>
> If agreed, a problem list is then a combined result of
> - pre-existing active (therefore ongoing) problems
> - plus pre-existing inactive but significant problems
> --> note, at the point of beginning to use a new EMR,
>          above items would need to be "newly entered"
>          (unless feasible to import)
> - anything *new* at the current encounter
>
> The "anything new" should be input through whatever
> is GNUmed's principal, clinical encounter widget, in
> order to reap any extra benefits that the method would bring.
>
> The tidiest (low-tech, non-query) method by which to bring
> in "past" items in the midst of an encounter could be to pre-
> define a very simple file format in which the user can grab a file
> prepared at the time, or in advance, formatted to contain data
> to satisfy:
>
> field1: clin_health_issue.description
> field2: clin_health_issue. is_active
>       (True for active ongoing)
> field3: clin_health_issue. clinically_relevant
>       (True for significant, whether or not it's active)
>
> That is all that you really need if what you are doing is importing
> into the current patient. You just need to be sure that it *is* the
> same patient. The low tech way to do this would be to have your
> "source" method provide and prepend to the file a comment line:
> # <patient lastname, given names>, <dob> <other>
>
> The most painful (low-tech, non-query) method would be to
> have, next to oneself, a screen with the legacy app showing the
> info and cutting and pasting or else the paper chart and just
> typing it in. For this implementation, in order to input the items
> as clin_health_issues, is it proposed to use a "special" widget limited
> to clin_health_issue .description,  .is_active and .clinically_relevant?
>
> And of course, any issues recognized to be "new" at the
> encounter, once these have been entered and the encounter is
> concluded, effectively join (become part of) what will, at the next
> encounter, have been the past history ;-)
>
> >Notice that, yes, there can be a clin_health_issue.is_active =
> >True *without* any clin_episode.is_open = True attached.
> >Example: Diabetes certainly is an active problem all the time
> >but there need not be a currently open episode because it's
> >under good control.
> >
> >Inactive but significant would be something that does not
> >currently affect health (eg post-appendectomy state) but may
> >well influence later medical decisions (differential diagnoses
> >to acute appendicitis are more likely in post-appendectomy
> >patients).
>
> The above are helpful examples.
>
> >"progress note may take a past history item as presenting problem"
> >- yep, we do that :-)
>
> ... by virtue of "past history" items having been input as
> clin_health_issues?
>
> >Questions:
> >
> >What is "Operation" used for ? Sure, it tells whether a problem
> >is an operation or has been operated on but what do you use
> >this information for ?  I would expect (I do so, that is) to
> >enter issues as "post-appendectomy" which makes it
> >self-explanatory. The only obvious advantage would be that the
> >operation field makes it safely processable/queriable.
> >
> >The same question stands for "laterality".
>
> What had been a clinical_health_issue of "abdominal pain",
> causing a person to be sent to hospital, gets treated with
> appendectomy. At the office encounter in which appendicitis
> was suspected, it would have appeared in the soAp row and
> the need to send to hospital entered in the soaP row (Plan).
>
> The appendectomy would not (normally) be done at a facility
> where GNUmed is in use as the EMR, but we should consider the
> general case where for a treatment or "operation" is so.
>
> Some coding systems include procedures, Could such a code
> be attached to the soaP row? Would a code attached to a
> soAp row suggest a diagnosis whereas a code that denotes
> an operation be able to be attached to a soaP row?
> And BTW are we still referring to this step "coding"?
>
> If the patient had presented to a doctor using GNUmed in the
> course of the actual illness, the description for the
> clin_health_issue could have been "abdo pain" and successively
> modified over time:
> - at the end of the visit --> to "abdo pain - ? appendicitis"
> - after the appendectomy --> to "s/p appendectomy".
>
> ... whereas if the issue is being newly created in GNUmed as a
> past history item it may begin as "s/p appendectomy".
>
> Now here is a question... in some cases the appendix is removed
> because of appendicitis incidentally noted while in the abdomen
> for a concurrent illness. In other cases it can be decided by a
> surgeon to remove an appendix in the absence of appendicitis.
> In every cases the patient could be designated as
> "s/p appendectomy" but that would obscure the nature of the
> past illness. I suppose if the illness had evolved within GNUmed
> this will be able to be reviewed without too much trouble. But
> even so supposing the patient had Crohns disease you would not
> replace the Crohns item with "s/p appendectomy", you would
> add the latter to clin_health_issues.
>
> So when newly creating a patient record in GNUmed perhaps the
> doctor will have to make a choice whether to enter both the
> inciting illness and the status-post-operation as distinct
> clin_health_issues. Perhaps in their legacy EMR they had
> "appendicitis" as a Past History item, inactive but significant
> and they also had an Operations item "appendectomy". In
> moving to GNUmed they *could* simply enter
> "s/p appendectomy" at a cost of losing richness and structure
> I can understand Richard would want to preserve. So how about:
>
> 1. create a clin_health_issue to record (if of interest) the disease
> or disorder that caused an operation to be done, otherwise
> input a description as "status post..."
>
> 2. enter a soap note with any desirable details of the operation.
> Not sure where details should go within "soap". If patient self-report,
> then in Subjective. If from credible collateral,  it is yet info that
> the doctor did not personally create, so maybe the soap row
> should yet be "typed" as "s". As a separate thread we could remind
> me what we thought about alternate GUI forms / kinds of SOAP
> labels in place of or adjunctive to Subjective Objective (Hx Px etc).
>
> 3. decide where in the soap to put (code)? the operation. I guess
> within the scenario, it is a History item, except when rendered in
> the office/surgery. People can give it whatever text "name" they
> want and it is next a matter of deciding how to code it so that
> one patient's "appy" and another's "appendix removal" can both
> be queried. Is our clinical coding supported as pairs
> (coding_system, coded_value). Whereas some people may choose
> to use ICD9, others ICD-10CM, others Reid etc and others a
> combination (all optional) are we here proposing that GNUmed
> by default include a gmOperations coding system with item
> descriptions to be built up by those using any one implementation?
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel

carlos_tabbed_incontext.png
Description: PNG image