### Author:  [@lakewood](https://discourse.openehr.org/u/lakewood)
#### Post date: [27 January 2005 09:23 UTC](https://discourse.openehr.org/t/age/14820/5 "2005-01-27T09:23:53Z")
Hi All,
One should include mental age as well. EHRs should not presume a Patient's mental
capabilities closely track their physical age. This would be a recipe for disaaster
under its own terms since 'young' physical age and 'senior' physical age represent
gray areas regarding mental competence, etc. These gray areas are recognized in
most legal systems.
Regards!
-Thomas Clark
Gerard Freriks wrote:
---
### Author:  [@Sam](https://discourse.openehr.org/u/Sam)
#### Post date: [27 January 2005 12:32 UTC](https://discourse.openehr.org/t/age/14820/6 "2005-01-27T12:32:49Z")
Hi
Gerard has raised other issues - there are names for age-ranges or phases such as adolescence, neonatal, toddler. It may be too much for us to deal with but age is certainly not just a number - you just have to ask the mother of a small baby - it has units like days, weeks, months.
I think Gerard missed the point of post-conceptual age - it is the time since conception and if a child is born very early, remains the basis on which dosing and milestones are based - sometimes for years after birth.
This was raised as a key issue in systems for paediatricians.
So I was wondering if we should model a class specifically for date of birth.....which handles date of birth and age as a function, and which takes arguments like date of conception, date of mothers LMP, Expected Date of Delivery and stores the normal gestational birthdate as well. The class then has a feature called post-conception age as well.
The advantage is that we could even deal with things like 'post-natal' as a function (actual birth to day 28) and other phases in future if appropriate. It would mean that in family history you could enter 'young adulthood' as an age which might be better than guessing 22.
Further, I think in our DateTime class we should store text as well as the date if people want - this would allow us to store "4.30 yesterday" if a transcription tool wanted to - and the actual date time. This can make observational data much easier to read when scanning back.
It also means that we can deal with almost impossible fuzzy times like 'last night' in some reasonable fuzzy way without losing the key information.
In our timing specification for workflow the same will have the same issue ie we may need the text as well as the computable data - three times a day might be at 08:00, 16:00 and 00:00, but it is a different instruction than 8 hourly (where there is no flexibility on spacing of doses).
Thats enough for now...but I am thinking of putting a change request together if there is enough interest. The DateOfBirth issue will win a lot of friends in paediatrics...they are really concerned that their absolute requirements are never addressed in systems!
Cheers, Sam
Any more thoughts?
Sam
b.cohen wrote:
---
### Author:  [@USM\_Bish](https://discourse.openehr.org/u/USM_Bish)
#### Post date: [27 January 2005 13:09 UTC](https://discourse.openehr.org/t/age/14820/7 "2005-01-27T13:09:34Z")
---end quoted text---
I am of the view, that there is no requirement of age at all.
What is needed is the date of birth in the initial record.
After that every time the patient/ individual seeks medical
attendance, the age is automatically calculated. This is of
special relevance in paediatric practice.
The concept of 'age' varies with context and usage, and it is
best to avoid anything arbitrary or non-specific.
It is true, that there are millions who may not be aware of
their date of birth (specially in a country like mine, India)
but more often than not they can furnish dates in alternate
calendars, or can give you an approximation to go by.
Dr USM Bish
Bangalore
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [27 January 2005 13:15 UTC](https://discourse.openehr.org/t/age/14820/8 "2005-01-27T13:15:11Z")
Hi,
We need a third type of concept dealing with Age.
-3- After life 🙂
Gerard
-- \ --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800
---
### Author:  [@lakewood](https://discourse.openehr.org/u/lakewood)
#### Post date: [27 January 2005 15:18 UTC](https://discourse.openehr.org/t/age/14820/9 "2005-01-27T15:18:35Z")
Hi All,
In legal systems where 'informed consent' is required physical age, as well as a host of
other factors affecting the communication and consent, is very important. A minor
in most jurisdiction cannot consent and a senior who has less than stellar capabilities
can be held to be incapable of communicating and/or understanding the content.
A different way of looking at electronic records and the information contained within them is:
1)the totality of the information available at any point in time should be reducible to a
collection of records which subsequently can be used to re-assemble a composite that
accurately reflects the prior point in time, precision still an issue.
2)Information, regardless of type and form, available to the senses of a typical Practitioner
is in fact relied upon in forming a diagnosis and should therefore be included within any
related set of records. Paper records often reflect the opinions of a Practitioner.
3)The creation of electronic healthcare records involves information storage and
retrieval that is allegedly more accurate and precise that prior record formats and hence
must be held to a higher set of standards, e.g., have to beat paper records.
Age is only one factor and since it impacts Healthcare in many ways, primarily and
secondarily, eliminating it will leave the EHRs with a big hole. Easy example: Age-related
beauty products that have an allergic impact upon a Patient. A data mining application would
raise that flag early.
A second example is the overuse of vitamins in an attempt to maintain vigor and a
healthy looking skin, e.g., Vitamin E.
Exclusion by its nature creates holes and opportunities. No data, lots of expert witnesses.
Regards!
-Thomas Clark
USM Bish wrote:
---
### Author:  [@Tim\_Cook6](https://discourse.openehr.org/u/Tim_Cook6)
#### Post date: [27 January 2005 15:37 UTC](https://discourse.openehr.org/t/age/14820/10 "2005-01-27T15:37:00Z")
Interesting discussion. The above comments are very close to my own
thoughts on this when I first read Sam's proposal. The ideas presented
in the other replies are certainly valid.
In the case of neonatal work (as I understand it from the physicians)
there are certain rules of thumb they use based on the (estimated) date
of conception compared with the due date and again compared with the
actual date of birth, modified by factors such as IVF, AI, multiple
births etc......to determine level of prematurity.
My point in that paragraph is to augment my argument that the concept of
'age' should NOT be in the model. While date of birth and estimated
date of conception SHOULD be in the model. Any further handling of the
concept of age is an application specific problem. As has been
identified by other posts in this thread, age is a very context
sensitive idea.
---
### Author:  [@Philippe\_AMELINE1](https://discourse.openehr.org/u/Philippe_AMELINE1)
#### Post date: [27 January 2005 19:15 UTC](https://discourse.openehr.org/t/age/14820/11 "2005-01-27T19:15:22Z")
Hi,
In Odyssee, we have made the choice of :
1) defining the concept "Age" as an ellapsed time value
2) defining age related concepts (like "child", "old person"...) as
fuzzy sets
I think that it is the only way you can manage this kind of thinks.
We also have a (quite) good model for cyclic events ; I can describe it
further if you want.
Cheers,
Philippe
Tim Cook wrote:
---
### Author:  [@Ergin\_Soysal](https://discourse.openehr.org/u/Ergin_Soysal)
#### Post date: [27 January 2005 21:14 UTC](https://discourse.openehr.org/t/age/14820/12 "2005-01-27T21:14:23Z")
Hi,
About age;
A notice: Gestational age is a part of obstetrical records (e.i. of
mother, or at least strongly related), and usually started by the 1st day
of last mensturation, although real ovulation (thus conception) is about 2
weeks later. So, a simple date data type would be ok.
After birth, time to delivery is a part of personal history of the person.
e.g. borned at 41st week, 3300gr, ...
Keeping date of birth as a datetime field would be enough to calculate the
both age and age group whenever required, even some pediatrical
requirements like 3/365 (3 days old), 2/12 (2 months old), and so on..
About sex, I believe, standard records must only include M/F/Indetermined
as it's written on the passport of the person.
Any other details other than above for sex and age, will express something
different (like diagnosis or classification..) than our intension: data.
Ergin Soysal, MD.
> Tom and others
>
> The idea of age as a complex notion - post-conception, gestational (LMP)
> ie it can involve pre-birth periods - even well into life. This apperas
> to be important for decision support.
>
> I wonder if we need to model this as an archetype for demographics - but
> it needs to be in the EHR - age crops up in lots of evaluations
> (problem, family history) so we might need to have it as a formal TYPE!
> That is - we can use it consistently in various settings.
>
> I would argue that gender is of the same nature - with social gender,
> physical gender and genetic gender as the key concepts.
>
> No doubt there are others but these two are worth thinking about
> carefully.
>
> Sam
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd@openehr.org
Pleksus Biliþim Teknolojileri
[http://www.pleksus.com.tr](http://www.pleksus.com.tr)
Tel: +90 (312) 435 5343
Fax: +90 (312) 435 4006
---
### Author:  [@lakewood](https://discourse.openehr.org/u/lakewood)
#### Post date: [27 January 2005 21:59 UTC](https://discourse.openehr.org/t/age/14820/13 "2005-01-27T21:59:04Z")
Hi All,
An additional thought re 'age' comes from Genomics and 'triggers'. In particular,
age-related triggers.
Presuming the Patient's family history reviels that both sub-trees provide evidence of
age-related triggers importing 'conditions' and/or 'flags' into the Patients EHRs may
be reasonable. These would signal potential events that would increase in significance
as the Patient approached a suspect 'age'.
Would appreciate any related information.
Regards!
-Thomas Clark
Ergin Soysal wrote:
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [27 January 2005 23:03 UTC](https://discourse.openehr.org/t/age/14820/14 "2005-01-27T23:03:15Z")
Dear Philippe,
Thank you for your reaction.
I'm interested in your model for cyclic events.
Gerard
-- \ --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800
---
### Author:  [@Philippe\_AMELINE1](https://discourse.openehr.org/u/Philippe_AMELINE1)
#### Post date: [27 January 2005 23:37 UTC](https://discourse.openehr.org/t/age/14820/15 "2005-01-27T23:37:56Z")
Hi Gerard,
We have found that we could represent anything cyclic with two concepts : regular cycle and unregular cycle
For regular cycle, you have just to specify the cycle length (say P) and the event duration (say D) ; time between events is P-D.
Natural langage expression is of the kind "ten minutes every two hours"
For unregular cycle, you need to specify a third parameter : the number of events inside a cycle (say N).
Natural langage expression could be : "one hour three times a day"
That way, you just need 5 semantic concepts to express any cyclic pattern of an event :
regular cycle
unregular cycle
cycle length
event duration
number of events inside a cycle
Of course, you can add some concepts such as starting time, ending time and overall duration.
Well, it seems very simple ; however, we started a project with a lot of pre-elaborated sentences samples provided by MDs, and we discovered that natural langage is very un-accurate because the same sentence can be understood very differently if you think of it as a regular cycle or an unregular one.
So we fumbled nearly one month before I was able to discover that the underlying model was so simple.
Cheers,
Philippe
Gerard Freriks wrote:
---
### Author:  [@Isabel\_Roman](https://discourse.openehr.org/u/Isabel_Roman)
#### Post date: [28 January 2005 08:24 UTC](https://discourse.openehr.org/t/age/14820/16 "2005-01-28T08:24:20Z")
Hello every body,
Sorry for my intrusion. I´m working with demographic models, so this
discussion about the concept "age" is interesting for me.
I think that the only demographic valid concept of "age" is the difference
between the actual date and the birth date. We can include a very close
concept "aproximate age", when the birth date is not very clear, as Dr USM
Bish comment in his mail. All this can be reduced to include the birth date
in the model, with an additional field "confidence". This new field is
between 0 and 1. And only have value 1 when the birth date is sure. You
don´t have to include the "age" concept if you have "birth date" concept...
of course is better use birth date because this parameter doesn´t change but
age change every second Unfortunately!
All the other concepts are not demographic but clinical and must be
registered (I think) in international codes and included as this in our
archetypes.
Sorry again if this is a nonsense.
Isabel Román
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [29 January 2005 00:55 UTC](https://discourse.openehr.org/t/age/14820/17 "2005-01-29T00:55:54Z")
b.cohen wrote:
> This is actually a 'type refinement'.
> You already have a type 'number' whose instances are values that may be operated
> on and stand in various relations, particularly ordering and equality.
> Now you want to refine it so that two instances of the refined type with the
> same 'value' are not necessarily equal.
> The main question that must be asked in these circumstances is:
> Will the definitions of the operations and relations in which the new type is to
> participate violate any of the definitions that applied to the old type?
> If so, then all instances of usage of the old type must be reexamined and
> brought back into line.
> This is known as the 'frame problem'.
> Good luck.
This thread is probably touching on multiple requirements, but my gut feeling is that there is a requirement for a "fuzzy band" data type which does the following:
- can accept data input in numeric ("I had mumps when I was 13") or word ("I had mumps in my adolescence") form
- has a definition of its fuzzy bands in terms of names and limits; e.g. infancy:0-3; childhood: 4-11; adolescence: 12-17; etc
- can be queried in terms of the names of the bands or values
- has solid definitions for mathematical operations
To be properly "fuzzy", the bands are not adjacent blocks but may overlap (usually drawn as trapezoids in a graph rendition); the utility of this (I think) is to allow outer numeric range defintions for word forms of the datum. E.g. "childhood" might be equated to 4-13 and "adolescence" equated to 12-18 etc. I'm not sure that this is useful without proper statistical models to drive it.
Nevertheless, it occurs so often in clinical medicine that clinicians want to enter the same thing in different circumstances using either names (which really represent bands of values), or actual precise values (or sometimes, a precise interval).
Examples:
- age: sometimes doctors and/or patients only think in terms of "phase of life" and use terms like "early adolescence"; other times they use the precise age in years. The paediatric ages Sam mentions seem like an example of this. But I think there is additionally a need to know "age since conception" as Sam has been told by people the HL7 meeting.
- timing: terms like "morning", "afternoon", "evening" are often used to tell patients when to take medication, or by patients to say when somehting happened. When a doctor says "3 times a day" she usually means "3 times a day, spread apart as evenly and far as reasonable for you". If you question them further, they would probably say that the patient should take one table in the "morning" band, one in the "afternoon" band and so on. Pushed further, they could nominate reasonable ranges for these bands of time
Currently, information systems really struggle with this simple requirements - they usually record the values as different types, and have to do some messy processing to be able to handle them for statistical purposes. But a two-level modelling approach would suggest archetyping the meaning (i.e. the names and interval definitions) of such types on a per-archetype basis, and also defining a new data type that could handle either a coded term or a quantity value, and function sensibly in terms of mathematical operations.
Maybe Bernie Cohen or other mathematicians here can provide some more precise ideas here.
- thomas beale
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [29 January 2005 01:07 UTC](https://discourse.openehr.org/t/age/14820/18 "2005-01-29T01:07:06Z")
Tim Cook wrote:
> > I am of the view, that there is no requirement of age at all.
> > What is needed is the date of birth in the initial record.
> > After that every time the patient/ individual seeks medical
> > attendance, the age is automatically calculated. This is of
> > special relevance in paediatric practice.
> >
> > The concept of 'age' varies with context and usage, and it is
> > best to avoid anything arbitrary or non-specific.
> >
> > Interesting discussion. The above comments are very close to my own
> > thoughts on this when I first read Sam's proposal. The ideas presented
> > in the other replies are certainly valid.
I think it's a given that we assume that "age" is not literally recorded in the db - the question is whether date of birth is good enough. Clearly for many paediatric cases it is not, since birth can come at a nearly arbitrary time these days (20 weeks?). To avoid working with negative ages, the one proper point of reference we have is (estimated) date of conception, but for most patients we probabl dont' need this. I suspect an application level type is needed that generates age\_since\_birth and age\_since\_conception from recorded expected date of delivery, which should presumably be estimated date of conception + 38 weeks (Sam tells me that actually recording the date of conception can get people into trouble!).. So "expected date of delivery" (assuming normal ful-term pregnancy) seems to me to be the reliable raw datum that paediatricians and other peri-natal carers might be interested in; coupled with a smart "age" class, it should be possble to get the desired effect.
> In the case of neonatal work (as I understand it from the physicians)
> there are certain rules of thumb they use based on the (estimated) date
> of conception compared with the due date and again compared with the
> actual date of birth, modified by factors such as IVF, AI, multiple
> births etc......to determine level of prematurity.
yes - the smart "age" type could incorporate some of this knowledge , or else ask some knowledge base to generate "effective biologic ages" of various kinds (are different systems' development retarded differentially depending on the 'problem'? I.e. premature birth versus IVF, etc as Tim mentions? This all suggest strongly to me "knowledge layer" not "information model layer"!
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [29 January 2005 09:07 UTC](https://discourse.openehr.org/t/age/14820/19 "2005-01-29T09:07:07Z")
Thomas,
What you wrote with respect to age, is absolutely true.
It is a notion defined at the knowledge layer.
But expressed at an information model layer.
On the level of the knowledge layer 'age' is more than a set of numbers indicating the time past since an arbitrary point in time.
Next to 'age' there will be more notions that warrant the same discussions we have had.
Gerard
-- \ --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [29 January 2005 12:08 UTC](https://discourse.openehr.org/t/age/14820/20 "2005-01-29T12:08:08Z")
Forwarded from - USM Bish \
[Next page](https://discourse.openehr.org/t/age/14820.md?page=2)