UseCasesMotivatedByDomainsAndApplications

Use Cases Motivated by Domains and Applications

In this section, we discuss a collection of use cases across multiple domains such as health care delivery, life sciences, clinical research and trials, manufacturing, earth and space sciences, and telecommunications. For each domain, we discuss the applications and stakeholders involved. This helps motivate the requirements and the features of the OWL 2.0 lanuage as discussed in later sections.

Domain: Health care

Knowledge management in health care aims to support physicians, nurses and other clinical staff to provide high quality clinical care to patients in various settings such as in-patient, out-patient and emergency settings. Key applications and functionalities supported in clinical information systems along with various users and stakeholders are as follows.

Applications

The key applications that form the core components of a health are delivery infrastructure are discussed next. For each application we identify motivate needs and requirements for information and knowledge representation languages.

Electronic Medical Record (EMR)

The EMR is the core component of any health care IT infrastructure that seeks to represent clinical information about a patient. EMRs pose significant challenges in terms of (A) common and consistent reporting of clinical observations and treatments and (B) standardization and interoperability to enable sharing of clinical data across applications and institutional boundaries that enable decision support and clinical quality reporting. There is a need for representation of clinical descriptors that capture various types of information in an EMR such as clinical observations, conditions, lab tests, medications and treatments. A formal representation of these clinical descriptors present a requirement languages for information and knowledge modeling that are precise, unambiguous and computationally tractable.

Enterprise Terminology Services

The need for standardization and consistent representation of clinical descriptors in an EMR is a key requirement for using and composing concepts from controlled medical terminologies such as Snomed-CT, LOINC, RxNorm and others. In order to achieve interoperability, the healthcare IT industry has attempted to use these terminologies to represent a wide variety of clinical descriptors. Over and above interoperabiliyt, this also enables consistent use of clinical descriptors to trigger clinical decision support and to represent clinical quality metrics. However, there has been wide variability, as different systems have used concepts from different terminologies with different granularities combined in multiple ways to reresent the same clinical data. There is a need for knowledge representation languages that provide the ability to specify a rich set of relationships between concepts, the ability to create new concepts based on the composition of pre-existing concepts and the ability to infer equivalence of the same concept representd in multiple ways.

Clinical Decision Support (CDS)

CDS tools have been widely used by healthcare organizations to provide support to the physician at the point of care. CDS logic is typically represented using some form of decision rules, which typically consist of clinical descriptors as a part of the antecedent, and recommended actions such as ordering a lab test, recommending a treatment or inference of a particular clinical condition, such as fracture in some location of the body. These rules typically levarage concepts and possible compositions of concepts from a terminology, e.g., Snomed-CT or Foundation Model of Anatomy to specify the logic in a decision rule. There is a need for a knowledge representation language to represent logic in a precise, standardized and computable formalism.

Clinical Quality Metrics

Managers and administrators at healthcare organizations are interested in monitoring the quality of care provided at their institutions. For this purpose all clinical transactions are stored in a centralized data warehouse or repository and analyzed for the occurrence of various clinical descriptors such as the number of times a particular test was ordered, the number of patients who have their LDL values in the normal range etc. They crucial challenge is similar to the one discussed above, in that, there is a need for consistent definition of these metrics and retrievel of clinical transactions in a uniform and consistent manner for further analysis. There is a need for knowledge representation languages that can represent these clinical descriptors on one hand, and map them to underlying clinical data on the other.

Clinical Documentation

Typically physicians dictate their impressions of a patient encounter into a recording machine which gets transcribed into unstructured textual notes by means of speech processing software. An alternative approach provides for development of templates and tools to document a patient's clinical condition in a structured manner using rich and expressive clinical descriptors. This enhances the ability to share clinical data across applications, enable automatic decision support and measurement and evaluation of clinical quality metrics.

Users and Stakeholders

Clinical/Biomedical Informatician

(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)

A clinical/biomedical informatician would like to create an ontology that helps in clinical decision support at the point of care. He or she would like to re-use pre-existing controlled vocabularies such as Snomed, Foundational Model of Anatomy, etc. to be able to represent rich clinical descriptors that characterize location of fractures in various parts of the bones. How can OWL 2.0 help the informatician in this regard. Are there new constructs in OWL 2.0 that enable a more compact and understandable rerpesentation of the ontology, both from an authoring and a use perspective?

Information Modeler/Architect

(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)

An Information Modeler/Architect is typically charged with developing Enterprise Information Models, that would form components of an Information Architecture underlying the SOA based system architecture. The typical MDA (Model Driven Architecture) practitioner falls under this heading. MDA practitioners tend to be senior software architects within an organization, charged with developing an integrated set of platform-independent models of an application or system's business functionality and behavior, so that they can be reused across a variety of implementation platforms. In some sense both the Information Modeler/Architect and the MDA practitioner share the same set of goals. How can OWL 2.0 help these users achieve key benefits such as: (A) standardization of definitions to enable information interoperability across services and applications; (B) minimization of transformations between enterprise models and local application data models and structures; (C) Modeling business vocabularies (and/or ontologies) relevant for a particular domain independently from the software and rules development, and reusing the same consistent vocabulary across multiple applications or services.

Subject Matter Expert

(From http://esw.w3.org/topic/HCLS/ParkinsonUseCase)

This user type is similar to a Business Manufacturing Standards Developer and is an expert in various domains of clinical medicine such as neurology, internal medicine and others. These users typically work in conjunction with clinical informaticians, where they provide the domain knowledge and the informatician works on creating the appropriate representations in some knowledge representation language. The primary concern for this user is the ability to represent the types of knowledge and the ability to reason with and query information represented in a language In particular, it will be an important requirement for the OWL 2.0 to represent the following types of clinical and healthcare knowledge:

• Internal Medicine: An internist would be interested in knowing the symptoms, diagnostic tests and diagnoses for a patient in a clinical setting. He or she would also like to refer a patient to a specialist, e.g., neurologist, and the ability to represent clinical descriptors that describe referral criteria.
• Neurology: Neurologists work with internists for management of neurological diseases and are interested in performing and knowing the differential diagnosis of a patient, diagnostic and other interventions given to a patient, the prognosis for a patient; and the cost/benefit for a particular intervention given to a paitent

Use Cases

Use Case (New) - Problem Oriented Medical Record (POMR) Ontology

There have been multiple attempts to design a formal description of the medical record of a patient. There have been attempts to define information models such as the HL7 RIM, Archetypes, medical terminologies such as Snomed and ontologies such as Galen. The fundamental motivation for the design and philosophy of the Problem-Oriented Medical Record (POMR) is the belief that the medical record is the central medium of communication and the first repository of knowledge in the practice of clinical medicine. The traditional structure / organization of the POMR is: Screening Data (collected in order to discover problems, problem list, initial plans (organized by problem) and progress notes (outcomes and follow-up). There have been attempts to use OWL to represent the medical record.

• A Problem Oriented Medical Record Ontology proposes an OWL-based specification in an intial attempt to create a formal specification of the POMR. In doing so, it leverages ontologies such as Galen and the HL7/RIM. This has been developed using Notation 3 Rules and OWL.
• An OWL representation of HL7/RIM is an initial OWL-based representation of HL7/RIM
• RDF/OWL Representation of HL7/RIM v3.0 is an ongoing task with the Clinical Observations Interoperability Task Force (part of the W3C Interest Group on the Healthcare and Life Sciences) which seeks to represent the HL7/RIM in OWL.

How can OWL 2.0 enable a better representation of the medical record of a patient and address some of the shortcomings seen in the proposals above?

Use Case (New) - Specifying mappings across Multiple Terminologies

Use Case (New) - Specifying decision logic in CDS Rules

A Biomedical/Clinical Informatician is working with an Orthopedist to help devel

Use Case #1 - Brain image annotation for neurosurgery

The application concerns the preparation of surgical procedures in neurosurgery. Specifically, the aim is to assist the user in labelling the cortical gyri and sulci in the region surrounding the lesion, whose resection is the primary objective. Providing anatomical landmarks, especially in eloquent cortex, is highly important for surgery. Besides brain images annotation is useful in terms of documentation of the clinical cases, and with respect to the ability of retrieving similar cases for decision support in future procedures. A shared ontology of brain anatomy is also needed to integrate multiple distributed image sources indexed by anatomical features. It is useful for large-scale federated systems for statistical analysis of brain images of major brain pathologies.

[MEDICAL REQ] [Ontology with rules] [Brain Imaging ]

Requires: Disjoint Union, Disjoint Classes, Qualified Cardinality Restrictions, Disjoint Properties, Property chain inclusion axioms, [N-ary predicate, rules]

 Question (Christine): should we mention delayed requirements such as those within brackets ?

Use Case #7 - The Systematized Nomenclature of Medicine (SNOMED CT)

The Systematized Nomenclature of Medicine, Clinical Terms (SNOMED CT) is a work of clinical terminology with broad coverage of the domain of health care, and it has been selected as a national standard for use in electronic health applications in many countries, including the U.S., U.K., Canada, Australia, Denmark, and others. SNOMED was originally published in 1976, while SNOMED CT became available in 2002 as a major expansion resulting from the merger of SNOMED RT with the U.K.'s Clinical Terms version 3. A major distinguishing feature differentiating it from prior editions is the use of description logic (DL) to define and organize codes and terms. Another major distinguishing feature of SNOMED is its size and complexity. With over 350,000 concept codes, each representing a different class, it is an order of magnitude larger than the next largest DL-based ontology of which we are aware. The size of the OWL XML/RDF form of SNOMED is approximately 248 MB, and this is just the DL representation without all the synonyms, mappings, subsets, and other special-purpose components of the terminology. Without property chain inclusion axioms, adoption of OWL by the SNOMED community would have required awkward workarounds with their attendant complications and complexities - effectively killing movement in that direction. With [them], we have a clear path to using OWL 2 for further development and integration with other biomedical ontologies. Like the FMA given the common use of SNOMED cross-references, keys would be highly useful.

 Note (Micheldumontier). Please elaborate on the requirement for property chain inclusions - give example, and describe the workaround.

[SNOMED REQ]

Requires: Property chain inclusion axioms, Keys

Use Case # 9- Kidney Allocation Policy in France

Allocation in France falls under the responsibility of the Agence de la biomedicine. It includes general rules such as: donor-recipient ABO blood group identity, unique registration on the national waiting list and definition of some organ specific nation-wide allocation priorities. For each kidney recipient, minimal HLA matching and forbidden antigens can be specified. Pediatric recipients get a priority for pediatric donors. Kidneys are proposed by order of priority to (1) urgent patients, (2) patients with panel reactive antibodies level ≥ 80% included in a specific acceptable antigen protocol or ≤1 HLA mismatch with the donor, then (3) zero mismatch patients, and (4) patients with low transplantation accessibility. This real-life application and allocation system show how distinguishing between adults and children has strong implications in health care: at hospital, patients under 18 (child) depend on pediatric services while over 18 (adult) depend on adult services; only children less than 16 years waiting for a transplant have a priority on the waiting list.

[Agence Biomedecine] [Transplant Ontology]

Requires: Negative Property Assertion, Datatypes extension

Domain: Life Sciences

Applications

Users and Stakeholders

Scientific Database Leadership

(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)

A Prinicipal Investigator (PI) is leading an NIH project which involves gathering and integrating data from many laboratories funded by the NIH, in one area of biomedicine. Although familiar with the construction of ontologies, the PI wants to figure out how he might exploit ontologies to better work with his data, and understand how OWL 2.0 can fit in to the picture. How can OWL 2.0 be used in conjunction with or in migration from relational databases. The PI would be interested in knowing how using OWL 2.0 for implementing an integrated system would be better than existing approaches.

Subject Matter Expert

(From http://esw.w3.org/topic/HCLS/ParkinsonUseCase)

This user type is similar to a Business Manufacturing Standards Developer and is an expert in various domains of the Life Sciences, such a systems physiology, cellular and molecular biology and others. These users typically work in conjunction with biomedical informaticians, where they provide the domain knowledge and the informatician works on creating the appropriate representations in some knowledge representation language. The primary concern for this user is the ability to represent the types of knowledge and the ability to reason with and query information represented in a language In particular, it will be an important requirement for the OWL 2.0 to represent the following types of life sciences knowledge:

• Systems Neurophysiology: Systems neurophysiologists try to learn more about the normal functioning of brain circuits and their malfunction in Parkinsons Disease. They try to represent knowledge and query information related to wiring diagrams in brain systems, chemicals/neurotransmitters used by neurons for communications, proteins that recognize these chemicals and the reponses elicited, properties of neurons in a particular part of the brain. In particular, there is a great emphasis on partonomic and spatial knowledge and it would be of interest to these users to understand what aspects of OWL 2 support representation of these types of knowledge.
• Cellular and Molecular Neurobiology: Cellular and molecular neurobiologists try to represent knowledge and query information relted to proteints implicated in a neurological disease, e.g., Parkinsons, impact of the disease on protein expressions, protein folding, protein regulations and other interactions; cell signaling pathways and the proteins implicated in a disease and different types of biomarkers for a disease.

Use Cases

Use Case #2 – The Foundational Model of Anatomy

The Foundational Model of Anatomy (FMA) is the most comprehensive ontology of human ‘canonical’ anatomy. Anatomy plays a prominent role in biomedicine and many biomedical ontologies and applications refer to anatomical entities. FMA is a tremendous resource in bioinformatics that facilitates sharing of information among applications that use anatomy knowledge. As its authors claim, the FMA is “a reference ontology in biomedical informatics for correlating different views of anatomy, aligning existing and emerging ontologies in bioinformatics...” . Anatomy, together with Gene and Disease reference ontologies constitute the backbone of the future Semantic Web for Life Sciences. The FMA should benefit to state that some properties are exclusive (e.g.; proper-part and bounded-by). Since many biomedical ontologies and applications refer to the FMA anatomical entities through cross-references, keys would be highly useful.

  Note (Micheldumontier). First, anatomy is more about the health sciences, than the life sciences. Second - please expand on the notion of "exclusive" properties, and what value they might have - illustrate with a clear example. Third, it is wholly unclear how "keys" would be useful in the identified context - please provide sufficient detail.

[FMA]

Requires: Disjoint Union, Disjoint Classes, Qualified Cardinality Restrictions, Disjoint Properties, Keys

Use Case #3 - Classification of chemical compounds

Functional groups describe the semantics of chemical reactivity in terms of atoms and their connectivity, which exhibit characteristic chemical behavior when present in a compound. In this use case the authors take a first step towards designing an OWL-DL ontology of functional groups for the classification of chemical compounds, highlight the capabilities and limitations of OWL 1.0 and the proposed OWL 1.1 in terms of domain requirements. They also describe the application of expressive features in the design of an ontology of basic relations and how, an upper level ontology, can be used to guide the formulation of life science knowledge. They report on experiences to enhance existing ontologies so as to facilitate knowledge representation and question answering.

[Chemistry]

Requires: Disjoint Union, Disjoint Classes, Qualified Cardinality

Use Case #5 - OBO ontologies for biomedical data integration

The Open Biomedical Ontologies (OBO) consortium is pursuing a strategy to facilitate the integration of biomedical data through their annotation using common controlled ontologies. Existing OBO ontologies, including the Gene Ontology, are undergoing coordinated reform, and new ontologies are being created on the basis of an evolving set of shared principles governing ontology development. The result is an expanding family of OBO ontologies designed to be interoperable and to incorporate accurate representations of biological reality. Within that effort the OBO ontology of relations is designed to define a set of basic relations with their semantics. OBO qualifies each relation using characteristics of being transitive, symmetric, reflexive, anti-symmetric. Property axioms to express these features are required for accurate knowledge representation.

[OBO] [RO] [OBO2OWL]

Requires: Reflexive, Irreflexive, Asymmetric, Property chain inclusion axioms, [Antisymmetric]

Use Case #8 - Simple part-whole relations in OWL Ontologies

Representing part-whole relations is a very common issue for those developing ontologies for the Semantic Web. OWL does not provide any built-in primitives for part-whole relations (as it does for the subclass relation), but contains sufficient expressive power to capture most, but not all, of the common cases. The study of part-whole relations is an entire field in itself - "mereology" - this note is intended only to deal with straightforward cases for defining classes involving part-whole relations. Several extensions of whole needed for part-whole are discussed in this study, namely, needs of qualified cardinality restriction, reflexivity, propagation from parts to whole

[Part Whole]

Requires: Qualified cardinality restriction, Reflexivity, Property chain inclusion axioms

Domain: Manufacturing

Applications

Users and Stakeholders

Manufacturing Technical Standards Developer

(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)

A Manufacturing Technical Standards Developer has some knowledge of manufacturing systems and processes and develops standard data formats, models, and/or protocols which enable integration or replacement of manufacturing systems. Typically could be a systems integrator, solution provider, system developer, or information modeler/architect. Probably has detailed familiarity with XML, EDI and/or some class of communications middleware. May have knowledge of one or more data modeling (e.g. NIAM/ORM or EXPRESS), object modeling (UML), or schema modeling languages.

Manufacturing Business Standards Developer

(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)

A Manufacturing Business Standard Developer has knowledge of a particular process, activity, and/or system in a manufacturing business. He might know some details of data related to that process or system but will likely prefer to use office applications (word processor and/or spreadsheet tool) to capture the information. He might be considered similar to a Subject Matter expert user type in the Healthcare and Life Sciences. In the context of developing consensus standards, he can work in conjunction with a competent information modeler or informatician to capture information and interpret the language for others. He has come to appreciate a modeling or ontology language as enabling richer shared understanding and more precise agreement on what is being standardized. To what extent can OWL 2.0 forward the goal of enabling richer shared understanding and more precise agreement on what is being standardized?

Use Cases

Use Case #4 - Querying multiple sources in an automotive company

Large companies often store information and knowledge in multiple information systems using various models and formats. A main issue is to retrieve the relevant knowledge for a specific concern from the different sources. The aim of the application is to query multiple data and knowledge sources for a large automotive company faced to this problem.

[Auto]

Requires: Disjoint Union, Qualified Cardinality

Domain: Earth and Space Sciences

Knowledge management in earth and space science information systems aims to support domain scientists, information and data specialists, teachers, and lay personnel in providing access to data concerning the natural world. Not only do applications need to provide access to data in single discipline areas, they also must provide access to data concerning multiple disciplines in ways that are appropriate to a wide range of users. Key applications and functionalities supported in earth and space science information systems along with various users and stake holders follow below.

Applications

Virtual Observatory (VO)

A virtual observatory is a suite of software applications on a set of computers that allows users to uniformly find, access, and use resources (data, software, document, and image products and services using these) from a collection of distributed product repositories and service providers. A VO is a service that unites services and / or multiple repositories.

 Note {DeborahMcGuinness}. We need to figure out how best to deal with typical and other publications that are the sources for our requirements and/or definitions such as this one above.

from http://lwsde.gsfc.nasa.gov/VO_Framework_7_Jan_05.doc . Numerous single discipline and multi-discipline virtual observatories (e.g., http://vsto.org, http://vmo.nasa.gov/ ) are beginning to use semantic technologies to provide data access and integration. Some Virtual Observatories are focusing quite heavily on provenance encoding at data ingest time (e.g., http://spcdis.hao.ucar.edu/ ). Organizations like the Federation of Earth Science Information Partners (ESIP - http://www.esipfed.org/ ) are looking to semantic technologies to support services ranging from ontology-enhanced search to fairly detail oriented integration of databases.

Users and Stakeholders

Earth and Space Science Researcher

From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents A scientist who is interested in using semantic technologies to perform information ontology-enhanced search over a repository or set of repositories of scientific information. The subject matter expert may need to review the science terms in the ontology to determine adequate coverage, they may need to enhance the ontology to include terms that are new to the ontology, and they may need to check existing definitions. They also may need to check for compliance with particular science vocabularies and thus may need to look for terms and same-as relationships. Some critical support for these users is browsing capabilities, targeted search, and expressive power for representing mapping across terms and for refining terms.

Computational Scientist / Software Engineer

Much of earth and space science revolves around sophisticated queries for data (that is largely numerical) but that is generated by complicated processes. These users need to be able to have expressive power for representing numerical ranges and scientific units and mathematical conversion processes. They also benefit from being able to express reasonably detailed scientific processes such as those described in the volcano and atmosphere example of the SESDI project (Semantically-Enabled Scientific Data Integration). (http://gsa.confex.com/gsa/2007GE/finalprogram/abstract_122252.htm )

Existing Implementation Owner of Earth and Space Science Application

From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents These users already have OWL 1.0 applications deployed and have significant amounts of programs written that connect to legacy databases and web services. They need to have migration support tools including translators and documentation concerning transition from both the language and the documents.

Use Cases

Use Case #18 – Virtual Solar Terrestrial Observatory

From http://www.ksl.stanford.edu/KSL_Abstracts/KSL-07-01.html and deployed at http://vsto.org . The Virtual Solar Terrestrial Observatory is a National Science Foundation and National Center for Atmospheric Research supported effort that allows researchers to find solar and solar-terrestrial data. It provides an ontology-enhanced interface to semantically-enhanced web services that help access a number of online repositories of scientific data. The background OWL ontology contains term descriptions for science terms including instruments, observatories, parameters, etc. Users essentially need to specify a description of the data they wish to retrieve which includes either a specific instrument class or a description of that class, a date range for the data taken, and the parameters. In order to specify that in relevant science terms, scientists need to be able to represent numerical ranges and comparisons (thus going beyond the numeric support of OWL 1). The application also needs to expand to include spatial descriptions. It would use representational power if provided for spatial/geographic containment.

Use Case #19 – Semantic Provenance Capture

From http://spcdis.hao.ucar.edu/. In an effort to provide better search capabilities over meta information in addition to scientific data, the SPCDIS effort is providing infrastructure to capture declarative descriptions of scientific provenance information at data ingest time. The initial domain of the effort is solar coronal physics. This effort requires (among other things) extended annotations (4.13 R13 in the requirements document) as well as datatype restriction (4.10 R10).

Use Case #6 – Spatial and topological relationships at the Ordnance Survey

Ordnance Survey is Britain's National Mapping Agency. It currently maintains a continuously updated database of the topography of Great Britain. The database includes around 440 million man-made and natural landscape features. These features include everything from forests, roads and rivers down to individual houses, garden plots, and even pillar boxes. In addition to this topographic mapping, entire new layers of information are progressively being added to the database, such as aerial photographic images which precisely match the mapping; data providing the addresses of all properties; and integrated transport information. Here for the topological and spatial relationships, and in many other places, “we need to be able to say whether a property is reflexive, irreflexive, asymmetric or antisymmetric in order to capture the true intentions of our axioms”.

[Ordnance]

Requires: Reflexive, Irreflexive, Asymmetric, [Antisymmetric]

Domain: Clinical Research and Clinical Trials

This domain consists of information and knowledge related to a patient's clinical information in the context of his or her participation in a clinical research study or a clinical trial, which may be characterized by a set of clinical processes or protocols.

Applications

Key applications in this domain are clinical trials management, that keep track of various patient, trial and investigator related information across multiple clinical trials, detection and resolution of adverse events,

Clinical Trials Management

This application supports the ability to acquire, store and manage clinical data of patients participating in a clinical trial. It also seeks to track the progress of a patient through a clinical trial based on well defined clinical processes and protocols.

Adverse Event Detection and Resolution

This application tries to detect adverse events and clinical conditions in response to a particular drug. It monitors the data for unusal signs of clinical events that can be correlated with starting the patient on a particular drug. It uses knowledge created by experts to determine an appropriate response to the adverse reaction

Patient Recruitment

This applicaion seeks to determine a set of patient cohorts that qualify for a clinical trial, based on the clinical data associated with a patient and the inclusion and exclusion criteria associated with the clinical protocol.

Users and Stakeholders

Subject Matter Expert

This user type is similar to a Business Manufacturing Standards Developer and is an expert in various domains of clinical medicine such as neurology, internal medicine and others. These users typically work in conjunction with clinical informaticians, where they provide the domain knowledge and the informatician works on creating the appropriate representations in some knowledge representation language. The primary concern for this user is the ability to represent the types of knowledge and the ability to reason with and query information represented in a language In particular, it will be an important requirement for the OWL 2.0 to represent the following types of clinical knowledge:

• Clinical Researcher/Clinical Trials Investigator: Clinical researchers and clinical trial investigators are responsible for running clinical trials and studies that seek to evaluate the effects of a drug on a patient cohort. They are interested in information and knowledge such as the diagnostic tests and imaging studies associated with a disease, therapeutic interventions and their impact/efficacy in treating a disease, side effects, costs and benefits associated with a drug.
• Clinical Guidelines Formulator: Academic researchers and professional societies synthesize the available evidence regarding the diagnosis and management of a disease to generate human-readable clinical guidelines. There are now approaches that seek to semi-automatically created executable representations of these guideline. The information and knowledge of interest to this user aare: the results of clinical trials, cost and benefits of a drug for a disease, the characteristics of a clinical trial, such as the type, e.g., double blind randomized clinical trial, the sample size and power of the trial, the relationships between recommendations made in the guideline and the results and evidence strength of the clinical trial.

Use Cases

Use Case (New) - Interoperation of Clinical Data across Healthcare Delivery and Clinical Trials

Use Case #10– Eligibility Criteria for Patient Recruitment

DESCRIPTION TO BE DONE: Vipul

=> n-ary dtatypes still in the spec or out ?

Requires: Datatypes extension

Use Case #11 – Multiple UCs of datatype extensions

Many Use cases that would benefit from datatype extensions are listed, some simply requiring datatypes restrictions like intervals, other ones requiring N-ary extensions.

Requires: Datatypes extension

[N-ary]