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: 

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

[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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[Thomas Beale]

An HTML attachment was scrubbed...
URL: