Improving Translation_details and other_contributors ?
_ POP access for Hotmail is here! Click here to find out more http://windowslive.ninemsn.com.au/article.aspx?id=802246 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090624/950b95a7/attachment.html
Concept Overload Caution
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
distributed development, governance and artefact identification for openEHR
Hi Tom, This is a good document - thanks. I have posted this to the clinical list as well. http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/di st_dev_model.pdf My comments: Page 11: Current text: Archetypes based on different classes from the same information model to have the same name, e.g. An archetype for 'vital signs' headings based on the SECTION class, and a 'vital signs' archetype based on OBSERVATION. Comment: I believe there will be archetypes for sections and entry that have the same name but this is not a good example. The entries for vital signs are BP, Pulse etc. I think it would be better to just raise the problem or get an example. The nearest one I can think of is a plural form - e.g: Problems (Section) and Problem (Entry). Page 16: Current text: Also in common with software, there is a strong interest among archetype and template users in one or a few high-level shared libraries of high-quality artefacts rather than scattered development with poor quality control. In an ideal world, there might be only a single repository, or a purely hierarchical set of repositories. However, we know from experience with software development that this is extremely unlikely. Each organisation initially starts out with its own point of view, timelines and priorities. If a coherent ecosystem of cooperating repositories, or a single international repository were ever to exist, it would be as an emergent result of collaboration among initially separate authoring groups, rather than being established at the outset. Comment: With my software hat on I concur with your sentiment. The reality is that it is likely to be the clinical colleges and other stakeholders outside the software domain that produce the authoritative archetypes that are sought after. I have no doubt that there will be both entropic and negentropic forces. I believe that the lowest energy state is so profoundly associated with collaborative work in this area that we are unlikely to see many competing efforts. This is for many reasons including: * There are many choices involved in developing archetypes - each has implications for other archetypes that have to be developed and maintained, translated etc * Clinicians are interested in alignment of recording around best practice and providing suitable flexibility - this is best done within one or a very small number of archetypes for a given clinical concept * Interoperability will be maximised with collaboration around the development of archetypes and vendors will have a much smaller footprint to manage * The cost of creating competing sets of archetypes is massive and probably not sustainable * The number of clinicians and technical people in a position to contribute is not high considering the work required * Structuring clinical information is more fractal than orthogonal in nature. Consensus provides a means of getting to grips with the issues and managing complexity In essence I am counselling everyone to see the centralised hierarchy of repositories as infinitely more useful than the software model of go and do, try, build and lets sort the differences in the future. I guess I am proposing that archetypes are a lot closer to terminology than software from a clinical perspective. Current text: Other national and institutional repositories are likely to come online from 2009 onward. This trend appears to be similar to the emergence of large-scale open source projects. The collaborative nature is similar. I hope that the national repositories will be used more to organise comments and development of archetypes for the collective effort in these early days than starting out on their own. In the end I hope the national repositories will be where the releases of largely international artefacts (with local specialisations) will be managed. Some archetypes for national or local use will also be developed but these will be edge cases. I guess I would see archetypes as the operating system of clinical interoperability if I were to use the technical analogy. Current text: Based on the above considerations, the 'modern' model of software development is assumed to provide a suitable paradigm for openEHR knowledge artefact development, with emphasis on collaborative development of one or a small number of well-known artefact repositories. I therefore do not agree with this statement. It may appear realistic but I do not think it is sustainable nor to be encouraged. I am interested in what other people think. It is really an important consideration. Terminology also could be organised primarily by country (or even regionally) and then at the core when people agree on things. If the clinical leaders in the openEHR community agree with me that we should really work with the centralised model it does not greatly influence the technical issues in this paper but it does mean we can work with the assumption that everyone will see a central authoritative source and
distributed development, governance and artefact identification for openEHR
Hi Tom Another very thoughtful document. I have been involved to some degree in the discussion of this area over the years as have many others prior to this draft release. http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/di st_dev_model.pdf This document suggests approaches that need very careful consideration and at present I do not support the direction of this document - specifically in the changes proposed. It is important that the community consider the implications for clinical interoperability etc. This document has being released to the community prior to careful consideration by the ARB to gauge the views of implementers and clinicians. It will be difficult for many to understand the implications but I want to raise some of my concerns so people have an insight into the implications. Page 5: Current text: 1.4 Changes proposed in this document: augmented form of ARCHETYPE_ID to include organisational / package namespace, e.g. org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v1 . concept name section of archetype identifiers (middle part of ARCHETYPE_ID) now relaxed to no longer require structure based on specialisation parents, e.g. 'problem-diagnosis' can now just be 'diagnosis', or any name preferred by designers; . addition of commit_id sub-section archetype description section; . addition of id_history sub-section to description section, e.g. id_history = se.skl.epj::openEHR-EHR-EVALUATION.problem.v1 This document when taken in combination with the distributed development model raise the stakes for participants. The outcome is the promise of the ability to interoperate from a knowledge artefact point of view but I have doubts whether the proposed changes will support clinical interoperability. I understand the wish of technical people to produce artefacts wherever and whenever they like (just as terminologists do) but I would propose that we have to manage complexity as well. In a world that is immensely complex already (clinical systems) we may have to sacrifice some possibilities to ensure we can perform the sort of functions people seek from a standard EHR architecture. I would like to add the requirements that are fundamental from my perspective so that the community can raise these: 1. Primacy of openEHR: I would propose that we need a hierarchy of authority. Although openEHR artefacts are presently managed within the Foundation it is possible that the governance will move to a more authoritative organisation in the near future. That said, I believe that archetypes released by the openEHR Foundation should not be identified specially (i.e. no name space). This means that openEHR becomes the default namespace for archetypes and begins to provide a hierarchy of authority that I think is so important in this space. One might argue that anyone can produce archetypes with no namespace - but really anyone can produce anything with any namespace so that is not sufficient. 2. Archetype IDs How archetypes are identified in the universe is of no great concern to me. I am happy to accept that people may want to give them arbitrary names and live with complexity from an archetype management point of view. What I am concerned about is how they are identified in data. And I do not want this to be any more complicated than is required to support the vision we have for openEHR. I am happy that we may need to extend this at some point but we have seen very successful extensions of many identifiers as systems grow (IP4-ip6, Ascii - UTF-8). I understand the technical vision - anyone can do anything and we will be able to sort out what is going on - but I believe we have to keep pushing for things to be right for where we are up to. In data the model is known - therefore the openEHR-EHR is redundant in an EHR implementation. The namespace of the archetype is not. In data, in XML expression of openEHR data, the archetype iD Class name and concept part provide a means of returning the data without knowledge of the archetype. An openEHR repository can be fully implemented, use AQL etc without any knowledge of archetypes whatsoever. The reason for this is that the archetype Ids are used in queries, and specialisations can be found without reference to any archetypes based on the ID. This is a fundamental benefit for implementers and losing this will require a considerably more complex engine with, potentially, access to every archetype ID in the world. This is not useful. So my fundamental requirement is, in openEHR systems, to be able to query for specialisations without the need to go to an archetype knowledgebase (which will by definition be incomplete). Page 17: Current text: As a general principle, for a given archetype used to create data (e.g. an openEHR OBSERVATION object), the following archetypes could be used for querying: . the same archetype, i.e. Exact same version, revision commit; . any previous revision of the same archetype; . any of the specialisation
distributed development, governance and artefact identification for openEHR
Sam Heard wrote: 1. Primacy of openEHR: I would propose that we need a hierarchy of authority. Although openEHR artefacts are presently managed within the Foundation it is possible that the governance will move to a more authoritative organisation in the near future. That said, I believe that archetypes released by the openEHR Foundation should not be identified specially (i.e. no name space). This means that openEHR becomes the default namespace for archetypes and begins to provide a hierarchy of authority that I think is so important in this space. One might argue that anyone can produce archetypes with no namespace - but really anyone can produce anything with any namespace so that is not sufficient. Hi Sam, The primacy of openEHR sounds good, but wouldn't it be better to stamp the archetypes with the openEHR seal of approval? Your proposal above means that all of the home-grown local archetypes sitting on people's own computers at the moment are indistinguishable from the authoritative openEHR archetypes. I don't buy the argument that producing an archetype with no namespace is equivalent to producing an archetype with any namespace: * Archetypes with no namespace can (and will!) be produced frequently, innocently and by accident. * Producing an archetype with the openehr namespace would be a deliberate act, a conscious choice. - Peter
Improving Translation_details and other_contributors ?
it separate? The other problem we have is with other_contributors not sticking to the same format (i.e. we only have a list of contributors without more formal metadata): RESOURCE_DESCRIPTION original_author : Hash http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700091 70_630396_833Report.html String,String1 -- Original author of this resource, with all relevant details, including organisation. other_contributors : List http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700090 80_492027_712Report.html String 0..1-- Other contributors to the resource, probably listed in ?name ? form. I think I understand why it is modelled as it is, but why not allow other_contributors to be 0..* Hash http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_11084700091 70_630396_833Report.html String,String ? Maybe, we need to look into formalising what an author/translator is a bit more in the model? Are there any suggestions for a better model of this? Or something from DCM or CDA or others on which we could base such a model to be compatible with? Regards Sebastian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090624/bc636f41/attachment.html
Out of office
I will be out of the office until July 13, 2009 with limited access to voice-mail and e-mail. If you have an urgent IT issue, please contact Darin Ivie at 208-819-4626.
