The power of this approach is hard to appreciate > until you're in a > situation where lots of people have lots of things > they want to > characterize in a system. It allows non-developers > to own and > augment their own notions of what data matters to > them, without > altering the underlying database model.
This is important for clinicians in different specialities with various interests in the specifics. No FOSS EMR I tried/used, except OIO, allow this to be done easily by users. The Concept Dictionary approach seems to be similar to the Archetypes approach of OpenEHR, which goes a further step. Nandalal --- Paul <[EMAIL PROTECTED]> wrote: > Hi Karsten, > > --- In [email protected], Karsten Hilbert > > > Agree. I'm reading this thread with interest. I > have been > > interested in the Concept Dictionary approach ever > since I > > learned about OpenMRS a year ago or so. There's a > strong > > camp opposed to EAV-only schemata. I have a > nagging feeling, > > however, that having a Concept Dictionary approach > can be of > > great value where it fits (as a poor-mans export > system, > > perhaps ?). I have read most of the OpenMRS docs > but haven't > > yet been struck by lightning going "Ah yes ! > That's how I'd > > want to use that in GNUmed !!". As I said, I do > think I am > > missing out on something very elegant and would > like to be > > educated on that. It's the same feeling I have > that once I > > eventually get around to implementing forms (as in > paper) > > support I will turn to studying NetEpi on that. > > Well, Burke and I started down the pathway of a > concept dictionary > based EAV model not due to any divine wisdom on our > part, but > because of the education we received from our > mentor, Clem McDonald, > who is the father of the RMRS, one of the oldest > (40+ years) and > largest clinical information systems I'm aware of. > We thought, if > it's not broke, let's not try to fix it. Of course, > we've > modernized and extended out some of the > functionalities from the > RMRS model, but the basic ideas have remained > intact. > > The most important technical "a-ha" for me was once > I got the point > that the dictionary defines both the questions and > the answers > within an observation. My favorite example is a > simple test in any > urinalysis, the urine color. We create a concept > for the > question "urine color" and then define all of the > appropriate meta- > data that drives that question. Like, what is the > datatype of the > concept, what are it's synonyms, what is it's > description? In the > case of urine color, you might set it's datatype as > "coded" so that > you can make separate concepts for each answer. > (ie, yellow, straw > colored, clear, etc.) The magic of this dictionary > is that any > concept can be used throughout the system in a lot > of ways. Want to > use "urine color" as an answer to another question? > No problem. > Want to use yellow to describe's someone skin color? > No problem as > well. > > The power of this approach is hard to appreciate > until you're in a > situation where lots of people have lots of things > they want to > characterize in a system. It allows non-developers > to own and > augment their own notions of what data matters to > them, without > altering the underlying database model. The RMRS > has over 30k of > these concepts. If you'd like me to set you up with > some examples > of what this looks like in a live system, just let > me know. I'll > point you to a demo that you can hack around with. > > Hope this is helpful, > -Paul > > ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091
