Age and named quantities
Sam, You mean the 'age of a person' and not 'age'. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 31 Jan 2005, at 23:30, Sam Heard wrote: > 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? -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 704 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050201/da6509b2/attachment.bin>
Libre Software Meeting for Medicine, July 5-9, 2005, at Dijon, France
LSM 2005 Libre Software Meeting for Medicine 6th International Conference, July 5-9, 2005, at Dijon, France CALL FOR PAPERS Dear Colleague, On behalf of the Organising Committee it is my great pleasure to cordially invite you, or a representative of your Organisation, as a speaker or participant to the Libre Software Meeting for Medicine, Conference to be held on July 5-9, 2005, at Dijon, France Goal LSM is the annual international meeting of experts (prividers and users) on new developments in free software medical systems (open source) and their applications. An important objective of the LSM/2005 is to open contacts between people from different domains mainly IT (Information Technology) and Medicine. This conference concentrates on advances in Application of Informatics in Healthcare, which implies a lot of challenges, as the value (the qualitative and economic implications) given by the expansion of health care information exchange and interoperability to the flow of clinical and other administrative data, and its importance for encouraging health care IT investment and facilitating health care reform. We wish to address the lack of real-world implementation of interoperable systems in health care. Seamless integration of local and remote records, is far more likely to offer clinicians the integrated information they need for providing optimal care. Doctors (MD), informaticians, decision makers, policy makers, etc are kindly invitited to participate to this European conference dedicated to free software for medicine mainly addresing the value of health care information exchange and interoperability. For further details please see the attached file. Travel support may be available for the conference speakers. With kind regards, Simion Pruna The Chairman of LSM/Medicine 2005 = Simion Pruna, PhD Head of the Center Telemedicine Center I.L.Caragiale Str. 12, 070208 Sect. 2, Bucharest, Romania Tel. +40 722 304655 Fax: +40 21 3303769 www.telemed.ro -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050201/5f3943d9/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: LSM2005 CALL for Abstracts.pdf Type: application/pdf Size: 10261 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050201/5f3943d9/attachment.pdf>
Age
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 - 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
For us it doesn't matter. It will have some pretty big consequences for our implmentation, since we currently assume a DVText everywhere in the code. Since we are behind on the specs anyway (meaning not really keeping up), this won't yet be integrated, untill we have a go at catching up with the changes made to the specificion. We would like to see some kind of deprecation however for changes to the openehr model, since it currently is already a very big puzzle for us to be able to use the new specs. Maybe it will somewhat clutter the specs, but currently we have to start downloading/tracking older revisions of the spec to get to what we implemented. Example is the table_s which was renamed to item_table (with a whole new inheritence tree) in the specs, finding the right spec gave us a hard time (we didn't have the time to refactor everything to use the new structure). You say : This CR has passed, and the changes been made and tested in software but not released. Which software and how was it tested ? Mvgr, Martin 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
openEHR change management
Martin van den Bemt wrote: > For us it doesn't matter. It will have some pretty big consequences > for our implmentation, since we currently assume a DVText everywhere > in the code. Since we are behind on the specs anyway (meaning not > really keeping up), this won't yet be integrated, untill we have a go > at catching up with the changes made to the specificion. Martin, presumably your implementation is locked at an earlier baseline of openEHR around 0.9? > > We would like to see some kind of deprecation however for changes to > the openehr model, since it currently is already a very big puzzle for > us to be able to use the new specs. Maybe it will somewhat clutter > the specs, but currently we have to start downloading/tracking older > revisions of the spec to get to what we implemented. Do you mean you want to keep all previous details intact in the specification documents? I think we have a reponsibility to publish the latest version of any specification in a "clean" form for new implementors - after all the latest version is "the specification". If you look at the changes that have been made, there are currently 125 or so change requests - some of which have changed the way we present the material, some of which change the structure of the model. Now, the intention is that such changes will diminish over time, with the forthcoming release 1.0 being a stable release. And of course, there cannot be ongoing chopping of changing of the basic models. However I think we are still in a phase where we are getting feedback from implementors about what works and what doesn't. I think it would be resonable to do what you say after the release of 1.0, and we will look into how this should be done. At the moment, we have tried to a) supply detailed CRs online and b) be careful to document all changes in the revision histories of the specifications and c) make sure that all the specifications compile in our modelling environment, before publishing them. It does mean that implementors have a certain responsibility to read the CRs (particularly the page http://www.openehr.org/repositories/spec-dev/latest/publishing/CM/CRs/CR_by_release.html) and the revision histories of documents. A new CR/PR system will make CRs more accessible, and the CM plan has been rewritten. What would help us is better feedback from implementors - it has been hard to determine how many developers are at what stage in implementation, and therefore what impact any change will have. Hopefully the new "implementers" list will help that; other suggestions are welcome. Another thing we will release in the next couple of months is a textual rendition of the entire RM and Archetype Model in XML form, using a UML 2.0 tagset. This expression of the model will be lossless from the specifications, and can be used to generate or validate other deliverables, such as XML-schemas, programming language interfaces, relational database schemata and so on. > Example is the table_s which was renamed to item_table (with a whole > new inheritence tree) in the specs, finding the right spec gave us a > hard time (we didn't have the time to refactor everything to use the > new structure). This change happened quite a while ago now - I would have thought nearly 2 years ago, but I would have to check that. Do you mean that it wasn't easy to work out what had changed? Suggestions on how to better provide such information are welcome. > > You say : > This CR has passed, and the changes been made and tested in software > but not released. > > Which software and how was it tested ? all modelling changes are made to the openEHR Eiffel model environment, compiled and tested in a basic way. This environment is used because it is the closest to UML that actually implements all UML semantics, particularly class invariants and pre- and post-conditions (otherwise known as "contracts"). I don't mean to imply that whole systems have been built with each change by openEHR - of course it doesn't have the resources for that. But most other specifications - standards - in the world are not even validated before being published, and so there is not even a minimum guarantee of implementability or coherence. In the future, with reference software implmentations in existence, we would use those to test changes before releasing them. This will include the emerging Java reference model implementation, XML-schemas and so on. hope this helps. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age and named quantities
On Tue, Feb 01, 2005 at 08:00:39AM +0930, Sam Heard wrote: > > 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: > > "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 at openehr.org
proposal for gathering community knowledge
On Sun, Jan 30, 2005 at 04:32:07PM +, Thomas Beale wrote: > Thomas, just noted that this nice suggestion of your has not evoked a response so far ... opening the batting here ;-) > > What it comes down to is this. Interesting, sometimes long > discussions occur about topics like "what is an episode", > "age", "confidentiality" and so on. Many good points are made, > and there may even be a consensus view reached due to the > discussion. Then a new discussion occurs. What is lacking is a > summary/pr?cis of the material - a synthesis if you like. I > suspect that most discussions which generate 50 pages of email > could be summarised in about 2 A4 pages. Now, there are various > technological attempts to help with this sort of process, such > as Wiki and other online document modification systems. > However, I have never been convinced that the best way still > isn't to get a good human brain on the job, to produce a > summary the old-fashioned way - by reading and thinking! The > kind of document we are looking for is something ranging from > an FAQ entry, to up to say 5 pages of detailed description; it > would then be added to the online knowledge pages of the > community. > [rest snipped] > o The proposal of summarising important discussions is nice. It is also quite unique. o Implementation would be a hurdle, because of the following :- a) You need the co-ordinating agency first, and then the core group needs to set the ball rolling ... b) Voluntary effort always works for intellctually stimulating things. IOW, the satisfaction to effort ratio would have to be high. In this type of thing, with smaller expected ratios voluntary jobs would have to be done military style: "One must be detailed to volunteer" ;-) c) Need a proper flow chart/ UML of the action plan ;-) o I can help in the Medical portions. I am a medical graduate of 1976 vintage, with a Diploma in Aerospace Medicine and MD.I am also an unqualified programmer/ IT man of sorts, with initial forays into programming since CP/M days, more or less self taught, having learnt tits and bits from works of 'gurus' like Knuth and Wirth. OOP is a oops situation for me but I am quite okay at scripting (shell, perl, php) and K&R C (programmed in pascal style) ! I am totally ANTI-M$, and on Linux/ *BSD since 1995. o If above QRs fit your bill, count me as an extra hand in for medical portions only ... Cheers Dr USM Bish Bangalore - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age and named quantities
An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050201/cf64f32b/attachment.html>
proposal for gathering community knowledge
USM Bish wrote: >[rest snipped] > > > >o The proposal of summarising important discussions is nice. It > is also quite unique. > >o Implementation would be a hurdle, because of the following :- > > a) You need the co-ordinating agency first, and then the core > group needs to set the ball rolling ... > > b) Voluntary effort always works for intellctually stimulating > things. IOW, the satisfaction to effort ratio would have to > be high. In this type of thing, with smaller expected ratios > voluntary jobs would have to be done military style: "One > must be detailed to volunteer" ;-) > > I hope there would be satisfaction from having produced a nice readable article (let's call it that for now) which will be read by many others later on. Particularly if we index and present all the articles well. > c) Need a proper flow chart/ UML of the action plan ;-) > > I think this is a good idea, although I often get flak for suggesting such things - too much process for some people. >o I can help in the Medical portions. I am a medical graduate of > 1976 vintage, with a Diploma in Aerospace Medicine and MD.I am > also an unqualified programmer/ IT man of sorts, with initial > forays into programming since CP/M days, more or less self > taught, having learnt tits and bits from works of 'gurus' like > Knuth and Wirth. OOP is a oops situation for me but I am quite > okay at scripting (shell, perl, php) and K&R C (programmed in > pascal style) ! I am totally ANTI-M$, and on Linux/ *BSD since > 1995. > > You are eminently qualified obviously. I am wondering if the best approach for this "editor" job is to get a sort of disinterested editor (who is reasonable at dissertation however) to collate existing discussion material into an article - a bit like a journalist or popular science writer - rather than an expert to write an article which might be more like an academic paper extolling one point of view, but perhaps not representing the discussion adequately. At least these two styles or writing are well-recognised. Perhaps as an experiment, we can just use this current topic of "age". Nathan Lea at CHIME at UCL has offered to have a go at editing something - he is an excellent writer & researcher, but not a doctor - this will mean he will use pieces of what you and other clinical people have said in various posts (Sam has another nice summary a few articles earlier). My suggestion is to try an experiment - let's just see if we as a group can produce: - an article summarising the "age" discussion. Needs decent headings to be thought up; can;t be too long; should cover all informed opinions found in posts - a process or flowchart for doing this habitually Reactions? - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age
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 ___ Kevin M. Coonan, M.D. kevin.coonan at utah.edu Adjunct Assistant Professor, Division of Emergency Medicine NLM Fellow, Department of Medical Informatics University of Utah School of Medicine -Original Message- From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of William E Hammond Sent: Monday, January 31, 2005 11:11 AM To: USM Bish Cc: OpenEHR Technical Subject: Re: 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 menstur
Age
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 -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 01 Feb 2005, at 02:45, 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. > > 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 -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2517 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050201/867c7508/attachment.bin>
Age and named quantities
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? FinallyI 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: "Birth" 0 "days" "Adolescence" 12 "years" 18 "years" "Three times a day" "FREQ=BYDAY;OCCURRENCES=3" "Three times a day" "0800;1400;2000" "Last night" 20:00 06:00 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: > 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
