# openEHR-clinical Digest, Vol 24, Issue 4 **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2008-10-05 12:33 UTC **Views:** 1 **Replies:** 1 **URL:** https://discourse.openehr.org/t/openehr-clinical-digest-vol-24-issue-4/15829 --- ## Post #1 by @Greg_Caulton >> >> Right, I am writing an open source HIS which hopefully will start >> hospital deployments in the spring\. I am loading the official >> archetypes to provide the core content and then anything I cannot map >> I will assign a LOINC or SNOMED code and then map it to an archetype >> later\. >> >> thanks for the info \! >> >> Greg >> > > I would have thought that it would be better to do it the other way > around i\.e\. map everything to archetypes and worry about the coding > later? Its a mistake to think that archetypes are just another way of > coding things and that archetypes and coding systems are > interchangeable, > > regards Hugh I considered that, and there are obvious benefits\. But I thought that if we each create our own local archetypes then there are going to be organized/classified differently using different concepts \- losing the semantic benefits\. I am all for submitting archetypes \- though for every form I am looking at I probably have a dozen questions :\-\) I guess ideally if we can collaborate near real time then we could spread the knowledge faster\. Or I am all for posting archetypes into a sandbox and getting feedback on whether it has a duplicate, should be organized differently, should be a coded entry not a discrete data element etc\. etc\. For example a nursing admission of a elderly patient completing a worksheet assessment for eating, bathing, locomotion, social, comprehension etc\. Should that just use openEHR\-EHR\-Evaluation\.check\_list\.v1 or perhaps form a specialization of that one\. But when I look at it there are data elements for answer, comments on the answer and summary of the questions \- but nothing for the question \- perhaps an oversight, perhaps not\. But my point is what is the best way to go about this: 1\) Flood the mailing list \(I assume not as that would peeve people\) 2\) Submit comments on the archetypes directly 3\) Submit changes on the archetypes directly 4\) Build a local set archetypes and submit for review\. What I want is what I assume everyone wants \- a core set of archetypes in the repository that has breadth and more importantly has been vetted for quality \- as things will get tricky if we have duplicate or overlapping concepts\. thanks\! Greg --- ## Post #2 by @heather.leslie Hi Greg, Comments are inline\.\.\. Greg Caulton wrote: >>> Right, I am writing an open source HIS which hopefully will start >>> hospital deployments in the spring\. I am loading the official >>> archetypes to provide the core content and then anything I cannot map >>> I will assign a LOINC or SNOMED code and then map it to an archetype >>> later\. >>> >>> thanks for the info \! >>> >>> Greg >>> >> >> I would have thought that it would be better to do it the other way >> around i\.e\. map everything to archetypes and worry about the coding >> later? Its a mistake to think that archetypes are just another way of >> coding things and that archetypes and coding systems are >> interchangeable, >> >> regards Hugh >>     > I considered that, and there are obvious benefits\. But I thought that > if we each create our own local archetypes then there are going to be > organized/classified differently using different concepts \- losing the > semantic benefits\. Totally agree \- but we need to start somewhere with someone putting up the straw man for discussion, review and hopefully publication\. The openEHR Clinical Knowledge Manager \(CKM\) will provide that collaborative function and support a formal archetype review process\. > I am all for submitting archetypes \- though for > every form I am looking at I probably have a dozen questions :\-\) Yes, there are issues related to best\-practice design and our knowledge on this is increasing with each archetype built \- as we understand the ramifications on querying, terminology etc\. > I guess ideally if we can collaborate near real time then we could > spread the knowledge faster\. Or I am all for posting archetypes into > a sandbox and getting feedback on whether it has a duplicate, should > be organized differently, should be a coded entry not a discrete data > element etc\. etc\. >   This is a large part of the intended purpose of the Clinical Knowledge Manager\. The first instance will let you know which archetypes are currently available and their publication status\. Following soon after, we hope, will be a sandbox very similar to what you describe \- once it has been established that an archetype is not currently available, then it will be a place for sharing needs/requirements for archetypes and posting raw archetypes, if you like \- pulling together people to collaborate on creating an archetype draft for formal submission to the repository\. > For example a nursing admission of a elderly patient completing a > worksheet assessment for eating, bathing, locomotion, social, > comprehension etc\. Should that just use > openEHR\-EHR\-Evaluation\.check\_list\.v1 or perhaps form a specialization > of that one\. But when I look at it there are data elements for > answer, comments on the answer and summary of the questions \- but > nothing for the question \- perhaps an oversight, perhaps not\. >   I agree that these archetypes need some revision as they are not perhaps as clear as they could be\. The intention is that the checklist is generic and can be specialised for particular use cases\. We may find that there are specific attributes that are common and can be archetyped explicitly, along the same lines as Barthel has been done\. Time and collaboration will make this clearer\. > But my point is what is the best way to go about this: > 1\) Flood the mailing list \(I assume not as that would peeve people\) >   Probably not the best medium to record all the issues, but great to get input and collaboration > 2\) Submit comments on the archetypes directly >   For existing archetypes, this is the purpose and functionality of the Knowledge Manager > 3\) Submit changes on the archetypes directly >   In the Knowledge Manger it is possible to submit modified archetypes to a branch for consideration by a review team\. > 4\) Build a local set archetypes and submit for review\. >   Please do so \- the Knowledge Manager will accept archetypes from registered users\. > What I want is what I assume everyone wants \- a core set of archetypes > in the repository that has breadth and more importantly has been > vetted for quality \- as things will get tricky if we have duplicate or > overlapping concepts\. >   Agreed For anyone who would like to participate in beta testing the openEHR Clinical Knowledge Manager, please email me and I will provide instructions on getting access\. Regards Heather --- **Canonical:** https://discourse.openehr.org/t/openehr-clinical-digest-vol-24-issue-4/15829 **Original content:** https://discourse.openehr.org/t/openehr-clinical-digest-vol-24-issue-4/15829