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 hospital'. 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. Regards Heather From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On Behalf Of Bakke, Silje Ljosland Sent: Friday, 12 February 2016 1:17 AM To: For openEHR clinical discussions (openehr-clinical@lists.openehr.org) <openehr-clinical@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 COMPOSITION? Kind regards, Silje Ljosland Bakke Information Architect, RN Coordinator, National Editorial Board for Archetypes National ICT Norway Tel. +47 40203298 Web: http://arketyper.no<http://arketyper.no/> / Twitter: @arketyper_no<https://twitter.com/arketyper_no>
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
