Gerard and Colleagues,

At Mayo Episodes of care start with any billable encounter with the health 
system (e.g. clinician visit, lab test, etc.) and ends when the clinician of 
primary record says that the episode is complete.  For curable illness this 
often occurs after the cure.  For chronic illnesses it usually ends when the 
patient reaches a steady state or a goal (e.g. Diabetes Mellitus with a HgA1C < 
7.0 mg/dl).  For surgeries it may be after the first post hospital visit.  For 
medical hospitalizations it is often at the time of discharge.  This has two 
important implications.  One there is one clinician who is identified as the 
team leader of record who is charged to coordinate all of the care from any 
provider in the health system.  Two, at the end of an episode the clinician is 
mandated to sum up the episode and state for the record what are the final 
diagnoses for this episode of care.

I hope that this helps.

Warm regards,

Peter

Peter L. Elkin, MD
Professor of Medicine
Mayo Clinic, College of Medicine


> -----Original Message-----
> From: owner-openehr-technical at openehr.org [SMTP:owner-openehr-technical at 
> openehr.org] On Behalf Of Gerard Freriks
> Sent: Saturday, November 20, 2004 4:45 AM
> To:   Thomas Beale
> Cc:   Openehr-Technical
> Subject:      Re: Episodes in openEHR
> 
> Colleagues, 
> 
> Consider the following as requirements from the Netherlands. 
> 
> The Dutch GP organization NHG has defined Episode as: 
> An Episode is a chronological collection of medical data (episode items) of 
> one patient and describes the state changes over time concerning one health 
> problem. 
> 
> The name of the episode describes the health problem  (health issue) and can 
> be changed over time. 
> 
> The episode unordered list contains all episodes, open or closed. 
> Episodes can have an attribute indicating "attention" 
> Episodes can be closed and opened. 
> Episodes can be joined and split 
> 
> One episode consists of episode items. 
> Episode items are: report as the result of a contact, Prescription/Order, 
> Diagnostic Archive, Correspondence. 
> 
> Most of Marten Spook's attributes stem from these Dutch GP requirements. 
> I consider Episodes as an alternative view on the information collected. 
> It is a list consisting of links pointing to registered information that is 
> available in the system. 
> The preferred place to store this list is the Folder. 
> 
> And then there are our DBC's (DRG's) One DBC is almost the same as an 
> Episode. 
> 
> Gerard 
> 
> -- <work> -- 
> Gerard Freriks 
> TNO-PG 
> Zernikedreef 9 
> 2333CK Leiden 
> The Netherlands 
> 
> +31 71 5181388 
> +31 654 792800 
> On 20 Nov 2004, at 02: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.  
> 
>        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 epis> ode - 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 d.lloyd at openehr.org
> 
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Reply via email to