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
