Re: [Gnumed-devel] Free your mind with mindmapping

[Sebastian Hilbert]

Am Samstag 09 Mai 2009 00:25:44 schrieb Karsten Hilbert:
> On Fri, May 08, 2009 at 02:33:58PM +0200, Hilbert, Sebastian wrote:
> > While I am wraping my head around the details of the cardiac device
> > pluging I realize just how complex it is to get it right. The software i
> > currently use solves that by ignoring corner cases like a lead being
> > implanted at the right ventricular apex but being paced fom the atrial
> > channel of the generator. It does not cater for the case that a patient
> > has an left ventricular and right ventricular lead but both being
> > connected to the RV channel through an Y- connector.
>
> It often helps to ask oneself a few questions a la:
>
>       What do I need to *compute* ?
It is about the level of detail. If you don't store the fact that there was an 
Y-connector between two leads you might send a patient to the specialist for 
device optimization (echo guided) only to find out it is technically 
impossible because of a Y-connector.

If someone has chosen to use a left ventricular lead in the RA channel because 
a two chamber generator is cheaper than a three chamber generator than you 
better know that so you don't program a mode where it wrongly assumes you are 
pacing in the right atrium and later in the right ventricle because that could 
do some bad things.

>       What do I need to *store* ?

In the software we currently use the physical leads are ignored. It simply 
assumes there is a lead for each chamber and it will not change over time. So 
when you would poll the data for the RA-lead (which could have changed over 
time) you could get data for a number of leads and compare them directly 
(which does not make sense as they might have been replaced)
>
> Of course, in an ideal world one would model (store
> computably, that is) everything. The pragmatic answer,
>
> however, lies in the user stories:
> > Why so overly complicated. Because you will want to know which of your
> > patients have a device
>
> Note the question: which patient *has* a device of type X
>
> > that has just been recalled
>
> That is outside knowledge being factored into the qestion.
> It won't influence our model.

Well if you do not record the device but only device class (such as two 
chamber ICD) you will never know that Jhon Doe which has a St.Jude Epic HF 
better comes to your office earlier because of a know battery problem which 
would negatively affect his condition given the total AV-Block.

>
> > or if the ICD shocks are related to the lead being flaky.
>
> There's no way this can be answered by GNUmed regardless of
> the model.
>
Well if you tag the lead as flaky and if you associate the physical lead with 
a number of jumping measurements you might at least have a chance to asociate 
the ICD therapies with the lead condition. Sudden jumps in impedance indicate 
a broken lead and could be detected by a software. If you don't correctly 
store the measurements you cannot compute such things.

> > You might also be interested in the fact that
> > the program you applied two years ago led to less shocks than the
> > currently active one.
>
> That, to me, seems a more worthwhile thing to model.
> However, it seems unlikely that this question will be asked
> (outside of clinical studies) across populations - it will
> rather mostly be interesting with regard to a specific
> patient. Thus you can plot the "number of shocks" (assuming
> you'd record that as a measurement - which can already be
> done today) against a specific piece of narrative "current
> device programming" relevant to that period of time. No
> magic.
This question is asked all the time. Patient comes in and you change the 
setting because of inadequate shocks. He comes in four days later again for 
new therapies. Then you think. Hell that guy had a similar episode two years 
ago. Which medication was he on and what was the program. Happens all the 
time.

>
> Note that to facilitate this we could add a, say, sOap field
> to the GUI somewhere intended to record the current
> programming - this would go into a standard sOap field in
> the backend but would be tagged with a pre-defined type
> beyond the SOAP labelling.
>
The programming will be stored in the XML file. It is simply a dynamic 
measurement much like the electrical measurements. For a single XML file there 
will be a number of devices (generators, leads) which hold exactly one set of 
measuremts (electrical, programming) per date of procedure (interrogation). To 
compare values over time one needs to read the time stamps and evaluate 
multiple XML files for any given device.

We need however a medication field because in my workflow I would like to see 
the current medication associated with an interrogation as well as a 
medication list in the referral report. 

This could help answer the question which medication the patient was taking at 
a prior interrogation and how that affected the patients health. I often 
change medication for heart failure, arrhythmias and the likes during a 
pacemaker follow up visit.

> > The XML file is changing almost every minute a new thought comes up. I
> > have been toying with the idea of how to group devices. To do that one
> > has to define what a device is. I have settled for the definition that an
> > ICD-device is actually a virtual device consisting of a generator and a
> > number of leads.
>
> Despite virtual somethings being very useful concepts in
> briding reality and computer science this seems a very real
> device to me: generator + battery + leads. Of course, the
> whole is more than the sum of its parts so that's the
> virtual aspect.

Yes. That is what I meant. The whole point is that at any point in time the 
number of connected parts can change. Most of the time the generator is 
replaced but the leads stay. So looking at each part as a device is easier to 
handle.

> Hopefully everything less clear now :-)

Most certainly.

Sebastian