# openEHR-clinical Digest, Vol 24, Issue 4
**URL:** https://discourse.openehr.org/t/openehr-clinical-digest-vol-24-issue-4/15829
**Category:** Clinical (archive)
**Created:** [5 October 2008 12:33 UTC](https://discourse.openehr.org/t/openehr-clinical-digest-vol-24-issue-4/15829 "2008-10-05T12:33:46Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Greg\_Caulton](https://discourse.openehr.org/u/Greg_Caulton)
#### Post date: [5 October 2008 12:33 UTC](https://discourse.openehr.org/t/openehr-clinical-digest-vol-24-issue-4/15829/1 "2008-10-05T12:33:46Z")
> > 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
---
### Author:  [@heather.leslie](https://discourse.openehr.org/u/heather.leslie)
#### Post date: [5 October 2008 13:14 UTC](https://discourse.openehr.org/t/openehr-clinical-digest-vol-24-issue-4/15829/2 "2008-10-05T13:14:13Z")
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