b.cohen wrote: >I was responding to the original message from Chris Feahr, to which Gerard had >already responded, which was indeed calling for a universal ontology. >But the issue here is what to do about enterprises that have to live with >ontological variety. If standards can't make the problem go away, what tools >can make it tolerable? Better still, how can these tools assist, rather than >impede, strategic development and sustainability of the heathcare enterprise in >the face of increasingly 'asymmetric demand' from its clients: the patients, >like you and me, who desire specific consideration of their individual >situations. >These enterprises, like all others, are exposed to three classes of risk: >performance risk - that the component capabilities on which one relies do not >behave in the way that one expected them to; >composition risk - that components that are well-behaved in isolation do not >interoperate in the way one expected them to; and > > maybe I would call this "integration risk"
>implementation risk - that the product or service delivered by a >well-constructed system of interoperating components does not satisfy the >client in her context of use. > > Do you mean that it just doesn't satisfy requirements, or that it doesn't take care of local specificities properly (which is a non-trivial problem in clinical software)? >It is possible to construct a model that reveals the degree to which an >enterprise is exposed to all these risks. Such a model is an invaluable tool >for strategic development but also, as an side-effect, generates an ontology >that most accurately describes the distinctions that are necessary to the >enterprise's operational and regulatory behaviour. This is, in effect, the >'data model' on which the enterprise's IT system must be based if it is to >provide adequate, and meaningful, support to the enterprise's actors (e.g. >clinicians and administrators), clients (e.g. patients), suppliers (e.g. >pharmaceuticals) and regulators (e.g. government). > > In the openEHR way of thinking, such a "model" would be the 2 layers of models - the reference model (in UML) and the clinical layer, comprised of archetypes, computerised guidelines, enterprise business rules and other domain-level / enterprise knowledge resources. Our point of view is that you don't want to put much into the UML which becomes software and databses, because it produces long-term unmaintainable systems - this has been the big problem in the history of information systems engineering to date (with some notable exceptions). >Clearly, a major part of this model is concerned with the 'healthcare record' >and much of that is ontologically (quasi-)universal, in form of (say, Western) >medical science. But much of the healthcare record is also ontologically >specific to the enterprise, particlarly that concerned with composition and >implementation risks (e.g. referral pathways, inter-service relations, chronic >care). > > The openEHR EHR model tries to be at a point of generality where it reflects 'science' - i.e. things like "Observations", "Evaluations" (opinions) etc, also captures auditing information, but doesn't really any clinical elements in it as such - these are all in the archetypes, and in future artifacts like workflow rulebases or whatever. >In order to be of value, all international standards in this area must >demonstrate that they do not prevent the individual enterprise from >'orchestrating' the systems and services at its disposal into the variety of >'systems of systems' that it considers requisite for the asymmetric demand that >it faces. > > Agree completely with that - which means: a) the reference models are domain-invariant - i.e. the concepts expressed in the base models mean the same thing right across the domain, to all users (e.g. an Observation as modelled means the same thing to eveyone, and everyone agrees with the model, as far as it goes) b) there must be flexible, systematic ways for enterprises to define their own screens, forms, 'information shapes', rules etc - this capability needs to be built right into the infrastructure. >I have yet to see a demonstration of this property, or even a desire to meet >it, >from any healthcare standards body. > > well, I don't know if you would consider it an endorsement of such a point of view, but CEN TC/251 recently voted to include the Archetype Definition Language in part 2 of its revised EN13606 standard, and has recognised the need for an archetyping approach for probably 2 years now. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
