Open GoogleCodeExporter opened 9 years ago
I have something similar, which I have called "diagnosis guideline" and defined
as "A directive information entity that specifies how to establish a diagnosis
based on clinical findings". I also have "diagnosis criteria" which are
described in the guideline (for example, generalized hives is a major
dermatologic criteria for anaphylaxis)
I subclass diagnosis guideline with (in my case) "Brighton case definition",
which is the parent of "Brighton case definition for generalized convulsive
seizure as an adverse event following immunization". The concretization of this
case definition is realized during a "generalized convulsive seizure as an AEFI
according to the Brighton collaboration" process.
I am still unclear as to how to relate the clinical finding (e.g. "hives
finding") with the actually process "hives" (is that needed?) and then how to
assert this is a major dermatological criteria for anaphylaxis and need to work
on this part of AERO (maybe something along the lines of "major dermatological
criteria for anaphylaxis according to Brighton" as a subclass of clinical
finding?). If this sounds like something close to your topic I would be happy
to talk further and see if we can find common grounds to accommodate both our
needs.
Original comment by mcour...@gmail.com
on 3 Aug 2012 at 6:22
Note from Barry:
Remember all terms need to be singular nouns. So either
diagnostic criterion
or
(e.g.) set of diagnostic criteria
Original comment by mcour...@gmail.com
on 7 Aug 2012 at 5:21
Melanie, I think that our goals and general approaches are very much in line
with one another and I welcome the opportunity to work together to find a
common solution to our needs.
So far I have just created the class 'set of diagnostic criteria' along with
about 60 subclasses of it for specific disease diagnoses in the Neurological
Disease Ontology (ND). I made 'set of diagnostic criteria' a subclass of 'data
item' and defined it as "A set of criteria that has been agreed upon by the
medical community to provide sufficient, necessary, or sufficient and necessary
warrant for a clinician to reach a particular diagnosis concerning a patient
whose clinical picture satisfies the relevant criteria."
I considered creating the class 'diagnostic criterion', which would serve the
same purpose as your 'diagnosis criteria'. The general idea was that each set
of diagnostic criteria would have specific diagnostic criterion classes as its
members. Difficulties arose though when I attempted to represent things such
as:
- how a single criterion can belong to multiple sets,
- the degree of importance of a particular diagnostic criterion for a particular set of diagnostic criteria, and
- the fact that a single criterion could have a different degree of importance in each set that it is a member of.
Having a single criterion belong to multiple sets is relatively unproblematic
as long as multiple parentage is permitted, but what exactly is a diagnostic
criterion? Keeping in line with 'set of diagnostic criteria' as a 'data item',
it seems that 'diagnostic criterion' should be some sort of data item as well.
But a criterion qua data item is not the sort of thing that a patient can have.
A patient can, however, have a disorder or a genetic makeup or undergo a
pathological process, and these things might be said to satisfy particular
criteria. This is one approach that might be used to partially represent the
connection between a patient and a physician's diagnosis of that patient, but I
think that this is more complicated than is needed.
Rather, I am currently leaning toward an approach that represents a diagnostic
criterion as a relation instead of a class. There are several reasons to
prefer the relation approach including:
1. Some criteria will concern qualities that inhere in a patient (e.g. elevated temperature), some will concern processes that the patient (or part of the patient) participates in (e.g. vomiting), others will concern material entities that are part of or contained in the patient (e.g. a virus or bacterium), and so on. The fact that these entities encompass a variety of disjoint classes makes it difficult to represent them all as the same sort of thing (i.e. a diagnostic criterion). This sort of concern is also a major issue with representing signs and symptoms as classes. I believe that the current plan is to represent 'sign' and 'symptom' as relations in OGMS for exactly this reason.
2. Creating the relation 'has criterion' (or something similar) to link a particular set of diagnostic criteria to instances of the processes, disorders, qualities, etc. of patients, eliminates the need to create additional classes in the ontology. If we choose to create a class 'diagnostic criterion', then we will be forced to create a diagnostic criterion class for each criterion and will still need to connect these criterion classes to the instances in patients that satisfy them (perhaps by using a 'satisfies' relation); however, by using the 'has criterion' relation', there will simply be the set of diagnostic criteria, the instances in the patient, and the relation between them.
3. We can create subclass relations of 'has criterion' to represent the degree of importance that a particular feature has for each set of diagnostic criteria. The relations 'has major criterion', 'has primary criterion', 'has supporting criterion', 'has minor criterion', 'has secondary criterion', 'has necessary criterion', or 'has sufficient criterion' might be candidates for representing this. For example:
- 'set of diagnostic criteria for norovirus' has_major_criterion 'vomiting'
- 'set of diagnostic criteria for pregnancy' has_supporting_criterion 'vomiting'
In this way, we can enhance the information that is represented in an ontology
without needlessly multiplying the number of classes or assertions that it
contains.
Original comment by Alexande...@gmail.com
on 17 Aug 2012 at 9:45
Original issue reported on code.google.com by
Alexande...@gmail.com
on 13 Jun 2012 at 8:11