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 to wonder about progress. This may indicate that someone has it wrong, e.g., perhaps the course of treatment is partially or completely ineffective. Perhaps the Provider has seen so many cases of flu today you must have it. There is no feedback in too many cases. This covers Patients and Providers. If an 'error', 'mistake', 'omission' occurs the system is likely to perpetuate it indefinitely. Records systems are very good at doing this. I would suggest looking at declaring suspect information precisely that: suspect. >Doctors DO develop "shorthand" for documenting even complex patient >comments, questions, complaints, etc., if they come up repeatedly. >There should always be a comment field for the weird stuff that is not >EXACTLY like any of the coded concepts. But it would be extremely >useful to have 80% of that "charted" information in a structured/coded >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... with the added bonus that everyone >else (AND their computers) can read and understand at least 80% it! > > 'Shorthand' notational systems are basically productivity tools and have great value. SNOMED CT will be a great productivity tool for Providers. It should not 'bury' other methods. >When I said that we should model the concepts, I was also assuming that >we would model the processes that use the concept/information... so that >we can be sure that we have structured the information in a way that >supports its use. CPT-4 is a good example of a concept-coding >methodology that was invented primarily to support insurance claim >adjudication... not so much, the practice of medicine. 30+ years ago, I >key payers, including Medicare approached the AMA (present owner of the >CPT code set) and requested set of codes for representing medical >procedures on claims... and this is what they came up with. Today, we >can conceive of representational models, in which the same basic facts >of the case are represented in ways that are much more useful in >medical decision support and research. If payers preferred their 30 yrs >old code set, we should only need to explain our new concept model to >them and let them tell us how it maps to their old CPT codeset. >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. >One brief comment on "precision": I'm not suggesting that greater >precision is invariably better or always worth the extra effort to carry >it along in our record systems. It may become controversial in a few >cases, but doctors should be able to agree on just the right degree of >precision to support the medical job... with the informaticists pushing >them toward the minimum level of granularity and precision, so that the >system is not overly complex. I' assuming that whatever precision level >makes the doctors happy will also be sufficient for payers and >governments. > > Variable precision is something you would not want to support in a malpractice case. >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. > > Standardization is good. >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" <lakewood at copper.net> >To: "Christopher Feahr" <chris at optiserv.com> >Cc: "Karsten Hilbert" <Karsten.Hilbert at gmx.net>; ><openehr-technical at openehr.org> >Sent: Sunday, August 10, 2003 12:39 PM >Subject: Re: HISTORY DATA SET IN EPR > > > > >>Christopher Feahr wrote: >> >> >> >>>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.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 >>> >>> >>> >>> >>> >>Hi All, >> >>Precision and accuracy are two attributes that do not seem to fit the >>detection and reporting of symptoms. It also seems that neither are >>appropriate since healthcare knowledge is in a continual state of >>evolution. >> >>SARS is a recent example; many other exist. Many Patients complain >>about healthcare problems that are ignored or result in a diagnosis >>that makes literally no sense. I know of a Patient who has a neck >>operation, went to the original Physician complaining about severe >>problems and requesting pain-killer medication for those times when >>the pain was especially severe. >> >>The Physician wrote a prescription for Prozac but no pain killer. One >>can only presume that the symptoms suggested that the Patient should >>at least feel good about being in so more pain. >> >>Credibility will be really hard to establish in cases such as this. >>Moreover, >>the diagnosis would have to be rational and logical and based upon >>credible, proven history, the Patient's and the community. I think I >> >> >have > > >>just eliminated the human Provider from the equation. >> >>Modeling is a great effort but fails quickly when it incorporates >> >> >humans. > > >>I have no objections to humans, I object to incorporating humans in a >>procedure that involves accuracy and precision. They are better at >>receiving dissimilar information, evaluating it, developing >> >> >alternatives, > > >>making decisions and following a course of action as long as it >> >> >appears > > >>to be the right thing to do. >> >>Automatic, knowledge-based processes and procedures could serve the >>Patient and Provider well. Modelling the Patient-Provider is very >> >> >difficult. > > >>-Thomas Clark >> >> >>- >>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
