Gentlemen, Thank you all for trying to answer my questions. Alas, they only raise more questions. :-)
> Obviously, it is not possible or desirable to fully pre-structure a > description of a patient. That is basically the task that must be True. > accomplished by the medical records system. I'm under the impression that archetypes are a way to get structured data into a medical records system. How do I match this to your comments? > On the other hand, it is helpful to structure the > information - having > some meta-data helps someone else understand what you are trying to > communicate. You see examples of metadata in headings, > sub-headings, etc - > archetypes and OIO forms are just more complicated versions > of the same. Right. So in a way archetypes (and OIO forms) can be considered as the paper form with blanks to fill in. > variable number and kinds of structured-data-elements. For example, a Clear. > patient would be described by any number of OIO forms that have been > completed by the patient's physicians. > Does this make sense? Yep. But wouldn't you require forms designed beforehand? Or can archetypes/OIO forms/other approaches be "designed" on the fly? Using the paper analogy: I can use specialised forms with blanks to fill in to get very structured data. I can also use more generic forms which can serve multiple purposes, but the data will be less structured (i.e. on a less detailed level). And I can use a blank paper and make up the form and fill in the blanks as I go along. But this one is even less structured. If I convert these papers into an electronic form, software will probably be very capable of correctly interpreting the values, because the structure is very strict. Clever software will probably do a good job with the more generic forms but it cannot handle the structured blank paper unless the structure is written in a specialised way. Now for the archetypes: The predefined archetypes are the specialised forms. I can "attach" screen representations for both entering and displaying the data and all this is leads to highly structured data that can be handled by the system. The generic forms can be described by archetypes, but screen representations will be also generic, therefore leading to less structured data and more "free" text. The blank paper can probably only be represented by a very generic archetype, which doesn't allow the user (i.e. MD) to further structure the data. Is this correct? > Obviously, you cannot make every single data-element obligatory. After > all, some patients don't even have an ulcer. :-) Thus, everything is > optional. However, certain data may be conditionally obligatory - for > example, if you are completing a certain "form" that > describes a patient's > ulcer, you may have to specify where the ulcer is. Right, correct. But do archetypes allow this conditionality? Same thing: when you need to examine genitals it would be nice to use the appropriate archetypes based on gender. :-) > The OIO system stores these recording as data-collected-through-a-form > :-). Right, but when you want to query the system, how would that be helpful/hinder? AM > I would expect that the model would be sub-classing and AM > inheritance, in other words both the GP and the specialist AM > archetype derive from a higher level, simpler, archetype about AM > ulcers. AM > Thus they should be expected to both fit into the object AM > container being used without interfering with each other. Ok, this makes sense (I did read about inheritance of archetypes). I suppose when the GP has both types of archetypes and he wants to use one to generate a new recording, he is either simply presented a choice, which one to use or the system defaults to a predefined one. AM > > How do you refer to information that is AM > > constructed with another archetype? AM > There may be something worth lloking at in Arden Syntax for AM > deciding how to do that sort of thing, and it may be unusual to AM > need to do that automatically. I'm not (yet) familiar with the Arden Syntax. I'll have a look at it. > There must be a "translator" or mediator that goes between the two. > > What Adrian Midgley says about inheritance etc makes sense if > and only if > a universal set of controlled vocabulary/metadata are fully Well, this might be idealistic, but I could think of a controlled vocabulary for the more generic, structured terms, and the OMG Terminology Query Service implemented to map one set of terms into another for the more detailed descriptions. Besides, by adding domain information to a term (e.g. DNS:HelmaVocabulary/Ulcers/Stomach/Size) you can always trace it back to the origin and try to clarify it there. Correct: it doesn't allow mapping to a standard set, but at least its meaning will be less obscure and ambiguous. > > You could send over the archetypes as well, but what to do then? > 1) You can view the patient records sent over by the > specialist. Although > the archetype is foreign to you, you may still know enough > about ulcers to > understand the specialist's desription. > > 2) You can either construct or download a mediator that can translate > information from the specialist into your own "format" > (archetype/form). > Does this make sense? In a way it does, but I'm getting more and more confused about the exact role archetypes have in this. I'm under the impression that archetypes (the detailed ones being inherited from generic ones) can be used as "translator" so in the above example: when the GP wants to see all of the details he uses the specialist archetype (or rather: a screen representation that knows how to handle all the specialist data), when he merely wants to see "summary" data he uses his own archetype or a screen representation for "summary" data. Thinking about this more: archetypes are used for data entry, to ensure equally structured data. But this needs some screen interpretation both for data entry and for review. How to "store" this screen representation? Added to the archetype means every review of data needs to access the archetype to get the screen representation. Added separately means that changes in an archetype require updates in another part of the system (the screen representation). And how to handle "overview screens" that consists of elements of several archetypes? E.g. I could imagine an overview screen that displays "problems at last visit", "most recent lab tests + results", "weight, length, gender", "chronic illness" whatever. It wouldn't be ok to store all this information in one object, generated by one archetype. > I can understand your observation that the two (validation > and decision support) are similar in certain ways. In my mind, I think > decision support involves processing of information that have already been > collected and stored. On the other hand, validation involves tools that facilitates > collecting the "correct" information. Hmm, this is a workable distinction. That answers a lot of questions. Thanks. > > How do you refer to information that is constructed with another > > archetype? Oops, same question, different phrase. > Great question! This is exactly what I have been working on > over the past > few months. I would love to discuss some of the possibilities > that I have > come up with if you are interested. Since this will be a > lengthy reply, I > suggest that we move this discussion over to the open-outcomes-general > mailing list. Is that acceptable to you? Yes, I'd like to hear/read this, although I'm not eager to follow another high volume list. :-) PA > Maybe I can be of some help since I have been working on structured report PA > generators for more than 15 years, and I am currently working hard on PA > Archetypes. PA > To get short, I shall give you the major keypoints we based our strategy on : PA > 1) A report generating system must be structured : PA > 3 reasons for that : PA > - speed, because the report must be ready within 2 minutes, and you must PA > have the screens "in mind" to be fast PA > - guidance, not to forget to describe something, you must travel through PA > something like a check list PA > - repeatability, you must try to have the same aspect being described in PA > the same way PA > 2) The life of a report BEGINS when he leaves the endoscopic lab. PA > Too often, people don't realize that their output is someone else input. PA > Here comes the Archetypes : you get the result, and you can gain access to PA > its reference model. But as far as I understand it, the reference model is a very generic set of relatively static concepts (e.g. Person, Observation and such). So how does knowing the reference model help you if you know that all archetypes generate objects that are subclasses of e.g. Observation? How do you enter data then? Through a "report" or through an "archetype"? If you use reports for viewing data, do they use archetypes to extract the proper information? > I hope my reply is somewhat helpful. Please feel free to ask more > questions. Something about the idiot asking more questions 10 wise men can answer. :-) Bye, Helma
