Episodes in openEHR

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Episodes in openEHR

[Tim Churches]

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 d.lloyd at openehr.org

Episodes in openEHR

[Thomas Beale]

Tim Churches wrote:

>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
>  
>
Definition from this link:
/The basic record is^ a finished consultant episode of care (the time 
spent under^ the care of one consultant). An admission, or spell, is 
defined^ as a continuous period of time spent as a patient within a 
trust,^ and may include more than one episode. Using HES data, we 
contrasted^ spell based activity and episode based activity, using 
myocardial^ infarction as an example.
..
/Measuring hospital activity by episode could result in^ overestimates 
of up to 50% for myocardial infarction. In 2.9%^ of spells, vague 
symptoms and signs were noted in the primary^ diagnosis of the first 
episode with myocardial infarction in^ the subsequent episode. 
Overestimates carry obvious implications^ for estimating the incidence 
of disease and assessing healthcare^ outcomes.


This would make the episode at Mayo as I described it a "spell"...

>and http://snipurl.com/armv
>  
>
Defintion from this link:
The period of admitted patient care between a formal or statistical 
admission and a formal or statistical separation, characterised by only 
one care type.

I personally think this is not that useful, since older and complex 
patients just don't have only one care type (which I take to mean 
specialty).

I would suggest that the most meaningful defintion of "episode" is more 
like the Mayo one - an admission (= acceptance by a provider institution 
to undertake provision of healthcare to a patient) to the point in time 
when the same institution performs a transfer of care to another 
provider - a referral of some kind to e.g. the GP, aged care home, 
self-care at home.

But we also have to ask the question of what use is knowing where the 
boundaries of an episode are. Clearly cost accounting occurs at a much 
finer level of detail, which is easily supported by models like openEHR 
(to our knowledge to date at least); it seems to me that an episode is 
more to do with a period of legal responsibility of care by a provider 
(institution).

- thomas


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Gerard Freriks]

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

--  --
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 resulting from the 
> class VERSIONED_COMPOSITION being a binding of VERSION_REPOSITORY to 
> COMPOSITION.
>   4.  contributors - as mentioned above, these can be derived from 
> 

Episodes in openEHR

[Elkin, Peter L., M.D.]

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 
> 
> --  -- 
> 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.  stop

Episodes in openEHR

[Philippe AMELINE]

Hi to all,

The first question, when it comes to "episodes" is to know if you are 
talking about "episodes of care" or "episodes of disease". Of course 
both concepts are very different.
To try a joke, I could says "tell me how you manage your patients over 
time, and I will tell you who you are".

Certainly, the choise of Episodes of disease, as described by Gerard is 
the vision of GPs and closely related to Problem Oriented Medical Record 
(POMR).
Episodes of care is either the vision of a care place or the way a group 
is organisd to treat a specific disease : for example the treatment of 
cancer is organized using a pre-determined set of Episodes of care.

 From my point of view, Episodes of disease are the primary concept when 
you deal with continuity of care. An episodes of care is a technical 
concept, and often a local concept. Clearly episodes of care occur in an 
episode of disease.
If the Episode of disease if a worldwide clearly defined concept, 
through the POMR structure and the WONCA organization, you probably will 
find a specific definition of the episode of care in each care 
organization (care places or care networks) and I don't know if you can 
standardize it.

Best regards,

Philippe

> 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
>
> --  --
> 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 
>> (me

Episodes in openEHR

[Tim Churches]

On Sat, 2004-11-20 at 20:19, Thomas Beale wrote:

> >and http://snipurl.com/armv

(which is the Australian definition)

> >
> Defintion from this link:
> The period of admitted patient care between a formal or statistical 
> admission and a formal or statistical separation, characterised by only 
> one care type.
> 
> I personally think this is not that useful, since older and complex 
> patients just don't have only one care type (which I take to mean 
> specialty).

Although you would never know it from the web page, by "care type", they
mean "acute care" versus "rehabilitation" versus "psychiatric". These
distinctions are purely administrative and have no definitive clinical
or epidemiological meaning. Nevertheless, it is teh basis of all
official Australian hospital statistics. The British definitions are
much better, I think.

> 
> I would suggest that the most meaningful defintion of "episode" is more 
> like the Mayo one - an admission (= acceptance by a provider institution 
> to undertake provision of healthcare to a patient) to the point in time 
> when the same institution performs a transfer of care to another 
> provider - a referral of some kind to e.g. the GP, aged care home, 
> self-care at home.

We refer to that as a "separation" - which begins with inpatient
admission to a healthcare facility and ends with discharge, transfer or
death. You also need rules for "leave" - some patients (eg long-term
psych patients, rehab patients) go on leave during the course of one
admission/separation.

> But we also have to ask the question of what use is knowing where the 
> boundaries of an episode are. Clearly cost accounting occurs at a much 
> finer level of detail, which is easily supported by models like openEHR 
> (to our knowledge to date at least);

Hospital- and ward-level cost accounting might take place at finer
levels of detail, but hospital funding tends to use these
administrative/"statistical" definitions, as noted in the BMJ article.
An EHR repository will not curry much favour with administrators (who
tend to hold the purse-strings) if it can't give them the information
they want (which is not necessarily what they need...)

>  it seems to me that an episode is 
> more to do with a period of legal responsibility of care by a provider 
> (institution).

Episodes could be called "funding temporal units".

Tim C


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Tim Churches]

On Sun, 2004-11-21 at 06:19, Elkin, Peter L., M.D. wrote:
> 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. 

That is quite different to the model of care in Australian hospitals
(and British hospitals when I worked there 20 yrs ago - probably still
the same). Patients are the responsibility of "teams" (or "firms")
organised around a consultant/specialist (or a small group of them).
Thus, if a surgical patient is admitted to ICU post-surgery, then it is
the ICU team (and ultimately the ICU specialist in charge) who has the
final say in the patient's care (well, the patient and relatives may
have some say...) while they are in the ICU. The surgical team might
drop by to see how the patient is going and to assess te outcome of the
surgery, but the surgeon doesn't manage, for example, the haemodynamics,
ventilation and blood sugars of the patient. Responsibility for
recording what happens falls to the teams currently in charge of the
patient.

>  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.

The defect in the Australian model is that the responsibility for this
summing up falls to the last team to look after the patient prior to
separation - and that team may not be very interested or knowledgeable
about the treatment which went on before they took over the patient
(although it would be rare or unfortunate if they did not know enough to
record some sort of precis of it). However, as a GP, I often used to
receive hospital discharge summaries which devoted one line to the
extensive surgery which a patient underwent and the weeks which they
spent in ICU recovering from complications, but half a page to their
rehabilitation and functional status at discharge. Of course that is
quite appropriate for a discharge summary, and perhaps for a
community-based EHR. Less useful if some other surgeon in some other
hospital needs to revisit the patient's earlier surgery (but surgeons
prefer to look for themselves and never believe anything written in the
medical record - or EHR).

Tim C


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Tim Churches]

On Sun, 2004-11-21 at 07:22, Philippe AMELINE wrote:
> The first question, when it comes to "episodes" is to know if you are 
> talking about "episodes of care" or "episodes of disease". Of course 
> both concepts are very different.

Exactly!
 
> 
> If the Episode of disease if a worldwide clearly defined concept, 
> through the POMR structure and the WONCA organization, you probably will 
> find a specific definition of the episode of care in each care 
> organization (care places or care networks) and I don't know if you can 
> standardize it.

Probably true. Jurisdiction- and organisation-specific "episode of care"
archetypes are likely to be needed.

Tim C


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Thomas Beale]

Tim Churches wrote:

>Although you would never know it from the web page, by "care type", they
>mean "acute care" versus "rehabilitation" versus "psychiatric". These
>distinctions are purely administrative and have no definitive clinical
>or epidemiological meaning.
>
i.e. more or less "setting"?

>>I would suggest that the most meaningful defintion of "episode" is more 
>>like the Mayo one - an admission (= acceptance by a provider institution 
>>to undertake provision of healthcare to a patient) to the point in time 
>>when the same institution performs a transfer of care to another 
>>provider - a referral of some kind to e.g. the GP, aged care home, 
>>self-care at home.
>>
>>
>
>We refer to that as a "separation" - which begins with inpatient
>admission to a healthcare facility and ends with discharge, transfer or
>death. You also need rules for "leave" - some patients (eg long-term
>psych patients, rehab patients) go on leave during the course of one
>admission/separation.
>
>  
>
in your understanding Tim, does "separation" mean transfer of legal 
responsibility for care?

>Episodes could be called "funding temporal units".
>  
>
is the best way to develop a model for "Episode" in a reference model 
like openEHR to start with a model of funding/cost reporting? That would 
almost seem to guarantee that a common model of episode is going to be 
dificult to find, since such matters are quite dependent on how 
healthcare is financed in each country.

- thomas


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Thomas Beale]

Clearly this discussion will run a while longer, and we can hope to hear 
from other clinicians, and from a variety of geographical locations and 
clinical cultures. At this point, can we suggest that:

1. there are "episodes of care", which are to do with a) 
accounting/reporting and/or b) acceptance / discharge of legal 
responsibility for care ("separation")
2. there are "episodes of illness", which are to do with the course of a 
problem/issue/disease. What about pregnancy, chronic asthma, and 
conditions which seem to slide from being chronic to being solved to 
relapses (e.g. back pain)?

I think "episodes of illness" can be modelled with openEHR (and CEN 
13606; possibly CDA as well) - it is done using links between Entries, 
Compositions etc to create "threads" (which may be branching) of 
recorded items relating to each problem. Each link indicates which 
problem it is about. A single given recording may be multiply classified 
as data relating to more than one problem. Of course we need more 
experience with this aspect of the models to see how well it will work. 
Philippe Ameline's system is probably ahead of any others I have seen in 
this respect - maybe he wants to add some wisdom here.

I would like to know who would agree with the proposition that an 
"episode of care" is bounded by acceptance & discharge of legal 
responsibility for care provision by a given provide (institution).

- thomas


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Tim Churches]

Thomas Beale wrote:
> Tim Churches wrote:
> 
>> Although you would never know it from the web page, by "care type", they
>> mean "acute care" versus "rehabilitation" versus "psychiatric". These
>> distinctions are purely administrative and have no definitive clinical
>> or epidemiological meaning.
>>
> i.e. more or less "setting"?

No, because a patinet can stay in exactlyteh same bed in teh same 
hospital and change bewteen an acute care epidsode and a rehab episode. 
Yes, its completely artifical, but that's how the bean counters count.

> in your understanding Tim, does "separation" mean transfer of legal 
> responsibility for care?

Yes.

> 
>> Episodes could be called "funding temporal units".
>>  
>>
> is the best way to develop a model for "Episode" in a reference model 
> like openEHR to start with a model of funding/cost reporting? That would 
> almost seem to guarantee that a common model of episode is going to be 
> dificult to find, since such matters are quite dependent on how 
> healthcare is financed in each country.

Yup, just pointing out that openEHr will need to accomodate these 
national requirements if openEHR repositories are to please the bean 
counters.

Tim C
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Christopher Clay]

Hi
I think Tim Churches is more on track.  Gerard appears to be describing a
"problem" as I would understand it in POMR.  An episode in natural language
implies a discreet period of time and I would make a plea that we (you?)
retain the meaning of any term that is closest to its natural meaning.  An
episode is an incident in a series of events or something along those lines.
A problem can be 'active', 'inactive', or 'terminated'.  An episode is
'active' or 'complete'.  I propose that there can only be one episode
effecting a person at one time.  You can only be in one place at one time
(except for some odd situations such as a person who takes leave from an
inpatient facility for a couple of hours for some ongoing and completely
unrelated treatment as an outpatient at private rooms. They may not even
tell the inpatient facility why they want to go out. It may be better to
call that two "concurrent" episodes for practical reasons because in this
situation, he/she is behaving semantically like two people.)
I propose the following definition: "An episode is a period of management of
a patient from the time of presentation to a medical unit (which can be
anything from the teams or "firms" in a teaching hospital to an individual
practitioner) until the unit or a proxy "discharges" the patient."  The
proxy could be a unit (on the last unit) to which the patient is transferred
during the course of the episode. (An example could be general surgery =>
cardiology => cardiac surgery => rehabilitation: all one episode.)
I would be against using definitions based on legal responsibilities as that
is truly nebulous, especially in common law jurisdictions and is ultimately
at the whim of some judge.
It is not very precise and can never be as each specialty and medical
culture may have a different approach.  However, almost everyone "knows"
when an episode is done.  That is why I propose that the treating unit
"declare" the end of an episode.  This is where the word "discharge" needs
definition.  It is an active, transitive verb and that is why the intention
of the unit/doctor concerned should be the paramount consideration.  It
their intention to relinquish direct responsibility that is crucial.  It is
comparable to death in our jurisdiction.  You are dead when a doctor says
you are! (i.e. declares "life extinct", or in the case of "brain dead", two
doctors after due deliberation but that is a special case.)
Our hospital systems speak of a "separation" which befits a hospital as
discharge is a form of separation.  It might be more difficult in GP.  I
think an episode has to be considered separate from say just "discharge from
hospital" which is better termed a "separation" or similar.  An episode can
involve a period of inpatient and outpatient treatment.
The question of transfer between units is difficult. If a person is admitted
under the abdominal surgeons with a stomach ulcer and is subsequently
transferred to the cardiologists when it is established 24 hours later that
it is a myocardial infarct, is that one or two episodes?  Most people would
consider it to be one episode in natural terms but there could be a rule
requiring that this is two separate "incidents" for the purposes of
remuneration for example.  It would be up to the two units as to whether
this would be called one or two episodes and could be handled semantically
by allowing that an episode can involve semantically "seamless" transfer
from one unit to another until a unit declares "DISCHARGE" and then the
episode is done.
Cheers
CDC, Perth

- Original Message -
From: "Thomas Beale" 
To: "Openehr-Technical" 
Sent: Sunday, November 21, 2004 9:02 AM
Subject: Re: Episodes in openEHR


>
> Clearly this discussion will run a while longer, and we can hope to hear
> from other clinicians, and from a variety of geographical locations and
> clinical cultures. At this point, can we suggest that:
>
> 1. there are "episodes of care", which are to do with a)
> accounting/reporting and/or b) acceptance / discharge of legal
> responsibility for care ("separation")
> 2. there are "episodes of illness", which are to do with the course of a
> problem/issue/disease. What about pregnancy, chronic asthma, and
> conditions which seem to slide from being chronic to being solved to
> relapses (e.g. back pain)?
>
> I think "episodes of illness" can be modelled with openEHR (and CEN
> 13606; possibly CDA as well) - it is done using links between Entries,
> Compositions etc to create "threads" (which may be branching) of
> recorded items relating to each problem. Each link indicates which
> problem it is about. A single given recordin

Episodes in openEHR

[Gerard Freriks]

Colleagues,

Looking at the discussion it is very obvious that there are several 
points of view and all are reasonable and correct.

One: the patient viewpoint. The Episode (as I described): one patient, 
one health issue, and many healthcare parties, contacts, etc
Two: the Healthcare party viewpoint. The administrative view. One 
admission upto discharge for whatever reason.
Three: What is the viewpoint as seen from the third type of healthcare 
party? The payor.
Four: What is the viewpoint as seen from Government reporting, 
reserach, etc?

Each viewpoint needs its own definitions of attributes and code systems
And all must be harmonized.
I expect that work in CEN/TC251 (System of Concepts for Continuity of 
Care) might enlighten us.


Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 20 Nov 2004, at 20:19, Elkin, Peter L., M.D. wrote:

> 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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2052 bytes
Desc: not available
URL: 

Episodes in openEHR

[Karsten Hilbert]

> The first question, when it comes to "episodes" is to know if you are 
> talking about "episodes of care" or "episodes of disease".
Interesting distinction. We (GnuMed) never thought of that but
implicitely used episode of disease (eg. our episodes are
stored in a table named clin_episode).

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Karsten Hilbert]

> 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. 
This is what GnuMed uses, too.

> The name of the episode describes the health problem  (health issue) 
> and can be changed over time.
Same with GnuMed. We allow any item within the clinical
narrative to be declared the defining item for the episode
name. The episode name describes the current active health
problem. The term health issue is used to describe underlying,
more general (chronic?) issues with one's health. Those are
highly likely to affect health of the entire lifetime with
differing levels of activity (eg. may be dormant for a while
but will still exist as a "threat"). Such a health issue may
show up in several episodes each of which pertains to a
different episode in time where a particular health problem
was active.

> The episode unordered list contains all episodes, open or closed. 
> Episodes can have an attribute indicating "attention" 
We consider the episode to "just be there" whether we pay
attention to it or not (and different clinicians may in fact
define the open-/closedness of an episode differently - and
they can, it's at the discreetion of the user to define their
state). Only members of it (eg. clinical items being attached
to an episode) can be "clinically_relevant" (eg. need
attention). One may want to define the deliberate association
that any episode with a clinical item that is
clinically_relevant to always be open. But this does not seem
mandatory.

> Episodes can be closed and opened. 
Agree.

> Episodes can be joined and split 
Agree.

> One episode consists of episode items. 
Agree.

> Episode items are: report as the result of a contact, 
> Prescription/Order, Diagnostic Archive, Correspondence.

> I consider Episodes as an alternative view on the information 
> collected. 
Agree.

> It is a list consisting of links pointing to registered information
> that is available in the system.
We have that information always bound to an episode - that
which is bounded by the states the primary clinician thinks is
useful. This we can do because we target the GP/community
specialist setting. It can be redefined, however.

Karsten Hilbert, MD
GnuMed i18n coordinator
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Karsten Hilbert]

> 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.

This is quite telling. Although Mayo certainly appears to be a
wee bit larger than my surgery (GnuMed) both are served well by
pretty much exactly the same definition of (medical) episode -
even though one is in the US while the other is in Germany.
Doesn't that indicate something about the validity of the
definition ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Thomas Beale]

Christopher Clay wrote:

>I propose the following definition: "An episode is a period of management of
>a patient from the time of presentation to a medical unit (which can be
>anything from the teams or "firms" in a teaching hospital to an individual
>practitioner) until the unit or a proxy "discharges" the patient."  The
>proxy could be a unit (on the last unit) to which the patient is transferred
>during the course of the episode. (An example could be general surgery =>
>cardiology => cardiac surgery => rehabilitation: all one episode.)
>I would be against using definitions based on legal responsibilities as that
>is truly nebulous, especially in common law jurisdictions and is ultimately
>at the whim of some judge.
>  
>
Actually, I agree with that, but we still need to be precise enough for 
the definition to work. As you say...

>...  This is where the word "discharge" needs
>definition.  It is an active, transitive verb and that is why the intention
>of the unit/doctor concerned should be the paramount consideration.  It
>their intention to relinquish direct responsibility that is crucial.
>
i.e. responsibility for providing any further care (until some later 
moment perhaps when you again accept responsibility for care)

>  It is
>comparable to death in our jurisdiction.  You are dead when a doctor says
>you are! (i.e. declares "life extinct", or in the case of "brain dead", two
>doctors after due deliberation but that is a special case.)
>Our hospital systems speak of a "separation" which befits a hospital as
>discharge is a form of separation.  It might be more difficult in GP.  I
>think an episode has to be considered separate from say just "discharge from
>hospital" which is better termed a "separation" or similar.  An episode can
>involve a period of inpatient and outpatient treatment.
>  
>
So a "separation" doesn't involve follow-up outpatient treatment/monitoring?

>The question of transfer between units is difficult. If a person is admitted
>under the abdominal surgeons with a stomach ulcer and is subsequently
>transferred to the cardiologists when it is established 24 hours later that
>it is a myocardial infarct, is that one or two episodes?  Most people would
>consider it to be one episode in natural terms but there could be a rule
>requiring that this is two separate "incidents" for the purposes of
>remuneration for example.  It would be up to the two units as to whether
>this would be called one or two episodes and could be handled semantically
>by allowing that an episode can involve semantically "seamless" transfer
>from one unit to another until a unit declares "DISCHARGE" and then the
>episode is done.
>  
>
If we followed the Mayo model (and your definition, depending on which 
granularity of "medical unit" is identified), it would be one episode, 
but detailed EHR recording will of course provide correct 
coding/classification of the incidents, allowing remneratoin to occur as 
usual.

How common is the Mayo model, where the initial clinician is the "team 
leader" (as Peter Elkin explained), and shepherds the episode through 
from go to woe?

- thomas


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[Christopher Clay]

Hi Tomas

"Separation" in our system means departure from hospital and does not imply
anything specific about follow up. A majority are followed up but if you
have fully recovered from a simple illness, you may be discharged to the
care of your GP or even to formal no follow up at all.

In our set-up, the team leader is the clinician under whom the patient is
"admitted" at the time and will change if the patient is transferred to
another unit.  We don't really speak of "team leaders".  The usual question
is "Who is this patient under?"   One important exception is ICU.  To be
admitted, a patient must be "under" another non ICU team as well as the ICU
team involved.  Thus all ICU patients are under two teams. The rational is
that the ICU can discharge anyone to the ordinary wards at will without
having to "find a team" if they need to free up a bed urgently.  The outside
team has to take the patient whether they like it or not and the ICU is
never left "holding the baby".  If a patient is admitted direct to ICU in an
emergency and no one else will take responsibility for them, the general
medical team of the day (of admission) is the default outside unit and then
have to try to "slough" the patient to a sub specialist or other appropriate
team, or take the patient on discharge.

Cheers
CDC, Perth


- Original Message -
From: "Thomas Beale" 
To: "Openehr-Technical" 
Sent: Monday, November 22, 2004 9:42 AM
Subject: Re: Episodes in openEHR


> Christopher Clay wrote:
>
> >I propose the following definition: "An episode is a period of management
of
> >a patient from the time of presentation to a medical unit (which can be
> >anything from the teams or "firms" in a teaching hospital to an
individual
> >practitioner) until the unit or a proxy "discharges" the patient."  The
> >proxy could be a unit (on the last unit) to which the patient is
transferred
> >during the course of the episode. (An example could be general surgery =>
> >cardiology => cardiac surgery => rehabilitation: all one episode.)
> >I would be against using definitions based on legal responsibilities as
that
> >is truly nebulous, especially in common law jurisdictions and is
ultimately
> >at the whim of some judge.
> >
> >
> Actually, I agree with that, but we still need to be precise enough for
> the definition to work. As you say...
>
> >...  This is where the word "discharge" needs
> >definition.  It is an active, transitive verb and that is why the
intention
> >of the unit/doctor concerned should be the paramount consideration.  It
> >their intention to relinquish direct responsibility that is crucial.
> >
> i.e. responsibility for providing any further care (until some later
> moment perhaps when you again accept responsibility for care)
>
> >  It is
> >comparable to death in our jurisdiction.  You are dead when a doctor says
> >you are! (i.e. declares "life extinct", or in the case of "brain dead",
two
> >doctors after due deliberation but that is a special case.)
> >Our hospital systems speak of a "separation" which befits a hospital as
> >discharge is a form of separation.  It might be more difficult in GP.  I
> >think an episode has to be considered separate from say just "discharge
from
> >hospital" which is better termed a "separation" or similar.  An episode
can
> >involve a period of inpatient and outpatient treatment.
> >
> >
> So a "separation" doesn't involve follow-up outpatient
treatment/monitoring?
>
> >The question of transfer between units is difficult. If a person is
admitted
> >under the abdominal surgeons with a stomach ulcer and is subsequently
> >transferred to the cardiologists when it is established 24 hours later
that
> >it is a myocardial infarct, is that one or two episodes?  Most people
would
> >consider it to be one episode in natural terms but there could be a rule
> >requiring that this is two separate "incidents" for the purposes of
> >remuneration for example.  It would be up to the two units as to whether
> >this would be called one or two episodes and could be handled
semantically
> >by allowing that an episode can involve semantically "seamless" transfer
> >from one unit to another until a unit declares "DISCHARGE" and then the
> >episode is done.
> >
> >
> If we followed the Mayo model (and your definition, depending on which
> granularity of "medical unit" is identified), it would be one episode,
> but detailed EHR recording will of course provide correct
> coding/classification of the incidents, allowing remneratoin to occur as
> usual.
>
> How common is the Mayo model, where the initial clinician is the "team
> leader" (as Peter Elkin explained), and shepherds the episode through
> from go to woe?
>
> - thomas
>
>
> -
> 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

Episodes in openEHR

[Sam Heard]

Tim

These links are very helpful...particularly to show that the idea of episode is 
about one consultant - rather than admission. The Australian data dictionary is 
about an admitted patient episode.

It is clear that many types of groupings will be required. The Folders solution 
may be one - but I believe a 'persistent' EVALUATION which is archetyped for 
the 
purpose is more likely to be usefulas it will allow collection of whatever 
data is required.

Sam


Tim Churches wrote:

> 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.
> 
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Episodes in openEHR

[SMK]

Greetings:
I am new to this discussion but had a couple of thoughts.
I am just in the final stages (actually finished) modeling some data for
oncology patients.

I would like to suggest that an "episode" be centered around a single
patient illness, and not dependent on whether that patient was in or out
of the hospital. This is speaking from a clinician's viewpoint which
involves a continuum of care, hospitalization being one event.

In regards to the Mayo model, my suggestion would be that the "episode"
for the patient mentioned be the injury, the MI a second "episode" etc.
The physicians associated with that patient's care are linked via
connecting tables, and the lead physician designated in the linking
table if that is desirable. That episode has many events associated with
it, including hospital admission, discharge, tests, procedures. All of
those things are housed in other linked tables.

In regards to the GI ulcer and MI patient mentioned below, my suggestion
would be two episodes, one of which was closed (ulcer question).
Physicians need something slightly different than institutions because
our focus is on responding to the disease episode, in or out of the
hospital, so none of this may apply. Just thought I'd jump in a little.

Regards,
Sally M. Knox, MD, FACS
Baylor Univ Medical Center
Dallas, Tx

-Original Message-
From: Christopher Clay [mailto:cla...@iinet.net.au] 
Sent: Monday, November 22, 2004 9:45 AM
To: Thomas Beale; Openehr-Technical
Subject: Re: Episodes in openEHR

Hi Tomas

"Separation" in our system means departure from hospital and does not
imply
anything specific about follow up. A majority are followed up but if you
have fully recovered from a simple illness, you may be discharged to the
care of your GP or even to formal no follow up at all.

In our set-up, the team leader is the clinician under whom the patient
is
"admitted" at the time and will change if the patient is transferred to
another unit.  We don't really speak of "team leaders".  The usual
question
is "Who is this patient under?"   One important exception is ICU.  To be
admitted, a patient must be "under" another non ICU team as well as the
ICU
team involved.  Thus all ICU patients are under two teams. The rational
is
that the ICU can discharge anyone to the ordinary wards at will without
having to "find a team" if they need to free up a bed urgently.  The
outside
team has to take the patient whether they like it or not and the ICU is
never left "holding the baby".  If a patient is admitted direct to ICU
in an
emergency and no one else will take responsibility for them, the general
medical team of the day (of admission) is the default outside unit and
then
have to try to "slough" the patient to a sub specialist or other
appropriate
team, or take the patient on discharge.

Cheers
CDC, Perth


- Original Message -
From: "Thomas Beale" 
To: "Openehr-Technical" 
Sent: Monday, November 22, 2004 9:42 AM
Subject: Re: Episodes in openEHR


> Christopher Clay wrote:
>
> >I propose the following definition: "An episode is a period of
management
of
> >a patient from the time of presentation to a medical unit (which can
be
> >anything from the teams or "firms" in a teaching hospital to an
individual
> >practitioner) until the unit or a proxy "discharges" the patient."
The
> >proxy could be a unit (on the last unit) to which the patient is
transferred
> >during the course of the episode. (An example could be general
surgery =>
> >cardiology => cardiac surgery => rehabilitation: all one episode.)
> >I would be against using definitions based on legal responsibilities
as
that
> >is truly nebulous, especially in common law jurisdictions and is
ultimately
> >at the whim of some judge.
> >
> >
> Actually, I agree with that, but we still need to be precise enough
for
> the definition to work. As you say...
>
> >...  This is where the word "discharge" needs
> >definition.  It is an active, transitive verb and that is why the
intention
> >of the unit/doctor concerned should be the paramount consideration.
It
> >their intention to relinquish direct responsibility that is crucial.
> >
> i.e. responsibility for providing any further care (until some later
> moment perhaps when you again accept responsibility for care)
>
> >  It is
> >comparable to death in our jurisdiction.  You are dead when a doctor
says
> >you are! (i.e. declares "life extinct", or in the case of "brain
dead",
two
> >doctors after due deliberation but that is a special case.)
> >Our hospital systems speak of a "separation" which befits a hospital
as
> >discharge is a 

Episodes in openEHR

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Episodes in openEHR

[mthak...@siu.edu]

Please unsubscribe me.  The unsubscribe email does not work for 
me.  It bounces back.

Thanks.


-- next part --
An HTML attachment was scrubbed...
URL: 

Episodes in openEHR

[Christopher Clay]

I agree that there needs to be more than one type of episode. In oncology, 
there is often one illness fairly well defined where the patient lives or dies. 
In other specialties, a disease is lifelong once it starts and the patient dies 
with the disease and not of it.  In that case the "episodes" are better thought 
of as exacerbation which settle often for long periods.  Each specialty may 
have a different idea of what constitutes an episode.  Is psoriasis one illness 
and hence one episode as it may last 60+ years!
Cheers
CDC, Perth 

- Original Message - 
  From: Thomas Beale 
  To: SMK 
  Cc: Christopher Clay ; Openehr-Technical 
  Sent: Wednesday, November 24, 2004 4:02 PM
  Subject: Re: Episodes in openEHR


  SMK wrote:

Greetings:
I am new to this discussion but had a couple of thoughts.
I am just in the final stages (actually finished) modeling some data for
oncology patients.

I would like to suggest that an "episode" be centered around a single
patient illness, and not dependent on whether that patient was in or out
of the hospital. This is speaking from a clinician's viewpoint which
involves a continuum of care, hospitalization being one event.

In regards to the Mayo model, my suggestion would be that the "episode"
for the patient mentioned be the injury, the MI a second "episode" etc.
  
  If we speak of "episode" as a course of an illness to a point where no more 
care is needed for that problem, (i.e. patient is a) returned to health, b) 
sustainable stabilised (chronic patients) or c) died) you are right...but the 
Mayo MICS uses the other definition of "episode" for its purposes - a period of 
care delimited by acceptance of responsibility for care and discharge from care.

  Let's not get too worked up about trying to have one sole definition for the 
word "episode". I suggest we refer to the two types as 
"episode-of-care-delivery"  and "episode-of-a-problem" (not a very good name - 
pregnancy falls under this categygory, and is not a problem for most people)

  I suggest that the issues of practical importance are:
  a) decide if either or both of these ideas of episodes need to be modelled 
explicitly in openEHR
  b) if so, name them properly
  c) define their data (i.e. model them)

  Maarten Spook's problem is to have something which includes the data:

1.. startDateTime: the date-time the episode is started (medically) 
2.. stopDateTime: the date-time the episode has ended (medically).

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 
  This kind of episode is an episode-of-care-delivery. I come back to modelling 
this with a Folder.

  As I stated earlier, the other kind of episode - related to the course of an 
illness, a pregnancy, or an 'epsiode' of some chronic disease - can be modelled 
as Links between the relevant Entries, where each Link object can be classified 
as relating to a particular problem, such as "diabetes" or "pregnancy".

  How do we want to proceed. Is it likely that there are sufficiently standard 
ideas of the two kinds of episode that they should be modelled in a more 
concrete way than with Folders and Links?

  - thomas beale

  - If you have any questions about using this list, please send a message to 
d.lloyd at openehr.org 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041124/0d14aab1/attachment.html>

Modelling Episodes in openEHR

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Modelling Episodes in openEHR

[Elkin, Peter L., M.D.]

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

 <http://www.mayo.edu/research/lbi>  

 

  _  

From: owner-openehr-technical at openehr.org 
[mailto:owner-openehr-techni...@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 
<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 
<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 

Modelling Episodes in openEHR

[lakew...@copper.net]

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 pro/vider
> - *episode of care*: situation during which /health care activities/ 
> are performed by one /health care provider/ to address one /health issue
> /- *cumulative episode of car*e: 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 comm

Modelling Episodes in openEHR

[Gerard Freriks]

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

Modelling Episodes in openEHR

[Thomas Beale]

lakewood at copper.net wrote:

>
> From Information Theory it is whatever I choose it to be and the act 
> of choosing has
> no impact upon the original data; it does have an impact on the analysis.
> In an object world an episode is derived (inherited)  from 'available' 
> data objects.  The derivation
> is not original data.
> However, should I choose to expand the 'derivation' to include 
> additional data the results may well
> change.

we agree with this. By using Folders to delimit episodes, and a special 
Composition to contain any episode adminitrative data, every institution 
can include whatever encounters or other data they want in the episode- 
all you are doing is putting references (pointers) to things, into a 
Folder, not changing the underlying data. Someone could come along later 
in the same institution, and define a new kind of episode, and 
retrospectively create all the Folders for that kind of episode in 
certain EHRs. This also won't change any of the underlying data. Episode 
Folders could also be removed, renamed, their references added to or 
removed - none of this changes any of the data either.

> BOTTOM-LINE
> As long as the 'original data' is not changed and is made available to 
> all subsequent accesses,  and
> others can define their own 'episodes', issues are likely to be move 
> to the conference room. in which
> the background of the episode can be thoroughly reviewed.
>
> A concern is that dedicating space in an EHR system to handling 
> episodes , their tracking and their
> resolution, not to mention the privacy concerns and accesses by 
> insurers, may become burdensome.
> It it apparent that multi potentially interacting episodes may exist 
> and there may be no easy
> resolution to the lot of them.

I think any institution has to have a firm model for what it thinks an 
episode is - e..g delimited by the points in time when it accepts 
responsibility for care of a patient to when it divests itself of 
reponsibility for care (by transfer of care, death, discharge/dismissal).

>
> Suggest a segmentation of  'episodes' so that they can be readily 
> identified and isolated. In particular,
> episodic data  should not be  merged with the original data. Their 
> existance and location should be
> sufficient.

I believe the Folder-based solution will do all this.

- thomas beale


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Modelling Episodes in openEHR

[Thomas Beale]

Gerard Freriks wrote:

> 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),

this kind of episode often has vague boundaries, and I think we have to 
rely on following LINKs in the EHR to find all its pieces. If I get 
bronchitis that seems to get better before it gets worse every two 
weeks, is this a single episode or many? I don't think it matters - what 
matters is being able to find all the information items relating to a 
given problem.

> treatment related (point of view healthcare provider),
> adminstrative contact related (point of view of healthcare institution),

these two are I think possible to identify as being delimited by known 
points in time, as long as the provider has a clear rule for when they 
are providing health care, versus when they are not. They might be 
providing care in parallel with other providers of course - e.g. Dipak 
had a good example of patients on weekend leave from a mental health 
institution, who become the responsibility of the local GP for the 
weekend, but don't really stop being the responsibility of the institution.

> insurance related (point of view payer)

How re-imbursing institutions want to define episodes is something I 
don't know much about, but Tim Churches or someone may have something to 
add here. How does that work in NL, Gerard? I know there is a mixture of 
government and private payors.

> - 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/)

I think such vague times can only be for clinical use (patient had an 
"episode" of bronchitis about 2 weeks go, lasting about a week). For 
billing or other computable purposes such as statistical studies, you 
have to be able to know which things are in and which are out.

- thomas




-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Modelling Episodes in openEHR

[Gerard Freriks]

Thom,

It seems we are in agreement.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 04 Dec 2004, at 12:54, Thomas Beale wrote:

> Gerard Freriks wrote:
>
>> 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),
>
> this kind of episode often has vague boundaries, and I think we have 
> to rely on following LINKs in the EHR to find all its pieces. If I get 
> bronchitis that seems to get better before it gets worse every two 
> weeks, is this a single episode or many? I don't think it matters - 
> what matters is being able to find all the information items relating 
> to a given problem.
>

And relating data in a specific context for a specific purpose that 
some times is defined in a group and sometimes defined by one actor for 
his own purpose.
Episodes likes these are more general and NOT depended on business 
rules.



>> treatment related (point of view healthcare provider),
>> adminstrative contact related (point of view of healthcare 
>> institution),
>
> these two are I think possible to identify as being delimited by known 
> points in time, as long as the provider has a clear rule for when they 
> are providing health care, versus when they are not. They might be 
> providing care in parallel with other providers of course - e.g. Dipak 
> had a good example of patients on weekend leave from a mental health 
> institution, who become the responsibility of the local GP for the 
> weekend, but don't really stop being the responsibility of the 
> institution.

episodes like these are depended on (local) business rules that vary 
from place to place.

>
>> insurance related (point of view payer)
>
> How re-imbursing institutions want to define episodes is something I 
> don't know much about, but Tim Churches or someone may have something 
> to add here. How does that work in NL, Gerard? I know there is a 
> mixture of government and private payors.

I don't know them either.
But think of mergers between firms and new insurance products and 
updates within one firm.


>
>> - 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/)
>
> I think such vague times can only be for clinical use (patient had an 
> "episode" of bronchitis about 2 weeks go, lasting about a week). For 
> billing or other computable purposes such as statistical studies, you 
> have to be able to know which things are in and which are out.
>

I agree.




> - thomas
>
>
>
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3103 bytes
Desc: not available
URL: 

Modelling Episodes in openEHR

[Bill Walton]

Hi Thomas,

Thomas Beale wrote:
>
> Someone could come along later in the same
> institution, and define a new kind of episode, and
> retrospectively create all the Folders for that kind
> of episode in certain EHRs. This also won't
> change any of the underlying data. Episode
> Folders could also be removed, renamed, their
> references added to or removed - none of this
> changes any of the data either.

Do you envision this being done manually?  Or is there a programmatic
solution?  The question this thread has raised in my mind is well
illustrated by your comment below.

>
> I think any institution has to have a firm model
> for what it thinks an episode is

Assuming that different institutions will adopt models that differ, what are
the implications for the exchange of data and the creation of a lifelong
EHR?

Thanks,
Bill

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Modelling Episodes in openEHR

[Gerard Freriks]

The disease  episode is about the patient and can and will be exchanged.

Other episodes defined on the basis of local business rules will not be 
exchanged.

GF
-- 
-- 
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 16:44, Bill Walton wrote:

>>
>> I think any institution has to have a firm model
>> for what it thinks an episode is
>
> Assuming that different institutions will adopt models that differ, 
> what are
> the implications for the exchange of data and the creation of a 
> lifelong
> EHR?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 687 bytes
Desc: not available
URL: 

Modelling Episodes in openEHR

[Sam Heard]

Bill and all

This is a very important consideration and one that we need to get right for 
lots of reasons.

Tom has been proposing an aggregation  approach - allowing us to find all data 
that relates to something - a disease, care at an institution etc.

It is clear that there are aspects of the episode that are specific to the care 
setting and administrative and billing requirements. We could have a 
composition 
that held information about the administrative aspects of the episodefor 
billing purposes or secondary data collection. It would be possible to 
archetype 
an 'episode' folder to contain one of these - and possible to define what is 
held within it should that be appropriate.

It is clear that a simple aggregation model is not enough, but we also do not 
want to have lots of folders to describe one episode from different 
perspectives.

The Mayo can only have one episode per patient at any timethis ensures that 
the person who opens an episode is responsible for closing it - and summarising 
it, tying up lose ends etc. This is a very important quality issue in 
distributed care environments. But in the Australian setting where we have 
primary and secondary care separated - the notion of secondary care episode is 
largely a billing or funding issue - although we have discharge referrals back 
to primary care.

In primary care, the idea of an episode - a single one at a time - is appealing 
to me - meaning it is non-routine care for the problems the person has. It 
stops 
what Michael Balint called the "collusion of anonymity" - a destructive outcome 
of 'shared' or 'parallel' care.

Cheers, Sam




> Hi Thomas,
> 
> Thomas Beale wrote:
> 
>>Someone could come along later in the same
>>institution, and define a new kind of episode, and
>>retrospectively create all the Folders for that kind
>>of episode in certain EHRs. This also won't
>>change any of the underlying data. Episode
>>Folders could also be removed, renamed, their
>>references added to or removed - none of this
>>changes any of the data either.
> 
> 
> Do you envision this being done manually?  Or is there a programmatic
> solution?  The question this thread has raised in my mind is well
> illustrated by your comment below.
> 
> 
>>I think any institution has to have a firm model
>>for what it thinks an episode is
> 
> 
> Assuming that different institutions will adopt models that differ, what are
> the implications for the exchange of data and the creation of a lifelong
> EHR?
> 
> Thanks,
> Bill
> 
> -
> 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

Modelling Episodes in openEHR

[lakew...@copper.net]

Hi All,

Handling data streams and derivations at points in time is analogous to 
Software Configuration
Management where branches are necessary and having multiple groups 
operating upon the
same branches, and special code, must be synchronized and ultimately 
merged into a release
that incorporates the original data, derivations, fixes, features and 
requests.

Obviously the data stream does not stop for individuals or groups, 
however, the individuals and
groups often find themselves late for the merge or possibly dealing with 
special cases that
require special attention prior to a merge.

A Patient is likely to continue generating data regardless of the number 
of individuals and groups
that are attempting to work on prior data. Multiple groups in Healthcare 
are similar to multiple
groups in software development, e.g., inter-group communication is 
lacking and they apply
their own lenses to the data yielding potentially conflicting 
interpretations, analysis and plans.

It is common to find individual developers working on their own 
'sandboxes' which ultimately
require substantial work, and re-work, to merge. An episode in 
Healthcare is like one in
development in that working on the episode can in the long run be 
limited in productivity
when merge time arises.

This is not to be taken as opposition to work on episodes, rather, treat 
them separately and
keep focus on the data stream since that is where the 'merging' occurs. 
Remember that once
a final release is obtained episodes can and should continue, e.g., upon 
deployment the
same problems may occur that were detected in somebody's sandbox.

The important point is get to the release ASAP. The next point is that 
as soon as the final
release occurs, development episodes are archived and left there unless 
a good reason
appears to take a second look.

An episode at age 10 is not likely to be important at age 30, 40 or beyond.

Regards!

-Thomas Clark

Sam Heard wrote:

> Bill and all
>
> This is a very important consideration and one that we need to get 
> right for lots of reasons.
>
> Tom has been proposing an aggregation  approach - allowing us to find 
> all data that relates to something - a disease, care at an institution 
> etc.
>
> It is clear that there are aspects of the episode that are specific to 
> the care setting and administrative and billing requirements. We could 
> have a composition that held information about the administrative 
> aspects of the episodefor billing purposes or secondary data 
> collection. It would be possible to archetype an 'episode' folder to 
> contain one of these - and possible to define what is held within it 
> should that be appropriate.
>
> It is clear that a simple aggregation model is not enough, but we also 
> do not want to have lots of folders to describe one episode from 
> different perspectives.
>
> The Mayo can only have one episode per patient at any timethis 
> ensures that the person who opens an episode is responsible for 
> closing it - and summarising it, tying up lose ends etc. This is a 
> very important quality issue in distributed care environments. But in 
> the Australian setting where we have primary and secondary care 
> separated - the notion of secondary care episode is largely a billing 
> or funding issue - although we have discharge referrals back to 
> primary care.
>
> In primary care, the idea of an episode - a single one at a time - is 
> appealing to me - meaning it is non-routine care for the problems the 
> person has. It stops what Michael Balint called the "collusion of 
> anonymity" - a destructive outcome of 'shared' or 'parallel' care.
>
> Cheers, Sam
>
>
>
>
>> Hi Thomas,
>>
>> Thomas Beale wrote:
>>
>>> Someone could come along later in the same
>>> institution, and define a new kind of episode, and
>>> retrospectively create all the Folders for that kind
>>> of episode in certain EHRs. This also won't
>>> change any of the underlying data. Episode
>>> Folders could also be removed, renamed, their
>>> references added to or removed - none of this
>>> changes any of the data either.
>>
>>
>>
>> Do you envision this being done manually?  Or is there a programmatic
>> solution?  The question this thread has raised in my mind is well
>> illustrated by your comment below.
>>
>>
>>> I think any institution has to have a firm model
>>> for what it thinks an episode is
>>
>>
>>
>> Assuming that different institutions will adopt models that differ, 
>> what are
>> the implications for the exchange of data and the creation of a lifelong
>> EHR?
>>
>> Thanks,
>> Bill
>>
>> -
>> 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
>

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Modelling Episodes in openEHR

[Gerard Freriks]

Sam,

Is it correct to say that:
- Each type of Episode will be an specific  Archetype that maps 
starting at  the folder.
- What must be communicable  generically is the disease type Episode 
since this can be true in many places.
- The Non-disease Archetypes are based on local business rules and 
don't have to be communicated to others outside the own organization. 
So each organization will have its own Archetype that fits their 
business rules.
- It will be wise to use in the Archetypes terms that conform to the 
CEN/TC 251 Continuity of Care standard.
- Three proto-Archetypes defining the various episodes must be 
standardized in order to create interoperability.
- Two non disease type proto-archetypes will be highly  specialize-able.
- The disease related proto-archetype will be of the kind that can not 
easily be specialized.

New term (=concept): proto-archetype - A standardized Archetype.
This proto-archetype must be the starting point for specialization in 
order to produce an Archetype to be defined and used in a local 
community.

Bye the way.
What types of standardized proto-Archetypes will we need?
What are the rules for specialization?
Which proto-archetypes can and can not be specialized?
Or are we more subtle; to what degree? Etc, etc.
Do we need accepted rules that govern the production and usage of 
Archetypes?

Gerard



-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 06 Dec 2004, at 03:08, Sam Heard wrote:

> Bill and all
>
> This is a very important consideration and one that we need to get 
> right for lots of reasons.
>
> Tom has been proposing an aggregation  approach - allowing us to find 
> all data that relates to something - a disease, care at an institution 
> etc.
>
> It is clear that there are aspects of the episode that are specific to 
> the care setting and administrative and billing requirements. We could 
> have a composition that held information about the administrative 
> aspects of the episodefor billing purposes or secondary data 
> collection. It would be possible to archetype an 'episode' folder to 
> contain one of these - and possible to define what is held within it 
> should that be appropriate.
>
> It is clear that a simple aggregation model is not enough, but we also 
> do not want to have lots of folders to describe one episode from 
> different perspectives.
>
> The Mayo can only have one episode per patient at any timethis 
> ensures that the person who opens an episode is responsible for 
> closing it - and summarising it, tying up lose ends etc. This is a 
> very important quality issue in distributed care environments. But in 
> the Australian setting where we have primary and secondary care 
> separated - the notion of secondary care episode is largely a billing 
> or funding issue - although we have discharge referrals back to 
> primary care.
>
> In primary care, the idea of an episode - a single one at a time - is 
> appealing to me - meaning it is non-routine care for the problems the 
> person has. It stops what Michael Balint called the "collusion of 
> anonymity" - a destructive outcome of 'shared' or 'parallel' care.
>
> Cheers, Sam
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3288 bytes
Desc: not available
URL: 

Modelling Episodes in openEHR

[Gerard Freriks]

Hi,

On 06 Dec 2004, at 09:10, lakewood at copper.net wrote:

>
> An episode at age 10 is not likely to be important at age 30, 40 or 
> beyond.
>

?!

An episode of appendicitis at 10,
an episode where the spleen is removed,
an episode of leukemia at 10,
all are more or less very important,
when talking about the disease related episode.
In contrast the administrative related episodes are NOT important under 
must (non-legal) circumstances.
Although it might be important to know for a relatively short period 
that because of hart failure the patient is admitted to a hospital 
every other week.

The list of recorded episodes is very valuable to discern important 
medical facts from common colds, and bruises.
It is the patients medical history where important medical facts are 
grouped.

Do we have a list of use cases for each type of Episode?

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1063 bytes
Desc: not available
URL: 

Modelling Episodes in openEHR

[Sam Heard]

Gerard

Wow.

> Sam,
> 
> Is it correct to say that:
> - Each type of Episode will be an specific Archetype that maps starting 
> at the folder.

As folders can hold symbolic links, compositions can appear in more than one 
archetype. Folders are the preferred way of aggregating and organising 
compositions - as that is what they are for.

A Folder archetype could limit the type of compositions in a folder, or ensure 
that particular compositions are present. It is these compositions that will 
hold information that is particular to the episode - and may have references to 
particular parts of compositions (data).

Some episodes may only require aggregation of compositions and so may be only a 
folder.

> - What must be communicable generically is the disease type Episode 
> since this can be true in many places.

A disease episode is an interesting idea. At the Mayo, an episode is only 
commenced if someone is getting non-standard care. So a patient may have many 
diabetic episodes, but only has diabetes once.

Aggregating compositions that deal with a particular condition may occur in 
more 
than one way...

Using Problem/SOAP sections, the problem can be identified and queried against.
Using Folders to aggregate compositions that contain any information about a 
particular problem
Using the responsible clinician who has certain qualifications
Using the composition type - eg Antenatal visit.

So I think this will vary for the time being. It is not necessary that we all 
do 
the same thing

> - The Non-disease Archetypes are based on local business rules and don't 
> have to be communicated to others outside the own organization. So each 
> organization will have its own Archetype that fits their business rules.

I guess here you mean an administrative episodeI agree. But it is likely 
that there will be some national reporting requirements in many jurisdictions.

> - It will be wise to use in the Archetypes terms that conform to the 
> CEN/TC 251 Continuity of Care standard.

Yesit will take some work to tease these out - but I agree

> - Three proto-Archetypes defining the various episodes must be 
> standardized in order to create interoperability.

proto-archetypes for me are just descriptions of the information space - as in 
Protege.

> - Two non disease type proto-archetypes will be highly specialize-able.

Agree - may only have a name in common

> - The disease related proto-archetype will be of the kind that can not 
> easily be specialized.

Probably true

> 
> /New term (=concept): *proto-archetype - A standardized Archetype.*
> This proto-archetype must be the starting point for specialization in 
> order to produce an Archetype to be defined and used in a local community./

All archetypes are potentially a starting point for specialisation...but some 
almost have an 'abstract' quality - such as episode.

> Bye the way.
> What types of standardized proto-Archetypes will we need?

There are some interesting ones potentially.

visualisation is one that I am interested in. To cover external observation and 
all forms of Xrays, Ultrasound etc. The advantage is that if you are interested 
in the Liver - it would be easy to find all visualisations - at laparotomy, by 
ultrasound, CT.

The price for such an approach may be too high - but I kind of like the idea of 
it. Visualisation.ultrasound or visualisation.xray.ctscan

> What are the rules for specialization?

There are the technical ones that ensure that a specialised archetype does not 
break the rules of the parent - some of these are working in the editor. 
Generally, specialisation is appropriate if a query on one archetype should 
return information even if it is in another.


> Which proto-archetypes can and can not be specialized?

No rules as yet.

> Or are we more subtle; to what degree? Etc, etc.

Yes...we are learning a lot about this as we go.

> Do we need accepted rules that govern the production and usage of 
> Archetypes?
>

We do, and we need to put these together as we go...

Sam

> Gerard
> 
> 
> 
> -- 
> -- 
> Gerard Freriks, MD
> Convenor CEN/TC251 WG1
> 
> TNO-PG
> Zernikedreef 9
> 2333CK Leiden
> The Netherlands
> 
> +31 71 5181388
> +31 654 792800
> On 06 Dec 2004, at 03:08, Sam Heard wrote:
> 
> Bill and all
> 
> This is a very important consideration and one that we need to get
> right for lots of reasons.
> 
> Tom has been proposing an aggregation approach - allowing us to find
> all data that relates to something - a disease, care at an
> institution etc.
> 
> It is clear that there are aspects of the episode that are specific
> to the care setting and administrative and billing requirements. We
> could have a composition that held information about the
> administrative aspects of the episodefor billing purposes or
> secondary data collection. It would be possible to archetype an
> 'episode' folder to contain one of these - and possible to define
>   

Modelling Episodes in openEHR

[Gerard Freriks]

wow, wow!

GF
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 07 Dec 2004, at 06:46, Sam Heard wrote:

>> Bye the way.
>> What types of standardized proto-Archetypes will we need?
>
> There are some interesting ones potentially.
>
> visualisation is one that I am interested in. To cover external 
> observation and all forms of Xrays, Ultrasound etc. The advantage is 
> that if you are interested in the Liver - it would be easy to find all 
> visualisations - at laparotomy, by ultrasound, CT.
>
> The price for such an approach may be too high - but I kind of like 
> the idea of it. Visualisation.ultrasound or visualisation.xray.ctscan
>

What else?
Lets have a look at the CEN/TC251 General Purpose Information 
Components (GPICS) or HL7 v3 CMET's) as starting points.

Visualisation on one hand might means the procedure and result as in a 
Dicom report.
Or on the other hand a specialisation of the Observation GPICS where 
the focus is on the expert opinion about the result of the former 
'visualisation-type'.

We need at least two classes of archetypes dealing with obeservations 
(and possibly other topics): the procedure plus result and the expert 
opinion about it.


>> What are the rules for specialization?
>
> There are the technical ones that ensure that a specialised archetype 
> does not break the rules of the parent - some of these are working in 
> the editor. Generally, specialisation is appropriate if a query on one 
> archetype should return information even if it is in another.
>

We need those things ecxplicitly in writing.
They have to end up in CEN/TC251 EN13606 part 3.


>
>> Which proto-archetypes can and can not be specialized?
>
> No rules as yet.

We need rules for this and several other things.


>
>> Or are we more subtle; to what degree? Etc, etc.
>
> Yes...we are learning a lot about this as we go.
>
>> Do we need accepted rules that govern the production and usage of 
>> Archetypes?
>>
>
> We do, and we need to put these together as we go...

Who?
How?

Where is the list?




-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2302 bytes
Desc: not available
URL: 

Modelling Episodes in openEHR

[Thomas Beale]

Gerard Freriks wrote:

>
>
> The disease episode is about the patient and can and will be exchanged.

>
> Other episodes defined on the basis of local business rules will not 
> be exchanged.
>
or if they are, no-one should read a great deal into them, unless they 
know they have the same model of adminstrative/accounting episode 
themselves.

- thomas



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Modelling Episodes in openEHR

[Thomas Beale]

Sam Heard wrote:

> Gerard
>
> Wow.
>
>> Sam,
>>
>> Is it correct to say that:
>> - Each type of Episode will be an specific Archetype that maps 
>> starting at the folder.
>
>
> As folders can hold symbolic links, compositions can appear in more 
> than one archetype. Folders are the preferred way of aggregating and 
> organising compositions - as that is what they are for.
>
> A Folder archetype could limit the type of compositions in a folder, 
> or ensure that particular compositions are present. It is these 
> compositions that will hold information that is particular to the 
> episode - and may have references to particular parts of compositions 
> (data).
>
> Some episodes may only require aggregation of compositions and so may 
> be only a folder.

And our current suggestion (from Dipak Kalra and myself at least) is 
that a special Composition be used in an episode-Folder to hold 
administrative data - i.e. in addition to all the clinical Compositions 
in the Folder.

- thomas



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Modelling Episodes in openEHR

[Thomas Beale]

Gerard Freriks wrote:

> In contrast the administrative related episodes are NOT important 
> under must (non-legal) circumstances.

agree

> Although it might be important to know for a relatively short period 
> that because of hart failure the patient is admitted to a hospital 
> every other week.
>
> The list of recorded episodes is very valuable to discern important 
> medical facts from common colds, and bruises.
> It is the patients medical history where important medical facts are 
> grouped.

I wonder if this might be the best justification for episodes to be made 
visible in the EHR that I have heard so far?

- thomas beale



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Modelling Episodes in openEHR

[Thomas Beale]

lakewood at copper.net wrote:

> Hi All,
>
> Handling data streams and derivations at points in time is analogous 
> to Software Configuration
> Management where branches are necessary and having multiple groups 
> operating upon the
> same branches, and special code, must be synchronized and ultimately 
> merged into a release
> that incorporates the original data, derivations, fixes, features and 
> requests.

At last, another proponent of CM;-) The current openEHR models have the 
SCM notion built in pretty well from the ground up - the Common RM with 
its "change_control" package include all these semantics. Personally I 
have been convinced for years that the shared care EHR has to be treated 
like an SCM system, hence this modelling. However, not many people 
understand SCM (even when they are using tools which do it), and to be 
fair, it's a pretty specialist area (just happens to be one where a few 
of us get our hands dirty); so they don't realise how important the 
parallel between collaborative teams working on software and team(s) of 
health info users working on EHRs is...

>
> Obviously the data stream does not stop for individuals or groups, 
> however, the individuals and
> groups often find themselves late for the merge or possibly dealing 
> with special cases that
> require special attention prior to a merge.

well, there are various strategies for dealing with such situations, 
such as optimistic and pessimistic write locks - where for longish 
transactions (e.g. doctor creates/canges 4 Compositions during a 15 min 
consult - this is one Contribution) - the pessimistic form is reasonable 
- it avoids merges, and takes the reasonable view that the chances of 
another clinician or software application (e.g. a message gateway) 
entering data for that same patient are fairly low. But if it turns out 
that being locked out for write is a problem, systems can and probably 
should dynamically swap to optimistic write locking for Contributions, 
and then deal with the merge scenario instead.

>
> A Patient is likely to continue generating data regardless of the 
> number of individuals and groups
> that are attempting to work on prior data. Multiple groups in 
> Healthcare are similar to multiple
> groups in software development, e.g., inter-group communication is 
> lacking and they apply
> their own lenses to the data yielding potentially conflicting 
> interpretations, analysis and plans.

especially if there are laboratories processing samples, message 
gateways collecting info from other databases, nurses and consultants 
entering data for the same patient at different terminals, and admin 
staff also making changes any of these changes could occur to the 
same EHR at once, just by coincidence. The EHR system has to deal with 
it. It's really why we have built not only versioning into openEHR, but 
also Contributions (= change sets in SCM).

>
> It is common to find individual developers working on their own 
> 'sandboxes' which ultimately
> require substantial work, and re-work, to merge. An episode in 
> Healthcare is like one in
> development in that working on the episode can in the long run be 
> limited in productivity
> when merge time arises.
>
> This is not to be taken as opposition to work on episodes, rather, 
> treat them separately and
> keep focus on the data stream since that is where the 'merging' 
> occurs. Remember that once
> a final release is obtained episodes can and should continue, e.g., 
> upon deployment the
> same problems may occur that were detected in somebody's sandbox.

i.e. you are saying that episodes don't necessarily fit cleanly into 
change sets & versions? I would agree.

>
> The important point is get to the release ASAP. The next point is that 
> as soon as the final
> release occurs, development episodes are archived and left there 
> unless a good reason
> appears to take a second look.

this is probably less true in clinical medicine - you may not want the 
details, but you will certainly want some info on prior important 
interventions, and recurrent problems. E.g. my father (nearly 80) had 
polio when he was about 7 (back in 1934)...no lasting effects of it at 
the time, and no visible damage. Until about 10 years ago, it was as if 
it was irrelevant. Since then he has had an assortment of annoying pains 
in the foot originally affected by the polio, occasionally extremely 
painful. He never even thought of the polio, but a couple of GPs asked 
him (due to his age probably - back then escaping Polio was more luck 
than anything else - I think they only had the Salk dead-virus vaccine 
back then), and both agreed that the current situation - which has 
become an important issue affecting his personal mobility - is due to 
Polio all those years ago. That's clearly important, because it means 
they don't waste time on therapies that won't work.

>
> An episode at age 10 is not likely to be important at age 30, 40 or 
> beyond.

soI suspect 

Modelling Episodes in openEHR

[lakew...@copper.net]

Hi Thomas,

Getting 'episodes' issues resolved and their handling in the form of
'intelligent procedures',
a 'next step' is to address the 'information weighting' problem, i.e.,
faced with a rush of
data how should it be categorized, prioritized, ordered (address in what
order) and
rated according to perceived significance.

This gets close to 'bug handling' in Project Management. For the
Practitioner it becomes
an issue of 'What to scan, in what order and what to do about it'.

My personal belief is that this is an area that can be addressed by
'automatic information
analysis and handling', potentially by 'expert systems', 'software
agents' and 'software
artificial intelligence'. In other words, personal robotic packages that
can accomplish
a lot of menial tasks quickly and support continual review of ongoing
procedures,
e.g., Did all the loose ends get taken care of.

An analogy with 'Project Managers' seems appropriate. In the development
environment
they are always findings things that should have been done and those
that were no done.

As an example, presuming that the Practitioner generates additional EHRs
before, during
and after a diagnosis-treatment process, valid questions regarding what
was reduced to an
EHR (e.g., did all the significant information get placed in an EHR),
what happened to all
the EHRs, have the appropriate copies been made and distributed, is there a
'backtracking' record of what happened (e.g., can one 'link' all the
EHRs), and what gets
published and to whom?

Content, dependence, relationships, history, usage and disposition are
all significant.
Content might be critical in the short term; the remaining issues may
become increasingly
significant with time.

Appreciate your inputs!

Regards!

-Thomas Clark

Thomas Beale wrote:

> lakewood at copper.net wrote:
>
>> Hi All,
>>
>> Handling data streams and derivations at points in time is analogous 
>> to Software Configuration
>> Management where branches are necessary and having multiple groups 
>> operating upon the
>> same branches, and special code, must be synchronized and ultimately 
>> merged into a release
>> that incorporates the original data, derivations, fixes, features and 
>> requests.
>
>
> At last, another proponent of CM;-) The current openEHR models have 
> the SCM notion built in pretty well from the ground up - the Common RM 
> with its "change_control" package include all these semantics. 
> Personally I have been convinced for years that the shared care EHR 
> has to be treated like an SCM system, hence this modelling. However, 
> not many people understand SCM (even when they are using tools which 
> do it), and to be fair, it's a pretty specialist area (just happens to 
> be one where a few of us get our hands dirty); so they don't realise 
> how important the parallel between collaborative teams working on 
> software and team(s) of health info users working on EHRs is...
>
>>
>> Obviously the data stream does not stop for individuals or groups, 
>> however, the individuals and
>> groups often find themselves late for the merge or possibly dealing 
>> with special cases that
>> require special attention prior to a merge.
>
>
> well, there are various strategies for dealing with such situations, 
> such as optimistic and pessimistic write locks - where for longish 
> transactions (e.g. doctor creates/canges 4 Compositions during a 15 
> min consult - this is one Contribution) - the pessimistic form is 
> reasonable - it avoids merges, and takes the reasonable view that the 
> chances of another clinician or software application (e.g. a message 
> gateway) entering data for that same patient are fairly low. But if it 
> turns out that being locked out for write is a problem, systems can 
> and probably should dynamically swap to optimistic write locking for 
> Contributions, and then deal with the merge scenario instead.
>
>>
>> A Patient is likely to continue generating data regardless of the 
>> number of individuals and groups
>> that are attempting to work on prior data. Multiple groups in 
>> Healthcare are similar to multiple
>> groups in software development, e.g., inter-group communication is 
>> lacking and they apply
>> their own lenses to the data yielding potentially conflicting 
>> interpretations, analysis and plans.
>
>
> especially if there are laboratories processing samples, message 
> gateways collecting info from other databases, nurses and consultants 
> entering data for the same patient at different terminals, and admin 
> staff also making changes any of these changes could occur to the 
> same EHR at once, just by coincidence. The EHR system has to deal with 
> it. It's really why we have built not only versioning into openEHR, 
> but also Contributions (= change sets in SCM).
>
>>
>> It is common to find individual developers working on their own 
>> 'sandboxes' which ultimately
>> require substantial work, and re-work, to merge. An episode in 
>> Healthcare is like one in
>>

Modelling Episodes in openEHR

[Gerard Freriks]

Hi,

That seems a good suggestion.

Gerard


-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 11 Dec 2004, at 17:20, Thomas Beale wrote:

> And our current suggestion (from Dipak Kalra and myself at least) is 
> that a special Composition be used in an episode-Folder to hold 
> administrative data - i.e. in addition to all the clinical 
> Compositions in the Folder.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 526 bytes
Desc: not available
URL: 

Modelling Episodes in openEHR

[Gerard Freriks]

Hi

reed in the text below.

Gerard

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 11 Dec 2004, at 17:13, Thomas Beale wrote:

As
  Software Configuration Management (SCM) is very important in my view.

Use case (one of many):
The plan is to have several test be performed: several chains of events 
are opened.
Each track provides preliminary partial reports. Each of these partial 
findings will give rise potentially to recordings in the record and 
extra actions.
Some of the tracks might include referrals to other physicians that do 
their thing and document the work in their version of the patient 
record.
After some time all tracks are resolved and must be consolidated.

This whole process needs a form of SCM for the generated information in 
federated EHR situation.

A way I view this process is: that there is one main track where the 
plan was set up and executed.
Each track generates intermediary reports that have a short shelf-life.
At the end of each track all information is summarized and an expert 
provides his personal opinion answering the question that started off 
that track.
The owner of the main track holds responsibility for the final 
consolidation.


>
>>
>> An episode at age 10 is not likely to be important at age 30, 40 or 
>> beyond.
>
> soI suspect some doctors will have something to say about this 
> statement!

Thomas, you provided an example.
On other one.
Car accident and spleenectomy 20 years ago, still influence decisions 
today.

And then. One fact unimportant at a certain time can become very 
important later.

> in summary - I agree with all your points above, except that I don't 
> think that "episodes of activity" can be conveniently archived and 
> forgotten about. But it is an interesting analogy that I for one had 
> not thought of, and may well bear further analysis.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2029 bytes
Desc: not available
URL: