Heath and Eric
Not sure about IMHO but the archetype story is that observations are measurements, clinical options, assessments are evaluations.
So any report will probably be a composition - and evaluations will be included with the observations. These can be as sections in a complex report.
So Diagnostic Investigation would probably always involve more than one archetype - still lab test will often as well if there is any clinical evaluation.
Hope this helps, Sam
Heath Frankel wrote:
Hi,
My thoughts:
The author is most often the care provider. It is his account with observations and assessments, and plans. He is the center of this small universe.
The business of healthcare is mostly collecting observations/facts, producing a professional opinion/assessment and a line of action(s) (=Plan)
Observations (=facts, eg lab test result, liver palpable, Blood pressure. Color of skin, Patient complaint, professional opinions by other care providers, previous professional opinions)
Assessments (professional opinion about an observation or collection of observations. Eg Diagnosis. Lab test indicate possibly Anaemia, Professional opinion about an X-Ray, about a measurement "blood pressure is to high", discharge summary)
Compositions consist of Observations by the care provider, sometimes direct entries by the patient or others), Professional assessments based on Observations and Plans.
Most Diagnostic Investigation is an Archetype consisting of Observations and optionally a Professional opinion (assessment))
Gerard
Hello,
I'm a university student. I'm a beginner about the openEHR.
Reading the papers in the site I don't undestand the difference between
an archetype and an ontology.... I think it's the same but I'm not sure.
Please help me.
Thanks.
Cristina.
Dear Cristina,
My version of the truth, as I understand it, is:
- Archetypes are clinical concept models. Each model is derived by applying constraints to a super ordinate model.
- In order to denote that some archetypes express the same clinical concept model are the same, almost the same or not the same, we need an ontology.
Example:
Clinical concept model 1= two measurements of the blood pressure expressed as mm/Hg
Clinical concept model 2= two measurement of the blood pressure expressed in Pascal
Clinical concept model 3= Three measurements of the blood pressure expressed in mm/Hg
Clinical concept model 4= Three measurements of the blood pressure expressed in mm/Hg plus the cuff size expressed in cm
CCM 1, 2, 3 and 4 point at the same node in the ontology indicating external measurement of blood pressure in an artery. And indicate what type of measurement it is
CCM 1,3 and 4 point at measurement units mm/Hg
CCM 2 points at measurement units in Pascal
The archetypes have relations also:
Each subordinate one has more constraints
Measurement Concept model
>
CCM1 CCM2
CCM3
CCM4
You are right Archetypes and Ontologies will have a strong relationship but they are not the same. And are not used in the same way. Their functions are different.
Gerard
Hi Gerard,
Thank you for this explanation. Would you agree that an archetype is the depiction of the physical form of a healthcare-concept… whereas the ontology model is the depiction of its meaning? If I am understanding these terms correctly, the ontology model for an enterprise could be used to generate a “data dictionary” view of the enterprise, which would also be one possible view of an idealized “vocabulary model”.
As I think about the most appropriate industry-layer at which we should attempt to “standardize”… i.e., try to ensure that things are viewed as exactly the same… I keep returning to the idea of a complete enterprise model, in which the “enterprise” is the global healthcare system. I see this model as an idealized representation of the way in which the aggregate healthcare process is coordinated temporally. I see this universal process model as the depiction of a complex dance involving all artifacts… persons, places, things, separate businesses, computer programs, etc… which which must be choreographed for the most efficient creation and delivery of care. A few questions come to mind, however:
Are any of our existing UML modeling tools capable now of rendering such a complete enterprise model… one that combines atomic data elements, archetypes, ontologies, vocabulary systems, care-related requirements, and temporally coordinated processes into a single model? If not, how many separate modeling methodologies/tools would have to be combined to accomplish this?
Are free/inexpensive “reader” tools available that would enable [non technical] reviewers of such a model to dynamically examine the part of it that corresponds to the part of healthcare with which the reviewer is familiar or interested?
What would an industry consortium look like if it was organized expressly for the purpose of creating, vetting, and maintaining/evolving such a model for all of healthcare? (Vision E-Business Council is attempting to do this for the Vision Care industry). While such a consortium would obviously require expert representation from all provider domains, it would have to also represent providers’ direct trading partners and supporting technology partners… essentially, all interested parties in one organized healthcare conversation. Eventually, I assume that even patients’ would have an interest in reviewing and commenting on such models. As such, the industry consortium would become the most clear, vetted, and unified voice of healthcare into international standards bodies like ISO, HL7, etc.
I believe that standardization efforts from this point forward should concentrate on building out the various sections of this Enterprise Model, corresponding to the different specialty domains of healthcare. The resulting standard model could simply be published… in a machine-understandable form… as our Consensus Industry View of how things are most efficiently done.
Countless different local implementations could be publicly or secretly mapped to such a public model. If each software vendor made his map public, however, all others would be able to infer an interoperability-mapping from it. Local vocabularies, concept-models, and message structures, for example, would not have to be identical in form to our Standard Model, in order to achieve interoperability. If all parties simply maintained a prescribed type of mapping to the master reference model, then systems should be [relaiively easily] mapable to each other.
By moving the standardization efforts away from specific message templates and data dictionaries and toward a global Enterprise Model, large trading partners like payers and manufacturers would be able to continue their beloved practice of “dictating” information requirements to smaller providers… as long as all such dictations and mandates were expressed in standard, machine-understandable forms.
In the US we have recently completed a $15 Billion demonstration (HIPAA) of the fact that it is impossible to persuade large stakeholders to adopt identical message structures and data dictionaries… even if you threaten them with the wrath of the federal government. On the other hand, if we have a standing, universally visible, best-practice enterprise model for healthcare… then no mandates will be needed… except, maybe, to pay the cost of maintaining the standard model. This cost would be minuscule, compared to the cost of trying to mandate HIPAA-like standardization efforts at the message level… which are doomed anyway. Each stakeholder should perceive the obvious economic advantage to itself [and also to its partners, of course] of ensuring that a non-ambiguous mapping is maintained between its system and the standard model. Why would a software developer not want to conform to such a model, if one existed??
Your comments will be most appreciated.
Kindest regards,
-Chris
Christopher J. Feahr, O.D.
Secretary, Vision E-Business Council
http://visionebiz.org
Project Lead, Vision Markup Language
http://www.openapplications.org/wg/VisionML
Optiserv Consulting
Office (707) 579-4984
Cell (707) 529-2268
I have uploaded an answer to this FAQ on the archetypes FAQ age at http://www.openehr.org/FAQs/t_archetypes_FAQ.htm#mozTocId524952. There is a presentation which I have at HL7 Atlanta recently which has a very good slide built by Sam Heard which shows the difference between archetypes and other ontologies.
- thomas beale
Hi Heath,
Heath Frankel wrote:
IMHO, Observation is to capture clinical observation such as blood sugars
levels, weight height and blood pressure, heart rate, etc, etc.Diagnostic Investigation is for more clinical investigations requiring some
specialist interpretation to provide an diagnostic assessment. I.e.
Radiology image taken and report written interpreting the image. There are
several other diagnostic investigations that are not imaging which have been
identified to me but I can regurgitate at this point.
diagnostic investigations of any kind are Observations in openEHR terms - it is the diagnosis itself which is an Evaluation (i.e. an opinion based upon supposedly objective and repeatable observations)
However, and this is where Sam my want to comment, If Observation is an
openEHR Observation Entry and Diagnostic Investigation is an openEHR
Evaluation Entry then we wont be able to have the equivalent openEHR
archetypes have a specialisation relationship. This gets worse if we
they should all be Observations - and specialisation will then be no problem.
- thomas
Thomas,
Question:
What will be the function/role of CEN GPICS (or HL7 CMETS) in the Archetype (Template) paradigm?
Answer:
GPICS (or collections) can be considered as pro-archetypes that serve as prototypes for a series of standardised archetypes/
And because of the mapping on the HL7 RIM help to map with the HL7 v3 world.
e.g. the Proto-Archetype: Measurement, Patient, Paying Organisation, etc/
Have a look at all 170 GPICS in the CEN standard to see the basic building blocks that can be used.
What is the opinion of the experts?
Gerard
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800
Christopher
It is not like you to see the big picture! Comments in line.
? If I am
understanding these terms correctly, the ontology model for an enterprise could be used to generate a "data dictionary" view of the enterprise, which would also be one possible view of an idealized "vocabulary model".
I do not think this is correct. Ontology is about truth, and representing the meaning of things in terms of known truths. I include a single slide power point to demonstrate the relationship between an ontological view of a Blood Pressure measurement and its archetype.
The complexity of the 'truth' based expression of the meaning of each element in a simple archetype such as this is astounding. It demonstrates that ontologies are probably impossible to build for all medical concepts - certainly in a form that is sustainable - as the 'truths' shift. The concept of phase of the heart may change fundamentally - the means of measurement so that a peak, trough and gradients may be the norm. It may then be necessary to model blood pressure as a waveform!
As I think about the most appropriate industry-layer at which we should attempt to "standardize"... i.e., try to ensure that things are viewed as /exactly/ /the same/... I keep returning to the idea of a /complete/ /enterprise model, /in which the "enterprise" is the global healthcare system. I see this model as an idealized representation of the way in which the /aggregate healthcare process/ is coordinated temporally. I see this universal process model as the depiction of a complex dance involving all artifacts... persons, places, things, separate businesses, computer programs, etc... which which must be choreographed for the /most efficient/ creation and delivery of care. A few questions come to mind, however:
Are enterprise models standardisable - it is possible that the EHR is within this standard model - and the set of other services being standardised at least at the interface level would help us.
Model driven solutions can then be based on the shared UML - this appears to be gaining robustness in controlled environments.
1. Are any of our existing UML modeling tools capable now of rendering such a /complete/ enterprise model... one that combines atomic data elements, archetypes, ontologies, vocabulary systems, care-related requirements, and temporally coordinated processes into a single model? If not, how many separate modeling methodologies/tools would have to be combined to accomplish this?
Rendering is not a problem - building something consistant from these is much more of an issue. Just getting these tools to read some XMI in the same manner seems very difficult to achieve.
2. Are free/inexpensive "reader" tools available that would enable [non technical] reviewers of such a model to /dynamically /examine the part of it that corresponds to the part of healthcare with which the reviewer is familiar or interested?
Difficult without being able to read UML. Archetypes are definitely easier!
3. What would an industry consortium look like if it was organized expressly for the purpose of creating, vetting, and maintaining/evolving such a model for all of healthcare? (Vision E-Business Council is attempting to do this for the Vision Care industry). While such a consortium would obviously require expert representation from all provider domains, it would have to also represent providers' direct trading partners and supporting technology partners... essentially, all interested parties in one organized healthcare conversation. Eventually, I assume that even patients' would have an interest in reviewing and commenting on such models. As such, the industry consortium would become the most clear, vetted, and */unified voice of healthcare/* into international standards bodies like ISO, HL7, etc.
It would have technical expertise, clinical leadership and resources! It would have a small design team - with members from at least 2 major players - the VA and a private vendor. It would have a clean sheet!
I believe that standardization efforts from this point forward should concentrate on building out the various sections of this Enterprise Model, corresponding to the different specialty domains of healthcare. The resulting standard model could simply be published... in a machine-understandable form... as our Consensus Industry View of how things are most efficiently done.
Well HL7 is moving into this space (a little) - Ken Ruben from the VA is working here and openEHR is trying to get part of that picture into focus.
Countless different local implementations could be publicly or secretly mapped to such a public model. If each software vendor made his map public, however, all others would be able to infer an interoperability-mapping from it. Local vocabularies, concept-models, and message structures, for example, would *not* have to be identical in form to our Standard Model, in order to achieve interoperability. If all parties simply maintained a prescribed type of mapping to the master reference model, then systems should be [relaiively easily] mapable to each other.
Again, I would argue that this is the aim of openEHR within a part of the domain.
By moving the standardization efforts away from specific message templates and data dictionaries and toward a global Enterprise Model, large trading partners like payers and manufacturers would be able to continue their beloved practice of "dictating" information requirements to smaller providers... as long as all such dictations and mandates were expressed in standard, machine-understandable forms.
OK
In the US we have recently completed a $15 Billion demonstration (HIPAA) of the fact that it is impossible to persuade large stakeholders to adopt identical message structures and data dictionaries... even if you threaten them with the wrath of the federal government. On the other hand, if we have a standing, universally visible, best-practice enterprise model for healthcare... then no mandates will be needed... except, maybe, to pay the cost of maintaining the standard model. This cost would be minuscule, compared to the cost of trying to mandate HIPAA-like standardization efforts at the message level... which are doomed anyway. Each stakeholder should perceive the obvious economic advantage /to itself /[and also to its partners, of course]/ /of ensuring that a non-ambiguous mapping is maintained between its system and the standard model. Why would a software developer *not* want to conform to such a model, if one existed??
It may make the work they have to do MORE difficult - and it may mean their clients are free to move to other software at any time and preserve their investment in information.
Sam
BP archetype.ppt (42.5 KB)
Hi Chris,
Comments are in between your text.
Gerard
I am afraid that this utopian call for a universal model of healthcare is not
only unrealisable but does not even represent a desirable ideal.
The fact is that there cannot be a universal ontology, despite the best efforts
of great philosophers, from Porphyry to Leibnitz and on to the agent advocatges
of today.
Why this must be so is a consequence of our humanity. We are all embodied
individuals, driven by our own desires and constrained by our own perceptions
of our capabilities and of our abilities to orchestrate them.
In healthcare, as in all other enterprises, we must interoperate with our peers,
our suppliers, our clients and our regulators in ways that are appropriate to
our perceptions of their needs and capabilites. Even although the underlying
conceptual frameworks may be common, as in, say, Western medical science, the
enterprises that share them may differ widely in structure and those
differences may be of vital importance to their clients (e.g. patients like you
and me).
Attempting to standardise beyond the boundaries of common understanding is not
only fruitless; it is positively dangerous.
Quoting Gerard Freriks <gfrer@luna.nl>:
Dear Bernie,
I'm not calling for a universal model.
What I wrote was that we need a 'language' so we are able to express what we need.
We need building blocks only and a evolutionary process so we are able to adopt to the changed perceptions of the real world.
And I even agree that the Ontology of everything is utopian.
Gerard
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800
Gerard Freriks wrote:
Dear Bernie,
I'm not calling for a universal model.
What I wrote was that we need a 'language' so we are able to express what we need.
We need building blocks only and a evolutionary process so we are able to adopt to the changed perceptions of the real world.And I even agree that the Ontology of everything is utopian.
I didn't read Gerard's mail as asking for the utopia of a universal ontology. But some people do believe in this, and in some way things like snomed-ct are an attempt at it. My experience as a software engineer is that universal ontologies don't work for exactly the reason Bernie mentions - everyone is an individual, with his/her own point of view; humans are just not synchronised to the extent that they can create a single ontology or model of the anything which is not extremely narrow in scope, and correctly represent all their points of view therein.
During many years of modelling, or leading modelling exercises, the one mistake I see repeated over and over again is the create of "domain models" for the whole of a domain, e.g. health. Many health departments and vendor organisations have these - usually gigantic ER models large enough to wallpaper the inside of the Albert Hall (US = Carnegie Hall); they are never used to build anything, becase they don't work. Primary reason: they don't embody any single, coherent point of view. You can't build any kind of system not based on a coherent model. Same goes for ontologies.
This was always one of the thought uppermost in our minds when creating the idea of formal archetypes - that they be distinct and self-standing. It is pretty easy to design an archetype for "physical examination" that works for a lot of people; those who want something else, either specialise it, build a different one, or perhaps build a template which uses bits of the original archetype. IN each case, the archetype fits on about 2 A4 pages or less - not too big to agree on.
- thomas beale
Hi,
Sorry not to have been able to make a description of the unified model in english yet.
However, I can see it pretty well in the overall direction Gerard described his target system.
We use an ontology in order to provide the "langage words"
The patient record is a graph : each "document" is a tree, and typed links can be established between any nodes inside the trees
Archetypes are used as tree molds (for the whole tree or tree parts).
So, you express things by building trees with elements from the ontology in the same way you would express yourself in natural langage by making sentences made of words.
A tree is a kind of "discourse schema" and Archetypes are pre-elaborated discourse patterns (classical models)
Inside the graph, trees belong to 4 information model levels : the root trees, the system management trees, the data organization tree, and the description trees
The root trees are : the root tree (root ontological concept "person"), the administratrive data tree (name, date of birth, adress...), the health professional data tree (for health professionals : job, abilities...)
Each of these trees are linked to the root tree with specific links (ie a "admin" link between root and admin tree, a "prodata" link between root and health professional data tree...)
The system management trees are : the "contribution trees" (for a given contribution : who, when, where...), the "document trees" (meta-data of a document : author, type, title, where and how you can get the document...)
There is a "contribution" link between the root tree and each contribution, and a "document" link between the root tree and each document. 3 links ("created", "modified", "read") can connect a document and a contribution in which it has been created, modified or read.
The organization level currently contains a single tree (root node "health index") that contains sub nodes "health concerns" (health problems and prevention follow up), health goals and treatments
This tree is linked to the root tree by a specific link, many other trees and nodes are linked to the health index (for example POMR links between a documents or nodes of a document).
The description trees contain structured description documents.
The Ligne de vie server allows local systems synchronization of the 3 upper levels (root trees, system management and organization). The description datas are accessed through services under the Ligne de vie server control.
As you can imagine the ontology contains medical concepts like "diabetis melitus", "patient weight", "kilogram", "colonoscopy", and so on, but also system management concepts as "document", "contribution", "file"...
We have been working 2 years with a knowledge management research team (from french well known INRIA : national institute of research on informatics and automatics) in order to see where and how we could manage "points of view". In the knowledge management field, the point of view is the sum of a "view angle" (for example the job : doctor, nurse...) and a "focus point" (in the medical field it can be seen as the speciality : cardiology, gastroenterology...).
The INRIA team proposed to specify ontological concepts from a point of view, but I was very reluctant to this idea because it in unmanageable : for example, you could say that "migraina" means simple headache for a patient, while, for a doctor it is a specific disease. However a patient with a genuine migraina will never make a confusion between both concepts.
I just forgot to tell you that our ontology has "only" 50 000 terms (it means less than 50 000 concepts, since a concept can be represented by several terms). As you may have understood, the ontology contains only "basic concepts", since complex concepts are expressed through a small tree.
50 000 is more than a standard medical dictionary (say a dictionary + anatomical terms + drugs international standard names), so it really represent the words used in the medical domain.
I hoppe I can make a more structured description soon...
Regards
Philippe
Philippe,
Thank you so much for this explanation! This is quite encouraging!!
Kindest regards,
-Chris
Hi,
Sorry not to have been able to make a description of the unified model in english yet.
However, I can see it pretty well in the overall direction Gerard described his target system.We use an ontology in order to provide the "langage words"
The patient record is a graph : each "document" is a tree, and typed links can be established between any nodes inside the trees
Archetypes are used as tree molds (for the whole tree or tree parts).So, you express things by building trees with elements from the ontology in the same way you would express yourself in natural langage by making sentences made of words.
A tree is a kind of "discourse schema" and Archetypes are pre-elaborated discourse patterns (classical models)Inside the graph, trees belong to 4 information model levels : the root trees, the system management trees, the data organization tree, and the description trees
The root trees are : the root tree (root ontological concept "person"), the administratrive data tree (name, date of birth, adress...), the health professional data tree (for health professionals : job, abilities...)
Each of these trees are linked to the root tree with specific links (ie a "admin" link between root and admin tree, a "prodata" link between root and health professional data tree...)The system management trees are : the "contribution trees" (for a given contribution : who, when, where...), the "document trees" (meta-data of a document : author, type, title, where and how you can get the document...)
There is a "contribution" link between the root tree and each contribution, and a "document" link between the root tree and each document. 3 links ("created", "modified", "read") can connect a document and a contribution in which it has been created, modified or read.The organization level currently contains a single tree (root node "health index") that contains sub nodes "health concerns" (health problems and prevention follow up), health goals and treatments
This tree is linked to the root tree by a specific link, many other trees and nodes are linked to the health index (for example POMR links between a documents or nodes of a document).The description trees contain structured description documents.
The Ligne de vie server allows local systems synchronization of the 3 upper levels (root trees, system management and organization). The description datas are accessed through services under the Ligne de vie server control.
As you can imagine the ontology contains medical concepts like "diabetis melitus", "patient weight", "kilogram", "colonoscopy", and so on, but also system management concepts as "document", "contribution", "file"...
We have been working 2 years with a knowledge management research team (from french well known INRIA : national institute of research on informatics and automatics) in order to see where and how we could manage "points of view". In the knowledge management field, the point of view is the sum of a "view angle" (for example the job : doctor, nurse...) and a "focus point" (in the medical field it can be seen as the speciality : cardiology, gastroenterology...).
The INRIA team proposed to specify ontological concepts from a point of view, but I was very reluctant to this idea because it in unmanageable : for example, you could say that "migraina" means simple headache for a patient, while, for a doctor it is a specific disease. However a patient with a genuine migraina will never make a confusion between both concepts.I just forgot to tell you that our ontology has "only" 50 000 terms (it means less than 50 000 concepts, since a concept can be represented by several terms). As you may have understood, the ontology contains only "basic concepts", since complex concepts are expressed through a small tree.
50 000 is more than a standard medical dictionary (say a dictionary + anatomical terms + drugs international standard names), so it really represent the words used in the medical domain.I hoppe I can make a more structured description soon...
Regards
Gerard Freriks wrote:
Dear Bernie,
I'm not calling for a universal model.
What I wrote was that we need a 'language' so we are able to express what we need.
We need building blocks only and a evolutionary process so we are able to adopt to the changed perceptions of the real world.And I even agree that the Ontology of everything is utopian.
I didn't read Gerard's mail as asking for the utopia of a universal ontology. But some people do believe in this, and in some way things like snomed-ct are an attempt at it. My experience as a software engineer is that universal ontologies don't work for exactly the reason Bernie mentions - everyone is an individual, with his/her own point of view; humans are just not synchronised to the extent that they can create a single ontology or model of the anything which is not extremely narrow in scope, and correctly represent all their points of view therein.
During many years of modelling, or leading modelling exercises, the one mistake I see repeated over and over again is the create of "domain models" for the whole of a domain, e.g. health. Many health departments and vendor organisations have these - usually gigantic ER models large enough to wallpaper the inside of the Albert Hall (US = Carnegie Hall); they are never used to build anything, becase they don't work. Primary reason: they don't embody any single, coherent point of view. You can't build any kind of system not based on a coherent model. Same goes for ontologies.
This was always one of the thought uppermost in our minds when creating the idea of formal archetypes - that they be distinct and self-standing. It is pretty easy to design an archetype for "physical examination" that works for a lot of people; those who want something else, either specialise it, build a different one, or perhaps build a template which uses bits of the original archetype. IN each case, the archetype fits on about 2 A4 pages or less - not too big to agree on.
- thomas beale
-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org
Christopher J. Feahr, O.D.
Secretary, Vision E-Business Council
Project Lead, Vision Markup Language
http://www.openapplications.org/wg/VisionML
Open Applications Group, Inc.
Optiserv Consulting
Office (707) 579-4984
Cell (707) 529-2268
Hi Chris,
See my comments inline.
Regards,
Sylvia Webb
Hi Sylvia,
I think we are more in agreement than it appears. Can you explain briefly what you mean by a “single enterprise architecture” when you say, “I do see a need and movement towards a single enterprise architecture but not a single enterprise process or data model.” ? This statement sounds like one that I would agree strongly with.
I’m suggesting only that a “complete enterprise model” will be necessary at whatever point a bunch of humans wish to behave more like a single entity. “Behaving as one” is simply a decision humans can choose to make or not make. This “oneness” behavior might actually be more achievable in some parts of the healthcare industry than it would be within some poorly organized single enterprises. I think quite a bit of this “acting like one efficient enterprise” thinking will be accepted in the vision care industry because so many of our doctors and smaller suppliers already tend to think like that. Surprisingly, even our software vendors appear to think this way… probably because most of them are small, too. The idea of banding together and “acting as one” is actually a very enlightened way for Little People to think… and Little People dominate the provider-patient world.
It’s not completely insane to consider engineering support for some degree of “oneness” across our global health system. Perhaps this is what you are suggesting by a “single enterprise architecture”. In a very real way, the global EHR effort is aiming at a variant of this idea. Even if a global healthcare industry consortium did nothing more than clarify our ultimate “oneness vision” for the future and lay out an achievable migration path to reach it, I believe it would be a helpful contribution. Of course, the primary contribution in the short term would likely be in the area of requirements analysis and vetting and harmonization of existing standards.
The benefits of “behaving as one” seem fairly obvious from the point of view of doctors and patients. The only issue is at what point(s) within our global architecture do we encourage this sense of oneness and where do we embrace or even encourage differentiation and competition. Clearly, software vendors will always desire the maximum basis for product differentiation and effective competition. Doctors, on the other hand, are much more interested in cooperation and interoperability and would probably vote for a unified global healthcare system if they thought it was possible to build… according to their actual needs!
Doctors and their technology partners may have different views regarding the helpfulness of “competition”… particularly if it will needlessly raise the costs of cooperation and interoperability… but at the same time, I think we would all cringe at the idea of completely eliminating that competition and being left with a single software vendor! So the reality will be at least a few more decades of data integration, mapping, and transformation, I suppose… simply absorbing the hideous cost and reduced functionality that goes along with that.
Nevertheless… I can’t shake this idea that there should be a lofty, utopian goal… some future vision in which efficiency is truly maximized for health care. Even our competitive software vendors occasionally get sick. And they have families who get sick. In some ways I think we should have the courage as a species to insist on some special and arguably “utopian” business goals for the Mother of all Industries… the industry that’s trying to keep us all alive so that we can operate all the other industries!
OK… that’s enough for now. Thank you all for listening!
Kindest regards,
-Chris
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
Dear Amnon, and others
This latest post has brought me out - time to stop lurking! Not to comment on the original question of how an archetype compares to an ontology, but the fundamental question of how to establish a broadly shared EHR.
My viewpoint is of someone working in a government that channels a reasonable proportion of its budget towards supporting a national health system. In responding I must stress that this is NOT an Australian government position - purely my own observations, and does not seek represent the position of others in the bureaucracy or the government.
While not a "techo"crat, it is clear that even most simplistically viewed, there are a couple of key success factors to achieving the nirvana of shared, longitudinal EHRs:
I see a role for governments in supporting these, particularly consistent with the extent that it is active in the health system. Putting all the apples in one basket is a high risk strategy, but standards can help overcome remove the barriers to interoperability - even between proprietary systems.
How can a purely commercial model (the independent health records banks) effectively operate in a highly subsidized (and arguable distorted) health system? Doesn’t there need to be value for health care providers, health care consumers and other players? How is this achievable in a purely commercial model if the health system itself is not purely commercial? Public -private partnerships are clearly worth exploring in such situations.
If we all call the tune will the piper lead us to reason? Somehow I think someone needs to pay to effect such change!
Kaely Woods
Amnon Shabo SHABO@il.ibm.com
Sent by: owner-openehr-clinical@openehr.org
15/11/2004 09:16 PM
Please respond to Amnon Shabo
|
To: Gerard Freriks gfrer@luna.nl
cc: Christopher Feahr chris@optiserv.com, crylla81@tiscali.it, “‘Eric Browne’” Eric.Browne@MontageSystems.com.au, “‘Heath Frankel’” heathfrankel@pacific.net.au, openehr-clinical@openehr.org, owner-openehr-clinical@openehr.org, “‘Sam Heard’” sam.heard@bigpond.com, smwebb@edatasystemsintegration.com, “‘Tom Beale’” thomas@deepthought.com.au
Subject: Re: Archetype vs. ontology |
- | - | - |
Hello all,
My 2 cents: one vendor/system sounds bad (think of it when your ms windows
crashes the next time) and standards (with all the respect… and I do
have a lot of respect… 
are not a magic solution. What we really need
is a way to sustain a lifetime-cross-institutional EHR for each person, and
the inevitable way to achieve it (imho) is by establishing new players in
the field - Independent Health Record Banks that will solely focus on that
mission while providers will finally get rid of the burden to archive
medical records that they created (records that will always be only part of
the whole EHR). Reconciling the various inputs from the provides along the
lifetime of an individual (when I’m sure that may systems and standards
will be replacing each other), and coming up with a useable and useful EHR
at any given time and any point of care, will the banks’ responsibility and
speciality.
Thanks,
Amnon.
Philippe AMELINE wrote:
Hi,
I just forgot to tell you that our ontology has "only" 50 000 terms (it means less than 50 000 concepts, since a concept can be represented by several terms). As you may have understood, the ontology contains only "basic concepts", since complex concepts are expressed through a small tree.
50 000 is more than a standard medical dictionary (say a dictionary + anatomical terms + drugs international standard names), so it really represent the words used in the medical domain.
to clarify a bit: in Philippe's system, there are 50,000 concepts in a compositional terminology, as well as the "fils guides" (guide paths) whch are little structured post-coordination rules defining legal ways to put the 50,000 concepts together in coordinated tree structures. This combination of a small, clean lexicon, and the fils guides are what makes Philippe's approach to terminology so exciting, in my view. Philippe - one question I have never asked - how many fils guides do you have currently?
- thomas