Time in interval in interval measurements
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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Cyclic events
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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age - a summary
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 questi
Age
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 > 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: > >> 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 >> On 27 Jan 2005, at 20:15, Philippe AMELINE wrote: >> >>> 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, >> >> > > - > 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
Time in interval in interval measurements
> 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 -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Time in interval in interval measurements
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: >>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 > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
CR-000024 - Revert meaning to String in LOCATABLE nodes in openEHR data
> The question to the implementors is: which name is preferable - > "node_id" or "archetype_node_id"? I prefer "archetype_node_id" for the same reasons mentioned by Thomas. And I don't see any big problem caused by this change in our current implementation. Rong Thomas Beale wrote: > > Dear all, > > this CR has been processed, but since it involves probably the most > crucial piece of meta-data in the data - the archetype node ids which > are imprinted into their corresponding data nodes - I want to ensure > that we are doing the right thing, particularly by implementors. > (original CR text - > http://www.openehr.org/repositories/spec-dev/latest/publishing/CM/CRs/CR-24.txt) > > To refresh your memories: > > * archetypes have an id for the whole archetype, like > "openehr-ehr-entry.blood_pressure.v1", and node-level ids > throughout the archetype, usually of the form "at0002" etc. > * these ids are included in data generated from archetypes. The node > ids are recorded in every node of the data; this is achieved by an > attribute in the LOCATABLE class (Common IM, > > http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/reference_model/common/im/REV_HIST.html > - note this version is the current release, without the CR-24 > changes) > * this attribute used to be named "meaning", and was of type DV_TEXT > (allowing it to be a DV_CODED_TEXT as well), but CR-24 > proposed to alter that to an attribute called "node_id" of type > String. The idea behind this change is that all you need in the > data is the archetype node_id to be able to match data nodes to > archetype nodes and process them. It also simplifies the XML > considerably. Further work has shown that a function called > "meaning" is useful - this function does retrieve the whole term > from the archetype, in the language of the locale. Doing this > means that the archetype must be available, and/or that in EHR > Extracts, at least a copy of the ontology section of the > archetype, where these terms are defined, is included. > > This CR has passed, and the changes been made and tested in software but > not released. However, during ARB discussions it was suggested that the > attribute name in LOCATABLE be changed to "archetype_node_id" rather > than just "node_id". Remembering that this is the name of an attribute > in the _data_, the idea was that "archetype_node_id" makes it crystal > clear that the value is a node id from the archetype, not some other > node id being used in the data. In XML data, this one attribute, along > with the archetype_id attribute (the one that appears at archetype root > points in teh data) are the only two which will be expressed as XML > "attributes", i.e. appear inside the tag. This a) clearly separates > these special attributes from the "real" data attributes and b) > significantly facilitates XPath/XQuery processing (work so far suggests > that we will be able to have very powerful Xpath-based data querying in > openEHR systems that use XML). > > The question to the implementors is: which name is preferable - > "node_id" or "archetype_node_id"? > > My recommendation would be that, if it doesn't cause terrible problems > to current implementations, "archetype_node_id" is better - it really is > unambiguous, and doesn't get in the way if at some future time we want > some other attribute called "node_id" in the EHR information model. > However, I know that we have said in teh past, and documented as such, > the name "node_id". So - what do implementers/would-be implementers think? > > - thomas beale > > - 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
Time in interval in interval measurements
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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age
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 @openehr.org on 01/29/2005 07:12:55 AM Please respond to USM Bish Sent by:owner-openehr-technical at openehr.org To:OpenEHR Technical cc: Subject:Re: Age On Sat, Jan 29, 2005 at 05:26:45PM +0530, USM Bish wrote: > On Sat, Jan 29, 2005 at 01:07:06AM +, Thomas Beale 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. 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 - 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
Age
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 -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 31 Jan 2005, at 19:10, William E Hammond wrote: > 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 -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 802 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050131/dfe55f71/attachment.bin>
Age
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 > 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 > -- -- > Gerard Freriks, arts > Huigsloterdijk 378 > 2158 LR Buitenkaag > The Netherlands > > +31 252 544896 > +31 654 792800 > On 31 Jan 2005, at 19:10, William E Hammond wrote: > >> 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 > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age
Who are you calling elderly? I still hold out for age, even if it is fuzzy. Ed Gerard Freriks @openehr.org on 01/31/2005 04:25:17 PM Please respond to Gerard Freriks Sent by:owner-openehr-technical at openehr.org To:William E Hammond cc:OpenEHR Technical , USM Bish Subject:Re: Age 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 -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 31 Jan 2005, at 19:10, William E Hammond wrote: > 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age
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 -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-techni...@openehr.org] On Behalf Of William E Hammond Sent: Monday, January 31, 2005 6:32 PM To: Gerard Freriks Cc: OpenEHR Technical; USM Bish Subject: Re: Age Who are you calling elderly? I still hold out for age, even if it is fuzzy. Ed Gerard Freriks @openehr.org on 01/31/2005 04:25:17 PM Please respond to Gerard Freriks Sent by:owner-openehr-technical at openehr.org To:William E Hammond cc:OpenEHR Technical , USM Bish Subject:Re: Age 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 -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 31 Jan 2005, at 19:10, William E Hammond wrote: > 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 - 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
