There seems to be a 'cloud' (of misunderstanding) around these things called archetypes.
But it is actually simpler that people think.
Simply put, all what we have been discussing, the blood pressure archetype, lets you have the form (or subform or formlet or whatever you like to call it) that you can see below.
Now, I wont go into the argument of what is more important - whether the templates that it can generate (ie the product) or the codes that generate it (the codes).
Most other issues concerning arhcetypes/templates revolve around the sections we discussed in previous blogs.
Now, imagine, we have thousands of these clinical models, 'certified' by domain experts and tested by many implementations. That explains the interest in archetypes. However, these days I am beginning to ask my self: 'where is the hl7 equivalent of this?'. Thats probably for another day...
Recently, the NHS Trust work on archetypes has really excited me. As you may know, the NHS Trust UK (and NHS Scotland) has made available their archetypes repository for free use.
Visit the NHS work here.
What you might not know is that they have made their xforms engine based on chiba, xmlprocess, also available at the OHT.
See it here
My goal in the coming weeks will be to learn more about Adam Flinton's work, Xmlprocess, and about how archetypes and templates work in his tool.
I think that his work will not only redefine the way we look at operational archetypes and templates, but will stimulate other efforts at using xml archetypes/templates.
Also, since I am generally getting (sorry.. have gotten) inclined to Xforms, I might need to align my work with the new Xforms wave in the OpenMRS community...
Lets keep at the good work...
I'm outta here
...tomorrow is another day...
ciao...
2 comments:
Ime,
Thank you SO much for sharing your thoughts along the way. I am enjoying your blog.
One of the issues for OpenMRS and archetypes will be codifying all the responses. My impression is that archetypes allow for internally coded terms — where OpenMRS strives to ensure that every concept is uniquely coded and re-used. For example, anatomic terms used to describe where the BP was measured should not be free text lists, but should come from a shared pool of anatomic terms used for other tests or questions. Not everything has to be mapped to a standardized vocabulary, but everything should at least be mapped to a local vocabulary.
This may be as simple as enforcing that archetypes must have all terms bound to vocabularies (of which a localized vocabulary would be an option). Or perhaps I am confused and have more to learn from Ime. :-)
Cheers,
Burke
Hi Burke. Thanks too.
I really appreciate your comments! I understand your point. What I think is that we probably shouldn't disrupt the way the concept dictionary, the local vocabulary, is organized in the OpenMRS. I think we can find a way to pass the concepts in archetypes into OpenMRS as concept proposals. This way we can still codify responses using our central dictionary. In many OpenEHR systems, the terms are normally bound to vocabularies but I think that has an overheard of maintaining bindings. Would you be thinking of us creating an archetype vocabulary system (consisting of all the terms) that will be linked to the concept dictionary? I guess we could just use the existing concept dictionary and have the wealth of concepts passed in. Maybe we should see archetypes mainly as 'messengers' that convey clinical knowledge - the messages it carries can be used by any system in its own particular way.
Ime
Post a Comment