Maybe I can be of some help since I have been working on structured report generators for more than 15 years, and I am currently working hard on Archetypes.
To get short, I shall give you the major keypoints we based our strategy on :
1) A report generating system must be structured :
3 reasons for that :
- speed, because the report must be ready within 2 minutes, and you must have the screens "in mind" to be fast
- guidance, not to forget to describe something, you must travel through something like a check list
- repeatability, you must try to have the same aspect being described in the same way
2) The life of a report BEGINS when he leaves the endoscopic lab.
Too often, people don't realize that their output is someone else input. Here comes the Archetypes : you get the result, and you can gain access to its reference model.
I am probably too short in my explanations... ask for more.
Philippe
Guys, I'm lurking here reading all kinds of interesting things, but now I'd like to hear your opinions on the following (please forgive me if I restart an old thread, I haven't thoroughly searched the archives) (and please forgive my nond-medical background):Archetypes are great to define very concise medical concepts like labtests and bloodpressure, but how to handle a description of a stomach ulcer done during an endoscopic examination? Should all this be structured beforehand? Say you include a data structure for a description of the tissue around the ulcer, would you require this to be optional or obligatory even if it's not always necessary to be filled in. And how would you store the recordings of this ulcer? In an anatomic hierarchy? Or in the context of the endoscopic examination? How to model an endoscopic examination, since it can not only be done for ulcers but also for numerous other purposes? Archetypes are said to enhance data exchange, but how necessary is this? I could think of data exchange between specialists and GPs, but GPs would probably have no archetypes for endoscopic examination and their "ulcer" archetype would be very different. How to handle this? You could send over the archetypes as well, but what to do then? Storing the specialist archetypes would not make sense since the GP doesn't need them for his day-to-day work and if he did store them, how would the specialist "ulcer" archetype interfere with his own archetype? Furthermore: I'd use archetypes as a template for objects resulting in objects that hold all necessary context information. In my opinion the archetype is then superfluous since all context related information is also available in the object. Another point: archetypes contain validation rules. But where does "data validation" end and "decision support" begin? It's obvious to validate "diastolic" vs. "systolic" values in a bloodpressure (assuming you store both values in one concept), but what if you want to use the body mass index to validate weight and/or length? How do you refer to information that is constructed with another archetype? Please don't think I'm against archetypes, but the idea is still not clear to me. Bye, Helma van der Linden
