[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnumed-devel] address@hidden: Episodes in openEHR],
Karsten Hilbert <=