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 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 d.lloyd at openehr.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5690 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041120/f6480d92/attachment.bin>
