[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Extended proposal concerning normcurves

From: richard terry
Subject: Re: [Gnumed-devel] Extended proposal concerning normcurves
Date: Wed, 26 Jun 2002 20:54:11 +1000
User-agent: KMail/1.4.1

I've had a quick browse and I'm sure we would all welcome this approach. I'm 
happy to play with the GUI presentation (which seems to me to be the simplist 
task in the whole thing!). Others more versed in maths, graphs and xml will 
have to volunteer to help you. I've noted there seems to be a good graphicing 
tool in the wxPython  you could look at if you've not already seen 

I'll check out your web reference. BTW despite much effort on the backend and 
currently by Ian and I on the GUI , there is not much in the way of database 
table structure, so volunteers need to raise their hands and maybe we could 
get a small team together to push that aspect forward.


Dr Richard Terry
Gui-coordinator gnuMed Project.

On Wednesday 26 June 2002 10:19 pm, Christof Meigen wrote:
> The name of the game
> --------------------
> Physicians, especially pediatrians, regulary measure parameters
> of a patient in order to check wether or not this patient
> develops/is normal in terms of that parameter.
> Such parameters include body height, weight respectively BMI,
> head circumference, but also blood pressure or peak flow
> (for asthma patients).
> The results of such measurements are usually viewed in comparison
> to the majority of the population, and usually a centile is
> calculated, saying that XY% of the population (with that age/sex)
> shows a value smaller that the measured one. To calculate
> these centiles, normcurves are used.
> I think that this idea "normcurves" can be implemented in
> GnuMed in a both flexible and standardized manner, aiming for
> - a very general implementation of the methods and algorithms used
>   to calculate centiles, print nice graphics, mark strange measurements
>   etc.
> - a standard framework to interchange centile data, easily pick
>   the desired norm for a patient etc.
> Why all that fuss?
> ------------------
> The view of what is "normal" changes rapidly with time, but there are
> also reginal differences.
> For example, 14% of the childen from Leipzig have now a BMI over that
> 97th centile that was used in the late 80's in the GDR.  Similar trends
> for height (secular trend) are common.
> In an international projekt, one ends easily up with 10 to 20 important
> normcurves, and the need to easily add new ones is obvious.
> What a normcurve does
> ---------------------
> Ok, let's view the normcurve as a black box. You put in a set
> of parameters (1) describing the patient, usually sex and age,
> and a parameter (2) the normcurve is about.
> The normcurve returns either a specific centile or a code on a scale,
> for example "overweight", "obese", "normal" etc.
> Parameters of type (1) does not necessarily be sex and age,
> for example it is common to check the development of babys
> on a "weight for length" chart.
> Furthermore, a normcurve can also do the reverse calculation,
> that means to calculate the value of a given centile
> or a given code on the scale, which is used for plotting
> centile curves on charts etc.
> What a normcurve is
> -------------------
> A normcurve consists of the following data
> 1) Country: the country in which the study was conducted that
>             the norm is based on, may contain "*" for worldwide
>             standards
> 2) Year   : The year the norm was published
> 3) Name   : A common name, usually the author's of the corresponding
>             paper
> 4) Reference: the bibliographical entry of where the norm was published
> 5) A range of ages for which it is applyable
> 6) Parameter of type (1): Code for the parameter that is used for
>             the X-Axis on the chart, usually age
>    Parameter of type (2): Code for the parameter that is used for the
>             Y-Axis of the chart, for example height, BMI, head
>           circumference
> 7) For borth sexes "centile" data, which is either
>        - a set of functions for some centiles (3rd, 10th, 50th etc.)
>          resp. for borders between codes like "normal"/"pathologically
> high" - or two functions, for the mean and the standard deviation (for
> normally distributed parameters)
>        - or three functions, for the median, coefficiant of variation
>          and Box-Cox-power (for skew normally distributed parameters
>          like BMI)
>      a function can be either:
>        - a list of fixed points between linear interpolation is used
>        - coefficients of splines
>        - coefficients of a polynom
> annotation for (1): At first sight, it might seem reasonable to
> introduce an "ethnical" parameter, which is common in the US,
> where "Hispanic", "Asian", "Afro-american" and "White" or so is used.
> This is generally a bad idea, since
> - it is, especially in germany, a bit peculiar to push people
>   in an ethnical category
> - normcurves are usually published with no recommendation for
>   which ethnical groups they should be used, but rather a country is
>   given (growth in Germany is significantly different from growth in
>   Poland, for example, although any statements about ethnical
>   differences between the two populations may be considered akin to
>   Nazi-ideology)
> - it seems wisest to avoid the whole discussion be leaving the
>   decision, which normcurve can be applied best to a certain
>   patient, to the physician. There are different tastes of the
>   physicians and different standards by the health insurences anyway.
> How the normcurve is stored
> ---------------------------
> I would propose a XML-file, the scheme or document type definition
> can be easily derived from the above definition.
> Furthermore, it would be simple to introduce a web service, where
> norm curves can be published by everyone (after reviewing by a core
> team) and easily downloaded and integrated in GnuMed.
> GnuMed would then at startup or on request load the XML-File and
> initialize the appropriate objects and GUI-Elements.
> How the normcurve is used
> -------------------------
> In the patient view, you would see the centiles or the text results
> ("obese" etc) of the normcurve next to the values. You can also
> view and print predefined charts, as they are common for height/weight
> among physicians now.
> Specialities of height and BMI development
> ------------------------------------------
> Well, the following is on the cutting edge of medical research,
> but it adresses intuitive problems:
> - Height of a child correlates with parentel height, with a
>   coefficient of correlation between 0.2 and 0.7, depending
>   on age and sex. Therefor, centiles for children whose parent's
>   heights are known, are usually moved up or down (for tall
>   parents, taller children are "normal") and they are also
>   closer together, since there is less variation in children
>   whose parents have the same height. "Parental adjusted centiles"
>   can be calculated statistically sound using the correlations
>   mentioned above (I calculated an appropriate table from the
>   famous Zurich study by Prader)
> - Even more important than the centile itself is the development
>   of a child's centile, for example it is remarkable when a child
>   keeps "dropping down" the centiles. The check which development
>   is normal is usually done by eye, which may be sufficiant for
>   a padiatrian with lots of experience. However, there are
>   several more or less sophisticated techniques to
>   automatically detect normality in longitudinal data.
>   I will give a talk on that in november at the Auxological
>   conference of the Deutsche Gesellschaft für Auxologie
>   in Glücksburg, Germany. The two most promising techniques
>   are based on cluster analysis of normalised SDS developments
>   respectively on Principal component analysis of phase-adjusted
>   growth curves, both resulting more or less in a definition
>   of common "growth patterns".
> What should/could be done
> -------------------------
> 1) Define an DTD for the XML-storage of a normcurve or introduce
>   a different storage scheme
> ---> I would volunteer here
> 2) Define a python object-tree to handle norm curves, that is
>   * Read from the file
>   * check measurements of patients, returning a centile or a code
>   * return values for given centiles/codes
> ---> I would volunteer here
> 3) Define how measurements of various types are stored in GnuMed,
>   including  global definitions of the measurement type (height,
>   bone age etc.atc)
> ---> I don't feel like having competence here
> 4) Integration of the results of the normcurve-chacks into the GUI
> ---> I don't feel like having competence here
> 5) Set up a web service where people can access a "comprehensive
>    GnuMed normcurve database"
> ---> That should be no problem once point (1) is solved.
> What should be done NOW
> -----------------------
> As soon as people find the whole idea appealing and no-one works
> on the yet, and (3) is clear (for example by introducing standard
> codes or names for measurement types like "height" "weight" etc.
> which would be used both in the XML-file as in the application
> to make clear which value is for which type of measurement)
> I would start with point (1) and maybe with point (5).
> I would start with point (2), although I have to become
> more familiar with python first, but as a perl hacker,
> programming in python should be as easy as \pi. Maybe some
> GUI guys could then make use of that and integrate the
> choice of a normcurve for a given patient and the resulting
> centile data into some views.
> Mark that this is all still completely independent of how
> the charts for the patients will look like, which has to be
> discussed with people who will actually use it. For my
> personal preliminary approach on growth charts (including
> cluster-based growth patterns) you can visit the (german)
> website
> what do you think about the whole matter?
>      Christof
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]