gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] address@hidden: Episodes in openEHR]


From: Karsten Hilbert
Subject: [Gnumed-devel] address@hidden: Episodes in openEHR]
Date: Sat, 20 Nov 2004 09:07:59 +0100
User-agent: Mutt/1.3.22.1i

FYI. Seems we aren't so bad.

Karsten
----- Forwarded message from Thomas Beale <address@hidden> -----
> 
> 
> This is part of a discussion that started off the list. The need is to be able
> to model Episodes in openEHR, while remaining compatible with available
> structures.
> 
> Currently, there is no "Episode" class (although this doesn't necessarily have
> to remain this way). Up to now, we have never been able to nail down
> sufficiently 'standard' requirements to satisfy everyone's idea of an
> "episode".  Instead we have suggested that Folders be used as reference
> containers to Compositions considered to have occurred in an episode. The
> current EHR reference model shows this.
> 
> More recent thinking on this issue:
> - on my recent visit to Mayo Clinic at Rochester Minnesota, I discovered that
> their idea of an Episode in the MICS system is "a period of care overseen by a
> particular clinician". E.g. if someone comes in with an injury, the doctor
> referred to (by a GP or by A&E) 'runs' the episode. Even if the patient 
> sutains
> an MI while in hospital, and that becomes her main problem, and a cardiologist
> gets involved, the original clinician in almost all cases is in charge of the
> episode, and will make the discharge summary. An episode can be 'closed' on 
> the
> MICS system, but can be reopened by some special operation, e.g. if erroneous
> information is spotted later on. I seem to remember that someone else can take
> over an episode - presumably if the original clinician becomes unable to
> continue giving care for some reason. (Someone from Mayo on this list might
> want to correct me if I have any of this wrong).
> 
> - Maarten Spook of 2Cure, Amsterdam has some very typical requirements of an
> "Episode", as follows:
> We think of attributes like:
> 
>  1. startDateTime: the date-time the episode is started (medically)
>  2. stopDateTime: the date-time the episode has ended (medically). When 
> present
>     this folder is closed?
>  3. createdDateTime: the date-time the episode was created (administrative)
>  4. contributers: care providers and their role (participations?) It would be
>     clear to see who had added info and who is responsible for this episode 
> etc
>  5. structured annotation: a short description of the content / context of the
>     episode
> 
> My comment on this is: of the above attributes, it is the first 3, and maybe 
> #5
> which need to be associated with an episode as such. Contributors can be
> determined from the contributors to versioned Compositions in openEHR 
> (remember
> "Contributor" is actually a class itself in the openEHR Common model). Let us
> consider if we could achieve this just using Folders, as a "straw man"
> proposal.
> 
>  1. clinical start date time can be determined from the start_time of the 
> first
>     Composition in the Folder
>  2. clinical stop date time can be determined from the endt_time of the last
>     Composition in the Folder
>  3. created date time of the "episode" - administrative. Depends on what this
>     really means. The creation date time of the Folder representing the 
> episode
>     is easy - it is the time_committed in the audit attribute of the type
>     VERSION<COMPOSITION> resulting from the class VERSIONED_COMPOSITION being 
> a
>     binding of VERSION_REPOSITORY to COMPOSITION.
>  4. contributors - as mentioned above, these can be derived from inspecting
>     Compositions in the Folder
>  5. structured annotation describing episode. Usually this would be in the
>     discharge summary, itself a Composition, containing narrative and links to
>     previous Compositions & Entries in the episode. However, does it need to 
> be
>     someting else?
>  6. Maarten also mentioned that in their system, they want to be able to
>     "close" an episode, in a similar sense as the Mayo description given 
> above.
>     This functionality doesn't exist in openEHR.
> 
> Lastly, I believe in CEN ENV13606 there was the idea of a Folder that could be
> "closed", presumably to simulate an episode. However, some users of 13606 
> don't
> want to use Folders at all, so where would that leave them.
> 
> Some questions:
> 
>   * are there other attributes or functions required in the "episode" concept?
>   * is there any hope of standardising the idea of "episode" sufficiently to
>     create a class in the reference model for it?
>   * is the Folder good enough to model an episode?
> 
> 
> over to the group....
> 
> - thomas beale
> 
> - If you have any questions about using this list, please send a message to
> address@hidden

----- End forwarded message -----
----- Forwarded message from Tim Churches <address@hidden> -----

> X-Mailer: Ximian Evolution 1.4.0 
> 
> On Sat, 2004-11-20 at 12:42, Thomas Beale wrote:
> > This is part of a discussion that started off the list. The need is to
> > be able to model Episodes in openEHR, while remaining compatible with
> > available structures. 
> 
> See http://bmj.bmjjournals.com/cgi/content/full/329/7476/1207
> 
> and http://snipurl.com/armv
> 
> for definitions of statistical episodes, which may or may not correspond
> to clinical episodes.
> 
> -- 
> 
> Tim C
> 
> PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
> or at http://members.optushome.com.au/tchur/pubkey.asc
> Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0
> 
> 
> 
> -
> If you have any questions about using this list,
> please send a message to address@hidden

----- End forwarded message -----

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]