HISTORY DATA SET IN EPR
Christopher Feahr wrote: Thomas, I'm curious to know if your comments are based on a review of SNOMED CT or of ontology/terminology systems, in general? As you probably know, SNOMED was designed expressly to support clinical information needs. yes, but we have to be careful about what needs we are talking about here. SNOMED-CT is a terminology in teh form of a semantic network - i.e. a terminology with an ontological flavour. Its purpose in systems is describing reality, although there are people I have met who do not think rigorous design principles have been applied, and that it is internally inconsistent (one company ran a tool over it and found 12,000 inconsistences). It also has a lot of pre-coordination in it, when what we really need it generative / compositional terminology. But these are details. The main point here is that SNOMED can tell you what the meanings of the parts of a complete blood count test are (and perhaps a good model of blood chemistry in general, e.g. facts like Mean cell volume and Mean cell Hb are attributes of cell), but it's not going to provide a model of an actual blood test - as you know, CBCs could have any number of items in them, and this might differ based on lab, health authority or some other factor. This is where archetypes and templates come in - they are about information *in use* not definitions of reality. Another comparison is the difference between blood pressure - a concept you might find described in an ontology, and blood pressure measurement - an archetype or template. THe latter is not a model of pressure of fluid in a vessel etc, but a model of the collection of items being measured, the measurement protocol, and any other data about patient state (e.g. sitting etc). So - even if SNOMED was perfect, it doesn't do everything - it is a knowledge support part of the environment, and it can be used to name things and perform inferencing (its main purpose in the eyes of some). - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
IS Models (was HISTORY DATA SET IN EPR)
Hi, The clincial analysis process is pretty much standard all over and this will find acceptability (hopefull). The data so captured can be used for a descision support system. This is an add on to your thaughts and maybe you can now look at your suggested solution in the light of what would find acceptance with a clinician. I must agree, since it was our starting point several years ago. That's the reason why we created an ontology. But we discovered it was useless trying to work on a decision support system if we only had the local datas (since you can far more easyly help a doctor by analysing what others produced... he usually can work well on what he recorded himself). So we worked on concepts in the continuity of care domain. But we discovered that the success key for continuity of care is the patient acceptance, but we had to present him with an acceptable system. So we worked on the Patient Health Project, an health management concept. Now we are quite happy with that, and we have nearly adapted a Blackboard (an Artificial Intelligence component) to our system. 10 lines to tell a 10 years story ;o) Philippe - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
IS Models (was HISTORY DATA SET IN EPR)
Thank you... this is becoming clearer from the clinical/business-process perspective. I still have this lingering concern about the inherent freedom and flexibility afforded by archetypes being somewhat in conflict with the need for interoperability. Let me see if I understand by reflecting a specific example of a physician ordering a pair of Rx spectacles from a lab: The ontology (which seems roughly synonymous with data dictionary and standard terminology a la SNOMED) would be a listing of all the atomic terms unique to specification of an Rx lens, along with industry-standard, unique definitions: SpherePower: The diopteric power of the blah, blah, blah... MinusCylinderPower: The algebraic difference blah, blah, blah... CylinderAxis: The angle represented by the blah, blah, blah... etc., fully specifying the data types, ranges of acceptable values, units of measurement, and somehow stipulating that only quarter and eighth diopter values are used. E.g., -3.25 and -3.37 are acceptable, but -3.90 is not an acceptable value for the unit, diopters. Cylinder axis is express in whole degrees with legal values from 1 to 179, etc.. Then we could define an Archetype called BasicLensFormula-MinusCylinderNotation, which is a combination of SpherePower, MinusCylinderPower, and CylinderAxis, more or less strung together. The Order specification message to the lab would require, amongst other things, the BasicLensFormula-MinusCylinderNotation for the right lens and the BasicLensFormula-MinusCylinderNotation for the left. Is this understanding correct so far? If I am using these terms and concepts correctly, then it seems to me that the most critical objects for doctors and other users to agree on INITIALLY and memorialize as a standard... across the region that wishes to experience interoperability... would be the basic ontology... correct?? If the ontology is the listing of atoms, then Archetypes would appear to be the molecules... and also something that would be helpful to attempt to standardize across the interoperability region/domain. But due to the inherent anything goes aspect of defining Archetypes, and the flexibility in system design that accompanies it, we might have a harder time getting users to agree on standard Archetypes. If 80% of the most common molecular concepts, however, could be agreed to at the SDO level, then that would seem to be in everyone's interest. I will assume that I'm still on the right track and take my question to one more level. Would it make sense, then, for the SDO to continue accepting Archetype definitions that are useful to some in the domain... even though they might be extensions or conglomerations of other Archetypes? ... and for the SDO to maintain all of them together in its library of standard archetypes for the vision industry? If Standard Archetype X was made from unique, atomic concepts A, B, C, and D... and a user only required A, B, and C... would he still use an Archetype X in his message schema, simply ignoring the value of D? Or would he register the combination of A, B, and C as a new Standard Archetype Y? (That's enough for one email!) Thanks. 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: Bhupinder Singh bob...@sancharnet.in To: Philippe AMELINE philippe.ameline at nautilus-info.com; openehr-technical at openehr.org Sent: Thursday, August 14, 2003 4:10 AM Subject: Re: IS Models (was HISTORY DATA SET IN EPR) Hello Philippe, What you are saying is correct. But let us review what christopher has already said and also reiterated in my previous mail. The objective is to have the clinicians needs fullfilled. A clinician is interested in the following. Does the application give me a user friendly interface. Does the flow follow the clinical thaught process. Does it allow the data collected to be used for a retrospective analysis. The data entry process should be completed with the minimum key strokes. The clinical process of analysis cannot be straight jacketed the system must meet the clinical requirements of the clinician. 70 % of the diagnosis is arrived at during the analysis of the symptoms and its associated findings Clinical compliance (read doctor compliance) is mandatory. For which the system should give value to the clinician. Let me give you one example of the Respiratory system. This systems in all has cardinal symptoms such as Cough Dyspnoea Haemoptysis Chest Pain And some general symptoms such as Fever weakness etc etc The complete respiratory medicine ( read 80% of the time) is based upon the findings that the clinician is able to descern out of these symptoms and assocoaited signs. If these are modelled and are available along with the flexibility to capture the information and then have the free text for the elements that are not modelled
HISTORY DATA SET IN EPR
Christopher Feahr wrote: . but my understanding was the the SNOMED people had already modeled complaints, signs/symproms, diagnosis, treatment plans, prognosis, outcomes... the whole 9 yards. If that is true (seems too good to be true!) then it may only require a (simple??) mapping of SNOMED CT to a collection of EHR Archetypes. this is a bit question. The key thing to remember is that: - terminologies/ontologies (attempt to) model reality, e.g. their model of symptoms related to tropical parasite infections will/could be a detailed semantic net of nodes describing in great detail the symptoms at every point of e.g. plasmodium lifecycle during malaria infection - textbook stuff in other words. - but the doctor in a hospital is interested in recording observations about the patient, ordering tests, making decisions, following progres and so on. The information he/she wants to record and read is to do with the observation and care process, not with the scientific description of the life history of plasmodium. This is the area of archetypes and templates - providing highly configurable models of this information and processes, during the clinical care path. - terminologies are necessary as a knowledge base during the use of archeytpes - they provide names of things of course, but more importantly, semantic networks support inferencing. So one can imagine a doctor recording symptoms and signs in their info system, and thinking that so far, it could be malaria or some other fever-inducing infection... if they have detailed enough observations, it may be that the ontology can provide some guesses as to what the patient has. So - we have two kinds of models here: terminology/ontology is about modelling the real world, and facts we have learned and appear to be dependable; archetypes and templates are about modelling patterns of information *in use*, and they depend on ontology for meaning of items they mention. Archetypes provide for a lot of optionality, whereas this is not part of ontology (except ontologies modelling decision making processes themselves perhaps). - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
I agree with Karsten - there is a basic principle here (and in openEHR). The physician must be able to write what they want. Now...if they want to write a sentence with the words possible Dengue Fever infection then the software may be able to code Dengue Fever using Snomed or some other ontology; the result would be narrative with key coded terms. Peter Elkin's group at Mayo have shown how they do the reverse (what Gerard Freriks mentioned also) - a post hoc coding structuring of the text. Philippe Ameline's Odyssee product on the other hand uses a structured input system for recording endoscopy investigations, and the specialists are happy with it. But - he has a nice, detailed lexicon of terms to draw on, and it seems it has everything they want; when it doesn't, they just write a free text field. Even so, the principle i mention above seems to be preserved. So - how structured the input I suspect depends more on the type of medicine or specialty than some overarching rule. Hi, We sold our first Endoscopic report generator in 1987 - so we now have some feed back ;o) You have to understand that a report from a specialist is primarily intended to have the others health professionals know something. The quality factors here are : - completness : you should not forget to mention something - a structured interface has proven to be a plus compared with free dictation - process oriented : don't be elusive, call a cat a cat (it is a common reflex with free dictation to be not as accurate as it should be) - terms repeatability : the same aspect should be described in the same way - it is a place where the process of reducing the term set is a plus ; elsewhere the same aspect will be described in very different ways - even in the same team. - defined corpus : if you know the corpus, you also know what could have been said, and has not been said (not easy however - but this concept is certainly in the Archetypes) - ready now : the report should leave with the patient It might be a french drawback, but very, very few free text reports I have seen are ok from this point of view. I am myself convinced that free text analysis is a dead way, since you usually can't structure afterward what has not been structured immediatly. To give an example, some time ago, I was installing my system in an hospital ; an endoscopist just ended an exam, and had hand-written his result on a paper. We took it as a learning model to make the report with the generator. Roughly, it was written something as : 20 cm from the teeth, there is a wide erythematous area Let's process it : 20 cm from the teeth, with this kind of endoscop, we are in the oesophagus (not so easy, even for a human being... you must know the size of anatomical parts) The wide erythematous area is our lesion. It is all right, we have the lesion, and we know where it is ; but unfortunately, in the report generator, you have to choose between oesophagitis or simple mucosa aspect. So the question is is it an oesophagitis ? (well, it is an interesting question anyway when it will be time to give some drugs to the patient - the process oriented part of the report). And we had to ask the question to the guy who saw the lesion, since even the network of 5 human brains in the room could not guess it. I perfectly understand Karsten's point about fuziness. But once again, you must behave differently in a local/personnal system and in a collective process oriented system. You can publish there is still fuzziness somewhere, you can't publish fuzzy datas. Best regards, Philippe - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
Philippe, [...] you can't publish fuzzy datas. Yes one can. But one needs to precisely indicate their degree of fuzziness. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
Hi, As a GP with 20 years of experience in the Netherlands I learned that free text plus a not to complicated set of codes (ICPC) is sufficient for daily practice. We could generate automatic advice for medication based on complaints or diagnosis. ICPC contains roughly 2000 complaints, diagnoses and procedures. It will cover 80% of every thing a GP will encounter during the day. The provision of medicine is an art. The registration of all medical (and other) relevant facts and findings is retelling the story of the pati?nt. It is a narritive process. Have we ever seen a piece of literature completely written in complex codes? The study of Archetypes (see the OpenEHR website) will reveal that Archetypes plus free text plus codes will enable future physicians a lot of flexibility and expressive power. Much of the flexibility will depend on the ontology (medical knowledge and knwoledge of the world) behind the scenes. And bye the way. In the RD facility where I work we have a very powerfull tool for analysis of free text. Recently a lot of progress has been been at this. If the free text is 'enriched' with Archetypes this process of meaningfull data extraction will become much more easy. Gerard Freriks -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 Leiden The Netherlands +31 71 5181388 +31 654 792800 -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 From: Christopher Feahr chris at optiserv.com Organization: Optiserv Consulting Reply-To: Christopher Feahr chris at optiserv.com Date: Mon, 11 Aug 2003 07:32:52 -0700 To: Thomas Clark lakewood at copper.net Cc: Karsten Hilbert Karsten.Hilbert at gmx.net, openehr-technical at openehr.org Subject: Re: HISTORY DATA SET IN EPR Presently, each doctor and EMR software vendor is cooking up his own shorthand-language, and I'm suggesting that information should be reduced as much as possible to a standard set of codes. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
Hi, From last Picnic meeting in Paris, I mainly remember the confucius sentence on a presentation from Ireland : May you live interesting times. In the field of health information systems we certainly are living interesting time since we are those who will allow the move from Office keeping + databases to Patient Health Project. It means several HUGE changes, the main one is to distinguish between the local and/or personnal datas (situated in the health professional referential) from the continuity of care/health management datas (situated in the patient referential). The management of these 2 referentials means that you now have to manage differently (and handle with different tools) the datas with a time duration (they may get changed by someone else) and the datas of the instantaneous picture kind (it is what YOU noticed and reported at a given time). Lots of work remains ;o) Philippe AMELINE - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
I shall like to have more insight on how you have handled the issue. - Original Message - From: aniket Joshi anya_jo...@yahoo.com To: Thomas Clark lakewood at copper.net; Christopher Feahr chris at optiserv.com Cc: Karsten Hilbert Karsten.Hilbert at gmx.net; openehr-technical at openehr.org Sent: Monday, August 11, 2003 3:05 AM Subject: Re: HISTORY DATA SET IN EPR Dear All, In HISTORY DATA SET,if seen carefully,the data can be divided into two broad categories. a.The format. b.The descriptive data. The history format is more or less structured all over the world. The descriptive part is mainly in the History of Present Illness in which the Onset Duration and Progess(ODP) of each complaint is given in chronological order. The rest of the history format is not so descriptive and can be easily strucutured. In History of present illness if we assign a indentifier for each Chief compliant which is going to be described later in terms of ONSET DURATION PROGESS, we have already been able to structure a large part of history. Again a sypmtom list classified according to the systems can be provided. I have already incorporated this in the system which I have designed. Plus if we incorporate CPGs in the system we will be to provide a smaller but comprehensive symptom set. I leave the thread OPEN for discussion. DR ANIKET JOSHI __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.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
HISTORY DATA SET IN EPR
Hi, Reply in text. - Original Message - From: Karsten Hilbert karsten.hilb...@gmx.net To: openehr-technical at openehr.org Sent: Sunday, August 10, 2003 4:55 AM Subject: Re: HISTORY DATA SET IN EPR The concept of modelling the symptoms in a genric manner manner and have these called up whenever there is a need to record the details. I am not sure I fully understand what you want to say. What do you mean by modelling the symptoms ? You must have seen my mail which addresses of what I had in mind. Any comments??? Symptoms could be recorded as free text. This approach you describe as inadequate. It *is* inadequate if the goal is to process the input computationally. The solution is not, however, to use (inadequate) coding systems as is discussed in Slee, Slee, Schmidt, The Endangered Medical Record (excerpt available from http://www.tringa.com ). The context on which I have used the word inadequate is from the computational angle and also from the clinical compliance angle. In developing countries the clinician is pressured and the recording may be inadequate if it is left to free text. Doctors are not good at recording in free text on a systems (not to be read as something against clinician but is a general comment). Another approach would be to really *model* symptoms based on openEHR archetypes. This promises to offer some degree of computationality yet preserve the free text. Others in this list have more experience with that. The clinical algoritms that a clinician uses can be defined and the data set to meet the needs of these algoritms can be built in. Free text can also be present ot take care of the exceptions not considered in the algoritms. Data-mining, however, shouldn't be the aim of an EMR. It should be focussed on patient care. Data-mining will occur with aggregates of extracts *from* EMRs. Data is collected in an EMR and should be amenable to analysis form the point of view of Epidiomologicla analysis. Here the data is depersonalized and should be used. Currently the data is being used in clinical studies is from the paper record why restrict this critical function when it comes to an EMR? Karsten Hilbert, MD -- 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
HISTORY DATA SET IN EPR
Hi, Reply in text, - Original Message - From: Christopher Feahr ch...@optiserv.com To: Karsten Hilbert Karsten.Hilbert at gmx.net; openehr-technical at openehr.org Sent: Sunday, August 10, 2003 10:08 AM Subject: Re: HISTORY DATA SET IN EPR Karsten, I agree that the medical concepts shhould be carefully modeled first... then extract the necessary terminologies... then build the necessary code lists. I have not wanted to pay the $500 licence fee to look at SNOMED CT, as it will be free for all in 3 months... so I apologize for my ignorance there... but my understanding was the the SNOMED people had already modeled complaints, signs/symproms, diagnosis, treatment plans, prognosis, outcomes... the whole 9 yards. If that is true (seems too good to be true!) then it may only require a (simple??) mapping of SNOMED CT to a collection of EHR Archetypes. A symptom is not for example dyspnoea it has a number of clinical add on parameters that a clinician records beyond onset, duration course. This is not addressed ( my belief stand to be corrected ) in the snomed CT. My presumption, given the magnitude of the task of producing such a granular model... not to mention, the massive physician input and necessary vetting, for which there is no efficient mechanism...I am assuming that the SNOMED modeling effort is still at a very high level.of abstraction. Can anyone fill ne in on the present state of this work? SNOMED CT claims to already have 350,000 coded medical concepts, but since it was constructed by a group of pathologists, I am assuming that other care domains are not represented in great detail. You are right in your assumption it is mainly pathology focussed and not with a clinicans perspective. Regards, -Chris 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: Karsten Hilbert Karsten.Hilbert at gmx.net To: openehr-technical at openehr.org Sent: Sunday, August 10, 2003 4:55 AM Subject: Re: HISTORY DATA SET IN EPR The concept of modelling the symptoms in a genric manner manner and have these called up whenever there is a need to record the details. I am not sure I fully understand what you want to say. What do you mean by modelling the symptoms ? Symptoms could be recorded as free text. This approach you describe as inadequate. It *is* inadequate if the goal is to process the input computationally. The solution is not, however, to use (inadequate) coding systems as is discussed in Slee, Slee, Schmidt, The Endangered Medical Record (excerpt available from http://www.tringa.com ). Another approach would be to really *model* symptoms based on openEHR archetypes. This promises to offer some degree of computationality yet preserve the free text. Others in this list have more experience with that. Data-mining, however, shouldn't be the aim of an EMR. It should be focussed on patient care. Data-mining will occur with aggregates of extracts *from* EMRs. Karsten Hilbert, MD -- 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
Well... yes... I'm dreaming a little... I'll grant you that. Nah, what I mean is ... If we could point today (in the US) to the system that I am imagining... one in which payers could reach out as needed and query EHR systems for data to support adjudication, ... that this is nothing I am going to support in any way. The payor has no business reading my EHR at will. Although ... At the end of the day, each payer wants a virtually unique data set to support its claims. I think we should point them to the EHR-landfill and hand them a shovel... I have patients to see! ... I do acknowledge this reason for wishing we could just do so. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
Again... please do not misunderstand my recommendation to give payers direct access to EHR information to be a recommendation of *unrestricted* access. I'm not sure exactly how we will control it, but I would argue for payers having access to no more information than they have access to today. Here's the dilemma I see for doctors. In the US, a patient essentially gives the payer a blank check to ask his doctor for any health data required to support any claim... which the doctor must spend human and system resources to send to the payer. Because doctors like to get paid, they usually do not question payers or make them explain WHY any particular health information is needed. Providers, as the principal custodian on behalf of their patients, probably SHOULD force payers to justify such requests, but there is no mechanism, venue, or guidelines for that... so we don't do it. We also know that if push comes to shove, the payer in most cases can send an audit team to your office and rifle through every record you own. In general, making it easier for the payer to get the data by its own effort removes cost from provider AND payer operations because much of the claim process is eliminated. So that's a good thing for the doctor. Depending on the security/access policies, however, this might also allow the payer to more easily look at MORE information... something most patients and provider would consider a bad thing. This privacy/fear issue will have to be resolved eventually. Doctors and patients must help us to develop a formal model of security and access requirements for health records (as Dr. Cohen has described in his paper, mentioned last week: http://www.soi.city.ac.uk/~bernie/hsp.pdf) and that model should be tested against real-life scenarios to be sure that we are really willing to pay for and live with the level of security that doctors and patients [think they] want. Obviously, the issue of what payers REALLY need to know or are implicitly allowed to ask for (or dig up on their own) will be critical to this discussion. The discussion, by the way, should take place in an accredited standards body, rather than in Congress or an administrative rule-making authority like DHHS. All the law should have to say is respect the standard... the chapter and verse of how to do that should be developed and maintained by a consensus-driven SDO, in which payers and providers have equal voice. 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: Karsten Hilbert karsten.hilb...@gmx.net To: openehr-technical at openehr.org Sent: Tuesday, August 12, 2003 8:17 AM Subject: Re: HISTORY DATA SET IN EPR Well... yes... I'm dreaming a little... I'll grant you that. Nah, what I mean is ... If we could point today (in the US) to the system that I am imagining... one in which payers could reach out as needed and query EHR systems for data to support adjudication, ... that this is nothing I am going to support in any way. The payor has no business reading my EHR at will. Although ... At the end of the day, each payer wants a virtually unique data set to support its claims. I think we should point them to the EHR-landfill and hand them a shovel... I have patients to see! ... I do acknowledge this reason for wishing we could just do so. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
Thomas, I'm curious to know if your comments are based on a review of SNOMED CT or of ontology/terminology systems, in general? As you probably know, SNOMED was designed expressly to support clinical information needs. I do not have the impression that it was an academic or theoretical exercise. In fact, the US govt. just paid $35 Million for a perpetual license to the SNOMED Clinical Terms database, which it plans to offer free, worldwide starting in Jan, 04. SNOMED is being positioned as a major piece in the healthcare part of our ambitious e-Gov initiative. Operational cost reduction is the principal driver for e-Gov and the Consolidated Health Informatics component. Unfortunately, I have not been able to get a look at the database of terms yet because they are still working out the terms of the deal with DHHS. 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: Thomas Beale tho...@deepthought.com.au To: openehr-technical at openehr.org Sent: Tuesday, August 12, 2003 6:20 PM Subject: Re: HISTORY DATA SET IN EPR Christopher Feahr wrote: . but my understanding was the the SNOMED people had already modeled complaints, signs/symproms, diagnosis, treatment plans, prognosis, outcomes... the whole 9 yards. If that is true (seems too good to be true!) then it may only require a (simple??) mapping of SNOMED CT to a collection of EHR Archetypes. this is a bit question. The key thing to remember is that: - terminologies/ontologies (attempt to) model reality, e.g. their model of symptoms related to tropical parasite infections will/could be a detailed semantic net of nodes describing in great detail the symptoms at every point of e.g. plasmodium lifecycle during malaria infection - textbook stuff in other words. - but the doctor in a hospital is interested in recording observations about the patient, ordering tests, making decisions, following progres and so on. The information he/she wants to record and read is to do with the observation and care process, not with the scientific description of the life history of plasmodium. This is the area of archetypes and templates - providing highly configurable models of this information and processes, during the clinical care path. - terminologies are necessary as a knowledge base during the use of archeytpes - they provide names of things of course, but more importantly, semantic networks support inferencing. So one can imagine a doctor recording symptoms and signs in their info system, and thinking that so far, it could be malaria or some other fever-inducing infection... if they have detailed enough observations, it may be that the ontology can provide some guesses as to what the patient has. So - we have two kinds of models here: terminology/ontology is about modelling the real world, and facts we have learned and appear to be dependable; archetypes and templates are about modelling patterns of information *in use*, and they depend on ontology for meaning of items they mention. Archetypes provide for a lot of optionality, whereas this is not part of ontology (except ontologies modelling decision making processes themselves perhaps). - 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
HISTORY DATA SET IN EPR
Dear All, In HISTORY DATA SET,if seen carefully,the data can be divided into two broad categories. a.The format. b.The descriptive data. The history format is more or less structured all over the world. The descriptive part is mainly in the History of Present Illness in which the Onset Duration and Progess(ODP) of each complaint is given in chronological order. The rest of the history format is not so descriptive and can be easily strucutured. In History of present illness if we assign a indentifier for each Chief compliant which is going to be described later in terms of ONSET DURATION PROGESS, we have already been able to structure a large part of history. Again a sypmtom list classified according to the systems can be provided. I have already incorporated this in the system which I have designed. Plus if we incorporate CPGs in the system we will be to provide a smaller but comprehensive symptom set. I leave the thread OPEN for discussion. DR ANIKET JOSHI __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
Great comments... It's always good to see this whole mess from the point of view of the most concerned eyeballs: those of patients. Often, the disconnect that patients perceive between their reported problems and prescribed solutions, is due to them having been intentionally insulated from a reasoning process that most would not understand anyway. Personally, I prefer to gauge each patient's ability to understand my medical reasoning... by feeding a little of it to them and seeing what sort of response it elicits. There are many reasons why patients often WANT to remain insulated from the medical decision making... but the ones who want/demand to be included have a right to be. I believe that the patient view of one's medical record should include a patient-understandable view of not just what had been ordered for them... i.e., done to them... but of the reasoning that led to it. How much to show them, of course, is the $64K question. Doctors are nervous about this whole subject area... as are their malpractice insurers. But we cannot ignore the steadily increasing level of sophistication within the patient community... of patient access through the Internet to best practice guidelines. Some patients arrive nowadays, armed with pretty darned good differential diagnosis lists to accompany their well-articulated complaints and symptoms. Some even have very good understandings of each possible diagnosis and the state of the art treatment protocols. For this reason, the Institute of Medicine content recommendations (reflected in the present version 1.0 of the HL7 EHR ballot) includes 4 main care settings: in-patient, out-patient, nursing home, and personal health record. The last is the patient's view of the record... presumably with certain write privileges for address, contact information, etc., and in the reporting of symptoms and complaints. This is bold new territory for us... but I think that we will all win with greater and more informed participation from the patients who desire it. Without a robust patient-view of the EHR to point them to, however, these type patients are likely to drive doctors nuts with questions. Hence, the doctor's inclination to keep them well-insulated from his medical thinking. Regards, -Chris 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: Thomas Clark lakew...@copper.net To: Christopher Feahr chris at optiserv.com Cc: Karsten Hilbert Karsten.Hilbert at gmx.net; openehr-technical at openehr.org Sent: Monday, August 11, 2003 10:25 AM Subject: Re: HISTORY DATA SET IN EPR Hi Christopher, Good response. Comments in text. -ThomasClark Christopher Feahr wrote: Thomas, When I said I thought the SNOMED people had already modeled complaints, signs/symptoms, diagnosis, treatment plans prognosis, outcomes... the whole 9 yards I was using the term model in the sense of a representation of those individual concepts... for example, to represent in a computer-understandable way, the fact that Mrs. Jones is complaining that her neck hurts. I was not suggesting, that we could/should try to model the relationship between her coded symptoms and her eventual treatment plan. 'model' conveys different information to different communities. A Patient Process Diagram would be interesting whereby current and historical Patient information is combined with Healthcare Industry available information and the interaction between Patient and Provider and compared with the results of the 'visit' and subsequent 'results' to determine possible and actual 'outcomes'. To me 'model' infers a static process whereby known data sets are processed to obtain known results. A Process Diagram, a component in a larger dynamic structure, should what information is available, how it is process and what the 'outcomes' are. This in turn should be compared with the 'outcomes' that actually occur, the measurement occurring at a later stage (from Control Systems). The doctor in your example must still record the fact of her neck pain and the fact of his Rx order for Prozac. Standard practice guidelines also suggest that he record the medical reasoning he used to support his [apparent] diagnosis of depression. If I were handling the case, I would probably also record the fact that she requested pain medication and my reasoning for not prescribing it. Somehow the Patient's input does not get integrated with the Provider-related information which is why many issues arise between Patients and Providers. Looked at from the Patient's perspective, the Healthcare Industry is like a machine with a microphone that one can talk into and perhaps get a response in the form of a list of drug prescriptions and advice (take more aspirin). Consistency can be missing, presuming an on-going condition(s), and cause the Patient
HISTORY DATA SET IN EPR
Hi Christopher, Christopher Feahr wrote: For this reason, the Institute of Medicine content recommendations (reflected in the present version 1.0 of the HL7 EHR ballot) includes 4 main care settings: in-patient, out-patient, nursing home, and personal health record. The last is the patient's view of the record... I think I'm a little lost here. I've read HIPPA, the regs and the preample, and my understanding is that the patient now has a legal right to copies of his medical record and a right to contest the contents of that record. Are you saying that the IOM / HL7 are taking the position that the physician can decide to withhold portions of that record? Where can I find out more about this? Best regards, Bill - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
RE: Are you saying that the IOM / HL7 are taking the position that the physician can decide to withhold portions of that record? No... not at all! You can read the HL7 ballot package and join the ballot pool at www.hl7.org/ehr (reduced fee for non-HL7 members of $100 to join the pool... reading/downloading the documents is free.) IOM and HL7 were essentially asked (this Spring) by CMS/HHS to collaborate on an EHR standard. IOM released it's recommendations a couple weeks ago regarding content requirements for the EHR. 4 principal record-views were contemplated by IOM and included as care setting profiles in the HL7 ballot. One of these would be a patient-view of his own EHR, with the ability to change/add certain data. This does not alter the HIPAA mandate in any way... although direct patient access to an up-to-date EHR would probably cut down on requests to providers for paper copies of health records. The issue of who could/should/would have read/write access to ANY EHR is still very much a matter of discussion. There is nothing about rights of access or stewardship or any other security issues in the present EHR ballot. 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: Bill Walton bill.wal...@jstats.com To: openehr-technical at openehr.org Sent: Monday, August 11, 2003 1:53 PM Subject: Re: HISTORY DATA SET IN EPR Hi Christopher, Christopher Feahr wrote: For this reason, the Institute of Medicine content recommendations (reflected in the present version 1.0 of the HL7 EHR ballot) includes 4 main care settings: in-patient, out-patient, nursing home, and personal health record. The last is the patient's view of the record... I think I'm a little lost here. I've read HIPPA, the regs and the preample, and my understanding is that the patient now has a legal right to copies of his medical record and a right to contest the contents of that record. Are you saying that the IOM / HL7 are taking the position that the physician can decide to withhold portions of that record? Where can I find out more about this? Best regards, 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 DATA SET IN EPR
Hi Karsten, please see comments in-line. thanks. 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: Karsten Hilbert karsten.hilb...@gmx.net To: openehr-technical at openehr.org Sent: Monday, August 11, 2003 3:53 PM Subject: Re: HISTORY DATA SET IN EPR form. I think this is the promise of SNOMED CT. Doctors will likely support such a system if it allows them to easily put MORE information in the record than they do today... Does *more* information also mean *more information that's accurate* ? Likely not if data providers are significantly limited by a restricted set of codes. Reasoning for this in Slee, Slee, Schmid The endangered Medical Record. My proposal is to structure what is possible to structure... but to do it with a standard. Any health information that is still too fuzzy for the chosen structure will have to be written freehand, as we do now. Eventually, they should reprogram their adjudication systems to consume the doctor's coded information, as it exists natively in the EHR. Not only will the content be richer and more potentially useful to the payer, but instead of sending a traditional claim, the doctor could simply send the payer a standard invoice for services, with a pointer to the EHR data... if the payer cared to look at it. While technically enticing, practically, uhm, no, no way (lest I misunderstand your intent). Well... yes... I'm dreaming a little... I'll grant you that. But we should be attempting to increase/improve the structure of our records and data anyway... in order to improve care. Even if this still has to be mapped to the payer's old 5-character dumb codes, the claim-coding process will be potentially more automatic and better supported by the record in the event of payer audit. If we could point today (in the US) to the system that I am imagining... one in which payers could reach out as needed and query EHR systems for data to support adjudication, then payers would be hard-pressed to justify the enormous provider-expense of serving this information to them on silver claim-platters. By the end of 2003 I suspect that we will have more payer-specific variants of the HIPAA 837 transaction than we ever had of the NSF and UB92 combined. At the end of the day, each payer wants a virtually unique data set to support its claims. I think we should point them to the EHR-landfill and hand them a shovel... I have patients to see! but doctors should be able to agree on just the right degree of precision to support the medical job... What, doctors agreeing on something ? Yes, I'm being cynical :-) I'll admit... doctors do not make this easy! But doctors have agreed in the sense that they have not objected to standards of care concepts and evidence based clinical practice guidelines. I believe that the acceptable minimum level of precision is documentable from existing literature. Practitioners can always add non-structured notes and information as necessary to beef up the precision of any structured/coded record information. I' assuming that whatever precision level makes the doctors happy will also be sufficient for payers and governments. That I tend to agree to. and I'm suggesting that information should be reduced as much as possible to a standard set of codes. If that means to reduce what I can put in my clinical notes then No, thanks. I use the fuzziness of German when writing progress notes to myself in order to capture the degree of fuzziness of the specific ailment at hand and augment that with commonly used scales (GCS, APGAR, Janda, ...) to map my notes to more standard values when writing referral letters etc being sent to colleagues. Of course I am not perfect in this and could make use of a tool that facilitates my correctly applying standard scales. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
The concept of modelling the symptoms in a genric manner manner and have these called up whenever there is a need to record the details. I am not sure I fully understand what you want to say. What do you mean by modelling the symptoms ? Symptoms could be recorded as free text. This approach you describe as inadequate. It *is* inadequate if the goal is to process the input computationally. The solution is not, however, to use (inadequate) coding systems as is discussed in Slee, Slee, Schmidt, The Endangered Medical Record (excerpt available from http://www.tringa.com ). Another approach would be to really *model* symptoms based on openEHR archetypes. This promises to offer some degree of computationality yet preserve the free text. Others in this list have more experience with that. Data-mining, however, shouldn't be the aim of an EMR. It should be focussed on patient care. Data-mining will occur with aggregates of extracts *from* EMRs. Karsten Hilbert, MD -- 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
HISTORY DATA SET IN EPR
Karsten, I agree that the medical concepts shhould be carefully modeled first... then extract the necessary terminologies... then build the necessary code lists. I have not wanted to pay the $500 licence fee to look at SNOMED CT, as it will be free for all in 3 months... so I apologize for my ignorance there... but my understanding was the the SNOMED people had already modeled complaints, signs/symproms, diagnosis, treatment plans, prognosis, outcomes... the whole 9 yards. If that is true (seems too good to be true!) then it may only require a (simple??) mapping of SNOMED CT to a collection of EHR Archetypes. My presumption, given the magnitude of the task of producing such a granular model... not to mention, the massive physician input and necessary vetting, for which there is no efficient mechanism...I am assuming that the SNOMED modeling effort is still at a very high level.of abstraction. Can anyone fill ne in on the present state of this work? SNOMED CT claims to already have 350,000 coded medical concepts, but since it was constructed by a group of pathologists, I am assuming that other care domains are not represented in great detail. Regards, -Chris 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: Karsten Hilbert karsten.hilb...@gmx.net To: openehr-technical at openehr.org Sent: Sunday, August 10, 2003 4:55 AM Subject: Re: HISTORY DATA SET IN EPR The concept of modelling the symptoms in a genric manner manner and have these called up whenever there is a need to record the details. I am not sure I fully understand what you want to say. What do you mean by modelling the symptoms ? Symptoms could be recorded as free text. This approach you describe as inadequate. It *is* inadequate if the goal is to process the input computationally. The solution is not, however, to use (inadequate) coding systems as is discussed in Slee, Slee, Schmidt, The Endangered Medical Record (excerpt available from http://www.tringa.com ). Another approach would be to really *model* symptoms based on openEHR archetypes. This promises to offer some degree of computationality yet preserve the free text. Others in this list have more experience with that. Data-mining, however, shouldn't be the aim of an EMR. It should be focussed on patient care. Data-mining will occur with aggregates of extracts *from* EMRs. Karsten Hilbert, MD -- 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
HISTORY DATA SET IN EPR
I have been following the issues with interest. There is an area on which I would like to have the views of all who have had to handle the electronic management Of the History. The concept of modelling the symptoms in a genric manner manner and have these called up whenever there is a need to record the details. How is possible to capture the the chief complaints and the details relating to the same in a manner that the information is available for datamining and analysis at a later point of time. I would like to have the thaughts of all as to can we not model the symptoms in a manner so as to make it a global element and then have the question set called up for recording the information pertaining to that element(Symptoms). An argument that may be advanced is that the symptoms can not be managed in a preprared template. I do believe that the present manner of capture of history in the Free text form is not adequate and cannot be effectively manipulated. If the symptoms are modelled they will be able to give the clinicians a protocol that may allow the capture of the symptoms in an appropriate manner to enable the clinicians to capture the information relating to each symptoms. The thaughts of all are welcome as to how the issue of capture of the details relating to Symptoms in the history data set need to be addressed. Dr B S Grewal Domain Expert PGIMER - Original Message - From: Sam Heard sam.he...@bigpond.com To: Christopher Feahr chris at optiserv.com; lakewood at copper.net; openehr-technical at openehr.org Sent: Thursday, August 07, 2003 1:06 PM Subject: RE: 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
