Thanks Ian for sharing the details. We can use it as a reference in the future.
regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Wed, Jun 19, 2019 at 8:00 PM Ian McNicoll <i...@freshehr.com> wrote: > Ultimately this is going to be about the context if use, and what you are > trying to do. Smoking history will be asked in many different places and in > many potentially different applications. > > If you are working with a single app, then the lifestyle_factors > composition is probably the sensible place as a default but in a multi-app > platform environment, you may want people to be able to ask about smoking > status in the context of a condition or disease pathway composition. > Ultimately it is really about your wish/ability to maintain a single source > of truth about smoking status > > Here is an approach we took for a coProduced Patient Health Record > > https://ckm.apperta.org/ckm/templates/1051.57.165/orgchart > > all of the templates are here > > https://ckm.apperta.org/ckm/#showProject=1051.61.34 > > and the underlying document is at https://apperta.org/coPHR/ > > but we took a different approach for a condition focussed pathway document > on Acute coronary syndrome - the key thing is that the archetype is > identical in both cases. > > Knitt > > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > > > Director, freshEHR Clinical Informatics Ltd. > CCIO inidus Ltd. i...@inidus.com > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Hon. Senior Research Associate, CHIME, UCL > > > On Wed, 19 Jun 2019 at 14:32, Thomas Beale <thomas.be...@openehr.org> > wrote: > >> >> Hi Dileep, >> >> it would be interesting if you could publish anything about your virtual >> folder design, because more is being added to the RM to standardise how >> FOLDERs are used to represent episodes, mainly based on how DIPS (Norway) >> and Code24 (NL) do it. See SPECRM-55 and SPECRM-56 >> <https://openehr.atlassian.net/projects/SPECRM/versions/12516/tab/release-report-all-issues>. >> THis is certainly not complete, and indeed we have not yet published a >> guide for how to use Folders to do this (there probably is not yet full >> agreement anyway). Nevertheless, both these vendors have sophisticated >> approaches to using FOLDERs for episodes, and it would be good to have any >> other ideas to add to the mix so that we could either standardise a single >> approach, or else describe a small number of extant approaches such that >> client software can figure out what kind of episode representation it is >> dealing with. >> >> ANother thing, just for reference: from a formal point of view, what gets >> committed due to an encounter is always be a Contribution, i.e. an openEHR >> change set (thinking in DVCS, e.g. Git terms). A Contribution can contain >> any / all of: >> >> - completely new TLO(s) >> - new version(s) of any existing TLO(s) >> - change(s) to any existing TLO(s) >> - logical deletion(s) of any TLO(s) >> - changes to path structure of any TLO with such a structure (= >> directory) >> >> Here, TLO = 'top-level object', which can be the following from the EHR >> model >> <https://specifications.openehr.org/releases/RM/latest/ehr.html#_change_control_in_the_ehr> >> : >> >> - COMPOSITION >> - directory, consisting of FOLDERs >> - EHR_STATUS >> - EHR_ACCESS >> >> And from the Demographic model >> <https://specifications.openehr.org/releases/RM/latest/demographic.html>: >> >> - PARTY >> - PARTY_RELATIONSHIP >> >> ANd from the Task Planning model >> <https://specifications.openehr.org/releases/PROC/latest/task_planning.html> >> : >> >> - COMPOSITION containing WORK_PLAN or TASK_PLAN >> >> It is of course very common that the result of an encounter is just one >> new COMPOSITION, or one new version of one existing COMPOSITION - but just >> as with Git or any other versioning system, this requires a Contribution >> since it is still a change set. >> >> Full versioning semantics here >> <https://specifications.openehr.org/releases/RM/latest/common.html#_change_control_package>, >> for reference. >> >> - thomas >> >> >> On 05/06/2019 12:15, Dileep V S wrote: >> >> Dear Gerard, >> >> Thanks for your response. Your point of a composition being designed to >> record a complete encounter is worth another discussion. >> >> I personally feel that it is one way of implementing your CDR, but there >> could be other equally effective approaches that work better in other >> situations. For example in the CDR service component of our platform >> (EHR.Network), we have gone with generic reusable templates such as >> complaints, diagnosis, medication summary, medication order etc. The >> application can compose the complete schema for different encounter/event >> use cases using a combination of these generic templates. The data gathered >> in any event is grouped together under episodes and events using the >> virtual folder service. >> >> This approach ensures the generic nature of the platform, while >> maintaining it's extensibility over time. It also helps us contain the >> proliferation of templates and keeps our library of commonly used stored >> queries to a manageable level. >> >> May be there are other better approaches than either of these that are >> already being used by others. I feel the approach to choose will depend >> upon the requirements and so maintaining flexibility for the implementer >> will be crucial. >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
