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
