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 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 at openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041203/2f25ed0e/attachment.html>
