Subject of care
Eric We have fetus and donor as subjects of care also - sorry for omitting that. Cheers, Sam -Original Message- From: Eric Browne [mailto:eric at montagesystems.com.au] Sent: Monday, 2 December 2002 8:48 AM To: Sam Heard Cc: Openehr-Technical Subject: Re: Subject of care Sam, I'm not sure if you are only considering familial links. If not, then organ donor/donee relationships might give rise to similar (and other) identification requirements. eric Eric Browne \ phone: +61 8 8331 3022 Montage Systems \ web:http://www.montagesystems.com.au Level 1, 145 The Parade, \ email: eric at montagesystems.com.au Norwood, SA 5067 Australia. On Mon, 2 Dec 2002, Sam Heard wrote: Dear all I have been reviewing the subject of care - over family history. It is clear that the following information is potentially useful: 1. The name of the person so you can refer to them as so-and-so 2. The relationship (father, mother) this might or might not include their genetic relationship (adoptive) - at present I have this in the genetic relationship boolean value of the family history problem. I think this is the most appropriate as it is the only time when it is essential to know it?? 3. The ID of the person in the demographic server - allowing contact details etc. Can others think of other issues with identifying the subject of an entry in the EHR - (not the ehr itself!) Times when this is likely are around the birth of a child and for family history problems. Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ - 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
Categorising EHR Content
Eric I have archetyped this to some extent based on health care pathways and external payments/insurance etc in such circumstances. I have called it Accident/Injury/Poisoning - this sounds like your non-health care event. It has information about the insurance company (if relevant). It does not, at present, have any features not dealt with in openEHR entry.observation class. Pregnancy is also modelled as an observation - it is does not include the antenatal visits - as these are recordings made during pregnancy. The fact that a (persistent) pregnancy recording might contain links to these (event) recordings is optional. One day, archetypes might be accepted nationally that make this mandatory? The pregnancy observation includes (as I have archetyped it) Date of LMP Date of EDD (can be revised as required) Active (is this pregnancy still active) (to cope with multiple births) [Name of child] \ date and time of birth [Name of child] \ location of birth [Name of child] \ mode of birth [Name of child] \ Birth weight (Then a whole lot on complications) Fertility procedure This may not prove to be the best approach - but it is clearly persistent information. Cheers, Sam -Original Message- From: Eric Browne [mailto:eric at montagesystems.com.au] Sent: Saturday, 7 December 2002 2:25 PM To: Thomas Beale Cc: Sam Heard; openehr-technical at openehr.org Subject: Re: Categorising EHR Content Tom Sam, Thanks for taking the time to explain the openEHR use of OBSERVATION, EVALUATION and INSTRUCTION and how these do not limit the ability to express state and events in a variety of clinical models. When one moves from thinking in the healthcare space to thinking in the recording space it is easy to misinterpret terminology, particularly in simplistically mapping state to OBSERVATION and healthcare actions to INSTRUCTION. I would, however, still like to crusade for the importance of the notion of non-care event, and its usefulness in future care. I appreciate it can easily be catered for in archetypes, but would like to re-stress its importance. To start with your statement, Tom, regarding the usefulness of recording the Bali-bombing in a subject's EHR: yep. And consider: while it would in theory be possible to put something in the EHR indicating the fact of the Bali bombing, this is in fact of no use to patient care - we have to the know the patient's point of view, not just the independently reported fact from the ABC reporter. Were they in the nightclub? Around the corner? Heard the blast (ear damage)? The very knowledge of the event totally transforms the care that is provided, as you, yourself indicate. I doubt that a person admitted to an ICU with burns to his/her foot would normally be tested for hearing loss! The normal course of healthcare is one of deducing the event. From thence forth, domain knowledge, harnessed from many similar events to other subjects, is used to guide the course of analysis and treatment. The analysis and treatment is, of course, modulated by the individual's symptoms, as you suggest. In fact, this process occurs so frequently that the first part of it is given a special name - diagnosis. It's just that diagnosis is usually limited to a subset of the event space (i.e. those change_of_state events that are taught in medical schools). Again, consider a 25 year old female who presents at a clinic having missed 2 successive periods. The GP, having considerable knowledge of a generalised pregnancy event, suspects, tests for, and diagnoses pregnancy. The event, and domain knowledge thereof, is more important than the recording of the observation missed 2 successive periods. Now one could view pregnancy as an aggregation of observations. One could view pregnancy as an evaluation from observations. One could view pregnancy as an event, about which special data should be stored ( subject's weight, estimated date of conception, HbA1c, etc. ) I think that there is value in the last of these views, independent of the first two. From an epidemiological point of view, it is useful to store non-care events. In their absence, one could trawl through a population's set of EHR's and discover a correlation between first degree burns, hearing loss and trauma. But I am not convinced this would lead to a clinical guideline for dealing with bomb victims. I seem to have drawn the discussion away from the topic of this list. Perhaps I should redirect further discussion to openehr-clinical instead? Thanks again for your explanations. regards, eric On Fri, 6 Dec 2002, Thomas Beale wrote: Sam Heard wrote: Eric You are into the territory that Computing and Health care have been swimming in for many years - how to model health care - rather than health care recording. exactly right. The models we have developed describe
[Fwd: RE: Subject of care]
Tom This is not necessary or appropriate - as Matthew has said - placenta is both! It is important that our solution allows information about another person to be in an EHR - family history is a good example. We will not link between peoples EHRs - ever in my opinion. Cheers, Sam -Original Message- From: Thomas Beale [mailto:thomas at deepthought.com.au] Sent: Thursday, 19 December 2002 1:43 AM To: Sam Heard Cc: openehr-technical at openehr.org Subject: Re: [Fwd: RE: Subject of care] I think that the only systematic approach is to make a new EHR for each genetically distinct individual. This means making an EHR for a foetus as soon as anything at all is to be measured about it, and also storing the link of this EHR to that of the mother. If the foetus dies in utero or is aborted, then its EHR shows this properly as death jsut as it would be shown in a normal person's record. As for situations where the individual's DNA distinctness is not totally clear like the bone marro transplant situation, I don't think that is a problem. Observations can be made on genetically different material to the patient, in the patient's record, as long as these observations relate to the care of that patient. E.g. blood tests, other tests made to a sibling for the sole purpose of doing a transplant into the patient - should probably go into the patient's EHR... But I do think we need to forget the idea that because a foetus is not really a person, it is not a possible subject of an EHR. I think we have to work on genetic distinction and distinct organism (whether called human or not) instead. thoughts? - thomas Sam Heard wrote: Matthew Great scenario's 1. If prenatal diagnosis is being done by chorionic villus sampling (CVS) in a twin pregnancy (which does happen) then it is the placenta - or rather the placentas - which are sampled. Each placenta has a DNA genotype matching that of the fetus attached to it (ie not the mother) as the placenta is an extension of the fetus. If however the fetus is an extension of the mother, then are we really saying we like the idea that the placentas may have to appear as multiple temporary organs of the mother, which are different in every pregnancy, and which never share her total genotype? A likely outcome would be selective termination of one twin (the affected one, on the basis of a molecular finding and either a makable or a confidently predictable clinical diagnosis) leaving the unaffected one to go to term. Thus a part of the mother is diagnosed clinically and molecularly, findings which are important for the mother later on, in that they'll trigger appropriate care next time around, but which *must not* be confused with her own clinical diagnoses or test results. This example is a very good one - it shows that there is a need to identify the fetus over and above its relationship with the mother. I have suggested that we use a local label for this - could be LOCAL:Twin1_2002. - the relationship for the information is FETUS. The important thing here is that we have the idea of subject of care - a unique identifier (or self) and the relationship. The sampling is the taking of a histological sample of a body part - the subject is the FETUS. There will be a procedure record, a sample and a histological report - all with the fetus as the subject of care for the data - in a composition that is part of the mothers EHR. It may be copied to the child's EHR in the future - I have thought about the transform required to do this and it should be relatively easy if the relationship of the two records is stated first. 2. Bone marrow transplantation, where it may be necessary to distinguish that the post-transplant patient may still have a haemoglobin variant, but a different one to the one they were treated for, and accordingly no disorder to go with it, but will still be genetically as they were before the treatment in every other organ. Also the donor was most probably selected from the same family, so confidentiality may be slightly different...? Interesting - who is the subject of care then? I guess this will be deduced from the data - I do not think that we can say the origins of all the states in a person that arise following a donation - at times it may be ambiguous (graft v host). We have considered 'donor' to be the relationship - but the person may have a relationship with the person apart from this? I do not think that the subject of care needs to be the donor then - it can be the family member as it is known who they are. Interesting! It seems to me that we can either organise our concepts to make this kind of record easier and more obvious, or we can begin to inbuild problems for later on (eg if the fetus is part of the mother, having to explain to all our knowledge agents that this might not extend
[Fwd: RE: Subject of care]
Ed Thanks for that - I think this is the correct approach - recognising that there will be times when a fetal record may be required - such as with antenatal surgery etc. Any thoughts on the EHR SIG? Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of William E Hammond Sent: Friday, 20 December 2002 11:19 PM To: Thomas Beale Cc: Ignacio Valdes; openehr-technical at openehr.org Subject: Re: [Fwd: RE: Subject of care] We actually dealt with this topic at Duke in the OB system in the early 1980s. We did create a record. One interesting problem was ghost pregnancies in which it appeared for a period of time to have two fetuses later to be one. Our actually execution turned out to not create the new baby record until birth but to back load the data from the mother. This also solved IDing problems. 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
[Fwd: RE: Subject of care]
Dear All Sorry, I have been out of touch over the Xmas - great surf on the east coast! This may be old ground? This conversation is sounding a little like a technical solution rather than a pragmatic solution. My response is that both solutions are required - a fetal record (rare) and fetal recordings in the maternal record. The fetal heart rate is an example of a measurement that is NOT the mother that is appropriate for the maternal record - and I do not think that anyone is going to start a fetal record for this value. Philippe is right - fetal scans will sometimes (rarely) have implications for the future child and will need to be copied to that record in the future. I do not think that linking between records will be an acceptable approach - although it is attractive technically - as it will pose a lot of privacy issues that the public are not ready for at this stage - neither am I frankly! Applications can clearly link the records as they wish with the appropriate access controls. The scenario of not having family history records but rather a set of links to all relatives records is not tenable in the current environment and should not be proposed as a solution at this stage. The fact that openEHR would allow this technically is not a problem. I will read on in this threadSam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Philippe AMELINE Sent: Thursday, 19 December 2002 7:57 PM To: openehr-technical at openehr.org Subject: Re: [Fwd: RE: Subject of care] A foetus is tightly coupled to a mother, but is sufficiently distinct for there to be a need for a separate EHR under certain circumstances. What do you call certain circumstances ; anyway, the follow up echographies during pregnancy belong to the future baby. The question is when do we spawn a new record? Under normal circumstances, this would probably occur at birth, partly since the foetus becomes a person under law, partly because it becomes an entity predominantly independent of the mother, partly because prior to birth there is rarely a need for information specifically regarding the foetus. which is what I used to think, based on Sam's thinking, but having had this discussion, I have changed my mind. As soon as the first observation is made of the foetus it should have its own EHR. I agree with that. A solution coul be to open an EHR immediately (first echography ?) and have this EHR usable as a time delimited window inside the mother EHR. The other solution (more pragmatic) would be to have the mother's pregnancy Problem (just POMR way of labelling things) being opened as a before birth window inside the baby record. It is more pragmatic since the system you work on during pregnancy is the mother (with extra organs). I can't guess the legal issues. Philippe - 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
Data Types
Tim I think this is true but from a date point of view we can only know the year if the month is unknown - if it is one or two then the person will have to guess and store it as a fuzzy date. I think this is the only sensible approach. We can record in text the time issues that have been mentioned. Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Tim Cook Sent: Tuesday, 4 June 2002 2:28 PM To: openehr-technical at openehr.org Subject: Data Types DV_PARTIAL_DATE - Purpose: Incorrectly assumes that a 'day' is unknown with a known or unknown month. It is very realistic to see a situation in which a person will recall that something occurred on the 1st of the month 10 years ago but cannot recall if it was June or July. People relate things in their life and if an event is recurrent on a specific day of the month they will recall that though they may have no reference to which month it was. DV_PARTIAL_TIME - Purpose: Incorrectly assumes that an hour will be known. Same reasoning as above that a person may not be certain if an event occurred at half-past 10 or half-past 11. R/S, Tim Cook - 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
TBD_10
This was meant to be a data type for the physical location of something - an Xray film, specimen etc. I agree that this should be an archetype. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale Sent: Tuesday, 4 June 2002 7:05 PM To: OpenEHR-Technical Subject: Re: TBD_10 Tim Cook wrote: Suggestion: Send DV_PHYSICAL_DATA to the bit bucket. I agree that those instances should be archetyped. that's 2 votes for the bin (me and Tim)! - 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
Data Types
Tim This is definately a mistake - amny disorders have a date of onset that is fuzzy from a month point of view but is worthwhile - last Pap smear, last attendance at Ophthalmologist etc. The point about a fuzzy date is that it is helpful for human interpretation - a month that a spouse died will be very worthwhile even if a day is not known - when chasing records at another centre - knowing that a date is accurate or not will overcome a lot of frustration. SAm -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Tim Benson Sent: Friday, 7 June 2002 6:19 PM To: Thomas Beale Cc: openehr-technical at openehr.org Subject: Re: Data Types Tom, I do not think that structure can be justified if that structure is unlikely to add either value or safety down the line. So in the situation where we are not able to rely on a time as being either a strict point in time or an interval is likely to create semantic problems. Unless you can rely on strict chronological listing it is unhelpful to try to give spurious precision. So my suggestion is that such fuzzy dates should be put into free text only and all dates associated with any entry should only be the ones we can rely on, such as date and time of entry. What is more precise: the first of the month, but do not remember which month, the night it rained or the morning that the kids were late for school? To me there is no point in using anything other than free text for any of these. Julian dates can be very useful, but not all date information fits the simple model and errors are made when we try to force it in. We should always have a time stamp for computer entry, which should be flagged if this is the only Julian-type date information that is available (and must be used with great caution along side free text data). Tim -- Tim Benson Abies Ltd, 24 Carlingford Road, London NW3 1RX, UK +44 (0) 20 7431 6428, tb at abies.co.uk From: Thomas Beale thomas at deepthought.com.au Organization: Deep Thought Informatics Pty Ltd Date: Tue, 04 Jun 2002 19:59:43 +1000 To: Tim Benson tb at abies.co.uk Cc: openehr-technical at openehr.org Subject: Re: Data Types Tim Benson wrote: Surely the criterion for any structured data is whether another application is expected to use that structured data in a way that (a) adds value and (b) is safe. If either (a) or (b) are not true then structure simply adds cost and complexity without benefit. Tim, I agree with the premise; but what is your solution in this case? The structure would only change in a very trivial way i.e. by adding a flag which means day_unknown. Are you asking for a use case which proves that this should exist? I agree - that's what we need. Tim has provided the simplest of all - if the patient said it, we should record it. Is it enough - I don't know... - 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
The concept of contribution
Henry Thanks for the 'dumb' contribution. I hope that you can see that openEHR has approached the problem in a way that will allow the sort of scenarion that you have painted as well as a more complex scenario with a distributed record - or even the big brother one record for each patient held centrally. The reason is that we cannot predict the size of future work units or the technology that will be around - only that the technology should not dictate the work practices - only support them. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Li, Henry Sent: Tuesday, 11 June 2002 11:36 AM To: 'openehr-technical at openehr.org' Subject: FW: The concept of contribution -Original Message- From: Li, Henry Sent: Tuesday, 11 June 2002 9:10 To: 'Denis Nosworthy' Subject: RE: The concept of contribution Hi I am not a real techno but I understand and deeply interested in the discussion. I had this vision of a real good electronic health record. It is one own by the patient, carry by the patient, and presented to the health care provider (whoever they are) by the patient (all over the world). The Browser and XML or its improved version whatever it may be in the future is the way to go. This is the process A patient visits a care provider and presents his e-card as a proof of consent to treatment The health care provider loads up the health record into the browser and download the info into whatever system he is using (this applies to Hospital as well), the health care provider can also choose to discuss the patient with other health profession on line through the web. When the patient leave the care provider, it is the responsibility of the care provider to upload whatever he has done to the patient back to the e-card and the patient goes away. Any subsequent test results etc, it is the responsibility of the health care provider to contact the patient to have the data put into the patient's e-card. (the patient can choose not to do so - but it is of course to the patients benefit to do so) The benefit of this is at any one time, the patient is the only person that has a complete health history of himself and he owns it. (Solve the ownership and privacy issue) After all, currently, the health care provider will only know as much as what the patient choose to tell them anyway. New industry will start up to take care of the situation and provide all sorts of support to the e-card holders. These services include how to download, how to backup or even help retrieve data in emergency etc. etc. - god knows what will come up in the commercial world. Good or bad, no big brothers. When the patient dies, he can choose to sell his e-card for research purposes and has money to bury himself - no burden to next of kin. The reason I write these is that, I think I contribute as from a dumb user's point of view, may be it has some bearing on the design and the structure of the 'database' or 'rules' or whatever you may call it. The only consideration will be where to put different types of health data in the structure. It is upto the provider system to come up with the download and upload method. Cheers Henry Li -Original Message- From: Denis Nosworthy [mailto:Denis.Nosworthy at swsahs.nsw.gov.au] mailto:[mailto:Denis.Nosworthy at swsahs.nsw.gov.au] Sent: Tuesday, 11 June 2002 8:37 To: 'Sam Heard'; openehr-technical at openehr.org mailto:openehr-technical at openehr.org Subject:RE: The concept of contribution File: InterScan_Disclaimer.txt Sam, Well said. We have for many years been operating under the ideas of 'interoperability' and whilst tools such as HL-7 have been very successful in getting us through these times the issue of EHR interoperability will be something else yet again. Source system interoperability is one thing however (mostly constrained within a controlled environment) but receiving systems such as EHRs will have to be truly interoperable if they are to be effective. The EHR is not a messaging system as some would have us believe (in some incantations it could be seen to be just that) but it must be a system that clinicians can rely on to be accurate and reflect 'real life'. If it has to rely heavily on 'real time' messaging then the vagaries of our telecommunications systems will have a significant impact on that level of acceptance -Original Message- From: Sam Heard [mailto:sam.heard at flinders.edu.au] mailto:[mailto:sam.heard at flinders.edu.au
Patient notifications
Aniket Of course I know about CPGs - just the acronym eluded me! CPGs are very interesting from an EHR point of view. The issue here is the generic CPG and the specific - how we allow specialisation to the particular patient, how we merge a number of them sensibly, how we allow updates of CPGs to influence future care. Our learning in this area has a long way to go but we can start. The openEHR entry called an instruction allows specific 'guidelines' to be entered into the record - monitoring or notifications, therapies etc. This is relatively straight forward - the issues start to arise when a generic guideline is altered - what does this mean to someone who is adhering to the previous guideline? We can go with defaults - 2 years in Australia for a PAP test recall. So if the Care Plan of a patient has a notification for a pap recall, and the period is set to default, then the notification period can change with the guideline. Not so bad - fixed recall periods will not be altered. There might be some people however who need a 2 year one based on the evidence - clinicians could learn to fix the period of anyone with any abnormality - that seems solvable. Then we get into the issue of a complex CPG such as immunisation - there are many rules, temporal and sequencing, age at immunisation etc. Changing the default guideline becomes very interesting and really requires a little decision support engine to be available specifically for the purpose. What do you think? Cheers, Sam Dr Sam Heard The Good Electronic Health Record Ocean Informatics, openEHR 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.gehr.org www.openEHR.org __ -Original Message- From: aniket Joshi [mailto:anya_joshi at yahoo.com] Sent: Wednesday, 27 November 2002 3:02 AM To: Sam Heard Subject: RE: Patient notifications Clinical practice guidelines. These can be incorporated in GEHR and thus we can have a much more specific application development. We can have mappings which will lead to particular set of tests as per the CPGs. This will ease the implementation of CPGs in clinical practice. Dr Aniket Joshi --- Sam Heard sam.heard at bigpond.com wrote: Aniket I am not aware of CPG ?? Sam Dr Sam Heard The Good Electronic Health Record Ocean Informatics, openEHR 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.gehr.org www.openEHR.org __ -Original Message- From: aniket Joshi [mailto:anya_joshi at yahoo.com] Sent: Monday, 25 November 2002 6:02 PM To: Sam Heard Subject: Re: Patient notifications In our scenarios majority of the population is illeterate,so interaction with the computers is out of question.We can record their videos and keep them in the folders. Other non-medical communication which come from the HCPs can definitely be kept in the folder. For the medical record of each appt a Hyperlink can be given so that we can have a vertical record. Have gone through the CPGs and their application in GEHR? DR ANIKET JOSHi --- Sam Heard sam.heard at bigpond.com wrote: Dear All I have been developing the idea of part of the record that the patient can write in - I have (Gates style) called it My Folder (eh?) and have two subfolders in it at present - consent statements (as these will be written by the patient) and appointments and notifications. It is clear that the patient needs to write and interact with these. I have thought recently that we may be best to develop a transaction for each of the patient notifications - which will have all the details in it - rather than process notifications into a collected transaction (like a calendar) - this means that the application will need to process these. I have thought that we could have an archive folder for when the patient has done whatever was required - or declined to do so. This would mean perhaps an archive folder and an entry for the outcome of the notification. What do you think? Sam Dr Sam Heard The Good Electronic Health Record Ocean Informatics, openEHR 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.gehr.org www.openEHR.org __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org __ Do you Yahoo!? Yahoo! Mail Plus Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Archetype rules (invariants) in openEHR RM?
Tom I think work Unit or Work Group is important as long as it is linked to an organisation - a person might work on a ward, an outpatient department and in the cardiology team. As far as the referral is concerned - it could be to a work unit if that is available and has a system for dealing with referrals. Clearly an institution would limit the parties that will accept referrals. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale Sent: Thursday, 28 November 2002 10:34 PM To: openehr-technical at openehr.org Subject: Re: Archetype rules (invariants) in openEHR RM? Ahmad Risk wrote: Please let me enetr this dialogue. In the UK, a GP might refer a patient to a named Cardiologist. However, that referral, upon arrival at the hospital, might be handled by the Cardiology Team of that cardiologist. One might argue here that the 'team' is really a department, albeit, a unit within the Cardiology department. Equally, the referral from the originating GP could be directed at the cardilogy department without specifying the named provider. there are two questions here: a) who is delivering the care - in this case, it seems to be the team. b) who is legally responsible for the care, which as far as I know, must always be an individual, or a registered health care provider. Both of these potentially need to be recorded. If we want to identify teams or departments, we may need a new kind of party, or else we generalise the notion of ORGANISATION to something like GROUP, where a group just means more than 1 person with a common purpose - or something in common - what would it be, in general? thoughts? - 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
Terminology services
Dipak I would propose that such narratives be kept in a different transaction if you want to specify the language and referenced from the main record. This can be transparent for the user (BUT the language would of the referenced transaction would need to be stated as it differed from the current workspace) but maintains the principle - one transaction, one language. Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of DipakHome Sent: Friday, 29 November 2002 4:45 PM To: Openehr-Technical Subject: Re: Terminology services Dear All, I would like to concur with Sam on these issues. i.e. 1. The natural language used in recording a set of EHR entries should normally be specified at the Transaction/Composition level. 2. The EHR must be able to represent faithfully the use of a term from a terminology system by an author, by being able to represent (either as one or as multiple attributes) a) the code value b) a unique reference to the terminology system that issued the code (ISO CEN naming schemes have been defined over the years but not rigorously or comprehensively adopted) c) the version of that system used d) the actual rubric as selected by the author (for safety, and for transparency in a distributed environment) 3. The language of the Transaction/Composition should be deemed to have prevailed throughout However, 4. There is at times the need to include remarks (e.g. made by the patient or a relative) in a different language to the main clinical author. This might arise, for example, if the main author is a health advocate working jointly with a patient and a clinician who do not speak the same language. This is not entirely conjecture, as I have worked in such clinical situations (but obviously, not with such wonderful systems that can do what I am proposing here). As patients begin to fill in questionnaires that form part of a consultation, a need for mutli-lingual Compositions may arise in that scenario too. This means that the EHR representation of narrative expressions should permit a specification of natural language that differs from that of the overall Transaction/Composition. With best wishes, Dipak Dr Dipak Kalra Senior Clinical Lecturer in Health Informatics CHIME, University College London Holborn Union Building, Highgate Hill, London N19 5LW Direct Line: +44-20-7288-3362 Fax: +44-20-7288-3322 Web site: http://www.chime.ucl.ac.uk - 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
No known allergies
Dear all Another issue that is coming up at the moment. In the EHR recording or clinical models ontology I have proposed that all allergies be recorded under the ehr://persistent transactions (Fld)/Therapeutic precaustions (Tx)/Known allergies (Org) as openEHR.evaluation.allergies. The issue is how do we know that the organiser is empty because the patient has been asked about this? I would propose that we have an 'Empty' entry that is generic and can be used to show that any organiser in the openEHR record is known to be empty - then we will know who put it there and when. I suggest that the empty entry allows a return string of type DV_TEXT (ie plain or coded) to state the situation - in this case it might be No Known allergies. Comments? Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Patient notifications
Dear All I have been developing the idea of part of the record that the patient can write in - I have (Gates style) called it My Folder (eh?) and have two subfolders in it at present - consent statements (as these will be written by the patient) and appointments and notifications. It is clear that the patient needs to write and interact with these. I have thought recently that we may be best to develop a transaction for each of the patient notifications - which will have all the details in it - rather than process notifications into a collected transaction (like a calendar) - this means that the application will need to process these. I have thought that we could have an archive folder for when the patient has done whatever was required - or declined to do so. This would mean perhaps an archive folder and an entry for the outcome of the notification. What do you think? Sam Dr Sam Heard The Good Electronic Health Record Ocean Informatics, openEHR 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.gehr.org www.openEHR.org __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
Karsten I do not go with the screen shot idea - the issue here is the accountability and if the information is stored in an explicit manner and the rendition can be stored (XSLT or application) then it will be clear what the person saw - the problem with screenshots is the plethora of views that might be used in a single consultation. And can we be sure that the screen was paged down? And what was the resolution of the screen - and the visual acuity of the practitioner - and what parts of the screen did their eyes stray to... Our research in GEHR had a clear outcome - clinicians did not want this sort of EHR and it served no useful purpose. Cheers, Sam Dr Sam Heard The Good Electronic Health Record Ocean Informatics, openEHR 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.gehr.org www.openEHR.org __ -Original Message- From: Karsten Hilbert [mailto:Karsten.Hilbert at gmx.net] Sent: Saturday, 14 September 2002 5:49 PM To: Gerard Freriks Cc: Melvin Reynolds; Thomas Beale; William Hammond; Sam Heard; Openehr-Technical Subject: Re: Archetype ontology So an EHR is a series of signed, authored messages that can be used in court. Without the fulfillment of the requirements, the EHR is nothing but information written in the sand before a wave of the sea washes it away. This is, however, the way medicine worked for thousands of years, and reasonably well, obviously. It is trust that defines the doctor-patient relationship, not proof. What an application does with the information on a screen and in its database is much less relevant from a legal perspective. What is signed is relevant. Are you suggesting applications should store digitally signed screenshots ? Regards, Karsten Hilbert, MD GnuMed i18n coordinator -- 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
Archetype ontology
Hello all This is a useful discussion - I am much more with Karsten than Gerard on this - all the 'proofs' in the world amount to nothing in the digital world - as things can be altered at any point anyway. The GnuMed trust solution does get someway towards this. The technical solutions offered at the moment really do not match the reality and until we have working EHR systems and integration, these sorts of debate need to stay in the background. They do not really impinge greatly on the EHR requirements. But keep it up! Sam Heard -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Karsten Hilbert Sent: Sunday, 15 September 2002 6:57 PM To: Gerard Freriks Cc: David Guest; Openehr-Technical; Ton Smit Subject: Re: Archetype ontology 1) How do I know that the passphrase I typed in to be used for the secret key is used to sign what I see on screen and nothing else ? 2) How does the court know that a signed screenshot was actually shown on screen and not just fabricated and never shown ? (It is my responsibility to _inspect_ what is being shown but I cannot prove that signed screenshots were actually displayed (on current-day systems). This isn't about 100% proof, this is about level of trust, feasability, deniability and due process. Even with signing screenshots. Or did I miss something ? Since it is my responsiblity to carefully inspect the on-screen information I could just as well extend that view to that it is my responsibility to use a system that I can trust to show me what is actually in the database. Thusly I could just as well sign database content. Gerard himself remarked that we cannot sign that anyone actually reviewed any information, only that it was made available. The latter can be at the level of a screenshot - or at the level of database content. After all it is my responsibility to inform myself no matter where I get the information from. Say, I am using an SQL shell and sign screenshots of my queries. Does this mean I am not liable for the anaphylactic reaction just because I didn't do the query for the known penicillin allergy ?!? Obviously not, although I understand your position to be: It hasn't been shown to me hence I am not to blame. What other purpose might a signed screenshot server ? To shift blame to the EHR software manufacturer ? Lastly, one simple question. How does TNO propose to handle the audit trail of signed screenshots simply in terms of storage requirements ? Making a hash of a screen dump indicates: This is the information as I saw it on a screen and take responsibility for it by signing. Nah, I doubt you really believe in the coherency of this statement. A screendump merely shows what a screen _may_ have looked like. Karsten Hilbert -- 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
openEHR security
) and have become fascinated with the discussion over how best to balance the needs of the various parties involved in the provision and payment of healthcare services so as to improve the quality and decrease the cost of health care here in the U.S.. Talk about a non-trivial problem! Interestingly, it looks to me like all the nonsense can be traced back to the health record and some fundamental questions about who owns it, who controls access to it, etc. Thanks again for sharing. Hope to hear from you soon. I agree - it is fascinating. Can I point you to our (original work on this - quite philosophical) which I wrote with Len Doyal - a professor of medical ethics in London. http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/Deliverables.htm#D8 Keep up the good work! Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030426/8be5b494/attachment.html
GEHR philosophical background info
Paul I've been following these discussions with a lot of interest. So I guess it's time for me to put in my two bits. While I've seen a couple of references to ownership of the medical record, I havent seen anything definitive that defines it (e.g. patient, provider, legal custiodian of record, etc., or some combination). Some countries are giving legal ownership to the patient - and if it moves anywhere it will be there. The author has copyright. Ambiguous ownership has major advantages - and access can be legislated without solving the access problems. Cheers, Sam It seems like this question needs to be clearly agreed on before issues of access can be identified. (It also could be a partial solution to distinguishing between the terms EMR, EHR, EPR). HIPAA aside, it seems that there may be some different legal issues about ownership that would also have implications for access. Any thoughts? Bill Walton bill.walton at jstats.com 04/28/03 12:32PM Hi Sam, BW: This is a really interesting problem space to me. I've been studying HIPAA (the Health care Information Portability and Accountability Act) and have become fascinated with the discussion over how best to balance the needs of the various parties involved in the provision and payment of healthcare services so as to improve the quality and decrease the cost of health care here in the U.S.. Talk about a non-trivial problem! Interestingly, it looks to me like all the nonsense can be traced back to the health record and some fundamental questions about who owns it, who controls access to it, etc. Thanks again for sharing. Hope to hear from you soon. SH: I agree - it is fascinating. Can I point you to our (original work on this - quite philosophical) which I wrote with Len Doyal - a professor of medical ethics in London. http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/Deliverables.htm#D8 I hate to ask this, but is there one deliverable you could point me to that contains the philosophical stuff? I'm up to my eyeballs right now and I can see there's a whole bunch of good stuff at the Chime site on GEHR that I'll have to get to asap. Thanks, Bill -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030429/e997479c/attachment.html
Encoding concept-relationships in openehr archetypes.
Gerard I am using the term 'assumed' value in the archetype editor. This seems helpful as it means that it does not have to be recorded and it is normal practice. A single BP reading is assumed to be sitting - possibly lying - but not standing. Weight is assumed to be measured in light clothing and without shoes... For legacy systems this approach seems beneficial as there will be a lot of data missing! Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Gerard Freriks Sent: Monday, 4 August 2003 9:36 PM To: Thomas Beale; Jim Warren Cc: 'openehr-technical at openehr.org' Subject: Re: Encoding concept-relationships in openehr archetypes. Hi, Is it? Is it about how to represent the domain normal values? Or is it more general: Are concepts related? Then the problem is: what relations are there between concepts (archetypes)? What semantics of these relationships between archetypes (concepts) do we need to describe reallity (including decision support)? Gerard On 2003-08-04 5:38, Thomas Beale thomas at deepthought.com.au wrote: Admittedly, I'm slipping into the realm of decision support, but I think it really is simply the structure of the domain of normal values in this specific application. I'd like to use archetypes to represent this, just as a I might use them to represent the min and max of a given quantity. Is the capability all there already? If not, what's missing? -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - 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
Distributed Records - An approach
Christopher It has been good to read this thread - but I have to wade in here. In designing openEHR I have had a few principles in mind. 1. The technical solution should impose no constraints on social behaviour. This means to me that if we want one EHR for each person that is patient held or one repository for the entire country the system should work. 2. Linking records is non-existant at the moment and we can move incrementally towards an environment where we know where health information about an individual resides. Once you start to send EHR data from one site to another in openEHR then the links will build automatically. Remember, sometimes the patient will not want their information to flow! and while the technical view of security checks seems omnipotent, partitioning will always be safer. 3. openEHR offers a one to one transform for all information in EHRs. Our idea is that openEHR servers will retain the comprehensive information that comes from legacy or specific systems. Other systems will develop their read and write interfaces with openEHR and that will be all they need (at some future date) to operate and interoperate with EHR systems. Could be fantacy but it looks sweet - we are moving to a real-time trial of this approach in Australia. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Christopher Feahr Sent: Wednesday, 6 August 2003 12:59 AM To: lakewood at copper.net; openehr-technical at openehr.org Subject: Re: Distributed Records - An approach Thomas, This sounds workable to me. If I am understanding you correctly, we need one (and only one??) registry in which anyone, anywhere (who is authorized, of course) could look up a patient and determine which region had master control at the moment over his record. If I'm a provider living in the region where the records are primarily managed, then when my system attempted to look up, say, the date of his last Tetanus vaccination, it would find it immediately. If I was a provider visited while the patient was traveling outside his home region, then the same local query about his tetanus shot would tell me: hold on a minute, while we search all known registries to see where this guy's home-region is... where his most current records will be located. ... and then my region does a full record update from the current home region? or just try to display his tetanus vaccination history? One of the problems alluded to is that different regions might be using very different EHR structures. Thus a simple record refresh in region B from the information stored in Region A is not so simple. It would involve mappings at least, and possibly even data transformation. The inability to assume an overarching authority seems to be the Achilles heel. After a dozen record movements from one region to the next, many little mapping and transformation errors may have accumulated to thoroughly hose up the medical information in the patient's master record. One way around the central record managing authority would be to have VERY FEW regions... each with a well organized regional authority... who come together under a global organization and work out a very tight choreography for these refresh/hand-off operations. But this sounds harder and no more likely to be created as one single authority such as the UN imposing the requirements on all regions. I believe that the most critical point for global standardization and what we must aim for (first) is the information in the record. When the world has settled into that (something that will ALSO require a central authority, but just for standardizing what the information elements mean, not for choreographing complex record-merge operations), people will gradually come around to the idea of moving to the next level of system interoperability, with standard record structures. With only the information standardized globally, two large and cooperative regions (say, US and Australia) could still choose to create a US-Aus. information authority and orchestrate a high level of interoperability for patients and providers floating anywhere within our two countries. If the functional regions initially were more along the sizes of counties and states, then we'd have a lot more hassle and negotiating. So I would suggest the world start with the largest sized regions that could be reasonably managed with the same EHR structure. The critical issue for all regional participants would be a strong, competent regional authority... that operated in conformance to a set of well defined regional authority rules... maintained by the UN?? Christopher J. Feahr, O.D. Optiserv Consulting (Vision Industry) Office: (707) 579-4984 Cell: (707) 529-2268 http://Optiserv.com http://VisionDataStandard.org - Original Message - From: lakewood at copper.net To:
Ontology Standard for Archtypes
Matias I have developed an ontology of archetypes in Protege - it has been a large endeavour and I think is starting to get there. I am happy to send this to you to have a look at. I believe OWL and Protege are merging their approaches. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Matias Klein Sent: Thursday, 9 January 2003 8:15 AM To: openehr-technical at openehr.org Subject: Ontology Standard for Archtypes Hello All, I was just looking over W3C's Ontology Web Language (OWL), and was wondering if anyone had thoughts on the subject as it related to openEHR. Should openEHR archetypes be modeled using OWL or another standard syntax? If openEHR archtypes are compatible with a standardized ontology description language, then generic ontology viewing and manipulation tools could be used on them. Perhaps the alternative of converting openEHR archetypes into OWL representations with XSLT and then using generic tools is preferable? Any ideas? -Matias Matias Klein Ethidium Health Systems 1447 Rhoades Drive Huntingdon Valley, PA 19006-2623 USA http://www.ethidium.com - 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
Introducing myself + question
Rafal We have seen this coming for some time and I would point out a few things that seem clear: 1. That queries can be based across a number of EHRs or within one - the oprimisation issues are somewhat different 2. That queries may return rows of data (like in current RDBS) or lumps of data for viewing - 'data queries' or 'clinical queries' 3. Within each EHR the query may be limited to a specific composition (transaction) type (ie and archetyped transaction) 4. Within transactions the query may be limited to specific organisers All of these queries outlined to this point will return disparate data (even if they are all entries) and will be very difficult to process - very useful clinically. Examples are: What examinations have been done in antenatal attendances What therapies have been planned or implemented for people in outpatients in the last week Then we have queries that get to the data level - these will need to return known data points in the entries. These will be accessed via paths. When building these queries the enquirer will be asked which archetypes and which paths (design time or run time) to return. This would enable us to get a row of data such as: For all patients who have had their blood pressure measured in antenatal clinic - return the systolic and diastolic blood pressures and their weight. For all patients who are on beclomethasone inhalers return the name and dose of inhaled steroid and their peak flow measurements for the past year. You will see that until the query addresses and entry archetype (like a table in RDBS) you will only return information that is clinically readable but difficult to process. The entries then become the equivalent of the tables - the paths are the equivalent of the columns. Some efficiencies come from running queries on one patient - when the query engine can use the archetypes in that EHR as the set of archetypes on which to query - you don't have to look if they are not there. Also, archetypes become the bases of indexes. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale Sent: Sunday, 23 March 2003 11:24 PM To: Rafal Szczesniak Cc: openehr-technical at openehr.org Subject: Re: Introducing myself + question if you are thinking of specific querying language - I would agree - we can already see that the use of archetypes at runtime changes how queries are written and does require some new kind of language. We have been experimenting on this, and are working on it... - thomas beale Rafal Szczesniak wrote: On Sun, Mar 23, 2003 at 02:56:40PM +1000, Thomas Beale wrote: Another issue which I think is more important than language is runtime interfaces. Components written in many languages can be interfaced by COM, and presumbly, .Net infrastructure; most languages can produce DLLs for Windows and .so or other kinds of libraries for the unixes. The ability to interface trusted components is key to building large systems without having to do everything yourself. Another interesting thing is that developing openEHR systems might reveal the need of specific language to operate on. Similiar to what SQL is for relational databases today. This could be also a mean to standarise communication between EHR systems. cheers, -- .. Deep Thought Informatics Pty Ltd mailto:thomas at deepthought.com.au openEHR - http://www.openEHR.org Archetypes - http://www.deepthought.com.au/it/archetypes.html Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html .. - 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
Data Types RM
Grahame
It is like being reviewed by a tornado - even my teeth feel clean!
These comments relate to v1.7.1
Section 4.2 DV_BOOLEAN. are the values {true, false}
case sensitive? Generally, is openehr case sensitive
or not?
no they're not. I'm not sure what it means to say is openEHR
case-sensitive or not - wherever Strings occur, it is, since String
processing in computing is always case-sensitive by default. Only in
specific places (e.g. the Windows NTFS file system) has it been removed.
hmm. I will come back to this later.
This is quite usual I guess.
5.1.5.2 This section introduces the match attribute, which has one
of the following values:
-1 code provided is more specific than it should be
0 code matches intent
+1 code provided is not as specific as the intent
The use of values like this seems poorly modelled - surely this
is a variation of the datum interpretation concept from the design
principles?
not sure why you say this - the only meaning for this attribute is to
indicate match. There is no other data in the attribute. But you might
argue that it should be an enumerated type rather than an
Integer. We went
for an integer for the following reasons:
- it is quite common in the C languages for -1/0/+1 to be the
results of a
comparison, e.g. with the string routines.
- to allow for the possibility in the future that sensible
meanings could
indeed be attached to higher /lower values.
yes, and we could use 0 to indicate null too, which is common practice in
the c langauges.
I do argue that this should be an enumerated type. If it get's
extended to
higher
and lower values, then begin a terminology makes the problems
with changing it
explicit
I tend to agree with your reasoning - really equivalence is 1 from a
mathematical point of view. These values will only be included if they are
already in mapping tables and would only be used for automatic processing -
and could be determined independent of the EHR and perhaps should be - but
it might be useful when you translate - for example - so Ross River
(Australian disease) might come out as an Arbo Virus Infection in Italy -
they will not know Ross River anyway and will see that the statement was
more specific - they will know it is a type of arboviral infection that is
not in their set.
5.2.1 TERM_MAPPING.purpose - no terminology? how could this have any
practical
meaning with a controlled usage?
I think it probably should be coded as well (I presume you meant here
without controlled usage). But there are no terminologies for this at
the moment, although it would not be hard to invent one.
oh yes - I did mean without. This is one of those horrible little corners
for which
one must invent a terminology
This was an area we wanted to cover but not control at the moment. It will
only have textural meanings at present but it could be helpful in some
jurisdictions - they can code it!
5.4.1 TEXT_FORMAT_PROPERTY. It seems strange to me that this
makes use of
CSS, rather than introducing semantic based markup. HTML is a mess, but
semantic based markup is a good thing, where as CSS is the opposite
the whole point is here not to introduce any semantic markup. We
only want
simple formatting. If you want to include whole tracts of semantic text,
use DV_PARSABLE or DV_ENCAPSULATED...
oh - parsable? interesting. I read that and ignored it since it
said so little
about what it was. why is it constrained to plain text?
back to the point. Why don't you want semantic markup?
6.4 reference Range type - this seems a little simple to handle the
gloriously
complicated reference ranges much beloved by endocrinologists.
What is the
intent in these cases?
to record only the reference range for a given datum, for a
given patient,
for the given test etc - not to record whole reference range tables. In
most pathology this appears to suffice. But I'll say again - it's not to
include all the reference range tables or data - only to record the
particular values for the particular measurement and patient ...
but the reason endocrinologists have such wonderful reference ranges is
that the particular values may not be
known (or even knowable). LH and FSH are classic examples -
here's a set of
reference ranges for different
stages of the cycle. The test as probably ordered to give some indication
of where the cycle is - so instead
of interpreting the test result in terms of the reference range for the
patient's situation, we are interpreting
the patient's situation in terms of the result compared to it's reference
ranges.
That is why we can have more than one - and then one can be marked as the
relevant one.
I will leave the rest to you - hope you get some sleep - Sam
But more generally, pathology test providers do not have enough
information
to assign
a patient to one of a set of reference ranges, where they have them
That is true - but it can be after the fact if that is
Links
Dear Remko The link class can only be associated with either instance and we have some work to do on how to go about this. The first thing that I would say is that we may want to create a 'report' transaction archetype that has a context attribute In resonse to and then a URL to the transaction that contains the order. This would mean that we have a firm idea of the link between a report and the order (even if it was made at another site). To work in a distributed environment it would mean that any order should give the URL of the instruction in the order (even if it is an HL7 message or other artefact) If the order is an openEHR extract it carries the URL with it. To work efficiently we will need the threads to be easy to follow - this will mean that the local EHR server will have to know which links point to which transactions from other transactions - this is an indexing problem and an example of what the server can do to make this work locally. You will not know links from outside that point in - but that is OK. Another issue that will make this far easier is smart transactions (in house) - that is to say - how we store transactions in the local DB with only smart updates - so only deletions, edits and additions are stored. If we solve this at a kernel level then updating states and links will be trivial in terms of local DB work. I hope this helps - you can see why we are not worried about commercial advantage for local application vendors as there are many implementation issues for us to consider as yet. Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Remko Nienhuis Sent: Monday, 12 May 2003 4:38 PM To: openehr-technical at openehr.org Subject: Introduction and question Dear list members, My name is Remko Nienhuis and I am currently working for a small Dutch company named 2Cure, which is an international medical software supplier. At this moment, my major goal in life is understanding the OpenEHR design paradigm and reference models and the way it can or will influence futureous developments on our products. I started studying OpenEHR just a couple of weeks ago, so despite the great documentation, there is still a lot to learn. One of the things I do not fully understand is how a softwaresystem should be able to relate an instruction(entry) with the futureous result of this instruction, which will in many cases be a new transaction, for instance a Radiology visit. This kind of relation, which can also be nested and then will create a kind of ehr-thread on its own, will occure rather often. Because the initiating instruction and the resulting transaction will not share the same Clinical_Context and are not the result of the same Contribution, their relation can not be derived that way. Ofcourse it is possible to put both transactions underneath the same Folder, but that won't create a relation between the instruction and a transaction. As I understand the Link class can be used to create such relationships, but in the above scenario the Link can only be created afterwards (after the second Transaction has been created). How to constrain such a relationship? I think I'm missing a major point here. Please help me out. Best regards, Remko Nienhuis. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030513/0bc41142/attachment.html
Genetic information and RM (data types and structures)
Korag This may well be the way to go soon - but I would think that an external datatype would be better for the moment as the representation will probably not be uniform (and openEHR should not impose uniformity in such a domain). Also, we would see the genome as only forming part of the genetic record - as there will need to be a lot of other information present to make healthcare work. What do you think? Cheers, Sam Heard Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Koray Atalag Sent: Thursday, 15 May 2003 11:10 PM To: openehr-technical at openehr.org Subject: Genetic information and RM (data types and structures) Hi, I had problems wth my membership with the list for a while so I could not catch up with recent stuff but during this time I had some time to examine openEHR documents posted on the website. As a person who had previously been involved with bioinformatics and especially human genomic databases, some part in my mind still reminds me of the fact that one day all these information shall be integrated. Also personally, I believe the approach taken in openEHR shall form the baseline for future of EHR systems. So I would like this issue to be considered during these discussions. Enough of good wishes, here is my question: Is there a specific way to represent genomic data of a patient (Either Nucleic Acid sequences or protein sequences) in the Reference Models or is the general purpose text data type is thought to be the solution? I think it could be wise to create a new class with its own attributes, methods and constraints right into the RM because with this speed of biologic evolution I don't think the genetic code and concepts are going to change for a couple million years! Best regards, Koray Atalag - 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
Archetypes and Terminology
Dear All This area is difficult and we must learn as we go. There are a few conclusions I have come to from an EHR system point of view.. 1. The data structures and term sets that are required for clinical care and communication must be able to be instituted both prior to and after the standardisation processes have been published. 2. Special requirements that are not contrary to agreed standards should be able to be implemented without difficulty - this is the norm rather than the exception. 3. Where terminologies required in archetypes are small and generally agreed, these should be primarily expressed in the archetype itself - not to do so is to add to the unrealistic demands on external terminologies. 4. Translations will be safest inside archetypes where the meaning is clear - the context is highly specified. This is a reason to extend the role of internal terminologies of archetypes. So, the new statements I would make are: 1. Archetypes should have no language or terminology primacy - and these should be able to be added post-hoc. 2. Terminologies internal to the archetype will always be safer to translate and provide synonyms and specialisations. Despite the feeling of some in the business, this does not really diminish the need for external terminologies. I am also aware that the comprehensive approach of Philippe and the Odyssey Project and the text processing of Peter Elkin. I believe these efforts will remain as relevant, but more focussed within an archetype driven information model. Cheers, Sam Heard Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-9-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale Sent: Thursday, 2 October 2003 8:46 PM To: openehr-technical at openehr.org Subject: Archetypes and Terminology (was Re: Antw: Re: Open Source EHR at the Americal Academy of Family Physicians ...) Philippe AMELINE wrote: Hi to all, We are currently experiencing such things ; it is not easy to have people understand the difference between description (As accurate as possible), local study (question 5 can be answered 5.1, 5.2...) and studies using classifications such as ICD or ICPC where you just can use concepts inside the classification (and it is sometimes complicated since, for example, send to the hospital as no entry inside ICPC). I don't think you can expect adressing all these issues through Archetypes I would not either...we just need some good oontologies... Yes, a validated scale on a particular issue around human functioning could be part of an ontology, but perhaps not always. The Barthel index or the APGAR score e.g. have distinct and different variables that probably would not stand beside each other in an ontology. Or, it would be an ontology with many to many parent - child relationships. The way we solve this kind of problem is that we incorporated inside the ontology concepts as ICD10 code, ICPC code and so on. These ontology concepts are given the code as a value in the same way patient size (cm) would be given 180 as a value. the ADL supports this more or less as well... - 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
Pathology requirements TIMED MEASUREMENTS
TIMED MEASUREMENTS The timed nature of specimens is dealt with in the history and event model of the RM and available in the archetype editor. This deals with timed measurements and interval measurements. The idea of a 21 day progesterone is covered in state information relating to the time since the last menstrual period - BUT there is still the idea of an untimed sequence of events where the order is critical. There are also sequenced events when it comes to looking for stool microscopy, occult blood - but these are reported separately and really are administrative rather than of the nature I will describe here. The best examples of this seem to occur in sampling - three samples of CSF - the first, second and third - or shavings for histology looking for depth of tumour. There are more, such as respiratory function tests with particular challenges - and timing is not an issue. These occur one after the other but the sequence is the only thing that is important - not the time - and time would probably be made up. The question is, how do we deal with this. I think we have two choices: 1. We recognise this is a sampling issue and there should be a label on each sample which is transfered to the report - we have sample 1, 2 and 3 with three separate microscopies and cultures in a single composition. This would get around the confusion of trying to deal with this as a timing issue - it would work for any sampling including location. We do not want to compare these CSF samples in queries as equals but we would have some sort of label associated. So, the sample label and order might be part of this - in the request and then in the result. I guess this goes on at the moment. 2. We have a sequence idea in the event model, by using the offset but having 'sequence' as the unit rather than time. This would mean that people did not have to enter spurious times in the data and name the event as Sample 1, which could be misleading. Comments? Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-9-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TEXTURAL RESULTS TO QUANTITIES
TEXTURAL RESULTS TO QUANTITIES The result of this analysis is that sometimes a single leaf in a tree will be reported as haemolysed rather than its numeric value - example: the results of an electrolyte measurement might have safe results for all analytes apart from potassium - the result will be 'haemolysed'. This can occur in haematology and other situations - reporting is required for medicolegal and billing purposes. This presents a problem. We have a number of possibilities at our fingertips - perhaps the most important being the ability to mark something as unsafe for automatic processing. At the moment, I believe, this is limited to the ENTRY. If we take the CDA line of structured data and display - this would mean the display said haemolysed, the data would say 9.5 mmol/L but it would be marked as unsafe for automatic processing. The query would have to check the automatic processing flag - but this will be necessary anyway - but it will lead to a differential between the view provided in the display and the query. My belief is that results that are incorrect should not be there if at all possible - so I would like to see a means of being able to put the potassium in as haemolysed. This would mean a generic node with an ID that could have a textural term data type in biochemistry - and still have the text and even the LOINC code attached - but have a different nodeID so it would not be returned in the query - unless you were just searching on LOINC codes independent of the archetype. This will look a little clunky in the archetype itself and I will need to discuss the technical issues with Thomas. Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-9-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TIMED MEASUREMENTS
Bhupinder The protocol describes the methods of measurement - each measure can only have one protocol - so this means that the measurement would be entered twice - quite appropriate because it is unlikely that a different method will lead to exactly the same result. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bhupinder Singh Sent: Thursday, 23 October 2003 1:12 PM To: Sam Heard; Openehr-Technical Subject: Re: Pathology requirements TIMED MEASUREMENTS Further to what you have stated there will also be events such as sample is single time is same and the test is same but method of reporting and or conducting test is different. Blood Sugar is one example sample is taken and tested on the bedside and sent to a lab also. These events and results need to be accommodated. Bhupinder - Original Message - From: Sam Heard sam.heard at bigpond.com To: Openehr-Technical openehr-technical at openehr.org Sent: Wednesday, October 22, 2003 4:02 PM Subject: Pathology requirements TIMED MEASUREMENTS TIMED MEASUREMENTS The timed nature of specimens is dealt with in the history and event model of the RM and available in the archetype editor. This deals with timed measurements and interval measurements. The idea of a 21 day progesterone is covered in state information relating to the time since the last menstrual period - BUT there is still the idea of an untimed sequence of events where the order is critical. There are also sequenced events when it comes to looking for stool microscopy, occult blood - but these are reported separately and really are administrative rather than of the nature I will describe here. The best examples of this seem to occur in sampling - three samples of CSF - the first, second and third - or shavings for histology looking for depth of tumour. There are more, such as respiratory function tests with particular challenges - and timing is not an issue. These occur one after the other but the sequence is the only thing that is important - not the time - and time would probably be made up. The question is, how do we deal with this. I think we have two choices: 1. We recognise this is a sampling issue and there should be a label on each sample which is transfered to the report - we have sample 1, 2 and 3 with three separate microscopies and cultures in a single composition. This would get around the confusion of trying to deal with this as a timing issue - it would work for any sampling including location. We do not want to compare these CSF samples in queries as equals but we would have some sort of label associated. So, the sample label and order might be part of this - in the request and then in the result. I guess this goes on at the moment. 2. We have a sequence idea in the event model, by using the offset but having 'sequence' as the unit rather than time. This would mean that people did not have to enter spurious times in the data and name the event as Sample 1, which could be misleading. Comments? Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-9-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ - 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
FW: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES
-Original Message- From: Sam Heard [mailto:sam.he...@bigpond.com] Sent: Friday, 24 October 2003 11:00 AM To: Tim Churches Subject: RE: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES Tim As we seek to achieve automatic processing of some of the data in the EHR there will be clear efficiencies in changing some conventions. For instance, RBC/HPF = 0 is very easy to understand. They are not usually 'seen' anyway any more so why pretend. What I was getting at is when a numeric response is there - but wrong - and a textural entry replaces the quantity - as in 'haemolysed'. I am proposing that the archetype node to do this is not the same as the quantity - so it would replace it. It would then not come back in queries looking for K+ levels. Tom and I have thought about ranges as fuzzy quantities e.g. 100 or 0.5 - these are possible in all analytes in practice but rarely met. Thanks, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Tim Churches Sent: Thursday, 23 October 2003 4:55 PM To: Tim Churches Cc: Sam Heard; Openehr-Technical Subject: Re: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES Tim Churches tchur at optushome.com.au wrote: Sam Heard sam.heard at bigpond.com wrote: TEXTURAL RESULTS TO QUANTITIES ?TEXTUAL? This raises the general issue of how mixed categorical/ordinal/scalar quantities are handled eg (made up example) haematuria: Trace-x RBC/ml - Gross haematuria. Sorry, brain-fade. I meant x RBC/HPF (per high power field) or similar. This is an example of a sampled result i.e. a random sample of portions of a specimen are examined and a mean is reported. The mean is quantitative, but is just a point estimate of the central tendency of an underlying probability density function. Thus it may have a std dev or confidence intervals associated with it. Also, in this circumstance zero doesn't really mean zero and is generally not reported as such: if no RBC were seen in any HPF, then it will be reported as No RBC seen, not as mean RBC/HPF = 0. Generalising this, scalars which parameterise a probability distribution are different from scalars which are precise quantities - or are they? Hmmm. Tim C Conceivably some use might be made of the numbers, as opposed to the ordinal categorical extrema? Tim C - 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements UNITS
Bhupinder
This is an interesting idea...but it raises issues as you have to have
normal ranges for each of these. I do not see why the results could not be
duplicated in multiple units is required - at present we do not have the
ability to add multiple values to a single element apart from as reference
ranges.
What do others think? I think Labs will probably push back on this one.
Sam
-Original Message-
From: owner-openehr-technical at openehr.org
[mailto:owner-openehr-technical at openehr.org]On Behalf Of Bhupinder Singh
Sent: Thursday, 23 October 2003 1:30 PM
To: Sam Heard; Openehr-Technical
Subject: Re: Pathology requirements UNITS
Can we not work on a UNITS module where a test can be attached to a number
of units where the conversion is not available. A clinician does
not want to
have to relearn the unit for the convenience of the application.
Bhupinder
- Original Message -
From: Sam Heard sam.heard at bigpond.com
To: Openehr-Technical openehr-technical at openehr.org
Sent: Wednesday, October 22, 2003 4:02 PM
Subject: Pathology requirements UNITS
UNITS
There are a lot of units out there - it has been our idea to build a
constraint model on units based on the property being measured. A good
example is frequency can be '/{time unit}' (e.g. /min, /hr, /s) or 'Hz'.
It
is hoped that we can translate from one to the other as much as possible
on
this basis.
It has come to my attention just how many units are out there and that
some
units are not translatable to another unit even when the property is the
same without further information. The best known example is gm percent -
which is the same as gm/100ml or gm/dl. This is a concentration
but it is
not possible to know the amount of substance (moles) without knowing the
molecular weight of the substance. This means we will have to have units
available in a property that are not translatable. We could
separate these
to MASS CONCENTRATION and CONCENTRATION as some have done - but I think
clinicians will want to choose from as small as list as possible.
We need some work done in this area and there are a number of documents
available to get this as tidy as we can.
Cheers, Sam
Dr Sam Heard
Ocean Informatics, openEHR
Co-Chair, EHR-SIG, HL7
Chair EHR IT-14-9-2, Standards Australia
Hon. Senior Research Fellow, UCL, London
105 Rapid Creek Rd
Rapid Creek NT 0810
Ph: +61 417 838 808
sam.heard at bigpond.com
www.openEHR.org
www.HL7.org
__
-
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
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
Pathology requirements CONTRIBUTION - 2 versions at once
Bhipinder Thank you. I think we have all of these issues covered. Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bhupinder Singh Sent: Thursday, 23 October 2003 1:23 PM To: Sam Heard; Openehr-Technical Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once You have factored the details relating to reporting. A major issue is the transmission and reading of the result by the clinician. Ther is to be time event to be recorded as to when the clinician who has direct control of the patient has read it. A legal issue that will come up at times is that the report shall be claimed to have been sent and the consultant clinician shall claim not to have received it and thus not having read it. A timed event for both these activities need to be available. Further there is a need for alerting the clinicians once the report is ready. There is a need to have the ability to generate an Interim report and then a final report. It is the interim report that shall have to be avilable to few and the detailed subsequently. Both these have to be a part of the EPR to substantiate the clinican actions in case of a abnormal event when the action of the clinician results in a abnormal event in the patients recovery. Even when the sample is haemolysed a track of the sample needs to be kept in the EPR of the patient. Bhupinder - Original Message - From: Sam Heard sam.heard at bigpond.com To: Openehr-Technical openehr-technical at openehr.org Sent: Wednesday, October 22, 2003 4:02 PM Subject: Pathology requirements CONTRIBUTION - 2 versions at once CONTRIBUTION - 2 versions at once There is a particular problem with results that are deemed to be incorrect as the specimen is damaged - haemolysed blood samples being the most common (See textural results to quantities thread). If the machine read data is to be preserved in openEHR then this would need to be over written with the correct result and both compositions saved at the same time - otherwise some other agent might base some process on the interim situation where the first composition is saved even for a microsecond. We think this relates to machine processed data - but keeping medical student entries might be dealt with in some environments in the same manner. ACCESS CONTROL to interim reports There will be times when the access to an interim report needs to be controlled - such as an abnormal result from a lab that has not been signed off by the final arbitor...but it may need to be available to a particular team. Our access control models need to deal with this. Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-9-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ - 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TIMED MEASUREMENTS
Thomas I am not sure that we need to do such a major rework. These samples are time ordered but have no sensible time. So they could appear in the history list without an offset, labelled in what ever way was helpful, recognising they are part of the same measurement. On thinking about this (if you wanted to keep all the measurements) a simple office based measurement like peak flow is a candidate - you might do three measurements in a row. At the moment the history demands an offset - the set of measurements would still be timed - but only the sequence of each would be known, not the time of each individual. This seems more appropriate. The query could return them all at the same time or, as I have suggested, with a nominal offset 1,2,3 etc This would allow for the fuzziness of a series to be captured. Another alternative is just to allow the application to put in what ever time it likes as the offset, and label them Sample 1, Sample 2. This would require no changes, and would not upset the query model. I probably favour this approach as there is no doubt there is a time element to sampling, otherwise it is not a sequence. Cheers, Sam -Original Message- From: Thomas Beale [mailto:thomas at deepthought.com.au] Sent: Friday, 24 October 2003 5:58 PM To: Sam Heard; Openehr-Technical Subject: Re: Pathology requirements TIMED MEASUREMENTS 1. We recognise this is a sampling issue and there should be a label on each sample which is transfered to the report - we have sample 1, 2 and 3 with three separate microscopies and cultures in a single composition. This would get around the confusion of trying to deal with this as a timing issue - it would work for any sampling including location. We do not want to compare these CSF samples in queries as equals but we would have some sort of label associated. So, the sample label and order might be part of this - in the request and then in the result. I guess this goes on at the moment. 2. We have a sequence idea in the event model, by using the offset but having 'sequence' as the unit rather than time. This would mean that people did not have to enter spurious times in the data and name the event as Sample 1, which could be misleading. I guess there are a few possibiities. a) we change HISTORY to SEQUENCE and make it general enough to cope with other sequences, not just time b) we add a type SEQUENCE and make the current HISTORY a subtype of it. The only reason to do this, rather than to have two disjoint types would be to enable software re-use (less code; better code) and to allow runtime substitutability. I am not sure what query could sensibly request all sequences, including histories, so I am not sure if this is an argument c) we add a type SEQUENCE as another subtype of STRUCTURE. Without having done the analysis, I would favour b), since there appears to be a fair overlap of semantics and therefore argument for reuse. What we need is a nice statement of a new model for history, which includes means, maxima, minima etc as Sam has been modelling, and a similar model for sequence. Then we can see what to do about changing the Data Structures Information Model - thomas - thomas c) - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TEXTURAL RESULTS TO QUANTITIES
Thomas My approach to this, which is expressed in the editor, is to standardise only on the base and maximum values of the ordinal. The terms that are used are not an issue and standardisation is really way beyond scope when people use all sorts of terms for this purpose. Apgar is a classic - 0,1,2 is quite clear - how these points are described varies enormously - but that is OK. Nurses may want something different than doctors - for example. It is the tightly defined context that is important and the fact that it is ordered. This does allow comparisons and normal values to be determined. So, Urinalysis - NORMAL can be something that an archetype can express. Blood = 0, Protein = 0 ... You are always worried about the non-standardisation but we do not need it in this world to make interoperability a reality - ordinal values are, on the whole, too gross for a great deal of concern. Reflex of +/- can be normal if the person is healthy and the finding is consistent. Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale Sent: Friday, 24 October 2003 6:22 PM To: Openehr-Technical Subject: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES Tim Churches wrote: Sam Heard sam.heard at bigpond.com wrote: TEXTURAL RESULTS TO QUANTITIES ?TEXTUAL? This raises the general issue of how mixed categorical/ordinal/scalar quantities are handled eg (made up example) haematuria: Trace-x RBC/ml - Gross haematuria. Conceivably some use might be made of the numbers, as opposed to the ordinal categorical extrema? The current DV_ORDINAL data type consists of an integer value representing the ordinal position in a range of values, and a symbol, which is the symbol given to that position. Ordinals are treated as being comparable ( operator is defined) but not quantified (the magnitude is unknown). We currently think that the correct way to express the symbol is as a term in a vocabulary (maybe subsetted). This means that each set of symbols comes from its own micro-vocabulary, and even if the same symbols (like trace, +, ++) are used for unrelated things, they cannot get mixed up in comparisons. Examles: pain: Value Symbol 1+ 2++ 3+++ reflex Value Symbol 1+ 2++ 3+++ haemolysed blood in urinalysis 1 ?neg? 2 ?trace? 3 ?small? 4 ?moderate? 5 ?large? OR - haemolysed blood in urinalysis (unit=cells/ml) 1 ?neg? 2 ?trace (10) 3 ?small (25) 4 ?moderate (80) 5 ?large (200) I am not sure if we need more sophistication to deal with this. The main problem I see is the lack of vocabularies, and/or non-standardisation of them. I guess LOINC has the kinds of values we want, but how to specify the correct subsets? - 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
Pathology requirements UNITS
Thomas
It is more that units match Force/Length^2 for pressure and it is an
expression that the property of pressure is the property of Force per
property of area - this does allow a very wide range of units to be used
if that is the requirement.
I am starting to see that things do get complicated out there in Unitsville.
Cheers, Sam
Can we not work on a UNITS module where a test can be attached
to a number
of units where the conversion is not available. A clinician
does not want to
have to relearn the unit for the convenience of the application.
I wonder if units should be considered part of a localsation profile?
Currently you can specify units in an archetype in two ways:
a) as the actual units you want to allow, e.g. units matches
{mm[Hg]}, units
matches {km, mi}
b) property matches {pressure}, property matches {length}
A nice alternative that Sam has thought of is:
c) property matches {FORCE/LENGTH^2} -- same as pressure
property matches {LENGTH/TIME}
We are currentl working on including this in ADL.
- thomas
-
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
Pathology requirements TIMED MEASUREMENTS
Bhupinder The only values we are not wanting to show are those that are wrong - and have been changed in a later version. The idea behind this is to store the information in an openEHR system inside the Pathology service and then send an extract - rather than develop a lot of messages. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bhupinder Singh Sent: Sunday, 26 October 2003 11:50 PM To: Thomas Beale; Openehr-Technical Subject: Re: Pathology requirements TIMED MEASUREMENTS What you say is one possibility. What is important is when there are two results out of the scenario and the readings are different. Would it be correct to take a mean. The difference in the reading may be on account of a number of causes starting from --Machine error --Human Error etc. The question is that there is a difference and this needs to be gone into in fact this requires to be highlighted and not covered through a mean value generated. Graphical representation should show both values and leave it to the clinician to decide what action he prefers to take. Textual display should show both values too. Bhupinder - Original Message - From: Thomas Beale thomas at deepthought.com.au To: Openehr-Technical openehr-technical at openehr.org Sent: Friday, October 24, 2003 4:29 AM Subject: Re: Pathology requirements TIMED MEASUREMENTS Bhupinder Singh bobdog at sancharnet.in wrote: Dear Sam, What you say is correct. In clinical practice it is also possible that the same sample is sent to two labs for the same test and the protocol followed by both the labs is same so is the est method and the unit of reporting. The sample date and time is the same. These two results have to be viewed and stored. Thus there should be a method to store and retrieve values where the date and time of sample and the test type and method and the UOM is the same needs to be available. Eg Blood Sugar reporting unit and test method are the same so is the date and time of the sample. Bhupinder this is an inteersting scenario actually, since even if there are two perfectly legitimate test results (let's say submitted to the EHR a day after each other) they don't really represent distinct results - they are the same result (presumably) submitted at same or different times. Wen doing statistical or other queries we have to be careful - if we draw the values on a graph for example of bsl over last five days, there might be two values at the one timepoint (where the timepoints are the times of taking samples, not doing the test - i.e. the biologically significant point in time). One way to look at thist situation is to say that all test results where there is just a single result are just a special case of a statistical testing situation in which at any point in body time, a sample might be tested any number of times (and more than one sample might be made as well) - giving a constellation of results. Where there are multiple results for the one biological timepoint, we could consider it as a statistical strengthening of the confidence in the result. Probably what applications processing the results should do is consider N results at the same biological timepoint to be the same as one, whoe value is the mean of the N, and whose confidence is some higher value than that attributed to single value samples. - 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements CONTRIBUTION - 2 versions at once
Vince The notion of superceded applies to compositions and is inherent in the versioning approach. Exclude from automatic processing is for entries. Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Vincent McCauley Sent: Monday, 27 October 2003 7:44 PM To: Openehr-Technical Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once I think there is a need for both superceded and exclude from automatic processing. Wherever the haemolysed marker ends up in the archetype/EHR it won't be the only such beast. Some other examples are clotted and clumped for full blood counts, incorrectly collected (specimen in wrong type of tube etc e.g not a fluoride tube for a blood glucose), warmed (where specimen has to be keep cold for correct results), cooled where specimen has to be kept at body temp. (cold agglutinins etc) and so on ... Regards Vince - Original Message - From: Thomas Beale thomas at deepthought.com.au To: Openehr-Technical openehr-technical at openehr.org Sent: Monday, October 27, 2003 18:54 Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once Vincent McCauley vincem at mccauleysoftware.com, Hi Thomas, The issue here is that Pathology labs will produce a numeric result for say Potassium but when it is high willl look at the specimen, decide it is haemolysed and actually report Haemolysed as the result. The Lab will store two results, the numeric value e.g. 7.0 and the reported result Specimen haemolysed. The value 7.0 should never be returned as the result to a query show me all potassium results but has to be recorded in the Labs EHR for the patient. How should this be modelled? If there is a lifecycle or other marker on Entries then the marker can be set to an appropriate value, either superseded as I suggested before, or perhaps something like exclude from automatic processing as Sam has suggested. Whatever the marker, this result will still be visible to queries that ignore this marker (i.e. queries that get results for display on the screen), and the result will still be available as a part of the record until such time as someone decides to do a repeat test to replace it, in which case it remains a previous version of a new correct result. Probably in the archetypes for blood tests there should be place to put the haemolysed classifier next to the value. Not sure exactly where this should go at the moment... - thomas Regards Vince Dr Vincent McCauley CEO McCauley Software Pty Ltd - Original Message - From: Christopher Feahr chris at optiserv.com To: Thomas Beale thomas at deepthought.com.au; Openehr-Technical openehr-technical at openehr.org Sent: Monday, October 27, 2003 01:26 Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once Hi Thomas, I'm not sure I like the notion of superceded. Is the first test an error? If so, the first result should simply be marked wrong and voided or removed. If the first result just looked a little goofy to the clinician, but there was nothing to indicate with certainty that it was erroneous... and the second result comes back with more reasonable- looking values... perhaps both results should be left in the record. The time-stamps will suggest to the clinician that the later one probably supercedes the earlier, goofy-looking result. (Did I understand your scenario correctly?) Regards, -Chris At 07:26 PM 10/24/2003 +1000, Thomas Beale wrote: Sam Heard sam.heard at bigpond.com, wrote: CONTRIBUTION - 2 versions at once There is a particular problem with results that are deemed to be incorrect as the specimen is damaged - haemolysed blood samples being the most common (See textural results to quantities thread). If the machine read data is to be preserved in openEHR then this would need to be over written with the correct result and both compositions saved at the same time - otherwise some other agent might base some process on the interim situation where the first composition is saved even for a microsecond. We think this relates to machine processed data - but keeping medical student entries might be dealt with in some environments in the same manner. I don't see the problem here. This is the classic version control situation which the model deals with. The preliminary result comes into the EHR and is recorded as an ENTRY in some COMPOSITION. This is the result that is available for say a couple of days. Presumably it should be marked PRELIMINARY! in red...one might argue that there is a need for an attribute to support this (in old
Modelling Episodes in openEHR
Bill and all This is a very important consideration and one that we need to get right for lots of reasons. Tom has been proposing an aggregation approach - allowing us to find all data that relates to something - a disease, care at an institution etc. It is clear that there are aspects of the episode that are specific to the care setting and administrative and billing requirements. We could have a composition that held information about the administrative aspects of the episodefor billing purposes or secondary data collection. It would be possible to archetype an 'episode' folder to contain one of these - and possible to define what is held within it should that be appropriate. It is clear that a simple aggregation model is not enough, but we also do not want to have lots of folders to describe one episode from different perspectives. The Mayo can only have one episode per patient at any timethis ensures that the person who opens an episode is responsible for closing it - and summarising it, tying up lose ends etc. This is a very important quality issue in distributed care environments. But in the Australian setting where we have primary and secondary care separated - the notion of secondary care episode is largely a billing or funding issue - although we have discharge referrals back to primary care. In primary care, the idea of an episode - a single one at a time - is appealing to me - meaning it is non-routine care for the problems the person has. It stops what Michael Balint called the collusion of anonymity - a destructive outcome of 'shared' or 'parallel' care. Cheers, Sam Hi Thomas, Thomas Beale wrote: Someone could come along later in the same institution, and define a new kind of episode, and retrospectively create all the Folders for that kind of episode in certain EHRs. This also won't change any of the underlying data. Episode Folders could also be removed, renamed, their references added to or removed - none of this changes any of the data either. Do you envision this being done manually? Or is there a programmatic solution? The question this thread has raised in my mind is well illustrated by your comment below. I think any institution has to have a firm model for what it thinks an episode is Assuming that different institutions will adopt models that differ, what are the implications for the exchange of data and the creation of a lifelong EHR? Thanks, Bill - 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
History paths
Rong This is an important consideration - especially if we are to get the event right. We have recently been moving away from offset to a datetime stamp for the items in the history - as this is easier and more realistic for summary data over a long period. With this change - you want to find and label the 1 minute, 5 minute and 10 minute Apgars - as the absolute time has no meaning. The Editor allows you to constrain the run time name of the event. Cheers, Sam Rong Chen wrote: Hi Thomas! A question regarding implementation of History paths in reference model: from data_structures rev1.4, p26, one of the examples is event: | HISTORY.name | EVENT.name, e.g. |history|event_3. But class EVENT has no attribute called name, it doesn't inherit LOCATABLE either. Does this imply that perhaps EVENT (or its super class EVENT_ITEM) should inherit LOCATABLE? Thanks! Rong - 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
Issues with Latest Spec
Hi Matias Tom is on leave so it is a bit late coming... I discovered the following issues in the latest spec. I would appreciate your perspectives on them. 1. DV_PARAGRAPH does seem to make any sense as a data type. This is more of a rendering issue. A paragraph can contain multiple observations, but the spec indicates that only DV_TEXT can be in the paragraph. In my opinion, a paragraph is a higher level construct than ENTRY and seems more synonymous with a SECTION. On page 24 of the RIM model it shows an example of DV_PARAGRAPH. However it only shows DV_TEXT items possible in the prose. What if you want to put other data types in the narrative prose? This area is an issue - DV_PARAGRAPH was added to allow formating and mixing of coded and non-coded text. It was not for the sort of purpose you have shown - which is mixing text and non-text data. It is not meant to be like a section - just giving a richer text. DV_TEXTblah, blah, blah/DV_TEXTDV_DATEJuly 16, 1999/DV_DATEDV_TEXTblah, blah, blah/DV_TEXT We believe that a date amongst the text is not processable anyway - but it is felt that some complex text may be possessable - or might be the result of a natural language processor. We have not used this class in any applications as yet and you may be right. I feel that if you go so far as to make DV_PARAGRAPH a data type, you should also create DV_SENTENCE, DV_BLOCK_QUOTE, DV_HEADER, DV_FOOTER, etc. (which also doesn't make sense IMHO). This is just the tip of an iceberg that I have spoken of before. openEHR needs a standardized spec for rendering visual representations of archetypes (i.e. an agreed upon style sheet language w/ a mandatory mapping to the RIM). I think this is a reasonable statement and we need to decide how openEHR will address the structure text situation. Tom and I have talked about the possibility of having a MIME class as an optional display form on locatable. This would allow ENTRYs and SECTIONs to have data that is just for display - much like CDA v2. The other advantage is that legacy data can still be dealt with and displayed - even if it cannot be processed. 2. I can not find the class CONTENT_ITEM detailed in the EHR Information Model. This class is the superclass of ENTRY, but the fields (i.e. name, meaning, etc.) are not described. OK - these two fields always cause difficulty. Things have moved on since these two attributes were 'named'. Both are now internal codes - ensuring that there is no language dependence. The 'meaning' is an 'at' code that identifies that node in the archetype - it is the design time or archetype path identifier - and is described in the 'term definitions' section of the archetype ontology. The archetype path (or design time path) is expressed largely in terms of these codes \at\atnnn1. Each code is guaranteed to be unique at that level in the path. The 'name' is now an 'ac' code - and is optional in the archetype. It is described in the constraint definitions section of the ontology. This code describes any constraints on the 'name' or 'runtime label' - ie a text or term that is seen by the user. The 'name' as a DV_Text forms the runtime or 'data' path. \first reading\[SNOMED-CT::234567]\ This is important to be able to access data - as any node that has an upper limit of occurrences of greater than 1 will be accessed specifically in queries by the 'name' value - rather than the 'meaning value'. An example might be in the microbiology archetype - when looking for sensitivities to penicillinor looking for sensitivies of E. Coli. I hope this is helpful, Sam Heard Matias Klein President, CTO Ethidium Health Systems 3993 Huntingdon Pike - Suite 108 Huntingdon Valley, PA 19006-1927 USA Office: (215)938-8630 Fax: (866)583-8018 http://www.ethidium.com - 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
Issues with Latest Spec
Hi Matias Tom is on leave so it is a bit late coming... I discovered the following issues in the latest spec. I would appreciate your perspectives on them. 1. DV_PARAGRAPH does seem to make any sense as a data type. This is more of a rendering issue. A paragraph can contain multiple observations, but the spec indicates that only DV_TEXT can be in the paragraph. In my opinion, a paragraph is a higher level construct than ENTRY and seems more synonymous with a SECTION. On page 24 of the RIM model it shows an example of DV_PARAGRAPH. However it only shows DV_TEXT items possible in the prose. What if you want to put other data types in the narrative prose? This area is an issue - DV_PARAGRAPH was added to allow formating and mixing of coded and non-coded text. It was not for the sort of purpose you have shown - which is mixing text and non-text data. It is not meant to be like a section - just giving a richer text. DV_TEXTblah, blah, blah/DV_TEXTDV_DATEJuly 16, 1999/DV_DATEDV_TEXTblah, blah, blah/DV_TEXT We believe that a date amongst the text is not processable anyway - but it is felt that some complex text may be possessable - or might be the result of a natural language processor. We have not used this class in any applications as yet and you may be right. I feel that if you go so far as to make DV_PARAGRAPH a data type, you should also create DV_SENTENCE, DV_BLOCK_QUOTE, DV_HEADER, DV_FOOTER, etc. (which also doesn't make sense IMHO). This is just the tip of an iceberg that I have spoken of before. openEHR needs a standardized spec for rendering visual representations of archetypes (i.e. an agreed upon style sheet language w/ a mandatory mapping to the RIM). I think this is a reasonable statement and we need to decide how openEHR will address the structure text situation. Tom and I have talked about the possibility of having a MIME class as an optional display form on locatable. This would allow ENTRYs and SECTIONs to have data that is just for display - much like CDA v2. The other advantage is that legacy data can still be dealt with and displayed - even if it cannot be processed. 2. I can not find the class CONTENT_ITEM detailed in the EHR Information Model. This class is the superclass of ENTRY, but the fields (i.e. name, meaning, etc.) are not described. OK - these two fields always cause difficulty. Things have moved on since these two attributes were 'named'. Both are now internal codes - ensuring that there is no language dependence. The 'meaning' is an 'at' code that identifies that node in the archetype - it is the design time or archetype path identifier - and is described in the 'term definitions' section of the archetype ontology. The archetype path (or design time path) is expressed largely in terms of these codes \at\atnnn1. Each code is guaranteed to be unique at that level in the path. The 'name' is now an 'ac' code - and is optional in the archetype. It is described in the constraint definitions section of the ontology. This code describes any constraints on the 'name' or 'runtime label' - ie a text or term that is seen by the user. The 'name' as a DV_Text forms the runtime or 'data' path. \first reading\[SNOMED-CT::234567]\ This is important to be able to access data - as any node that has an upper limit of occurrences of greater than 1 will be accessed specifically in queries by the 'name' value - rather than the 'meaning value'. An example might be in the microbiology archetype - when looking for sensitivities to penicillinor looking for sensitivies of E. Coli. I hope this is helpful, Sam Heard Matias Klein President, CTO Ethidium Health Systems 3993 Huntingdon Pike - Suite 108 Huntingdon Valley, PA 19006-1927 USA Office: (215)938-8630 Fax: (866)583-8018 http://www.ethidium.com - 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Propositions?
Matius Thank you for your email. You are correct in your assertion. I have felt that this is not summary data and as an Entry should go in an archetype called questionnaire. Archetype can then have a question and an answer. Such data is usually derived from the EHR in the long run - I call it cross sectional data - it is not persistent as it is false the next day if they are diagnosed tomorrow. Observation concept = questionnaire item Element Do you have diabetes? value BOOLEAN You may have many of these - I believe processing will need to be undertaken by the designer of the questionnaire - but these may with time become standardised. You could map the element term to the code for Diabetes Mellitus in SNOMED. How does this sound? Sam Matias Klein wrote: Hello All, We are making incredible progress with the openEHR framework! Recently we faced a requirement to create patient-facing data capture tools. Unfortunately we can't seem to find a place in the openEHR model where these types of propositions fit cleanly. For example if I have a patient intake form that has the question, Do you have diabetes? Obviously the patient's answer to the question could be modeled as an observation of diabetes mapped by the DV_CODED_TEXT datatype to SNOMED or ICD. However what I don't understand is how the proposition Do you have diabetes? should be modeled? Should a diabetes archetype have a proposition field where a question can be stored as a string? How would multiple perspectives be modeled (i.e. question to patient, question to doctor, question to family member, etc.)? Your assistance in helping me understanding this issue is greatly appreciated. Kind Regards, Matias Matias Klein Ethidium Health Systems 3993 Huntingdon Pike - Suite 108 Huntingdon Valley, PA 19006-2623 USA Office: (215)938-8630 Fax: (215)938-7301 http://www.ethidium.com - 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
Propositions?
Gerard The alternative suggestion is to allow the patient to add information to the EHR problem list - ie enter diabetes mellitus as a problem. It is true that the Entry will be known to have come from them. The composition will also come from them and unless the world changes a little - will not be accepted as valid without some clinical input. Cheers, Sam gfrer wrote: The archetype is the archetype and describes a specific concept. It does not matter who is using the archetype to provide answer. The author attribute will indicate whether it is the doctor or patient that filled in the slot in the archetype. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 04 Mar 2004, at 22:24, Matias Klein wrote: Should a diabetes archetype have a proposition field where a question can be stored as a string? How would multiple perspectives be modeled (i.e. question to patient, question to doctor, question to family member, etc.)? - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Propositions?
Jim Patients often report that they have diabetes and clinicians usually believe them. Infact it would be negligent not to without good reason. So we are used to doing that. Entering the problem in their problem list is something that increases the scope of the information. We have added diagnostic criteria to diagnosis - so we might be able to keep track of these in future. In the non communicating health world we and Jim are used to the scenario is more problematic. The future (and openEHR) will hopefully remove the need to enter data in multiple ways. Specifically - openEHR can attribute the composition, the entry and the addition to the problem list. We believe this is sufficient. A patient reporting diabetes would not be entered as a diagnosis unless the clinician judged this to be the case. Recording that a patient said it is possible as free text, or as the answer to a question as I have stated earlier. Cheers, Sam Jim Warren wrote: I'd be very interested in a detailed explanation apropos to Matias' query. Among other things, this question seems important for home monitoring contexts as well as questionnaires filled out in the doctor's office. Normally a contact note is attributed to a provider, so that takes care of the idea that Dr X records Diabetes or Nurse J records diabetes. However, if Nurse J is not *diagnosing* diabetes, but recording that the patient *says* they have diabetes - well, that's different. Presumably the entry could be organised under the Subjective component of the contact note (?). Nonetheless, it would seem dangerous to assign the SNOMED or ICD *diagnosis* code for Diabetes (and of what type?), since a subsequent query could pull this out of context as a provider diagnosis. How is the best way to represent that 'the patients says they were diagnosed with diabetes'? All of the above might seem less academic if the disease in question were one where the patient was more likely to be in error, or particularly to give a false positive. I assume that the prompt would NOT be modelled in the archetype, but perhaps implied by the actual code used and otherwise left up to the application to provide. (Again, I'm not sure - please enlighten me!) Jim Warren Assoc. Prof. Jim Warren Advanced Computing Research Centre University of South Australia Mawson Lakes SA 5095 AUSTRALIA -Original Message- From: Matias Klein [mailto:matias at ethidium.com] Sent: Friday, 5 March 2004 7:54 AM To: openehr-technical at openehr.org Subject: Propositions? Hello All, We are making incredible progress with the openEHR framework! Recently we faced a requirement to create patient-facing data capture tools. Unfortunately we can't seem to find a place in the openEHR model where these types of propositions fit cleanly. For example if I have a patient intake form that has the question, Do you have diabetes? Obviously the patient's answer to the question could be modeled as an observation of diabetes mapped by the DV_CODED_TEXT datatype to SNOMED or ICD. However what I don't understand is how the proposition Do you have diabetes? should be modeled? Should a diabetes archetype have a proposition field where a question can be stored as a string? How would multiple perspectives be modeled (i.e. question to patient, question to doctor, question to family member, etc.)? Your assistance in helping me understanding this issue is greatly appreciated. Kind Regards, Matias Matias Klein Ethidium Health Systems 3993 Huntingdon Pike - Suite 108 Huntingdon Valley, PA 19006-2623 USA Office: (215)938-8630 Fax: (215)938-7301 http://www.ethidium.com - 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Basic EHR functionality
Tim The openEHR and before it GEHR work on legality made it clear to me that a document has no legal status until it is saved in some voluntary manner - just as a correction in a written document has no status as fact (if you contemporaneously correct the document). Sam On Sat, 2004-03-06 at 10:08, Thompson, Ken wrote: Do you thing that a document being informally saved by an automated process designed to support recovery of the document should be subject to the same modification constraints as a formally saved document? I would say that the data is not a formal document until a deliberate action is made by the creator to commit it as such. Does anyone know if there is any existing legal precedent on this? Tim - 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
[Fwd: Fwd: XML.org Daily Newslink. Friday, 12 November 2004]
Original Message Subject: Fwd: XML.org Daily Newslink. Friday, 12 November 2004 Date: Sat, 13 Nov 2004 12:20:36 +0100 From: Gerard Freriks gf...@luna.nl To: Angelo ROSSI MORI angelo at itbm.rm.cnr.it, Sam Heard sam.heard at bigpond.com, Klein Gunnar gunnar.klein at sis.se, Magnus Fogelberg magnus.fogelberg at fogare.se, Mennerat Francois francois.mennerat at wanadoo.fr, Beale Thomas thomas at deepthought.com.au, Kalra Dipak d.kalra at chime.ucl.ac.uk, Maskens AP alain.maskens at chello.be CC: A.J.M.Rovekamp ajm.rovekamp at pg.tno.nl, Dumay Acm ACM.Dumay at pg.TNO.nl, Loos vd Jan loos at hislink.nl, Verhees Bert bert.verhees at rosa.nl, Spook Maarten Maarten.Spook at 2cure.com Hello, Archetypes are slowly percolating through the world. Have a read. What shall/can we do in addition to promote this process. Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 Begin forwarded message: XML.org Daily Newslink. Friday, 12 November 2004 Provided by OASIS http://www.oasis-open.org Edited by Robin Cover === This issue of XML.org Daily Newslink is sponsored by SAP http://www.sap.com/ === HEADLINES: * Exploiting ebXML Registry Semantic Constructs for Handling Archetype Metadata in Healthcare Informatics * Atom Syndication Spec Ready for IETF Closeup * The Atom End-Game * Web Services in Action: Integrating with the eBay Marketplace * Coalition Asks US Congress to Kill Copyright Bill -- Exploiting ebXML Registry Semantic Constructs for Handling Archetype Metadata in Healthcare Informatics Asuman Dogac, et al, OASIS IHC TC Technical Paper Using archetypes is a promising approach in providing semantic interoperability among healthcare systems. To realize archetype based interoperability, the healthcare systems need to discover the existing archetypes based on their semantics; annotate their archetypes with ontologies; compose templates from archetypes and retrieve corresponding data from the underlying medical information systems. In this paper, we describe how ebXML Registry semantic constructs can be used for annotating, storing, discovering and retrieving archetypes. For semantic annotation of archetypes, we present an example archetype metadata ontology and describe the techniques to access archetype semantics through ebXML query facilities. We present a GUI query facility and describe how the stored procedures we introduce, move the semantic support beyond what is currently available in ebXML registries. We also address how archetype data can be retrieved from clinical information systems by using ebXML Web services. http://xml.coverpages.org/healthcare.html#DogacIJMSO See also on Artemis: http://xml.coverpages.org/healthcare.html#DogacInfSys - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype vs. ontology
Philippe Thank you for this...very informative and I am starting to see how we are converging with your work. I believe that the 'structured terminology' - fils guide down from the archetype nodes - is an important part - SNOMED are trying to address it generically (ie without archetypes) - I doubt this is possible in one language - and it is certainly not in other languages. From my experience with health one, French is particularly suited to the approach that you are taking as qualifying terms (such as adjectives) tend to follow their nouns and the subject, verb, object structure is usual in sentence. I know that moving to English - where qualifiers precede, that such an approach has to be more sophisticated - and in other languages it is far more complex. What is called for is getting to grips with some key archetypes for interoperability - from a range of stakeholders - and then really having a close look at where more complex terminology is sought. One place I have no doubt it is required is in anatomyhow you describe the location of a lesion or mass. Another is the characteristics of a mass or lesion. The high level 'smarts' you are talking about are impressive - and I do not know about this end of things. Cheers, Sam Hi Thomas, The very word we are talking about here is Knowledge management. Archetype and ontology are some (very strategic) components, but are not the whole thing. From my point of view, Knowledge management is a superset of (at least) 2 concepts : artificial intelligence (AI) and smart data management. An example of smart data management is the ability, when you expect a document of 'A' type and that a document of 'B' type arrives, to check if 'A' -is a- 'B' or 'B'-contains-'A', in order to close the goal get a A. So, Knowledge management doesn't only mean expert systems or smart agents, but a system that is globally aware of what it manages. In Odyssee, the ontology is the very kernel of the systems, since it is the langage used to tell the patient health journey, but also to represent the internal knowledge. The AI components are structured around a Blackboard (we started from Stanford's BBK, now largely adapted) that federates smart agents. The smart data management components are everywhere else, for example in the data model and interfaces management. This (somewhat long) introduction to tell that, in the way we use it, Archetypes are data model elements and Fils guides are interface elements of the smart data management category. A Fil guide is a multi-purpose information element aimed at answering the question what can I do now ? for something/someone that is somewhere in a tree (multi-purpose isn't it ;o)). So a Fil guide is made of two parts : a path (in the form colonoscopy/description/polyp or colonsocopy/*/polyp or */polyp) and a content (currently in the form of a list of ontology concepts that can allow to bring the description one step further, but it can be anything else - say an html page or a function pointer). When you describe something in the medical field, if there is a genuine gold standard description, you have to use a deterministic approach, since the user has to be compliant to the standard. This description becomes part of the information system reference model through an Archetype. And the instanciated data remember the mold (Archetype) they come from. But in most cases, there is just a fuzzy expertise, and you can just say something like being where you are, an expert would keep on the description that way : it is tipically what a Fil guide will do. You have many Fils guides in a big bag, and when the user is somewhere, you find the more relevant Fil guide (if any) : more relevant means the one whose path is the semantically closest from user actual current path. But the Fils guides are just oppostunistic description support in a non deterministic domain. So the data don't remember the Fil guide they come from. This (too) long description to explain that Fils guides neither belong to the reference model, nor to the ontology, but are interface components in a knowledge management system. Currently, we have nearly 3500 Fils guides, but most of them are used for our report management system and should be replaced with archetypes. By the way, the Fil guide engine, that decides which Fil guide to throw, can also decide to throw an Arcehtype if the user has entered a part of domain where a deterministic description should occur. And you also can go beyond the leaves of an Archetype using Fils guides (or just using the ontology by hand). I hope that all this is understandable ;o) Philippe AMELINE Hi, I just forgot to tell you that our ontology has only 50 000 terms (it means less than 50 000 concepts, since a concept can be represented by several terms). As you may have understood, the ontology
Episodes in openEHR
Tim These links are very helpful...particularly to show that the idea of episode is about one consultant - rather than admission. The Australian data dictionary is about an admitted patient episode. It is clear that many types of groupings will be required. The Folders solution may be one - but I believe a 'persistent' EVALUATION which is archetyped for the purpose is more likely to be usefulas it will allow collection of whatever data is required. Sam Tim Churches wrote: On Sat, 2004-11-20 at 12:42, Thomas Beale wrote: This is part of a discussion that started off the list. The need is to be able to model Episodes in openEHR, while remaining compatible with available structures. See http://bmj.bmjjournals.com/cgi/content/full/329/7476/1207 and http://snipurl.com/armv for definitions of statistical episodes, which may or may not correspond to clinical episodes. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype constraints and interfacing instruments/DSS to an OpenEHR system.
Damon This is important to consider I believe that DSS groups will be a major player in determining the final archetypes that are agreed at a high level. It seems to me that in the same way, archetypes will have great impact on the development of future EHR-compatible instrument interface standards. If instruments and instrument interfaces are required to provide information that is complete enough to be integrated into the EHR, then additional context information will need to be appended as the measurement values are recorded. Lets assume that a typical existing instrument interface was not designed to produce shareable EHR extracts - a safe bet in my view. Result: missing context info. So to ensure compatibility either, It is not critical that the instrument give all the context as you point out below. - the instrument interface is revised by the instrument vendor to satisfy the associated archetypes OR - an adapter on the EHR side of the interface adds the required context information prior to submitting it to the EHR-S proper. (not very nice) I guess you know this from experience.we would see the clinician setting up the monitoring - this is the only context I think that would not come from the machine - the protocol information and measurements should be enough then. OR - some compromise is reached on the completeness of the archetype. (dangerous) OK - maybe I am exaggerating - but it would be interesting to pick a legacy instrument standard (say crusty old ASTM 1394-91) and see how it holds up. If you know something well, lets use that. I would not see an extract as the way to go - but it would be appropriate if a whole session was captured in another environment and then sent to the EHR - perhaps in a catheter lab. The norm for instruments would be to create one or two (or three) entries. Pulse oximetry is a good example. Sam Damon - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
openEHR and Odyssee
Philippe, I agree - your work has been an inspiration to us to keep going with the approach we have chosen. There is no doubt that we need an ontological underpinning in our work - and its relation to the ontological underpinning of terminology should be clear. For a start we are populating archetypes that are discreet and can be specialised for use in different situations. It is possible that the more terminological approach you have taken would be the best link from the archetype to pure terminologies such as SNOMED and ICD-10. I am interested in where you see the ideal line and where your work sits with SNOMED-CT. Cheers, Sam - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Medication Regimens
Matias Thanks for the email - and sorry to be so slow getting back to you. Our current work in this area relates to instructions as a generic class in the reference model. The links between individual instructions can modelled in a number of ways: 1. The start condition for one instruction might be the start of another (paralell) or the completion of another (chained) 2. A set of instructions might have overlapping start and finish - that is they have no relationship other than the fact that they occur at the same time. 3. A section - perhaps called 'Regime' could contain linked medications. 4. A link could be used. We are currently working on an oncology project in which medication regimens are used. I would appreciate some guidance on the preferred way to model regimens using openEHR. Here is an example of a regimen I am modeling: Regimen Name: CAF Step 1: Cyclophosphamide 100 mg/m2/day po days 1-14 Step 2: Doxorubicin 30 mg/m2/day iv days 1 and 8 Step 3: 5FU 500 mg/m2/day iv on days 1 and 8 repeat q 4 weeks As I see it, there are two possible models: 1. One INSTRUCTION with an ITEM_TABLE data structure that has each step in a different column. The way we are modelling instruction would mean that this must be two separate instructions - as the frequency of the action specified is held in the timing part of the instruction and must apply to the complete action. A regime could be displayed in this manner. OR 2. Three INSTRUCTIONs with LINKs between them (i.e. a concurrent medication order). This would be very similar to the chained medication order described in the EHR Information Model (Figure 27). However in this case, the LINKs' meaning would be concurrent actions rather than next action. Any instruction with the same timing is concurrent by definition - the question is - do we need to know that they are linked in a way that is more than concurrent timing. I think not, apart from the ability to link these as you describe - have the same indication and be organised as a regime or course or other grouping as required. Does anyone have a preference or another way to model this? Thanks, Matias Cheers, Sam - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Flavour of null
Dear All A reminder on why flavour of null is at the ELEMENT level: it allows a composition with mandatory data to be saved even if the data is not available, or allows a reason to be stated for data that is missing. It also allows us to deal with the HL7 flavour of null on the data types. I am concerned that the flavour of null is set to DV_CODED_TEXT and not DV_TEXT (ie. it has to be coded from a terminology). I agree that some systems will want things coded for safety in some situations, but I believe that this should be handled through archetypes and templates. Laboratories will want to use this for all sorts of reasons, one clear example is when an electrolyte sample has haemolysed - and they cannot give a potassium reading (they do not want to omit it!) So I want to propose that the flavour of null is set to DV_TEXT. Cheers Sam Heard - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The Uncertainty Decision was: Dr R LONJON Confidence indicator !
Arild and Tim This is clearly an issue. In the CIP project the group wanted to be able to say that a diagnosis was a working diagnosis. We have archetyped a number of concepts that I think will enable the clinician to express these levels of uncertainty without resorting to confidence ratings on all entries in the record. Arild has shown that you could not possibly do a mastectomy without rating your certainty at 100% - or you will be sued. And not treating a pneumonia in a newborn with a certainty of only 20% will probably get you in trouble. These sort of explicit ratings are - in my opinion - very problematic. The solution lies in the recording constructs used for many years: 1. To express differential diagnoses (with or without probabilities) and to note key excluded diagnoses as well. 2. To express a diagnosis as a problem (such as lump in left breast) even if the likelihood of cancer is 100% clinically until the histology is returned. 3. To be able to label a diagnosis as a working diagnosis - ie it is likely enough to warrant the current management - but not certain. Appendicitis is a good example. So the archetypes for problem, problem-diagnosis (specialised) and differential diagnosis should meet these needs. Comments? Sam Tim Cook wrote: While it might be an interesting exercise for us to record how confident a clinician was at the time of recording a diagnosis, it will have no impact on the health care of that patient. If we were to do this would we ask them to do so in sarcasm10% steps, 5% steps or .01% steps/sarcasm? I assert that any one of these would seriously impact the usability of an EHR in a negative manner and would result in the clinician taking the option that presents the least liability on their part. So back to the short answer above.is it really relevant to assert ANY confidence factor in the EHR? My opinion is that there indeed is highly relevant to assert a confidence factor in the EHR. ln decision analysis one talks about treatment thresholds for diagnostic uncertainity as the probability of disease at which the expected value of treatment and no treatment are exactly equal, and ne ither option is clearly preferable. (Hunik and Glasziiou Decision making in health and biomedicine). Factors influencing the treatment threshold are the expected benefit and the expected harm of the treatment. Example: Treatment threshold is much lower for pneumonia (treatment: penicillin) than for cancer of the left mamma (treatment: Mastectomy) Thus: How confident a clinician is at the time of recording a diagnosis has high impact on the health care of that patient. Comments on this? regards, Arild Faxvaag - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age, gender and more
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: 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 at bigpond.com: 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 - 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
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 questions about using this list, please send a message to d.lloyd at openehr.org -
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 -- private -- 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
openEHR in the news in Australia
Tim Ocean Informatics is working in two key activities. 1. Tom is working on the finalisation of the V1 specification and the development of the open source Java kernel at CHIME(UCL) in London, working with a group in Sweden. The DSTC RecordPoint product (J2EE on SQL database as I understand it) announced yesterday may merge with this work in the future if appropriate - we will have to see where this goes. The DSTC are spinning off a commercial company to provide services in this area. 2. Ocean have a growing team here in Australia building a .Net proprietary openEHR EHR Service (Called EhrBank!). We are starting out at the NSW Cancer Registry working with Vince McCauley from McCauley Software as part of an ITOL grant and have some other potential customers for this product. The archetype repository is coming on - a first glimpse is available at: http://www.dualitysystems.com.au/archetypefinder/archetypefinder We and the DSTC, are ready for project based work in this area, either separately or together as suits customers, to get things moving. Happy to talk you, as I am sure are the DSTC, about any ideas that you have. Cheers, Sam Ocean Informatics Thomas Beale wrote: some may find this interesting...http://australianit.news.com.au/articles/0,7204,15675784%5E24169%5E%5Enbv%5E,00.html Thomas, Can you tell us more about the openEHR storage and retrieval engine being used in the Brisbane HealthConnect trials? Our situation is that we admire the openEHR model and think that it is basically sound, and have played with the openEHR archetype editing tools, which seem adequate for the task. We'd like to have a go at creating some draft archetypes for use in the public health domain, but in the absence of an openEHR storage engine, either open source or proprietary, we don't really see the point except as an armchair thought experiment. We don't have the resources to build and validate a storage engine of our own (the building doesn't look too hard; validation is the bit that looks like it would consume a lot of resources). Any advice for us on how (or when) we should proceed? Tim C - 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
Demographics service
Karsten You will see from the attestation class that it is possible to add an image with a digital signature - allowing compositions to be pixelmaps for legal purposes if required. Cheers, Sam Heard The EHR is rather a unique document and a layered approach is necessary as old data must never be altered - may not necessarily be accessible but must never be altered. Errors can be corrected but the error must remain totally accessible in the manner it was presented to the clinician when it was relied upon - eg clinical results, medications. That is not feasible as it would amount to taking physical pictures of the screen as it looked when displayed. And even this would only prove what the user *might have seen had she tried* - certainly not what she *saw*. Karsten - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
archetypes and class constraints
Kerry The archetype editor sets this constraint for dv_date_time using a syntax for the purpose. At present the other reference model classes are not available in the same manner - that is they do not impinge directly on the data. Generally, one assumes that in the reference model people will use the actual classes specified. I am sure Tom will have something to say on the matter! Cheers, Sam Heard - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Demographics service
Dear All The openEHR design team have, over many years, decided to separate the demographic information from the EHR data. Advantages are, amongst others: 1. Security - you need access to both sets of data to know about an individual 2. Normalisation - you can find people even though they have moved, changed their name etc 3. Many health environments have developed demographic services which people want to keep. The EHR model has quite different classes than the EHR model - and the archetypes are therefore different. The demographic server in an openEHR environment provides identifying, contact and credentialling information about parties. Hope this is helpful...Sam Hi, What is the definition, scope, function of the concept: demographic server in the context of OPENEHR? Thomas, Sam, Dipak: HELP! Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 06 Mar 2005, at 19:50, lakewood at copper.net wrote: Hi Gerard, My understanding is that demographic services collect, organize and process the characteristics of a 'population'. Presuming this, then I am a member of a large number of 'populations' regardless of intent. Narrowed to Healthcare the number of 'populations' shrinks but not to one. Given the fact that modern 'populations' are not 'stationary' it appears that there are many of us that can claim or hold membership in multiple Healthcare 'populations' which themselves are subject to new additions, e.g., those genetically sensitive to drugs of a particlular family. Identifying the indiviudal may have to be a separate operation. Identifying whether the individual is a member of a 'population', or 'populations's a subsequent task. A 'demographic server' is likely to be specific and limited in scope to address 'super populations', e.g., persons residing within the boundaries of a specific geographical region, e.g., Africa. A 'network' of such server could provide additional coverage. Since one can apply a variety of rules to the specification of an individual 'population', the 'rules' become significant especially where the 'rules' are chosen to affect results, all Diabetes Patients in the London area. Due to a number of reasons one may not be able to claim that London-area Diabetes Patients are the same as those in other regions, and, of course, that the Healthcare systems are the same or equivalent. Foundational is 'personal identification'. Without it a 'demographic server' is handicapped. Hence a good test for the server is a seriously injured person arriving at a Healthcare facility unable to communicate with no other form of identification. Since there are many other 'issues' and 'factors' important to the design, development and deployment of a 'demographic server' one may have to accept discussions that attempt to integrate topics. They are valuable RD efforts are results-oriented expectations are very likely to increase quickly. Regards! -Thomas Clark BTW: I tried to avoid bringing 'Public Health' into a discussion about 'demographic servers'. That would have been lengthy! - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
ADL to XML Schema
David W. Forslund Good to see you sniffing around! The key issue for us in ADL is that Eiffel is not UNICODE compliant. There will be a number of Java parsers soon, and I hope a JAVA archetype editor. I am interested in what you can do with Schematron as well as another implementation routekeep me up to speed. Cheers, Sam I've been looking at schematron for doing the equivalent of archetype in a more general situation, particularly since there as been no ADL parser available in Java. Schematron seems to be reasonably popular for enforcing rules for XML data structures and there is a variety of software available for using it. Dave On Tue, March 8, 2005 4:28 am, Gavin Brelstaff said: Rahil Qamar wrote: Hi Alfonso I can answer one of your questions for certain and am not very sure about another one. Alfonso Mata wrote: - Is it possible to obtain a XML-Schema based on 13606 from an ADL file? You can obtain an XML representation of the ADL Archetype from the Archetype Editor but not an XML Schema. Atleast not at the moment. However Im trying to write out a schema based on the UML Archetype Object Model. Its not proving to be an easy task is all I can say ! I've done one version of the schema but its far from perfect to generate a sensible XML. If you are interested in doing some work on this we could collaborate. There are some less heavy ways of doing XML rule checking that avoid most of the irrational intricacies of the W3C Schema. Did you ever explore Jim Clark's RelaxNG for schema validation of XML structures, and Schematron for rules involving Co-occurance relationships. That might be a way to go. -- Gavin Brelstaff - BioMedical Area, CRS4 in Sardinia Loc. Pixina Manna Edificio 1, C.P. n.25, 09010 Pula (CA) Italy. Email: gjb at crs4.it Phone:+39.070.9250.312 Fax:+39.070.9250.216 - 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
ADL to XML Schema
Dave I am not familiar with Schematron. I have had a look on the web, at some tutorials etc - and it is available in the Oxygen editor that I use. Generally the openEHR approach has been to apply archetypes to the reference model in memory. This works well and is proven. What you are proposing, as far as I can see, might lead to a schema for a composition - where the schema met both the archetype constraints and the reference model schema. It will be relatively easy to test this with something like the blood pressure archetype. At the moment I can only give you XML data that fit the RM schema - the archetype constraints are only expressed in our in memory objects. I enclose the archetype and data for your information. If we could spit out a schema based on a template (a composition built from a set of archetypes) and express the constraints in the archetype, this would be well received. It would mean that standard compositions, like a discharge summary or a laboratory report, could be expressed as XML schema + Schematron. I believe this is worth investigating. Cheers, Sam David W. Forslund wrote: What I would like to do is automatically translate from an ADL description to a schematron description. Hopefully, this is semantically possible. Dave On Tue, March 8, 2005 5:58 pm, Sam Heard said: David W. Forslund Good to see you sniffing around! The key issue for us in ADL is that Eiffel is not UNICODE compliant. There will be a number of Java parsers soon, and I hope a JAVA archetype editor. I am interested in what you can do with Schematron as well as another implementation routekeep me up to speed. Cheers, Sam I've been looking at schematron for doing the equivalent of archetype in a more general situation, particularly since there as been no ADL parser available in Java. Schematron seems to be reasonably popular for enforcing rules for XML data structures and there is a variety of software available for using it. Dave On Tue, March 8, 2005 4:28 am, Gavin Brelstaff said: Rahil Qamar wrote: Hi Alfonso I can answer one of your questions for certain and am not very sure about another one. Alfonso Mata wrote: - Is it possible to obtain a XML-Schema based on 13606 from an ADL file? You can obtain an XML representation of the ADL Archetype from the Archetype Editor but not an XML Schema. Atleast not at the moment. However Im trying to write out a schema based on the UML Archetype Object Model. Its not proving to be an easy task is all I can say ! I've done one version of the schema but its far from perfect to generate a sensible XML. If you are interested in doing some work on this we could collaborate. There are some less heavy ways of doing XML rule checking that avoid most of the irrational intricacies of the W3C Schema. Did you ever explore Jim Clark's RelaxNG for schema validation of XML structures, and Schematron for rules involving Co-occurance relationships. That might be a way to go. -- Gavin Brelstaff - BioMedical Area, CRS4 in Sardinia Loc. Pixina Manna Edificio 1, C.P. n.25, 09010 Pula (CA) Italy. Email: gjb at crs4.it Phone:+39.070.9250.312 Fax:+39.070.9250.216 - 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 -- next part -- An embedded and charset-unspecified text was scrubbed... Name: openEHR-EHR-OBSERVATION.blood_pressure.v1.adl URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050310/fffeb536/attachment.adl -- next part -- A non-text attachment was scrubbed... Name: BloodPressure.xml Type: text/xml Size: 3295 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050310/fffeb536/attachment.xml
DV_MULTIMEDIA
Dear All I have been working with DV_MULTIMEDIA and feel that the thumbnail feature should be a JPEG rather than a DV_MULTIMEDIA. I believe this is the way to go as although it restricts the thumbnail to an image - it means that everyone can view the thumbnails. It also means we do not have a cyclical definition. The danger is fixing to a particular technology - but I think in this case it is worth it. Thoughts? Sam Heard - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Ang. Archetypes new tool versions
Sorry Torsten The notification was sent to an old email..we have renewed it so I hope that goes well very soon. Sam - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The semantics of archetype Specialization
Hi Andrew The principles of specialisation have been described in our development environment and there is a placeholder for the documentation in the archetype system document. Our initial thoughts are at: http://www.deepthought.com.au/it/archetypes/output/specialisation.html The rules that we are working with but are not fully embodied in the editor are: An archetype that is a specialisation of a parent contains data with archetype node IDs that conform to that of the parent. This means that: 1) All paths mandatory in the parent are present in the child 2) All paths optional in the parent may be present in the child, and if so will have the same path The meaning of any element or cluster expressed in the parent is preserved in the child (although it may be narrowed). If it is not identical then it will have an id that is a specialisation of the parent id. at0001 - at0001.1 Optional elements (and clusters) in the parent do not have to be available in the child. New elements can be available in the child - their meaning is guaranteed to be different than that included in the parent. They have a code that identifies the level of specialisation, and these may be specialised in subsequent children. A new id at level 0 is at0001, a new id at level 1 is at0.1, a new id at level 2 is at0.0.1. The editor enforces most of these, but specialisation of clusters (allowed in the laboratory archetype) introduces issues. These rules do need documentation and it would be helpful to have others think about this. Cheers, Sam Hi, Does anyone know what it actually means to specialize an archetype? And what the rules are? I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don?t exist as optional fields in the parent archetype To me this particular example is not safe as one of the basic rules of specializing archetypes is you should be able to validate any new specialized EHR data against the parent archetype. -Andrew - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The semantics of archetype Specialization
Andrew The lab result is a good example of further constraining and it is really additional constraints. It is just that the at0013 (any data type) is labelled and turned into a quantity with units. It looks like extention but is it further constraint in this instance. However, we do extend archetypes - as Kerry says - as long as there are no surprises at runtime this is OK. So all the paths in the parent must do what they do in the parent. Cheers, Sam Hi Grahame and Health, It seems that Sam is working by a philosophy of extension in his archetypes. For example, take lab result, which is an entry level archetype that has a list of coded result values. The lipids labs result archetype seems to extend the existing archetype by create new fields for cholesterol, triglycerides, etc, rather than further constraining the existing coded result values in the lab result archetype. I am not sure specialization by extension is applicable to the archetype specialization case. Archetypes works by constraining the reference model. Therefore, any further specializations of an archetype may only further constrain what the parent archetype supports. For example, the lipids lab result archetypes should have further restricted the lab result archetype to have contained coded fields for cholesterol, triglycerides, etc. -Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 2:21 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew If the language only makes positive structural statements, such as standard 3gl o-o paradigms, then specialization cannot be done by restriction - while there's nothing stopping it, there's no way to express it. (Though reference Heath's email - there's various ways to actually do it, but many of them result in ill-formed models, just the compiler doesn't know how to stop them, therefore they are legal) If the language is able to make constraint statements, then specialization can be done by both restriction and extension - but restrictions in the generalization will prohibit some forms or instances of both extension and restriction in the specializations. ADL is able to make both positive structural statements and constraint statements, so it's able to support specialization by extension and restriction. But I think, due to the nature of ADL, that there is no computationally provable answer to whether any given specialisation is properly formed (at least in the general case). Many of the stupid things about XML Schema arise because they have a requirement (I think), that there must be a computationally provable answer. Grahame Andrew Goodchild wrote: I would only hope that that is what is intended. However, the semantics at the moment that appears to be supported by the editor implies that archetype specialization is nothing more that cut and paste style semantics. We will have to wait for the answer from Tom and Sam. Also, I am wondering if archetype specialization only supports restriction or extension or both? -Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 12:08 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Well, I'll defer to Tom or Sam. But from a computational perspective, what else could make sense? Grahame Andrew Goodchild wrote: Thanks Grahame, The UML specs definition of specialization matches what I thought it had meant. I guess what I would like to understand is whether such a definition is true or not for archetypes? Is specialization in archetypes meant to support the definition you provided and the archetype editor is missing some functionality to ensure that only correctly specialized archetypes can be built? - or - Is it that archetypes and the editor supports some new semantics around specialization that I don't quite understand yet? I am sure Sam or Tom could shed some light on this ... Cheers, Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 10:57 AM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific
The semantics of archetype Specialization
Andrew We are not able to implement specialisation as I would like - true O-O would be better - so the child has all the features of the parent at the outset - though the editor knows a little about what is going on. Try renaming - you have to specialise the concept (shadowing in O-O), but you can move it about with impunity. This should not be allowed if the archetype is ordered. Until we get an editor that can cope with specialisation in the o-o paradigm (which is well beyond my technical skill) we will have to make do with what we have. Cheers, Sam I would only hope that that is what is intended. However, the semantics at the moment that appears to be supported by the editor implies that archetype specialization is nothing more that cut and paste style semantics. We will have to wait for the answer from Tom and Sam. Also, I am wondering if archetype specialization only supports restriction or extension or both? -Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 12:08 PM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Well, I'll defer to Tom or Sam. But from a computational perspective, what else could make sense? Grahame Andrew Goodchild wrote: Thanks Grahame, The UML specs definition of specialization matches what I thought it had meant. I guess what I would like to understand is whether such a definition is true or not for archetypes? Is specialization in archetypes meant to support the definition you provided and the archetype editor is missing some functionality to ensure that only correctly specialized archetypes can be built? - or - Is it that archetypes and the editor supports some new semantics around specialization that I don't quite understand yet? I am sure Sam or Tom could shed some light on this ... Cheers, Andrew -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 26 May 2005 10:57 AM To: openehr-technical at openehr.org Subject: Re: The semantics of archetype Specialization Hi Andrew Does anyone know what it actually means to specialize an archetype? And what the rules are? The UML specification offers this definition for generalization: A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed I think that this is a fairly watertight definition and quite relevent to your question. I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don't exist as optional fields in the parent archetype By the UML definitions, these become ill-formed model. Of course, it's one thing to to state the definition, quite another to know how to compute whether a model is ill-formed. Grahame - 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Question about Ocean's Archetype Editor
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051115/ba78c98c/attachment.html
Archetypes, paths and the reference model - issues for the Editor
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051117/99e8e947/attachment.html
parsing error
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051012/e6e93d46/attachment.html
Templates - should we record which are used?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051020/dc94bc9d/attachment.html
Templates - should we record which are used?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051021/43bd828c/attachment.html
openEHR XML-schema Questions - Include or Import?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051021/9a530b40/attachment.html
openEHR XML-schema Questions - Now in four sections
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051021/a2b7da1d/attachment.html
openEHR XML-schema Questions - Now in four sections
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051024/d7a30877/attachment.html
DV_QUANTITY_RATIO - remove from specification
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061210/991d7f80/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
DV_QUANTITY_RATIO - remove from specification
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061211/b594f834/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Constraint references
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061218/384b0599/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Suggestions re Term binding in Archetype Editor
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061218/707c2271/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Suggestions re Term binding in Archetype Editor
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061218/548fab4a/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Suggestions re Term binding in Archetype Editor
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061219/b572aa58/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML Schema candidate
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060217/525f3886/attachment.html
openEHR Terminology
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060217/ca03d054/attachment.html
Suggestion about the Multi-axial Archetype Indentifier
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060218/3a339af0/attachment.html
Pathology numeric values not supported in DV_Quantity
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/bd767cfc/attachment.html
difficulties starting an implementation
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060118/cdefb747/attachment.html
Proposed slightly radical change to CODE_PHRASE in Text package in openEHR
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060124/5febd8a0/attachment.html
More questions!!!
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060705/d295f949/attachment.html
what is the use of the reference model?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060707/3c0f9def/attachment.html
Pathology numeric values not supported in DV_Quantity
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/14f81e20/attachment.html
Version and commit
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060308/853cbce0/attachment.html
Pathology numeric values not supported in DV_Quantity
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060322/62f4b2c9/attachment.html
New alpha of release 1.0 archetype editor
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060504/0fedbfb9/attachment.html
Authorisation
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060504/99e01d8e/attachment.html
[Fwd: Modelling Medication Administration Control]
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060510/87c5c233/attachment.html
Lifestyle: substance_use archetype
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060510/28b25a87/attachment.html
Lifestyle: substance_use archetype
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060510/39b56008/attachment.html
Lifestyle: substance_use archetype
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060511/4847d27b/attachment.html
