Modeling Biomedical Systems I

Health Level-7 or HL7 refers to a set of international standards for transfer of clinical and administrative data between software applications used within a give hospital...lets a health system share data across its domains

• The models and messages were too complex - Average HL7 V3 message had 5–10 times the number of XML nodes as messages in other industries
• The RIM tried to model everything, with maximum extensibility and generality
• The standard lacked a useful mechanism to add extensions
• Documentation was poor

Version 3 RIM

• "80/20"
• make life simpler for implementers, rather than for modelers

• modular
• "Resources"
• Small contained model
• Concepts related to a particular thing
• e.g. medication prescription, adverse reaction
• Discrete, but may reference one another, forming a graph

"profiles"

within

it can be shared with another health system

• How to package up composite information for transfer *across* institutions?
• Mobilization of patient data electronically across regions, communities, or health-care organizations
• Enables exchange of information across disparate information systems
• Goals are
• To enable more coordinated, timely, efficient care
• To aid public health reporting and clinical research

a clinical document

RIM

within and between

XML-based language,

RIM and from controlled terminologies

HL7 International and ASTM.

allowing physicians to send electronic medical information to other providers without loss of meaning and enabling improvement of patient care.

Continuity of Care Document

HL7 Version 3 Clinical Document Architecture (CDA)

• formal specification of a shared conceptualization
• Conceptualization: the way we think about a domain
• Specification: formal way of writing it down

• lexicon
• simple taxonomy
• thesaurus
• relational model
• fully axiomatized theory

vocabulary, possibly with natural-language definitions

terms with class-subclass relations

taxonomy plus related terms

unconstrained use of arbitrary relations

upper-level ontology

• Share common understanding of the entities in a given domain - Among people, software agents, between people and software
• Enable reuse of data and information - Introduce standards to allow interoperability and automatic reasoning - Create communities of researchers

• patients - chronically ill, acutely ill
• care providers - doctors, nurses
• notes - histories, updates

• care providers write notes
• doctors have patients
• notes pertain to patients

Ontology that consists of very general terms (such as “object”, “property”, “relation”) that are common across all domains

• Support broad semantic interoperability among a large number of domain-specific ontologies
• Provides a common starting point for the formulation of definitions
• Domain ontology terms are ranked under terms of upper ontology - I.e. upper ontology classes are superclasses or supersets of all classes in domain ontologies

• Upper-level classes provide a useful organizing structure
• Upper-level classes minimize the chance of category errors
• Standard upper-level ontologies aid alignment and reuse across ontologies

• Small, upper level ontology
• Designed for supporting information retrieval, analysis and integration in scientific and other domains
• Does not contain physical, chemical, biological or other terms that fall within domain ontologies

definitions should be objective and complete

• Ontology should sanction those inferences consistent with the definitions
• No concepts exist that are unsatisfiable (interpreted as a empty set)

Should anticipate future uses

No assumptions about knowledge representation

Say no more than is necessary

• Determine the scope that your ontology needs to cover - Consider how it will be used and how it might need to be used in the future when deciding how detailed you want it to be. 
• Enumerate the terms that need to be covered by the ontology
• Define your classes (concepts)
• Define the roles (aka data properties and object properties) of each class
• Define constraints for these properties
• Create instances

• Gene Ontology (GO)
• Foundational Model of Anatomy (FMA)
• MYCIN
• INTERNIST-1/QMR

• 1. molecular function - elemental activity or task, DNA binding
• 2. cellular component - location or complex, cell nucleus
• 3. biological process - goal or objective within cell, secretion

• Suggesting biological process associated with expressed genes
• Enables analysis of how genes cluster together based on functional properties
• Using gene annotations to custom-design microarrays based on biological processes of interest

• Knowledgebase of anatomy information
• Well-developed

Explicitly

frame hierarchy - Concepts, attributes, relations

upper-level ontology - Anatomical spatial entity, anatomical structure, body substance

• rule-based system
• certainty factors and backward chaining

a translation of a rule that has the parameter in its premise

• frame-based system
• its own brand of ad-hoc system (ranking algorithm, heuristic rules)

hypothetico-deductive reasoning as performed by human experts (considered the importance and frequency of each symptom in relation to each disease to rank diseases in a differential diagnosis)

• a Bayesian Belief Network
• They mapped the frequency rankings (1 to 5) in the ad-hoc system to conditional probabilities so that they could get P(symptom | disease)

• UML
• Common Logic
• Web languages - XML, OWL

• Entities are not defined at useful levels of abstraction - Necessary to distinguish between mammals and dogs?
• Entity definitions are overloaded - Helpful to have the class red bicycle?
• Hierarchical relationships are not uniformly taxonomic - Amino acid is a descendant of protein

a weak theory

ontological commitment

concepts represented

any specific application

The subject area of a system (e.g. infectious diseases)

Activities within a domain that a system performs (e.g. diagnosis)

The procedures used to carry out the tasks (e.g. classification)

• Characterize the overall task
• Identify a method that solves that task, entailing any number of subtasks
• For each subtask, identify a method that solves that subtask
• Terminate when there is a well-described method for solving each subtask

Heuristic classification is suitable for classification problems in which it is known from experience which observations— or combinations of observations — indicate intermediate or final solutions, and with what degree of certainty.

• In order to accomplish a big, complex task, you need to break it down into sub-tasks that can be solved with the PSMs that you have. 
• 1. Identify the task you want to accomplish
• 2. Create a PSM that can solve it
• 3. Identify the sub-tasks that must be solved to accomplish the PSM
• 4. Create the PSMs necessary to accomplish the sub-task...
• The result is a structure that defines how problem solvers should be invoked

• To help conclude a diagnosis of which you are suspicious
• SpPIn
• Specific test when Positive, rules In

• To help to determine that an unlikely diagnosis is not present
• SnNOut
• Sensitive test when Negative Rules Out

Resulted from a mistrust of Bayesian statistics

(Certainty factors, fuzzy logic)

• Adopts a measure of belief that ranged from -1.0 (complete falsehood) to +1.0 (complete truth)
• Requires each rule to include a certainty factor for its conclusion
• Requires the runtime system to update the CF for a proposition dynamically as each rule fires
• Requires threshold for acceptance or rejection of a proposition

• Does not overcome the conditional independence assumption - Highly related findings (e.g. fever, chills, and sweats) all individually increase posterior probability of disease (eg influenza)
• Assessing “correct” CFs is difficult - There is no direct translation from statistical data to CFs
• Developers assigning CFs have a tendency to conflate probabilistic values with other considerations - I.e. more important conclusions may be assigned higher CFs

• Truth is not binary but a continuous value between 0 and 1
• Reflecting the degree of membership in a fuzzy set
• Goal is to infer degree of truth
• Unlike probability theory, where goal is to determine likelihood of situations
• Process of fuzzification
• Converts numerical values into confident levels for membership in a fuzzy set

• Disease in the differential diagnosis are assumed to be mutually exclusive
• Differential diagnosis is assumed to include the correct diagnosis (complete)
• Observations supporting the diagnosis are assumed to be conditionally independent when seen in the setting of any of the diseases in the differential diagnosis

• conditional dependencies
• conditioned

• Users enter the state of those nodes for which the state is known (e.g., person went to Honey-Baked Ham)
• Algorithm calculates the posterior probability of all possible states of the remaining nodes (e.g., patient has swine flu)
• If no state values are entered, then the initial probability of each value of each node is simply the prior probability

• Markov Logic (the kind of logic used in Bayesian reasoning) is probabilistic. Therefore, you can have two opposing statements that each have some probability of being true
• In a traditional FOL knowledgebase, every statement must be true (with probability one, so to speak), so having two opposing statements would make the knowledgebase incoherent.

• Producing the correct diagnosis? -At the top of the list of candidates? - Somewhere within the list of candidates?
• The “quality” of the differential diagnosis?User acceptance/satisfaction?
• Amount of use of the system?
• Appropriate management suggestions?

• Is there a need for it?
• Does it work?
• How fast does it work?
• Does it work reliably?
• Do people use it?
• Which parts cause which effects?
• How can it be improved?

• Do people like it?
• Does it improve efficiency of performing some task?
• Does it improve accuracy of performing some task?
• Does it influence the collection of data?
• Does it influence users’ decisions
• Does it affect third parties (e.g., patients)
• How long do the observed effects last?

• Formative: How can be build better systems?
• Summative: What can we conclude about a system that has been built?

• What can we measure and compare about a system?
• Quantitative or hard research

• Logical-positivist perspective
• Assumes that questions can be answered in terms of attributes and can be measured
• Assumes that rational people can and should agree a priori what attributes are important to measure
• Assumes that precise numbers are better than imprecise verbal descriptions

Can be relatively easy to do

May not measure the most important results

• peer review
• difficult
• Anonymous computer or human recommendation
• Limitations
• Relatively few cases and evaluators but still arduous to conduct
• Says nothing about usability
• Claims that expert-level performance was meaningless
• System could not fit into real clinical workflow, despite excelling expert-level performance

• What can we infer from observation of a system
• Qualitative or pejoratively, soft research

the observer

context