RE: [COI] Following up on your comment re "underlying model" in your reviewing the functional requirements spreadsheet

> my comment was about the need for a "underlying model". While the issue I
> raised is about our current focus on the mappings between specific terms
> in different terminologies. Instead I would like us to move beyond the
> mappings and focus more on how to specify different types/classes/kinds of
> clinical observations.

[VK] This is exactly, which I have divided the functional requirements
spreadsheet into three parts now:
- Information Models
- Terminologies
- Data Types and Units

> SDTM's information
> model assumes a flat file structure of variables for information
> interchange/submissions to FDA (see slide 7 and 8).

[VK] Yes, that might be an issue when it comes to map "flat constructs" in SDTM
to "nested constructs" in DCM and other Healthcare models. 

>       So far, CDISC do not provide a common model to specify the different
> types/classes/kinds of observation descriptions: what observations of
> "real-world phenomenon" they describe using different terminologies, the
> contextual information required to interpret the observation results,
> alternative classifications and formats for the observation results etc..
> Instead sets of terms / codes / "submission values" are published as
> CDISC's own controlled terminologies using terms such as "ALT", "CRP" and
> "DIABP" 2] defined in NCI Thesaurus (see slide 5).

[VK] This is exactly what we will figure out how to handle when we do the
mapping exercise.

>       CDISC SDTM include a trial design variable for inclusion/exclusion
> criterion rules "in computer-executable form" (see slide 3). This is very
> good, but as long as we lack a common way to specify, and identify, the
> different types/classes/kinds of clinical observations, I think it will be
> hard to express such rules.

[VK] Absolutely agree with the above! The key issue is getting the underlying
information models right. Specifying rules/axioms to express the protocols will
follow easily. It is interesting to note that most of the BRMS engines focus on
building a robust Business Object Model which is the vocabulary for specifying
these business rules.

Nice to see the meeting of the minds!

---Vipul


The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.

Received on Monday, 29 October 2007 17:28:38 UTC