> A few comments: > I note the site of collection (arterial vs venous) produces a > (partial) doubling of the archetype > - why not one set of analytes with a slot for site of > origin? While what has been chosen is one way to go how is > the choice arrived at? How does it cope with reporting an > arterial blood gas bicarbonate - or is that part of another > electrolyte archetype? So do you need a super-archetype to > bring together commonly co-reported information? > How does it cope with local practice differences e.g. some > use Base Excess while others may prefer Standard Bicarbonate > as a derived parameter. > > I realise all these sorts of questions have been (or are > being) agonised over with LOINC coding and SNOMED-CT with no > one answer - so are archetypes related to these or another > bite of the same cherry? >
Hi Nigel All very good questions - which I'll attempt to answer. Archetypes can be versioned or specialised so that changes can be incorporated if needed. What is needed at the initial design time of an archetype is to design an archetype that is as rich as possible and its obviously best to get experts involved at that level. Of course other archetypes can be built using lower level archetypes and there are a number of different archetype types that specify different levels of the openEHR hierachy. The clinical concept of the archetype is fixed in a particular version but if it was changed, the software you are using shouldn't need ANY change to be able to store, retrieve and display the information. That's what I was talking about with rigid db schemas which would need such changes. openEHR also has the concept of templates that are site specific and can build up a concept such as "discharge referral". Templates can group archetypes and further constrain them. Because these are built from archetypes, even if they are site specific, any openER system can understand the components. This is where you can build your site specific groups of results without losing the semantic interoperability. I would encourage you to read the specification because a lot of this stuff needs a lot more discussion to become really clear. Regards Hugh _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
