Hi Tim, Thank you for your post, I complete agree. Like you I am not a clinician and feel that I am rocking the establishment of openEHR and the principles of Archetypes by saying this, but I strongly believe that we need to have a technical review process of archetypes before they are published. What I am looking to review is not related to the clinical content, but the patterns used to represent that clinical content. In particular, I would looking to ensure that we have single concept representation, loose coupling, reusability, appropriate use of specialisation, and most importantly I believe, appropriate structures to support querying. These are all good object-oriented (or general software) design principles that technicians are trained to be better at then clinicians.
As part of the archetype governance and publishing process, I would like to see a technical review process. I realise I am writing to a group of technicians on this list and this is probably a topic for the clinical list, but I think there probably are enough clinicians on this technical list to knock me around if they feel that I am rocking it too hard. Please understand that I not trying to re-empower the technician, I am simply looking for good quality knowledge artefacts and believe this a process that is missing in the current archetype development process. Regards Heath > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Tim Cook > Sent: Wednesday, 3 June 2009 9:59 AM > To: For openEHR technical discussions > Subject: Concept Overload Caution > > Hi All, > > The past 3 or 4 subjects on this list takes me back to conversations > that we had before (maybe several years ago?) when we were discussing > slots and links. Maybe they were here maybe they were on the ARB list. > I do not recall now. > > But my feeling in both of these areas are that there is a tendency for > archetype developers to create archetypes that are more than one > clinical concept. IIRC, that is about the time that templates were > being thought of/designed to alleviate the pressure on archetypes to > serve everyone, everywhere. > > As Heath has just mentioned, templates are the better place for this > type of grouping. They tend to provide that ability to be more > localized. Remember that when you are creating or reusing archetypes > that they should be universally reusable. If they are not, then they > do not meet the basic requirement of being a single clinical concept. > This is fundamental to openEHR being future proof. > > The misuse of slots and probably any use of links in a particular > archetype; IMHO is a very bad thing and will lead us down the road that > we see with data model centric systems as opposed to our information > model. > > While I am not a clinician nor a lab tech I do ask those of you > creating archetypes to review the fundamental principles of archetypes > and templates. Then think twice before publishing an artifact. > > From what I am reading I think that there is becoming a tendency to put > too much runtime functionality into what is supposed to be singular > data items. > > My 2 cents/pence/centavos > > --Tim > > > > > > -- > Timothy Cook, MSc > Health Informatics Research & Development Services LinkedIn > Profile:http://www.linkedin.com/in/timothywaynecook > Skype ID == timothy.cook > ************************************************************** > *You may get my Public GPG key from popular keyservers or * > *from this link http://timothywayne.cook.googlepages.com/home* > **************************************************************
