Bill Walton wrote: >It seems to me that question of "context" needs to be addressed before those >task descriptions will have much value. I'm thinking that Roles differ from >country to country, and in most cases, by health-care setting within a >country. So just starting here we have a three-level hierarchy (Country -> >Setting -> Role). Once that's established, Responsibilities and Authority >can be mapped. Exceptions to Authority would need to be mapped. Now we're >at five levels, perhaps six depending on the approach to mapping exceptions. > >I wouldn't suggest even attempting to extend this to descriptions of the >tasks. Just establishing the taxonomy above would be a huge job; forget >about the effort to maintain it over time. Task descriptions would, IMO, >make the maintenance task impossible. > > I think that may be a little over-pessimistic - at least for the kinds of tasks I have in mind to describe. The kind of thing I would suggest documenting would be:
- a simple chain of events: GP visit; request for test; test result; diagnosis or other evaluation; therapy or other action/advice; - the management of any patient with the typical pattern of recurrent visits, monitoring of progress, education, occasional crisis episode, e.g. an asthma patient. This is bread and butter for doctors, but very interesting (and not trivial) to get right in the EHR, if we are to accurately represent not only what happens at each visit, but to string the visits together with links which document the causality and other relatedness of the items, so as to tell any carer who looks at it the "story of the patient" (something which Mike Mair, a NZ opthalmologist is always reminding us we should be concentrating on). - scenarios to do with creation of fine-grained information by multiple clinicians in an ICU e.g. during a re-animation situation; when / what parts of this info hits the EHR? - decision by clinicians/tools on what pieces of detailed episodic EPR to move up to shared EHR - scenarios to do with management of patient in home care with automatic monitoring and controlling of devices (e.g. pill dispenser) - medication management, from prescription to completion, for complex (but common) cases, e.g. chemotherapy; multi-drug aged patients - scenarios where the patient is interacting with the EHR, e.g. adding data of weight, blood sugar etc, maybe adjusting their own dosage of a drug; - attestation scenarios; e.g. a junior doctor commits a note about a patient to their EHR; it needs to be attested legally by a senior person before being completely legal, but in between time, it is clinically useful and _usable_ info whcih should be in the EHR; - and so on. What I believe the clinical part of this community needs to think about is: how can we codify what we do in such a way as to tell us how to design certain aspects of the EHR? We hope that most of the answers will be in the form of archetypes, templates, terminology, guidelines - i.e. knowledge resources; but we know that some tings will affect the concrete models of the EHR whcih we need to get right as best as possible in order to support all possible scenarios. A lot of the design features of openEHR are in response to having thought carefully about specific scenarios and then generalising to categories of scenarios (i.e. by induction, if you will). The UML models might look simple, but they are not accidental. >It seems to me that the value of such a collection would extend _much_ >further than the development community. > > > one kind of additional value it would have is that scenario descriptions (as with all requirements) are the basis of test cases - you use them to test systems. So if your hospital is threatening to buy some expensive system, you can provide a large repository of test cases you believe it should satisfy as a means of vetting it. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
