# Age **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2005-01-26 16:58 UTC **Views:** 1 **Replies:** 62 **URL:** https://discourse.openehr.org/t/age/14820 --- ## Post #1 by @Sam 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 --- ## Post #2 by @Puvanendran_SenthilR I too agree on this\. We need to consider about these\. --- ## Post #3 by @system Hi, There are two concepts with the name 'age'\. Age as a number\. Age=56 Age as a process\. baby, youth, post conception, gestational, As with many concepts we have two different concepts with the same name in daily life\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #4 by @b.cohen 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\. Quoting Sam Heard <sam\.heard@bigpond\.com>: --- ## Post #5 by @lakewood 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: --- ## Post #6 by @Sam 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: --- ## Post #7 by @USM_Bish \-\-\-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 --- ## Post #8 by @system Hi, We need a third type of concept dealing with Age\. \-3\- After life :\-\) Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #9 by @lakewood 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: --- ## Post #10 by @Tim_Cook6 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\. --- ## Post #11 by @Philippe_AMELINE1 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: --- ## Post #12 by @Ergin_Soysal 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 Tel: \+90 \(312\) 435 5343 Fax: \+90 \(312\) 435 4006 --- ## Post #13 by @lakewood 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: --- ## Post #14 by @system Dear Philippe, Thank you for your reaction\. I'm interested in your model for cyclic events\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #15 by @Philippe_AMELINE1 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: --- ## Post #16 by @Isabel_Roman 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 --- ## Post #17 by @thomas.beale 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 --- ## Post #18 by @thomas.beale 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 --- ## Post #19 by @system 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 \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #20 by @thomas.beale Forwarded from \- USM Bish <bish@hathway\.com> --- ## Post #21 by @USM_Bish > > 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\. > If the EHR is designed is to be developed for a 'patient centric' database where data is appended from the first registration onwards to ad\-infinetum till his/ her death, the only thing needed is DOB\. If the objective of the EHR is institution or episode centric, then ofcourse amendments as per the need may be thought of as per the setting\. > Clearly for many paediatric cases it is not, since birth can > come at a nearly arbitrary time these days \(20 weeks?\)\. > Prematurity and postmaturity are concepts in relation to gestational age \(being one of the component factors\) and not chronological 'age' per se \(viz\. 'age' as we percieve in common medical parliance\)\. > 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\!\)\.\. I am of the view, that things like 'age since conception' is too variable a thing to be included in an objective database\. In cases of conception within the period of gestational amenorrhoea, or worse still, spotting after conception, more often than not, gestatonal age is determined from ultrasound findings and other methods\. It is best to leave these to the discretion of the practitioner\. > 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\. > There is actually little guess work here\. If the last menstural period is known, the calculations are quite simple \(irrespective of the method of conception\)\. Even without accurate LMP, a fairly good estimation of the development process can be obtained \(while the baby is in the womb\) with invesigation methods available today\. Normally, in medical practice, the term 'age' is chronological age in years as on last birthday \(except in paed practice, where it may be in days, weeks or months\)\. If credence is to be given to gestational age, mental age and other ages used in various sub\-disciplines of medicine, the implementation would go into all sorts of tangents and unnecessary complexities\. Yes, alternate age definitions may find a place in specialised scenerios, but not in a generic medical database setting\. I would suggest, to clearly define 'age' as chronological age, and proceed accordingly\. Dr USM Bish Bangalore --- ## Post #22 by @Philippe_AMELINE1 Hi, As Aristote said 'the final goal is not knowledge, but action' Don't you think that we all agree that 'age' is a calculated value \(difference between event time and birth time\)\. That should be the EHR data representation\. Then, from a knowledge management point of view, when you have to deal with 'events over time' in medicine, you quite always have to work with fuzzy logic\. Because experts eventually write constraints of the kind 'this drug shouldn't be used by elder persons with recent ulcer' ; as you may notice, we have two fuzzy sets here : 'elder person' and 'recent ulcer'\. As you can see we have to work with the person age, but we also have to consider his diseases age ;o\) Or maybe age is just a sexually transmited disease, so we get a single semantic concept\.\.\. just kidding ;o\)\) Cheers, Philippe --- ## Post #23 by @USM_Bish > > As Aristote said 'the final goal is not knowledge, but action' > Hey, that's a nice quote \.\.\. New to me \.\.\. I like it ;\-\) > Don't you think that we all agree that 'age' is a calculated > value \(difference between event time and birth time\)\. That > should be the EHR data representation\. Don't get me wrong here\. My statement was made in context of gestational age being considered for 'age' computation purposes\. My contention was to segregate the two and just stick to chronological age\. Gestational age should be considered for specialised areas of obstretics and neonatology as a seperate entity\. The computational algorithms are different\. > Then, from a knowledge management point of view, when you have > to deal with 'events over time' in medicine, you quite always > have to work with fuzzy logic\. Because experts eventually write > constraints of the kind 'this drug shouldn't be used by elder > persons with recent ulcer' ; as you may notice, we have two > fuzzy sets here : 'elder person' and 'recent ulcer'\. > This is a different issue that you have brought out\. The vague nature of medical communication in vogue\. The grey area here is not 'age' per se but what would be the definition of the term 'elderly'\. This IS a complex issue\. Similarly, the 'recent ulcer' fuzziness in the definition of 'recent' not ulcer\. This too has no ready or accepted answers\. Yours is a very valid point \.\.\. but then you're at crossroads\. It is a matter of opinion as to whether we should proceed with what we have as definitive and tangible, or collaterally sort out the non\-definitives and then take the next step\. My vote is for the former approach\. Dr USM Bish Bangalore --- ## Post #24 by @Bill_Walton USM Bish wrote: > > > > 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\. > > > > If the EHR is designed is to be developed for a 'patient > centric' database where data is appended from the first > registration onwards to ad\-infinetum till his/ her death, the > only thing needed is DOB\. It seems to me, although I'm not a physician, that there are, or we might learn that, there are medical problems that crop up later in life that are related to whether or not a person was born full\-term or not\. If so, or it it's a possibility, then perhaps that needs to be recorded\. Is there some sort of problem, either technical or philosophical, with recording both DOB and \[estimated\] DOC? Best regards, Bill --- ## Post #25 by @thomas.beale Bill Walton wrote: > It seems to me, although I'm not a physician, that there are, or we might > learn that, there are medical problems that crop up later in life that are > related to whether or not a person was born full\-term or not\. If so, or it > it's a possibility, then perhaps that needs to be recorded\. Is there some > sort of problem, either technical or philosophical, with recording both DOB > and \[estimated\] DOC? > Sam says that rather than estimated DOC, estimated date of delivery should be actually recorded, since if a DOC is estimated then recorded and it turns out that e\.g\. the father was known to still be in Canada that week on business, it can create all kinds of problems \- when the explanation is probably compltely innocent\. So he suggests that estimated DOC should be always computed from estimated DOD, rather than being stored\. But the result is the same at the application level \- a 0\-offset age from the \(approximate\) moment of conception \(for those patients for whom this is relevant obviously\)\. \- thomas --- ## Post #26 by @USM_Bish A few mails back on this thread, Dr Ergin Soyal quite correctly pointed out that these things \(like LMP, DOC, EDD\) pertaing to history would go into the mother's obstretic record, whereas, date and time of birth would form a part of the infant's \(individual\) record\. Yes, birth factors may have influences in later life\. To keep the neonatologists and paediatricians happy, a seperate container with all gestation related problems may be kept\. This could be descriptive or field defined where all causes of perinatal morbiditity like prematurity, postmaturity, low APGAR or even delivery modes which may affect at a later stage like foreceps/ vacuum/ caesarian trauma etc could be clubbed for the individual record\. No jugglery with dates needed\. This would avoid all complexities on this issue\. Dr USM Bish Bangalore --- ## Post #27 by @Ergin_Soysal I'm not sure if it makes sense\. Because: Calcution DOC using DOD is not a secret\. So the father can easily calculate DOC back, if your intention is to provide some level of privacy\. And you are assuming, father will not see this information at the application level, but at the raw data level\. Also, you must keep conceptional age confidential, since it's expressed in weeks for a long time\. Ergin Soysal, MD > Bill Walton wrote: > >> It seems to me, although I'm not a physician, that there are, or we might >> learn that, there are medical problems that crop up later in life that >> are >> related to whether or not a person was born full\-term or not\. If so, or >> it >> it's a possibility, then perhaps that needs to be recorded\. Is there >> some >> sort of problem, either technical or philosophical, with recording both >> DOB >> and \[estimated\] DOC? >> > > Sam says that rather than estimated DOC, estimated date of delivery > should be actually recorded, since if a DOC is estimated then recorded > and it turns out that e\.g\. the father was known to still be in Canada > that week on business, it can create all kinds of problems \- when the > explanation is probably compltely innocent\. So he suggests that > estimated DOC should be always computed from estimated DOD, rather than > being stored\. But the result is the same at the application level \- a > 0\-offset age from the \(approximate\) moment of conception \(for those > patients for whom this is relevant obviously\)\. > > \- thomas > > \- > 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 Tel: \+90 \(312\) 435 5343 Fax: \+90 \(312\) 435 4006 --- ## Post #28 by @Bill_Walton Hi Thomas, Thomas Beale: > Bill Walton wrote: > > >It seems to me, although I'm not a physician, that there are, or we might > >learn that, there are medical problems that crop up later in life that are > >related to whether or not a person was born full\-term or not\. If so, or it > >it's a possibility, then perhaps that needs to be recorded\. Is there some > >sort of problem, either technical or philosophical, with recording both DOB > >and \[estimated\] DOC? > > > > > Sam says that rather than estimated DOC, estimated date of delivery > should be actually recorded, since if a DOC is estimated then recorded > and it turns out that e\.g\. the father was known to still be in Canada > that week on business, it can create all kinds of problems \- when the > explanation is probably compltely innocent\. So he suggests that > estimated DOC should be always computed from estimated DOD, rather than > being stored\. But the result is the same at the application level \- a > 0\-offset age from the \(approximate\) moment of conception \(for those > patients for whom this is relevant obviously\)\. Please forgive my density ;\-\) I understand what Sam's saying, but I don't see how that provides the information to which I was referring\. Specifically, how would it be recorded that a person was born at something \(perhaps significantly\) less than full\-term? Thanks, Bill --- ## Post #29 by @Bill_Walton Hi Dr\. Bish, USM Bish wrote: > > > > Sam says that rather than estimated DOC, estimated date of > > delivery should be actually recorded, since if a DOC is > > estimated then recorded and it turns out that e\.g\. the father > > was known to still be in Canada that week on business, it can > > create all kinds of problems \- when the explanation is probably > > compltely innocent\. So he suggests that estimated DOC should be > > always computed from estimated DOD, rather than being stored\. > > But the result is the same at the application level \- a > > 0\-offset age from the \(approximate\) moment of conception \(for > > those patients for whom this is relevant obviously\)\. > > > > A few mails back on this thread, Dr Ergin Soyal quite correctly > pointed out that these things \(like LMP, DOC, EDD\) pertaing to > history would go into the mother's obstretic record, whereas, > date and time of birth would form a part of the infant's > \(individual\) record\. > > Yes, birth factors may have influences in later life\. To keep > the neonatologists and paediatricians happy, a seperate > container with all gestation related problems may be kept\. This > could be descriptive or field defined where all causes of > perinatal morbiditity like prematurity, postmaturity, low APGAR > or even delivery modes which may affect at a later stage like > foreceps/ vacuum/ caesarian trauma etc could be clubbed for the > individual record\. No jugglery with dates needed\. > > This would avoid all complexities on this issue\. I'm approaching this from a "data mining," medical research, as opposed to practicing physician perspective\. That is, as you note, we already know that there are health issues that show up in a person's early years that are directly related to gestation\-related problems\. It may well be the case that researchers will find out that there are another set of issues that don't show up until much later in life\. Having the information you mention stored somewhere other than that person's own EHR seems to me to preclude, or at least postpone, some types of data\-mining research\. Best regards, Bill --- ## Post #30 by @thomas.beale Bill Walton wrote: > Please forgive my density ;\-\) > > I understand what Sam's saying, but I don't see how that provides the > information to which I was referring\. Specifically, how would it be > recorded that a person was born at something \(perhaps significantly\) less > than full\-term? > well I assume that EDD and DOB are both recorded\. So EDD might be 15 sep 2000 \(implying conception on 1/1/2000 \- sorry to the obstetricians if I am a bit off here\!\); DOB might be 1 aug 2000, implying a 6\-week premature birth\. Then an application Age object could compute or provide: \- date\_of\_birth : Date \- estimated\_date\_of\_delivery: Date \- estimated\_date\_of\_conception : Date \- prematurity: Duration \(days/weeks ?\) \- biological\_age: Duration \- other special concepts\.\.\.\.\. I don;t know what specialists call the last two \- I am just inventing here \- but presumably there is a concept representing "age of organism since conception"\. \- thomas beale --- ## Post #31 by @thomas.beale Isabel Román Martínez wrote: > 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\. > I think you are at least partly right here \- for other values which need to be stored but are not date of birth should be archetyped\. In fact, in the openEHR demographic model, not even date of birth \(or date of death by the way\) are hard\-modelled \- it is all archetyped\. \- thomas --- ## Post #32 by @USM_Bish Bill, the suggetion is not to keep it in a different place, but within the individual's records itself as a seperate entity from the chronological DOB\. For sheer purposes of explanation, I am placing a small XML representation of my thought process below: <record>     <\.\.\.></\.\.\.>     <dob> dd\-mm\-yyyy </dob>     <birth\_factors>         <apgar> 9 </apgar>   <gestation\_factors> Full term </gestation\_factors>   <delivery\_factors> Forceps delivery </delivery\_factors>   <birth\_trauma> Nil </birth\_trauma>   <\.\.\.></\.\.\.>     </birth\_factors>     <\.\.\.></\.\.\.> </record> If you keep data in this fashion, all relevant info is available with more details than anticipated, and very much amenable to any sort of data mining\. Hope this makes my point a bit clearer now\. Dr USM Bish Bangalore --- ## Post #33 by @Sam Dear all I have been thinking about the date/time measurement with regard to interval measurements in the HISTORY class \(used in OBSERVATION\) Consider a maximum temperature measured over a 12 hour period \- or an average\. At the moment the date/time will be the beginning of the 12 hr period\. My suggestion is that clinicians will record this at the end of the 12 hours and the date/time should reflect this\. That is to say: a 12hr maximum temperature of 36 C over the period 0600\-1800 on 2004 Jan 01 should be: 2004 Jan 01 1800 12hr max Temperature = 36 C and not 2004 Jan 01 0600 12hr max Temperature = 36 C One could argue that this is easy to do computationally\.\.\.I agree\. But I argue that the default data should be the most meaningful\. Feedback? I would like to put in a Change Request if this is not contentious\. Cheers, Sam --- ## Post #34 by @Sam Phillippe We are working hard on INSTRUCTION at the moment and have a document coming out soon\. The model is basically to have an instruction and a new class of ENTRY which records execution or actions\. Thus the execution of an instruction can be tracked and any variation recorded \(to the detail users require\) while being sure of the original instruction\. To do this effectively we need to work in the Workflow space \- and there are many developing standards in this area\. We have had a look at the HL7 GTS which pushes a lot of information into a single slot \- and it is not as far as we can see conformant with current workflow standards\. We have been looking closely at iCal for timing \- it probably does a lot of what we need\. I would be interested to hear what you are up to\.\.\. Cheers, Sam --- ## Post #35 by @Sam Ergin, and all ERGIN: Thanks \- there is no problem working from date of birth forward to age group \- it is when you are working back and times are fuzzy\. In family history when the DOB is not known it is even more of an issue\. The issue of FUZZY ages \(and other quantities\) I believe we need a means of representing quantities in a named band \- even if the naming varies\. So data can be entered as 'adolescent' and the age entered as a range from 13\-20 yrs \(or some other range\)\. In family history 'young adult' may be a requirement \(18\-20 yrs\)\. The important thing is that a textural representation of the data, plus a range is entered\. In the future the timing phrase 'last night' might need to be computable \- so the time range of 2200 \- 0600 might be entered for computational purposes\. Another example of when the text is important is 'three times each day' and 'every eight hours'\. Using iCal times it is possible to differentiate these but once actual times for taking the medication have been agreed then, if the timing is exactly 8 hours apart the differentiation is lost\. Three times a day may be represented in iCal as: FREQ=DAILY;OCCURRENCES=3 Eight hourly is FREQ=HOURLY;INTERVAL=8 But, in a setting where administration is controlled both of these timing rules may be transformed into: 0600;1400;2200 Recommendation: We consider a formal way of representing verbal statements of quantity and the quantity or quantity range they represent\. The issue of Age for Paediatrics On the paediatric front \- it is the age from conception that the clinicians work from in decision support and protocols \- as the children are often born very early and their DoB does not provide the details necessary\. For instance, the dose of a drug will be represented as mg/kg in age ranges post conception in a neonatal intensive care unit\. I agree with a number of statements that we need to record 2 date/times The first is the date of birth \- just as we have always done\. The second is to record a date time that allows us to estimate the date of development since conception\. As LMP is not an appropriate measure \(it is not reliable\), the two possibilities are: 1\. Approximate date of conception 2\. Expected Date of birth \(based on 38 week gestation\) You can then calculate one from the other quite safely\. One could allow either \- but I would suggest for interoperability issues we should have one modelled concisely in the demographic model\. The advantage of the first is that it gives an anchor date for the sort of calculations without any computation\. The advantage of the second \(EDB\) is that this data is usually in the mothers record \(EDD\) and also that giving a date of conception can cause great anguish to people \(as they were not together at that time e\.g\. the partner who returns from military service and the approximate date of conception is calculated as 7 days before he returned\)\. What I am sure of is that we need \(at least\) one of these modelled as part of the openEHR demographic model\. Cheers, Sam --- ## Post #36 by @Sam Philippe I would suggest that the duration of the event is not included \- rather modelled in instructions themselves as there are many different ideas of event duration\. The time to give a dose of intravenous agent may be very specific and I believe needs to be modelled explicitly \- not as part of a time specification\. That is, it is necessary to say that the dose must be given over at least 20 minutes\. Rather than the medication is given for 20 min twice a day\. The other point is that the model you have come up with is part of workflow \- but theirs are more complex as events are related and timing of relations is also important\. Cheers, Sam --- ## Post #37 by @Philippe_AMELINE1 Hi Sam, To be honnest, I must confess that we certainly have to work a lot on workflow, as a global process "goals for patient's safe become action plan for him and members of his/her health team"\. We have worked so far in two domains : health goals and drug prescription\. Health goal : a health goal is "something that should be done at a given time or at given intervals" or even a biometrical data that should remain in a specific range\. If you want I can write a web page with an accurate description of the whole model ; I can already give you some details : \- 3 semantic concepts are involved : action starting time, action ending time and biometrical value \- for each of these concepts, we can set a "target" : red>yellow>green>blue>green>yellow>red     blue means the ideal period/biometrical interval     green is good \(just too early or too late \(or too low or too high\) to be ideal\)     yellow is not good     red is bad \(clearly outside references\) 6 semantical concepts are needed for a target \(the pipes symbols of red>yellow>green>blue>green>yellow>red\), for example "min ideal starting time", "max ideal starting time" and so on\. Since we have 3 kind of targets \(start, end, value\), it means we get 18 semantical concepts\. For a given goal, you can perfectly just use a subset of these concepts, for example you can suppose that only the starting moment is usefull, and that the target is of the kind yellow|green|yellow\. So, for a goal, we can define : \- goal opening date and goal closing date \(for example from 40 to 75 years old\) \- goal targets \(start, end, value\) \- goal type : once, cyclic, always ; once for goals of the kind "preventive colonoscopy at 40 years old", cyclic for "BMI measurement every month", always is currently only for drugs For drug prescription, I must check the model ; it is complex since drug pescription involves cycles into cycles \(for example 2 times a day, two days a week\), so we have worked on a circadian cycle inside another cycle\. Cheers, Philippe --- ## Post #38 by @Karsten_Hilbert > Consider a maximum temperature measured over a 12 hour period \- or an > average\. At the moment the date/time will be the beginning of the 12 hr > period\. > > My suggestion is that clinicians will record this at the end of the 12 > hours and the date/time should reflect this\. > > That is to say: > > a 12hr maximum temperature of 36 C over the period 0600\-1800 on 2004 Jan > 01 should be: > > 2004 Jan 01 1800 12hr max Temperature = 36 C > > and not > > 2004 Jan 01 0600 12hr max Temperature = 36 C I think one should think of it this way: The temperature value \(be that average or maximum\) gets recorded as soon as it is known \(hopefully\)\. Hence the second version \(@0600\) seems wrong\. The first version seems OK but it seems to hide something implicitely\. There are actually two things being recorded: a\) the maximum temperature \- recorded at a given time\. b\) the time range this maximum applies to \- eg an interval that needs to be recorded, too \! It just so happens that many recorded values will have their time of recording and their time of occurrence \*coincide\*\. In many cases that will suffice, too, and in many cases \- say GP level free text for an encounter \- it does not matter too much whether I record the progress now when I hear it or two hours later\. Nonetheless are there two times: recording and occurrence\. Which should \- in cases where it matters \- be explicitely modelled\. Paper charts make us forget about this distinction because we routinely lie about the time of recording, eg\. we put down the time of occurrence while we actually mean that of recording\. Karsten --- ## Post #39 by @lakewood Hi Karsten, I was under the impression that time was recorded more frequently and under additional constraints, the constrants ranging from \+/\- some percent variation or \+/\- some value\. Additionally, another impression, is that the 'rate of change' is significant\. From a family member who had open heart surgery, post\-op was difficult because of hampered bodily control over the heart and rates of change of temperature become significant\. From IT/Engineering the Nyquist Sampling Theorem is a baseline governing sample rate\. It seems to me that what is being sampled here is the max value of temperature and whatever happens in\-between gets overlooked\. It would seem that equipment malfunctions could render the data useless\. It also appears that that pseudo real\-time activity of the temperature variable is missing\. Regards\! \-Thomas Clark Karsten Hilbert wrote: --- ## Post #40 by @thomas.beale Karsten Hilbert wrote: >> Consider a maximum temperature measured over a 12 hour period \- or an average\. At the moment the date/time will be the beginning of the 12 hr period\. >> >> My suggestion is that clinicians will record this at the end of the 12 hours and the date/time should reflect this\. >> >> That is to say: >> >> a 12hr maximum temperature of 36 C over the period 0600\-1800 on 2004 Jan 01 should be: >> >> 2004 Jan 01 1800 12hr max Temperature = 36 C >> >> and not >> >> 2004 Jan 01 0600 12hr max Temperature = 36 C >>    > > I think one should think of it this way: The temperature value > \(be that average or maximum\) gets recorded as soon as it is > known \(hopefully\)\. Hence the second version \(@0600\) seems > wrong\. The first version seems OK but it seems to hide > something implicitely\. There are actually two things being > recorded: a\) the maximum temperature \- recorded at a given > time\. b\) the time range this maximum applies to \- eg an > interval that needs to be recorded, too \! > In openEHR it is\. See http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/reference_model/data_structures/im/data_structures_im.pdf \- section 6, figure 7\. Every EVENT has a width \(by inheritance\) and an offset\. Sam is arguing that the offset should represent the end of the interval rather than the start, since this makes sense for any recording where the value has been averaged, or is a maximum etc\. > It just so happens that many recorded values will have their > time of recording and their time of occurrence \*coincide\*\. In > in openEHR, this means that the width is 0 and it is a point sample\. There is a function defined on the ITEM\_EVENT class called "is\_instantaneous" which tells you this \(although I notice it is not shown on the UML diagram\)\. > many cases that will suffice, too, and in many cases \- say GP > level free text for an encounter \- it does not matter too much > whether I record the progress now when I hear it or two hours > later\. Nonetheless are there two times: recording and > occurrence\. Which should \- in cases where it matters \- be > explicitely modelled\. > well, that's always taken care of in openEHR \- recording times appear in the VERSION class audit trail; when data is committed in openEHR, it is always as a COMPOSITION which inherits from VERSION\. Also, COMPOSITION\.context contains data/time info of patient contact etc, if there was one\. > Paper charts make us forget about this distinction because we > routinely lie about the time of recording, eg\. we put down the > time of occurrence while we actually mean that of recording\. > interesting point \- makes you wonder just how many scanned/keyed in paper records are actually misleading, and what kind of skew this might have caused in statistical studies\! \- thomas beale --- ## Post #41 by @William_E_Hammond For an age, I agree that the date of birth is adequate as long as you remember people do not age after they die\. It is also convenient to have a reference time mark for many things, including conception, start of a course of treatment\. Adjectives and nouns are difficult to put into algorithms unless the definitions are precise\. Ed Hammond USM Bish <bish@hathway\.com>@openehr\.org on 01/29/2005 07:12:55 AM Please respond to USM Bish <bish@hathway\.com> Sent by: owner\-openehr\-technical@openehr\.org --- ## Post #42 by @system Dear all, It is fine for me when we can agree that we mean by 'Age' time after birth\. How will we name and define concepts like: youth, post conception, post gestation, middel aged, elderly? Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #43 by @Philippe_AMELINE1 Gerard, From all the messages, it seems to me we can define 3 kind of values : 1\) Values with a genuine relationship with date of birth : youth, middle age, elderly\.\.\. Those who can manage fuzzy sets will do it that way, while others will have to use simple time intervals based on date of birth\. Can we define these fuzzy sets or intervals as standards ? Maybe we should work on it\. 2\) Values somewhat related to age, but with a non linear/standard relationship : date of conception, date of first flue, date of first walk\.\.\. These dates should be recorded somewhere, as unrelated informations\. 3\) Values whose name includes the term "age", but are, in fact, ratios : mental age, growth age\.\.\. These informations are neither dates, nor time intervals, but only some comparisons versus a "standard developpement" ; from my point of view, they are some kind of ratios and have little to do with this discussion\. Cheers, Philippe --- ## Post #44 by @Sam Dear All Age is time after birth \- we are not going to change that\. We have agreed that we need to record one more date in the demographic model \- which is 'approximate date of conception', or 'expected date of birth' Which do people prefer \- I chose the latter as it will probably be a cut and paste from the mothers record and does not get into the when did I conceive stuff\. What do others think? Finally\.\.\.\.I am proposing that we think about a new class \(?datatype\) such as 'DV\_Textural\_Ordered' for dealing with named quantities \- which have DV\_ORDERED or DV\_INTERVAL as their value \- a fuzzy quantity\. Examples in XML might be something like: <DV\_Textural\_ordered>   <text>"Birth"</text>   <value type="DV\_QUANTITY">     <magnitude>0<magnitude>     <units>"days"</units>   </value> </DV\_Textural\_ordered> <DV\_Textural\_ordered>   <text>"Adolescence"</text>   <value type="DV\_INTERVAL">     <lower type="DV\_QUANTITY">       <magnitude>12<magnitude>       <units>"years"</units>     </lower>     <upper type="DV\_QUANTITY">       <magnitude>18<magnitude>       <units>"years"</units>     </upper>   </value> </DV\_Textural\_ordered> <DV\_Textural\_ordered>   <text>"Three times a day"</text>   <value type="DV\_TIME\_SPECIFICATION">     <repeat>"FREQ=BYDAY;OCCURRENCES=3"</repeat>   </value> </DV\_Textural\_ordered> <DV\_Textural\_ordered>   <text>"Three times a day"</text>   <value type="DV\_TIME\_SPECIFICATION">     <repeat>"0800;1400;2000"</repeat>   </value> </DV\_Textural\_ordered> <DV\_Textural\_ordered>   <text>"Last night"</text>   <value type="DV\_INTERVAL">     <lower type="DV\_TIME">       <value>20:00<value>     </lower>     <upper type="DV\_TIME">       <value>06:00<value>     </upper>   </value> </DV\_Textural\_ordered> The problem is that they would not be available through inheritence \- so the possibility of entering these classes would have to be constrained\. This is just thinking out loud\. Cheers, Sam Gerard Freriks wrote: --- ## Post #45 by @William_E_Hammond Who are you calling elderly? I still hold out for age, even if it is fuzzy\. Ed Gerard Freriks <gfrer@luna\.nl>@openehr\.org on 01/31/2005 04:25:17 PM Please respond to Gerard Freriks <gfrer@luna\.nl> Sent by: owner\-openehr\-technical@openehr\.org --- ## Post #46 by @Elkin_Peter_L_M.D I agree with using date of birth for making the determination of an individual's age, as long as we have support for relative age for concepts such as puberty, menopause, at an age of risk given their family history of a malignance with a first degree relative whose onset of illness was at a certain age\. Relative age also includes number of years since an event like an MI or a CABG which are both medically relevant relative periods of time which are a type of age \(years since event\) with clinical relevance\. Warm regards, Peter Peter L\. Elkin, MD Professor of Medicine Director, Laboratory of Biomedical Informatics Department of Internal Medicine Mayo Clinic, College of Medicine Mayo Clinic, Rochester \(507\) 284\-1551 Fax: \(507\) 284\-5370 --- ## Post #47 by @system Hi, Age=: Time since an reference event took place and is expressed as: lightyears, years, months, days, minutes, seconds \(and parts thereof\) There is one fixed reference point and one changing \(non\-fixed\) reference point in time\. e\.g\. Event: big bang of our universe \-> age of the universe Event: birth of a person \-> age of a person Puberty=: ??? What is the reference event? Start of sexual development? Certain hormonal changes? Or is this the time of birth? We have two fixed reference points \(two fixed referenced events\) in time and no non\-fixed point in time\. This type of concept is clearly different from the 'Age' concept as defined above\. My point is: Concepts like these are expressed in the same manner as 'Age'\. But are different\. Question to be answered: How will we name these two distinct types of concepts? Peter is using the term 'relative age' to indicate things like puberty, or menopause\. Both types of concepts are relative since any time measurement is relative\. So we need a better term\. In my system of concepts 'Age of a person' is just one of the co\-ordinates to place an object in time\-space with its birthdate as reference event 'Age at which a person entered the state of puberty' is not placing a person in time\-space co\-ordinates\. It is indicating a change of state of the person and the time at which this took place expressed using the concept 'age of a person'\. It is expressing a functional aspect belonging to the person\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #48 by @system Sam, You mean the 'age of a person' and not 'age'\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #49 by @thomas.beale Elkin, Peter L\., M\.D\. wrote: > I agree with using date of birth for making the determination of an individual's age, as long as we have support for relative age for concepts such as puberty, menopause, at an age of risk given their family history of a malignance with a first degree relative whose onset of illness was at a certain age\. Relative age also includes number of years since an event like an MI or a CABG which are both medically relevant relative periods of time which are a type of age \(years since event\) with clinical relevance\. > Peter, can there be multiple relative ages for one person, relating to different life events? Do current clinical systems try to model this? \- thomas --- ## Post #50 by @USM_Bish > > Age is time after birth \- we are not going to change that\. > That's fine \.\.\. now for the second \.\.\. > We have agreed that we need to record one more date in the demographic > model \- which is 'approximate date of conception', or 'expected date of > birth' We should confine ourselves with available recommendations of the WHO, which is based on LMP only\. All other parameters are derived from this\. Besides, LMP is a fixed recordable event\. > From the XML, I understand, you may be thinking in terms of some gestational history for the newborn\. Calculations can be done from the mother's obstretic history, as per parameters defined by the WHO\. This is the current recommendations: o LMP = first day of the Last Menstrual Period o Prematurity = birth < \(LMP \+ 37 wk\) gestation o Normal gestation = birth > \(LMP \+ 38 wk\) < \(LMP \+ 41 wk\) o Postmaturity = birth > \(LMP \+ 42 wk\) gestation Please note the hazy zones between 37\-38th week and 41\-42nd wk\. We can expand the band of normalcy from 37 to 42, and eliminate this vagueness without significant real\-life issues\. Date of Conception is normally not used because it depends upon the periodicity of the menstural cycle of the mother and other factors\. The variations are too many to be correctly instituted as a measure\. If you are thinking of an additional DV\_Textual\_ordered class as seen from the XML \(quoted below\) then: > <DV\_Textural\_ordered> >       <text>"Birth"</text> >       <value type="DV\_QUANTITY"> >               <magnitude>0<magnitude> >               <units>"days"</units> >       </value> > </DV\_Textural\_ordered> > o The 'magnitude' would obviously have to be taken from the EDD   \(Expected Date of Delivery\)\. Since the 'normal range' itself   is a wide band, with the midian point at \(LMP \+ 274 days\) the   above representation would have to be re\-structured\. o Incidentally, there is also an alternate 'prematurity' defini\-   tion based on weight \- the original WHO recommendation of 1948   \(viz birth weight < 2500 gm\)\. This covers the "small\-for\-date"   newborns, burn within normal gestation period\. This is still   in use in several countries \(mainly developing countries\)\.This   should not be ignored\. o Postmaturity is another factor which would need inclusion in   such a textual class\. To keep it simple and self explanatory,   I suppose, the following should do:   <DV\_Textural\_ordered>       <text>"Gestation\_period"</text>       <value type="DV\_QUANTITY">           <magnitude>0<magnitude>           <units>"weeks"</units>       </value>   </DV\_Textural\_ordered>   <DV\_Textural\_ordered>       <text>"Birth\_weight"</text>       <value type="DV\_QUANTITY">           <magnitude>0<magnitude>           <units>"grams"</units>       </value>   </DV\_Textural\_ordered> Keeping the gestational period kept as an absolute number leaves things like normal range, prematurity, postmaturity etc as a search/ derived parameter\. Any changes in WHO criteria would not affect the database\. Just a suggestion \.\.\. Dr USM Bish Bangalore --- ## Post #51 by @thomas.beale This is an excellent post containing very good information on which I think we can base thinking of a) ontological concepts arond the "age" concept, b) an application model of the Age concept, c) an additional fuzzy data type for openEHR. Philippe Ameline I belive has such a type already in his system. ASIDE: I would like to discourage people from using raw XML in posts meant for humans to read (i.e. any post). XML is pretty unreadable at the best of times, and usually obscures the data with the tags. A better way of presenting data is just indented attribute = value form (effectively textual UML instance form) or even the dADL abstract syntax, if you happen to like it. I know this is a small point, but consider how much more readable the following is: ``` ---- psuedo - UML text form ----- DV_TEXTUAL_ORDERED text = "Birth" value = DV_QUANTITY magnitude = 0 units = "days" ---- dADL form -------- DV_TEXTUAL_ORDERED < text = <"Birth"> value = DV_QUANTITY < magnitude = <0> units = <"days"> > > ``` USM Bish wrote: > ``` > We should confine ourselves with available recommendations of > the WHO, which is based on LMP only. All other parameters are > derived from this. Besides, LMP is a fixed recordable event. > > >From the XML, I understand, you may be thinking in terms of > some gestational history for the newborn. Calculations can be > done from the mother's obstretic history, as per parameters > defined by the WHO. This is the current recommendations: > > o LMP = first day of the Last Menstrual Period > o Prematurity = birth < (LMP + 37 wk) gestation > o Normal gestation = birth > (LMP + 38 wk) < (LMP + 41 wk) > o Postmaturity = birth > (LMP + 42 wk) gestation > > Please note the hazy zones between 37-38th week and 41-42nd wk. > We can expand the band of normalcy from 37 to 42, and eliminate > this vagueness without significant real-life issues. > > Date of Conception is normally not used because it depends upon > the periodicity of the menstural cycle of the mother and other > factors. The variations are too many to be correctly instituted > as a measure. > > If you are thinking of an additional DV_Textual_ordered class > as seen from the XML (quoted below) then: > > > ``` > > > ``` > > > > "Birth" > > > > 0 > > "days" > > > > > > > > > > ``` > > ``` > > o The 'magnitude' would obviously have to be taken from the EDD > (Expected Date of Delivery). Since the 'normal range' itself > is a wide band, with the midian point at (LMP + 274 days) the > above representation would have to be re-structured. > > o Incidentally, there is also an alternate 'prematurity' defini- > tion based on weight - the original WHO recommendation of 1948 > (viz birth weight < 2500 gm). This covers the "small-for-date" > newborns, burn within normal gestation period. This is still > in use in several countries (mainly developing countries).This > should not be ignored. > > o Postmaturity is another factor which would need inclusion in > such a textual class. To keep it simple and self explanatory, > I suppose, the following should do: > > > "Gestation_period" > > 0 > "weeks" > > > > > "Birth_weight" > > 0 > "grams" > > > > Keeping the gestational period kept as an absolute number leaves > things like normal range, prematurity, postmaturity etc as a > search/ derived parameter. Any changes in WHO criteria would not > affect the database. > > Just a suggestion ... > > Dr USM Bish > Bangalore > > - > If you have any questions about using this list, > please send a message to [d.lloyd@openehr.org](mailto:d.lloyd@openehr.org) > > > ``` - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #52 by @Kevin_Coonan_MD Perhaps:     if \(dead\) age=dod\-dob;     else age=today\-dob;     if \(age<=myAge\) ageGroup="young"; For time intervals, etc\. this is not a terminology problem, but should be handled at the application interval, and I suggest that the context of the interval will determine membership \(i\.e\. I still consider myself to be a 'young adult'\)\. The same argument partially applies about post\-conceptional age\. If all you have is LMP, the most accurate estimation of post\-conceptual \(or gestational\) age your application could come up with is going to be based upon this, and certainly will have a "fuzzy" value \(or at least a point estimate w/ defined confidence intervals\)\. Again, the need for/meaning of this is going to be very contextual and probably best handled at the application level\. However, there is a determination of gestational age that is made based on maternal LMP, ultrasound, and physical examination of the newborn that is a clinical conclusion, and that has intrinsic meaning and must be recorded like other observations about the patient\. There is inherent error and imprecision in all of our clinical observations, but this is not a terminology problem, but rather an ontology/application layer issue\. I\.e\. you don't record if a person had an MI as a "young adult" since this is not an observation, and the validity is completely derived from the context of what "young adult" is\. E\.g\. in the clinical context of testicular cancer v\. stroke there are very different concepts of what "young" is\. A terminology sans context is just data w/o information\. Kevin --- ## Post #53 by @USM_Bish >    \[some snipped\] > > I would like to discourage people from using raw XML in posts > meant for humans to read \(i\.e\. any post\)\. XML is pretty > unreadable at the best of times, and usually obscures the data > with the tags\. > Valid point\. Even worse, when using a HTML mailer, where white space formatting in mails from vanilla text mailers may be 'chomped' and the indenting also goes \.\.\. > A better way of presenting data is just indented attribute = > value form \(effectively textual UML instance form\) Accepted\. UML would be the defacto for me \(in future\) \.\.\. Cheers Dr USM Bish Bangalore --- ## Post #54 by @Karsten_Hilbert > Age=: Time since an reference event took place and is expressed as: > lightyears, years, months, days, minutes, seconds \(and parts thereof\) Lightyears is a measure of distance, not time\. And not constant either, at that\. Karsten --- ## Post #55 by @David_Guest1 Karsten Hilbert wrote: >> Age=: Time since an reference event took place and is expressed as: lightyears, years, months, days, minutes, seconds \(and parts thereof\) >>    > > Lightyears is a measure of distance, not time\. > In fact it is \*the\* measurement of distance\. > And not > constant either, at that\. > Bugger\. http://www.everything2.com/index.pl?node_id=29831&lastnode_id=11221 David --- ## Post #56 by @lakewood Hi All, Light has successfully been slowed and stopped, i\.e\., encapsulated in a material\) for a significant period of time\. Lasers are used to send it on its way\. Destroyed a niche in my memory banks when it was announced\. Do not see a substitute for the 'old\-light', aka the 'new\-light'\. Regards\! \-Thomas Clark David Guest wrote: --- ## Post #57 by @Karsten_Hilbert >> And not constant either, at that\. > > Bugger\. > http://www.everything2.com/index.pl?node_id=29831&lastnode_id=11221 I stand corrected as I was being imprecise\. I was referring to a\) the speed of light is depending an material, and b\) the speed of light seems to not be constant over time even in a given material\. However, the \*definition\* of a lightyear certainly \*is\* constant so you are correct\. Karsten --- ## Post #58 by @lakewood Hi Karsten, The \*definition\* of a lightyear is \*fixed\*, i\.e\., the 'distance light travels in a year', and not directly measurable, e\.g\., tag a photon and measure its progress thoughout one year\. The problem is that the \*distance\* each photon travels in a year may not be the same\. You are correct re 'speed of light'\. The \*definition\* of a lightyear was created and agreed upon to facilitate measurement\. The 'trap' is trying to turn this 'convenience' into a physical constant\.\. Regards\! \-Thomas Clark Karsten Hilbert wrote: --- ## Post #59 by @rob_challen Sorry to add my thoughts after the discussion has died down\. > From the paediatric / neonatal point of view 3 dates are recorded routinely in the notes\. Firstly, and most importantly, is actual birth date and time \(Dob\) Secondly 2 dates related to Expected Date of Delivery \(EDD\): \- One calculated from Last Menstrual Period \(LMP\+40 weeks\)\. This is a bit unreliable as the information may or may not be available, as the woman may or may not have a regular cycle\. \- The other is the EDD as determined by a radiologist during the 12 week antenatal scan\. Determined by foetal head size amongst other factors\. It becomes less reliable the further away from 12 weeks the dating scan was done\. EDD by scan is more reliable than EDD by LMP, and is used in preference\. Once a premature neonate is born, his gestation is calculated\. This is calculated as \[40 \- \(EDD \- Dob\) / 7\] and usually expressed as e\.g\. 27\+1/40 \(27 weeks and 1 day gestation\)\. Subsequently the number of days since birth is also recorded\*\* \(and is what people use to refer to as "age" or "chronological age"\)\. Corrected Gestational Age \(CGA\) is then the sum of gestation and chronological age Therefore when describing an infant you would say "Baby X was born at 27\+1/40 gestation, he is 42 days old, and has a Corrected Gestational Age of 33\+1/40" or in shorthand "27\+1/40 gest \-\-> day 42 \-\-> CGA 33\+1/40" Gestation is an estimate, based on scan or LMP\. When an unbooked pregnancy delivers prematurely & often no information, even of LMP, is available \(it's a zoo out there\.\.\.\) If no information is available there are scoring systems to estimate gestation such as the Dubowitz or Ballard scales\. In current practice CGA remains the age used for growth markers and developmental milestones until the \(CGA\) age of 2 years when paediatricians arbitrarily decide to start using the normal date of birth to calculate the age\. For neonatal drug dosing the main marker used is current weight, although sometimes you also need to know the age \(from Dob\) as well as the gestation at delivery\. The two most useful numbers to the neonatologist and paediatrician are therefore Chronological Age \(from D\.o\.b\) and Corrected Gestational Age, all the rest can be worked out if you know todays date\. o DOB = Today \- Chronological Age o Gestation at birth = CGA \- Chronological Age o Est date delivery = Today \- CGA \+ 40\*7 o Est date of conception \(rarely used in medicine\) = Today \- CGA \+ 15\*\*\* Given the uncertain nature of life I think it is eminently sensible to record a confidence interval for CGA, as was previously suggested\. Sorry about the verbal diarrhoea\. Hope this is of some help, it obviously doesn't address the concept of elderly patients when birthdates are unknown etc, or fuzzy age ranges\. Rob\. \*\* P\.s\. currently \(although I think stupidly\) Chronological age in days is usually recorded as number of middays the baby has seen\. Therefore, at 12:30pm an infant born at 11:58am is 1 day old, whereas one born at 12:02pm is 0 days old\. Brilliant eh\.\.\. \*\*\* P\.p\.s All this is calculated from the historical notion that birth occurs 40 weeks after last menstrual period\. BUT in a regular cycle ovulation usually occurs 15 days after LMP\. Conception will probably occur in the next 24\-48 hours, foetal implantation 2\-3 days later, and birth on average will occur about 37\.5 weeks after this\. If any bit is early or late the timing will all be off\. Hence scans being more reliable\. --- ## Post #60 by @Philippe_AMELINE1 Hi Rob, These are very accurate informations\. Even engineers on the list will understand it \(and make good use of it\)\. This must certainly be part of the summary note concerning ages \(who writes it, by the way ?\)\. Regards Philippe an engineer on the list ;o\) rob challen wrote: --- ## Post #61 by @USM_Bish > Sorry to add my thoughts after the discussion has died down\. > Actually, yours is the first concrete proposal towards the issue of gestational age \.\.\. so cant't really say that the discussions have died really ;\-\) \[lots snipped\] > > The two most useful numbers to the neonatologist and > paediatrician are therefore Chronological Age \(from D\.o\.b\) and > Corrected Gestational Age, all the rest can be worked out if > you know todays date\. > > o DOB = Today \- Chronological Age > o Gestation at birth = CGA \- Chronological Age > o Est date delivery = Today \- CGA \+ 40\*7 > o Est date of conception \(rarely used in medicine\) = Today \- CGA \+ 15\*\*\* > Three of the above 4 computations are CGA based, whereas CGA itself remains uncertain \(being based on gestation\)\. Do we base gestation on something like this ? if \( ultrasound done in 12 to 16 weeks \) \{    gestation = ultrasound\_gestation    confidence = \(\+/\-\) 2 days \} else \{    gestation = \($today \- $LMP\) \+ 14    confidence = \(\+/\-\) 3 days \} > Given the uncertain nature of life I think it is eminently > sensible to record a confidence interval for CGA, as was > previously suggested\. > Does the above convey what you want to say ? Dr USM Bish Bangalore PS: I have some reservations on the EDD estimation, because the 40     week rule of thumb \(Nagele's Rule\) is not supported by current     statistics\. Gestation is not a fixed period and affected by     factors like parity and ethnicity\. However it is not of much     relevance to gestational age, per se\. --- ## Post #62 by @rob_challen Yes\.\. I later though after sending the e\-mail that what I'd meant to say was, of course, that the two most useful numbers are indeed CGA and Chronological age but they are of course both variable depending on the current date \(one gets older every day, after all\.\.\.\)\. Equivalent fixed values that do not change are of course Date of Birth and Gestation at birth\. These are the numbers you actually need to record\. The rest change every day\. Your calculation of gestation below is right if '$today' is the child's birthday\. It's probably better to express it as: if \( ultrasound done in 12 to 16 weeks \) \{    //EDD by scan method for calculating gestation    $gestation\_at\_birth = \($ultrasound\_EDD \- $date\_of\_birth\)/7 \+ 40    confidence = \(\+/\-\) 2 days \} else \{    //EDD by dates method for calculating gestation    $gestation\_at\_birth = \($date\_of\_birth \- $LMP\) \+ 14    confidence = \(\+/\-\) ???3 \(???maybe 7\) days \} Gestation \(at birth\) is after all a constant value, just sometimes not a very accurate one, and sometimes subject to revision\. The confidence interval of the the EDD by dates method is probably quite large \- I wouldn't even like to hazard a guess\. EDD by dates is frequently quite wrong though\. EDD by scan is better, but by no means foolproof\. Usually the question "how sure are you about your dates" is asked of the mother at some stage and the response is sometimes recorded in the notes\. It's not very scientific\. Infants who initially are thought to be 32 weeks gestation are sometimes 'down\-graded' to 34 weeks gestation based on their physical signs or dubowitz score, for example\. In the end though it is about setting a time\. In the grand scheme of things gestational age is only ever a guess\. It is worth recording, but I know of infants that have lost or gained a couple of days over a long stay in NICU from administrative error without any major consequences\. So it probably isn't worth losing sleep over\. Rob\. --- ## Post #63 by @thomas.beale This is an excellent discussion; re: my earlier post about creating knowledge pages, does anyone have the time or inclinication to create some sort of summary of this topic? If so, we can capture the important points \(including some of these technical details below and from other posters\) and have them as an efficient reference doc on the openEHR website rather than having to wade back through all these posts when we next need to revisit this topic\. \- thomas beale rob challen wrote: --- **Canonical:** https://discourse.openehr.org/t/age/14820 **Original content:** https://discourse.openehr.org/t/age/14820