Hi Ian
I do not propose that Folders be the problem list, rather that it is possible to link compositions to problems by placing them in Folders. The advantage is that it is possible to create a query response that is determined consciously by clinicians rather than all the links people have created for whatever reason. Also, a problem has to be quite substantial to warrant organising the content of the EHR. I agree with your approach, I think I was talking about an additional means - it may only work in some settings but it is sustainable I think. Cheers Sam From: Ian McNicoll Sent: ?Wednesday?, ?7? ?January? ?2015 ?1?:?58? ?AM To: For openEHR clinical discussions Hi Erik, I am not sure that FOLDERS are the correct solution, since these can only contain Compositions (or other folders) which is a pretty clunky way of maintaining a problem list whose core artefacts will be ENTRY-level archetypes. it also prevents the roots and branch aspects of the tree-like list from containing important meta-info like a problem name or dates. For a problem list, we are certainly looking at some sort of separate composition, maintained separately from the core event compositions in which the problems were originally entered, either by copying the original ENTRIES or (I think more correctly, via LINKS, but that is partly an implementation issue. Whilst the current 'persistent' composition arrangement works ok for GP-type longitudinal problem lists, setting the composition.type attribute to 'persistent' prevents the use of composition.context which is too restrictive for e.g an episodic problem list maintained across a hospital admission. Both the HL7 Health Concern DAM and CEN Contsys Health Thread documentation are pretty well aligned in overall requirements. In particular both envisage the use of problem thread type constructs within much more defined contexts such as a discharge/ referral document or even a Care plan. The longitudinal problem list is just a very specific sub-type of this construct. https://github.com/openehr-clinical/shn-contsys with some example archetypes and mindmaps. This approach does rely heavily on LINKS, which I think is unavoidable because of the need to nest ENTRY level constructs, whether these ENTRIES are held in-line with in the same Composition or a referenced from a different composition. The Health Thread archetype is the root ENTRY which contains one of more Health Issues which is the container for the real payload of ENTRIES, which can be of any ENTRY class. Since developing this arrangement I have begun to wonder if Health Issue is actually redundant and that we could simply use the Problem /Diagnosis archetype in that role. This would simplify the structure for simple uses case, whilst ensuring that the root of any Health Issue was a Problem/Diagnosis, beneath which any kind of ENTRY is allowed e.g a medication statement, procedure or even in some cases and admin_entry. The other very tricky area is how to reconcile this approach with the more common arrangement in episodic care of e.g. Primary Diagnoses/ procedures, Co-morbidity, other problems etc. It would be nice to find means to bring these two approaches together. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 28 December 2014 at 09:54, Erik Sundvall <erik.sundvall at liu.se> wrote: > The FOLDER approach suggested by Sam looks interesting and flexible for some > problem-oriented applications. Especially since folders can be hierarchical > (problem vs sub-problem?) and are versioned (and thus easily can be updated > without losing log/history info). > > What are the experiences positive/negative from using this approach for > problem orientation? Any documented? > > Best regards, > Erik Sundvall > > Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or > 010-1036252 in Sweden) > Li?: erik.sundvall at regionostergotland.se (lio.se changing name 1 Jan 2015) > LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ > > > On Tue, Nov 18, 2014 at 9:33 PM, <sam.heard at openehrfoundation.org> wrote: >> >> It is really problematic in most systems. First there are often more than >> one problem addressed. Second, a lot of them are trivial and one off and do >> not need to be on the problem list (more reason for encounter). >> >> I like the idea of doing this with folders in openEHR. No need to link >> from the document so it can be done retrospectively. It can even be >> different for different users potentially. >> >> Cheers Sam >> >> Dr Sam Heard >> Chairman, openEHR Foundation >> >> From: pablo pazos >> Sent: ?Tuesday?, ?18? ?November? ?2014 ?1?:?04? ?PM >> To: For openEHR technical discussions, For openEHR clinical discussions >> >> Hi all, just re-sending this question on the clinical list too. >> >> I'm wondering how to handle the link between documents and health problems >> in a problem-oriented record. >> >> Thanks! >> >> -- >> Kind regards, >> Eng. Pablo Pazos Guti?rrez >> http://cabolabs.com >> >> ________________________________ >> From: pazospablo at hotmail.com >> To: openehr-technical at lists.openehr.org >> Subject: Problem-oriented records and querying by problem >> Date: Thu, 6 Nov 2014 13:28:40 -0300 >> >> Hi, another question related to querying: >> >> I have a case of problem-oriented records, where I need to query all the >> COMPOSITIONS related to a specific problem (evolutions, controls, etc). >> >> Since we have a Problem List persistent archetype that records >> OBSERVATIONS about the health problems: >> >> - Would it be a good solution to use LINKs between those OBSERVATIONs and >> the COMPOSITIONs related to those problems in order to solve the "query >> COMPOSITIONS by health problem"? >> >> Is there another solution for this? What do you think? >> >> Thanks! >> >> -- >> Kind regards, >> Eng. Pablo Pazos Guti?rrez >> http://cabolabs.com >> >> _______________________________________________ openEHR-technical mailing >> list openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org _______________________________________________ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150109/6db5d525/attachment-0001.html>
