Dear all,
Am I correct to conclude and propose that:
- episode: situation considered to occupy a time interval
- there are at least 4 context's in which the term 'Episode' is defined:
disease related (point of view of the patient),
treatment related (point of view healthcare provider),
adminstrative contact related (point of view of healthcare
institution),
insurance related (point of view payer)
- sometimes the period is real and enumerated (dd-mm-yy, ISO 8601 :
1988Data elements and interchange formats - Information interchange -
Representation of dates and times),
sometimes indefinite (one week ago, some weeks ago, ongoing, during,
before, etc, as defined in CEN/TC251 EN1238 Time standard for health
care specific problems)
Gerard
--
--
Gerard Freriks, MD
Convenor CEN/TC251 WG1
TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands
+31 71 5181388
+31 654 792800
On 04 Dec 2004, at 01:00, 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
>
> ?
>
> 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 Fran?ois 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 provider
> - episode of care: situation during which health care activities are
> performed by one health care provider to address one health issue
> - cumulative episode of care: 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 13499 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041204/41d788e6/attachment.bin>
