Re: Problem-oriented records and querying by problem

sam.heard at sam.heard at
Fri Jan 9 06:24:36 EST 2015

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.

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

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.

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian at
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> 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 ( changing name 1 Jan 2015)
> LiU: erik.sundvall at
> On Tue, Nov 18, 2014 at 9:33 PM, <sam.heard at> 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
>> ________________________________
>> From: pazospablo at
>> To: openehr-technical at
>> 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
>> _______________________________________________ openEHR-technical mailing
>> list openEHR-technical at
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

openEHR-clinical mailing list
openEHR-clinical at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list