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. 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.
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! 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. 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. 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: 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
