Modelling Episodes in openEHR
lakewood at copper.net
lakewood at copper.net
Fri Dec 3 21:50:32 EST 2004
Elkin, Peter L., M.D. wrote:
> Dear Thomas,
> I favor the episode being a single point of audit (regardless of the
> timeframes at which an episode starts and stops). So all encounters
> and non-encounter events would indeed be part of an episode of care.
> This brings continuity to the notion of an episode of care. Episodes
> allow the summarization of the care which has occurred during the
> episode and there should be a provision in the OpenEHR architecture to
> affix this information to the Episode for further reference.
> Warm regards,
> Peter L. Elkin, MD
> Professor of Medicine
> Director, Laboratory of Biomedical Informatics
> Department of Internal Medicine
> Mayo Clinic, College of Medicine
> Mayo Clinic, Rochester
> (507) 284-1551
> Fax: (507) 284-5370
> *From:* owner-openehr-technical at openehr.org
> [mailto:owner-openehr-technical at openehr.org] *On Behalf Of *Thomas Beale
> *Sent:* Thursday, December 02, 2004 5:36 AM
> *To:* Openehr-Technical
> *Subject:* Modelling Episodes in openEHR
> Dear all,
> the definitional debate about what an "episode" will of course
> continue long into the future, and we will not solve it here - indeed
> there will never be a single definition. But we can in the abstract
> identify a couple of solid concepts:
> - episode of care by a care delivery enterprise / health care provider
> - provider-centric
> - episode of course of illness / situation - patient-centric; finishes
> at death, return to health, or stabilisation (chronic problems)
> A long-term effort into these types of concepts is the CEN TC/251
> Continuty of Care work (prEN13940), led by Franois Mennerat, who is
> on this list. The current draft of this standard is hosted on the
> openEHR website at
> http://www.openEHR.org/downloads/prEN13940_2004E_041107.zip (600k zip
> file of 2Mb Word document), and is worth a read. Notable definitions
> from this work include:
> - *period of care* (was "period of service"): situation during which
> one or more /contacts /occur between a /subject of care/ and one or
> several /health care professionals/, in the framework of a /care
> mandate/ held by a /health care pro/vider
> - *episode of care*: situation during which /health care activities/
> are performed by one /health care provider/ to address one /health issue
> /- *cumulative episode of car*e: situation encompassing the occurrence
> of all /health care activities// /related to only one /health issue thread
> /In the above, "period of care" appears to be the same as what I have
> informally called "episode of care" above; while "cumulative episode
> of care" appears to correspond to the second informal definition.
> People may like to use the prEN13940 definitions.
> In any case, the practical problem we have is to provide a way to
> model episodes (however defined) for users of openEHR, while retaining
> data and service interface interoperability. To model patient-centric
> clinical episodes (of illness, pregnancy etc) we believe that the
> current approach of using LINK objects to connect Entries,
> Compositions to be the best one. An animated slide presentation done
> by Dipak Kalra, using EN13940 terminology shows how this works in a
> particular example - see
> http://www.openEHR.org/downloads/CONTSYS-EHRcom.ppt (143k powerpoint).
> The other kind of eposide - "period of care/service" - we believe can
> be done using Folders. After some discussions recently with Dipak
> Kalra, we would suggest the following two ways of doing it in openEHR.
> 1. One "episode" = an openEHR Folder. Remember that a Folder in
> openEHR is a reference list, like a little index to particular
> groups of Compositions. A given Composition can appear in more
> than one Folder. The Folder can be named as being an episode
> (Folders inherit "name" from LOCATABLE) and every relevant
> Composition deemed by the provider to be in that episode can go
> in. If a Composition wants to be included in more than one
> episode (if you are the kind of provider that uses the 2nd
> EN13940 definition above), or in sub-episodes, then it can.
> 2. The Folder when committed to the EHR as part of a Contribution
> which causes the EHR Directory to be updated (remember all
> Folders in a given EHR are part of the Directory structure), the
> date of committal is recorded, as for any openEHR data commit.
> 3. A special Composition is defined in an archetype(s) as being for
> the purpose of "episode administrative information", and
> contains one or more Evaluation type Entries, which provide
> whatever administrative details are required for episodes in
> your establishment.
> 4. When the episode is deemed to have started - which may be
> clinically before the creation of the Folder on the EHR system,
> this special Composition is created/updated to indicate that
> date. It might also have any other descriptive information
> required for the episode as a whole. In particular, it could
> have a data item meaning "state of episode in time", which could
> be archetyped to take vocabulary valies of "initial" (meaning
> "intended", "scheduled" or whatever), "active", "closed",
> "reopened", etc). Date/times could be defined for all of these,
> as well as the participants responsible for starting, closing,
> reopening the episode.
> 5. When the episode is deemed to be closed, the admin Composition
> is updated to reflect this.
> 6. In this way, the special admin Composition in a Folder
> representing an episode always provides the current situation of
> the episode in each of its versions. It also means that for
> querying, there is only one Composition to search for in
> episode-Folders, in order to get the admin data of the episode.
> Currently, Compositions are connected to Folders by a List<OBJECT_REF>
> in the Folder. It might be useful to use a LINK, which is already
> inherited into FOLDER from LOCATABLE, to point to the admin
> Composition of an eposide-Folder. This would facilitate querying.
> A second alternative to this scheme is a minro adjustment - instead of
> using the versions of a single admin Composition, a number of admin
> Compositions could occur within the episode-Folder, each indicating an
> act of starting, closing, re-opening, terminating etc, the episode.
> Personally I favour the former approach, because it limits the
> "special" Compositions in a Folder to just one, and also presents a
> simpler picture in versioning terms, but both approaches a clearly
> possible, and the second one would be used by systems not implementing
> version control at all.
> In summary, we are suggesting a way to use openEHR to accurately and
> interoperably represent "episodes", regardless of what your definition
> of "episode" may be. The solution requires no changes to openEHR, and
> if adopted as the standard approach, means that episode data will be
> guaranteed to be interoperable in openEHR, and also provides guidance
> for how to represent it in CEN EN13606 EHR Extracts. If this solution
> is shown to have no faults and to be workable, we would document as
> part of openEHR and publish it.
> Further thoughts & discussion?
> - thomas beale
> - If you have any questions about using this list, please send a
> message to d.lloyd at openehr.org
Multidisciplinary backgrounds at times result in conflicts and Webster's
tool has to be referenced.
"1. a formal, often periodic examination and checking of accounts or
financial records to verify
their correctness 2. a settlement or adjustment of accounts. ..."
"1. the part of an ancient Greek tradegy between two choric songs: it
corresponds to an act
2. in a novel, poem, etc., any part of the story, or a narative
digression, that is largely complete
in itself. ..."
'Depression - episodic' (
"Term used to describe a problem that tends to get better and worse over
'a medical episode'
'episodic Hospital Data':
'root cause analysis'
'a problem with multiple episodes':
'Amnesia has several root causes':
'structural and non-structural (semantic or episodic) memory systems':
A easy definition does not exist.
When force to analyze a mountain of data an 'episode' might be whatever
I choose to
identify it as. Hence, additions might be made the deeper and more
detailed the analysis
The easiest 'episode' to identify comes from the TV Guide.
From Information Theory it is whatever I choose it to be and the act of
no impact upon the original data; it does have an impact on the analysis.
In an object world an episode is derived (inherited) from 'available'
data objects. The derivation
is not original data.
However, should I choose to expand the 'derivation' to include
additional data the results may well
As long as the 'original data' is not changed and is made available to
all subsequent accesses, and
others can define their own 'episodes', issues are likely to be move to
the conference room. in which
the background of the episode can be thoroughly reviewed.
A concern is that dedicating space in an EHR system to handling episodes
, their tracking and their
resolution, not to mention the privacy concerns and accesses by
insurers, may become burdensome.
It it apparent that multi potentially interacting episodes may exist and
there may be no easy
resolution to the lot of them.
Suggest a segmentation of 'episodes' so that they can be readily
identified and isolated. In particular,
episodic data should not be merged with the original data. Their
existance and location should be
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
More information about the openEHR-technical