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