Architectural choices: One composition archetype per document type, or not?
ian at freshehr.com
Sat Feb 13 13:32:03 EST 2016
Sorry I am late to the party but I am going with what seems to be the
consensus to use a small set of generic Composition archetypes.
Personally I use composition/name/value to identify local use, rather than
templateID, which I would regard as more of a design-time name, but I think
that is still up for discussion.
In the UK there is also a set of standard SNOMED document type names
which I would add as a mapping to the composition name.
and service/speciality names
which are used in conjunction.
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
email: ian at freshehr.com
Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On 12 February 2016 at 00:54, Heather Leslie <
heather.leslie at oceaninformatics.com> wrote:
> Hi Silje,
> Each admission note will likely have it’s own content priorities and level
> of details, so there will be many templates – maybe not ‘hundreds if not
> thousands’ of templates if business logic drives some of the display of
> each template, but still many – that will be the reality. The templates
> have IDs, COMPOSITIONS can be renamed to ‘Neurosurgery outpatients – Dr
> ABCD’. We could consider creation of a specialisation of
> COMPOSITION.encounter for Neurosurgery but then we would have to consider
> every specialisation and govern them all – not sure that there is value
> here. And we definitely don’t want to create a COMPOSITION archetype that
> is specific to Dr ABCD consulting in Neurosurgery outpatients at XYZ
> Querying will occur at different levels – eg ‘any BP in any template,
> including consumer entered as well as hospital records’ through to ‘all
> Antenatal encounters during Pregnancy #1’ etc.
> I think we need to create use-case related archetypes, COMPOSITION or
> other, only where we can identify informatics, quality or querying
> benefits. And from first principles I suggest that we should keep the
> number of archetypes to a sensible, pragmatic minimum and let the power of
> terminology and querying within archetypes/templates play their very
> important part in letting us identify and retrieve the different types of
> documents. You can see that in action with our latest iteration of
> INSTRUCTION.request – it will subsume all of the current specialisations,
> rendering them redundant. I think this is good modelling UNLESS we
> determine that specialising INSTRUCTION.request-laboratory might be of
> value to simplify querying, but I’d never agree to a specialisation for
> every type of request – use terminology here. Otherwise the overhead on
> governance and maintenance of the extra archetypes becomes orders of
> magnitude greater and distributed authoring of templates in a consistent
> way which will support interoperability will become more confusing with a
> multitude more options. (Funny how that reminds me of the confusing array
> of options when using post-coordination to represent the same thing –
> everyone seems to do it differently.)
> Your question about 1:1 archetype development needs to be applied to all
> concepts not just the COMPOSITIONs and I think the solution becomes easier
> to decide.
> *From:* openEHR-clinical [mailto:
> openehr-clinical-bounces at lists.openehr.org] *On Behalf Of *Bakke, Silje
> *Sent:* Friday, 12 February 2016 1:17 AM
> *To:* For openEHR clinical discussions (openehr-clinical at lists.openehr.org)
> <openehr-clinical at lists.openehr.org>
> *Subject:* Architectural choices: One composition archetype per document
> type, or not?
> When implementing an openEHR based system for a large hospital, there will
> be hundreds if not thousands of document types. Examples of these are
> admission notes for different departments and specialties, outpatient
> notes, nursing documentation, check lists, discharge summaries, etc ad
> infinitum. Each of these could either have its own COMPOSITION archetype,
> or they could reuse generic compositions but have a separate template for
> each document type.
> What’s the smart architectural choice to make here; 1-1 document type –
> COMPOSITION, or reuse of generic COMPOSITIONs in specific templates? Why?
> How can you query a specific document type if it doesn’t have its own
> Kind regards,
> *Silje Ljosland Bakke*
> Information Architect, RN
> Coordinator, National Editorial Board for Archetypes
> National ICT Norway
> Tel. +47 40203298
> Web: http://arketyper.no / Twitter: @arketyper_no
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical