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 > 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 at openehr.org >> > > > > Pleksus Bili?im Teknolojileri > http://www.pleksus.com.tr > Tel: +90 (312) 435 5343 > Fax: +90 (312) 435 4006 > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
