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