On 02/11/2018 00:00, Heather Leslie wrote:
Hi Dileep,
From a clinician/modeller’s point of view, each of the consultations
or visits that you describe as screening, consult encounter, revisit
encounters are discrete events and need to be recorded using a
separate event COMPOSITION. Each clinical consult will be recorded
independently including identifying the changes from visit to visit.
As part of a consult a diagnosis may be marked as resolved and that
should be included as part of the consult record.
yep, this is the way it should be in openEHR, and logically in any EHR.
If you don't do it like this, the data probably won't make sense to
other openEHR software, applications etc.
This information needs to be recorded once for medicolegal purposes
and sensible querying. Similar data that needs both event based
recording and sensible updated representation in summaries or
persistent lists include medications, problem/diagnosis,
immunisations, adverse reactions, social history, tobacco/alcohol
summaries etc.
The question of where that data should be actually 1) stored vs 2)
copied and displayed vs 3)displayed as the result of a query or
4)<other technical solution outside my capability> is not implemented
consistently as far as I understand. Implementers please correct me if
you have documented consensus.
For medicolegal purposes the consult record needs to be able to be
accurately displayed and reintegrated on request, even if the
component data is stored in a mix of event and persistent COMPOSITIONS.
also correct.
I would think that you would also need to be able to keep a
representation of the health summary, also primarily for medicolegal
purposes, so that it could be determined precisely what the clinician
viewed in that summary as they made a critical clinical decision,
especially if it were to result in a bad outcome. That is one of the
key reasons for the versioned persistent compositions.
And that will not prevent the patient summary being the last known
status of the person – totally agree with your intent there. It’s just
a question of how to be able to demonstrate what was the summary on a
certain data, at a certain time.
You might consider the 'health summary' a 'document' of some sort, and
you /could/ take the line that you are maintaining and updating just
that summary rather than the constituent data. In that case, you could
treat the summary as a persistent Composition and add versions to it as
you say, but now your patient EHR doesn't contain any clinical event
data, only the data of a manually pre-built summary of those events.
Generally it's much more useful to record the event Compositions and
just compute the summary. This can be easily facilitated by use of
Folders that represent episodes, in a fashion already done by some of
the vendors (at least DIPS and Code24). There is a new change to the
FOLDER type <https://openehr.atlassian.net/browse/SPECRM-56> in the RM
that facilitates adding more data - this will appear in the next RM
release, very soon.
hope this helps.
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/> | The Objective Stance
<https://theobjectivestance.net/>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
