# Modelling Episodes in openEHR **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2004-12-02 11:36 UTC **Views:** 9 **Replies:** 21 **URL:** https://discourse.openehr.org/t/modelling-episodes-in-openehr/12002 --- ## Post #1 by @thomas.beale 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 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](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. 1. 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. 1. 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. 1. 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 any other descriptive information required for the episode as a whole. In particular, it could have a data item meaning "state of episode in time", which could be archetyped to take vocabulary valies of "initial" (meaning "intended", "scheduled" or whatever), "active", "closed", "reopened", etc). Date/times could be defined for all of these, as well as the participants responsible for starting, closing, reopening the episode. 1. When the episode is deemed to be closed, the admin Composition is updated to reflect this. 1. In this way, the special admin Composition in a Folder representing an episode always provides the current situation of the episode in each of its versions. It also means that for querying, there is only one Composition to search for in episode-Folders, in order to get the admin data of the episode. Currently, Compositions are connected to Folders by a List in the Folder. It might be useful to use a LINK, which is already inherited into FOLDER from LOCATABLE, to point to the admin Composition of an eposide-Folder. This would facilitate querying. A second alternative to this scheme is a minro adjustment - instead of using the versions of a single admin Composition, a number of admin Compositions could occur within the episode-Folder, each indicating an act of starting, closing, re-opening, terminating etc, the episode. Personally I favour the former approach, because it limits the "special" Compositions in a Folder to just one, and also presents a simpler picture in versioning terms, but both approaches a clearly possible, and the second one would be used by systems not implementing version control at all. In summary, we are suggesting a way to use openEHR to accurately and interoperably represent "episodes", regardless of what your definition of "episode" may be. The solution requires no changes to openEHR, and if adopted as the standard approach, means that episode data will be guaranteed to be interoperable in openEHR, and also provides guidance for how to represent it in CEN EN13606 EHR Extracts. If this solution is shown to have no faults and to be workable, we would document as part of openEHR and publish it. Further thoughts & discussion? - thomas beale XE "Health Care Professional" - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #2 by @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> --- ## Post #3 by @lakewood 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@openehr\.org \[mailto:owner-openehr-technical@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 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 any other descriptive information >       required for the episode as a whole\. In particular, it could >       have a data item meaning "state of episode in time", which could >       be archetyped to take vocabulary valies of "initial" \(meaning >       "intended", "scheduled" or whatever\), "active", "closed", >       "reopened", etc\)\. Date/times could be defined for all of these, >       as well as the participants responsible for starting, closing, >       reopening the episode\. >    5\. When the episode is deemed to be closed, the admin Composition >       is updated to reflect this\. >    6\. In this way, the special admin Composition in a Folder >       representing an episode always provides the current situation of >       the episode in each of its versions\. It also means that for >       querying, there is only one Composition to search for in >       episode\-Folders, in order to get the admin data of the episode\. > > Currently, Compositions are connected to Folders by a List<OBJECT\_REF> in the Folder\. It might be useful to use a LINK, which is already inherited into FOLDER from LOCATABLE, to point to the admin Composition of an eposide\-Folder\. This would facilitate querying\. > > A second alternative to this scheme is a minro adjustment \- instead of using the versions of a single admin Composition, a number of admin Compositions could occur within the episode\-Folder, each indicating an act of starting, closing, re\-opening, terminating etc, the episode\. Personally I favour the former approach, because it limits the "special" Compositions in a Folder to just one, and also presents a simpler picture in versioning terms, but both approaches a clearly possible, and the second one would be used by systems not implementing version control at all\. > > In summary, we are suggesting a way to use openEHR to accurately and interoperably represent "episodes", regardless of what your definition of "episode" may be\. The solution requires no changes to openEHR, and if adopted as the standard approach, means that episode data will be guaranteed to be interoperable in openEHR, and also provides guidance for how to represent it in CEN EN13606 EHR Extracts\. If this solution is shown to have no faults and to be workable, we would document as part of openEHR and publish it\. > > Further thoughts & discussion? > > \- thomas beale > > \- If you have any questions about using this list, please send a message to d\.lloyd@openehr\.org Hi All, Multidisciplinary backgrounds at times result in conflicts and Webster's tool has to be referenced\. 'audit': --- ## Post #4 by @system 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 --- ## Post #5 by @thomas.beale lakewood@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 --- ## Post #6 by @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 --- ## Post #7 by @system Thom, It seems we are in agreement\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 > 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\. --- ## Post #8 by @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 --- ## Post #9 by @system 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 --- ## Post #10 by @Sam 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 episode\.\.\.\.for 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 time\.\.\.\.this 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 --- ## Post #11 by @lakewood 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: --- ## Post #12 by @system 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 --- ## Post #13 by @system Hi, > 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 \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #14 by @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 --- ## Post #15 by @Sam 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 episode\.\.\.\.I 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\. Yes\.\.\.\.it 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 --- ## Post #16 by @system wow, wow\! GF \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 >> 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? --- ## Post #17 by @thomas.beale lakewood@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\. so\.\.\.\.I suspect some doctors will have something to say about this statement\! Also \- it is worth remembering that the current state of certain information in the health record is always of interest \- e\.\.g the vaccination history, or problem list \(incuding inactive problems\), whereas some is not \- e\.\.g a normal BP taken 30 years ago is probably not of much interest\. Another reason why old data will be of more interest in the EHR than in software CM systems is the need to provide medico\-legal support for doctors & patients when problems surface later on \- and this can be up to 30 years later\. I think that in Australia patients can take a GP to court for improper treatment up to 20 or so years earlier\. 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\. \- thomas beale --- ## Post #18 by @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 --- ## Post #19 by @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 --- ## Post #20 by @lakewood 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: --- ## Post #21 by @system Hi, That seems a good suggestion\. Gerard --- ## Post #22 by @system Hi reed in the text below\. Gerard --- **Canonical:** https://discourse.openehr.org/t/modelling-episodes-in-openehr/12002 **Original content:** https://discourse.openehr.org/t/modelling-episodes-in-openehr/12002