Expressing Clinical Data Interpretation Facility Semantics Using Business Object Component Architect

1
Expressing (Clinical) Data Interpretation
Facility Semantics Using Business Object
Component Architecture (BOCA) Component
Definition Language (CDL)corbamed/98-03-26bom/98
-03-1631 March 1998 (Revised)
Presented by Michael Reeds Chiron
Informatics Supported by Genesis Development
Corporation
2
Why CDL ?

• Goal To make analysis--creating
  specifications--as disciplined as programming
  --Kilov Ross, Information Modeling,
  Prentice-Hall, 1994
• IDL supports expression of a types syntax
• Attributes
• Operation signatures
• BOCA and CDL support expression of a types
  semantics
• Specifying whether a type is abstract
• Constraints on and initial values for attributes
• Pre- and post-conditions for operations
• Specifying whether an operation alters state (has
  side effects)
• Signals (events)
• More precise specification of relationships
  between types
• Specification of type-level attributes and
  operations
• etc.

3
Declaring Value Types

• // dependent is a keyword that declares a type
  whose
• // instances have no identity, are not
  responsible for
• // their persistence, and are passed by value.
• //
• // is_abstract means the type is abstract.
• is_abstract dependent DIFValue
• // A type (manager) level attribute
• MANAGER attribute string unitOfMeasure
• dependent ProbabilityValue DIFValue
• // Attribute value can be initialized in a
  subtype and
• // locked from further changes
• MANAGER, is_locked attribute string
  unitOfMeasure
• percentage

4
More Specific Subtypes of Value
dependent HBVViralLoadValue DIFValue
MANAGER, is_locked attribute string
unitOfMeasure
meq constraint ((value gt 0)
(value lt 100000)) attribute unsigned long
viralLoad is_abstract dependent
OrdinalValue DIFValue attribute
unsigned short ordinal dependent
NodellScoreValue OrdinalValue //
NodellScoreValue imposes a constraint on the
// inherited attribute constraint ((value
gt 0) (value lt 4)) attribute unsigned
short ordinal
5
Adding Semantics to HL7 Value Types
// Based on HL7 Dt_date class dependent
Dt_dateValue DIFValue constraint
((value gt 1) (value lt 31)) attribute
unsigned short day_qty constraint
((value gt 1) (value lt 12)) attribute
unsigned short month_qty constraint
((value gt 0) (value lt 3000 attribute
unsigned short year_qty
6
Declaring Relationships
// The problemId attribute is declared to be the
unique key // for identifying Problem
instances is_abstract, keys problemId entity
Problem // a.k.a Transformation attribute
string problemId attribute string
description attribute string didacticURL
// InputSet and ResultSet are types defined
elsewhere. attribute InputSet inputSet
attribute ResultSet resultSet // Declares a
relationship named isSolvedBy that references
// one or more instances of the type Solver
without // containment, and identifies its
inverse relationship // named solves in the
type Solver relationship isSolvedBy Many 1..
Solver inverse solves
7
Relationships, Part 2
is_abstract process Solver // process
means that the type
// represents a business process ... //
The inverse of the isSolvedBy relationship in the
type // Problem relationship solves
references 1..1 Problem inverse isSolvedBy
...
8
Behavioral Semantics
is_abstract process Solver // process
means that the type
// represents a business process void
SolveAsync (in InputSet inputSet,out unsigned
long jobNum) ... // Pre and post
conditions specify semantics for the signal
pre_condition (Status (jobNum) solved)),
post_condition (Status (jobNum)
notified)), readonly // The signal cant be
triggered by another object signal Solved (in
unsigned long jobNum) enum JobStatus
unknown, solving, solved, notified,
solutionRetrieved, failed //
is_query means state not altered--i.e. no side
effects is_query JobStatus Status (in
unsigned long jobNum) pre_condition
((Status (jobNum) notified)
(Status (jobNum) solved)),
post_condition (Status (jobNum)
solutionRetrieved) ResultSet GetSolution (in
unsigned long jobNum)