Hi everyone There are a lot of technical people who have volunteered as reviewers on CKM and we have had major input from a number of them. There will be more issues that arise when we have the first set of archetypes for publication to ensure consistency.
There is no doubt that we all benefit from people speaking up about what their systems do and why. This helps ensure archetypes are suitable to support existing systems. Cheers, Sam > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Stef Verlinden > Sent: Tuesday, 23 June 2009 4:02 PM > To: For openEHR technical discussions > Subject: Re: Concept Overload Caution > > Hi Heath, > > I complety agree with you. Let's all do what we're best at. What I > would like to add to your proposal is some feedback (both ways) so > doctors and technicians can learn from eachother. Rather than de- > empowering the one or the other I think we should team up to create a > properly working system that really adds value for the citizens/ > patient who are the subject of this all. > > Also as I clinician I really would like an understandable (at > technical lay-mans level) manual with clear examples who things can > work and why some solutions shoudl be avoided. Maybe some best- > practices of whatever you like to call that > > Cheers, > > Stef > > Op 23 jun 2009, om 02:15 heeft Heath Frankel het volgende geschreven: > > > 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* > >> ************************************************************** > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
