Schedule

2. Schedule

3. Agenda: Q1 (8:30 – 10:00) • Introductions (JPE) • Learning Objectives (JPE) • UML Overview • What is a Domain Analysis Model? (AMS) • Why is BRIDG needed? (AMS) • How to read UML using the BRIDG style (AMS)

4. Introductions • Julie Evans • Sr. Director, Technical Services, CDISC • Abdul-Malik Shakir • Principal Consultant, Shakir Consulting • Information Management Strategist, City of Hope Hospital • Wendy Ver Hoef • Senior Analyst, ScenPro, Inc. • Diane Wold • Director, Data Standards, GlaxoSmithKline

5. Learning Objectives • Each team leader should have some idea about the relationship between their standard and BRIDG. • Each team leader should see the value in BRIDG and how it can be applied to their standard.

6. Domain Analysis Modeling PARTY IDENTIFICATION NUMBER PARTY PARTY ACTIVITY ROLE Identification Number Begin Date Issuing Authority Name End Date Issue Begin Date Role Code Issue End Date PARTY CASE DEFINITION ROLE CASE DEFINITION Type Code Begin Date Begin Date End Date Category Code Role Code Description End Date PATIENT COVERAGE Name Provider Code PARTY CASE ROLE Begin Date End Date Role Code BILLING ACCOUNT PARTY NOTIFICATION CASE Begin Date Begin Date End Date Confirmation Method Code PARTY TO PARTY ASSOCIATION Notification Receiver Identification Number Count Notification Sender Identification Number Begin Date Count Type Code Code Detection Method Code End Date End Date Identification Number Transmission Mode Code Status Code Status Date PUBLIC HEALTH NOTIFICATION Begin Date End Date Identification Number Reason Code ORGANIZATION INDIVIDUAL Entity Alias Name Name Name Type Type Code Outbreak Begin Date DIAGNOSIS End Date PARTY CONDITION Classification Scheme Code Extent Code Disease Code Begin Date Peak Date Diagnosis Code Description Diagnosis Date End Date Source Code Name Source Text Name Status Text INFORMAL ORGANIZATION Formal Organization PERSON NON PERSON LIVING ORGANISM Status Date OUTBREAK STATISTIC Industry Code Birth Date Genus Name Death Date Species Name Amount Ethnicity Code Category Code PARTY LOCATION ROLE Race Code Type Code Begin Date Sex Code End Date Soundex Text Role Code Occupation Name Status Code Status Date PARTY SPECIMEN ROLE PERSON NAME Begin Date Degree Name End Date First Name Role Code Last Name Middle Name Prefix Name Suffix Name Type Code PARTY VEHICLE ROLE Begin Date End Date Role Code VEHICLE HEALTH RELATED ACTIVITY Description Begin Date Time Name Disposition Date Time (Implication) Status Code Disposition Description Status Date End Date Type Code Identification Number Notification Indicator Priority Code Source Type Code DISEASE ASSOCIATION Type Code LOCATION Disease Code Address Disease Imported Code Identification Number Etiologic Status Code Name Etiologic Status Date VEHICLE CONDITION Setting Code Exposure Begin Date Type Code Description Exposure End Date Description Status Code Infection (or Illness) Type Code(s) Status Date SPECIMEN LOCATION Begin Date End Date TEST REFERENCE TABLE Method Code Name Samples Required Number Samples Required Unit Code SPECIMEN Type Code Collection Date DISEASE CAUSING AGENT Description Agent Type Code TEST Identification Number HEALTH STATUS INQUIRY Agent Name INTERVENTION REFERRAL Name Amount Amount Referral Basis Code Source Code Amount Unit Code Amount Number Referral Type Name Type Code Begin Date Amount Unit Code Referral Acceptance Code Description Description Description Code Duration ADDRESS TELEPHONE Duration Duration Unit Code Begin Date Telephone Type Code Duration Unit Code Enrollment Code City Name Area Code End Date Enrollment Type Code Country Name Number Live Births Number Manufacturer Lot Number County Name Manufacturer Lot Number Manufacturer Name End Date Manufacturer Name Name Postal Code Reason Text Route Code TEST RESULT CODE Status Date Result Date Status Code Amount Code State Code Result Text Status Date Amount Unit Code Description Street Address Text Status Code Code Coding System Name Type Code Status Date Date Travel Country Name Description Type Code Description Code

7. Why Model To aid in understanding relevant functions and information needs of a particular domain To communicate the modeler’s understanding of the domain and allow that understanding to be assessed by others To aid in reconciling multiple perspectives of a domain by combining varying perspectives into a single specification To document a solution design (existing or planned) so that the design may be evaluated

8. Reveal Assumptions Do you play football? Yes, I do play football. Revealing assumptions is an essential component of effective communication. Data models are an effective means of documenting our assumptions about a domain

9. Reduce Ambiguity A B 0..* 1 0..* 0..* C Modeling provides a language that allows us to unambiguously express our understanding and assumptions about the actions and information of interest in a particular domain

10. Reconcile Conflicts X B A B 0..* 0..* 1 1 0..* 0..* 0..* 0..* C C Sharing models provides an opportunity to identify and reconcile conflicts in our understanding and to validate our assumptions.

11. Expand Understanding A B A B 0..* 1 0..* 0..* 0..* 1 0..* 0..* C D Sharing models also provides an opportunity to identify gaps in our understanding. No one of individual has the complete view of domain of interest.

12. Consolidate Ideas A B A X B B 0..* 1 0..* 0..* 0..* 1 0..* 1 0..* 0..* 0..* 0..* C D C G B E 0..* 1 0..* 1 0..* 1 D C X A F 0..* 0..1 1 0..* Model I Model II Model III

13. Value of Modeling Reveal Assumptions Reduce Ambiguity Reconcile Conflicts Expand Understanding Consolidate Ideas

14. What is a Domain Analysis Model • A Domain Analysis Model (DAM) is a conceptual model used to depict the behavioral and static semantics of a domain of interest. • A DAM provides an opportunity for subject matter experts (SMEs) within a particular domain to integrate and harmonize their perspectives regarding the use cases, activities, and information needs of their shared domain. • A DAM is particularly useful when used in a domain with broad interests and a diverse population of SMEs.

15. Domain Analysis Model Use • A domain analysis model is used as reference material in development of information system interoperability specifications as well as design specifications of information system components • The DAM is a requirement specification and is the primary artifact from which information system design specifications are derived. • The preferred language for expression of a domain analysis model is UML.

16. Unified Modeling Language (UML) • UML is a standardized general-purpose modeling language in the field of software engineering. • UML is not a development method; however, it was designed to be compatible with the leading object-oriented software development methods. • UML includes a set of graphical notation techniques to create visual models of software-intensive systems.

17. Introduction to UML Modeling

18. UML Diagram Classifications There are three classifications of UML diagrams: Structure diagrams.  A type of diagram that depicts the elements of a specification that are irrespective of time.  Behavior diagrams.  A type of diagram that depicts behavioral features of a system or business process.  Interaction diagrams.  A subset of behavior diagrams which emphasize object interactions.

19. Relevant DAM UML Diagram Types

20. Domain Analysis Modeling

21. Domain Analysis Use Cases

22. Use Case Diagram

23. Use Case Diagram A use case diagram is used to define the scope of activities and stakeholders of interest to the domain analysis model. Each use case is an activity in the domain of interest that provides value to the participating actors Use case actors are persons, organizations, systems, and system components that participate in use cases as performers or beneficiaries

24. CTRR DAM – Use case diagram

25. Tutorial Domain Analysis Use Cases

26. Activity Diagram Activity diagrams depict a controlled sequence of activities. Activity diagrams optionally include swim lanes and information flows. Swim lanes can be used to related processes to responsible actors. Information flows are useful for linking behavioral requirements to information requirements.

27. Activity Diagram Activity diagrams are typically used to depict the flow of activities within a given use case. Swim lanes in an activity diagram are often traceable to the actors involved in the use case realized by the activity diagram. Information objects in an activity model can be linked to classes in a class diagram and messages in an interaction diagram.

28. CTRR – Clinical Trial Registration

29. CTRR Activity Diagram

30. Tutorial Domain Analysis Use Cases

31. Components of an UML Class Diagram • Package • A collection of related classes • Class • Something about which information is maintained • Attribute • An element of information pertaining to a class • Data Type • A specification of the structure and value constraint for an attribute • Relationship • An association between classes

32. Package Class Relationship Attribute Datatype Components of an UML Class Diagram

33. CTRR – Class Diagram

34. CTRR Class Packages

35. CTRR Material Class Diagram

36. Relationship Assertions A relationship assertion is a sentence derived from the data model by examining the relationship between two classes. The sentence asserts a fact implied by the relationship. A subject matter expert must be consulted to determine if the assertion is true. If the assertions is not true then the model must be modified. Each Class {always / sometimes } relationship name {one / one or more} Class Each Patient Service always is provided in one Encounter

37. Domain Analysis Use Cases

38. Domain Analysis Model Model Elements

39. Domain Analysis Model Diagrams 39

40. Style Guide

41. One Concept - Many Symbols 2 II TWO 102 1 + 1 41

42. Semantic Consistency – Structural Variance Model One «datatype» Person PersonName - name: PersonName - lastName: char - birthDate: dateTime - firstName: char - phone: PersonPhone [0..2] (list) Person constraints Model Two {PersonPhone(1) is Home Phone} - lastName: char {PersonPhone(2) is Work Phone} - firstName: char - birthDate: dateTime - homePhone: char «enumeration» - workPhone: char PhoneKind «datatype» PersonPhone «enum» Home - phoneKind: PhoneKind Work - phoneText: char PersonName Person - personNameKind: PersonNameKind - personNameText: char - birthDate: dateTime 0..2 constraints {PersonNameKind is Unique} Model Three 0..2 PersonPhone «enumeration» «enumeration» PersonPhoneKind PersonNameKind - phoneKind: PersonPhoneKind - phoneText: char «enum» «enum» Home lastName constraints Work firstName {PersonPhoneKind is Unique}

43. All models are wrong; some are useful. ~ George Box

44. Characteristics of a Useful Model Salient: Since no model can represent everything, it must selectively represent those things most relevant to the task at hand. Accurate: The model should precisely encode the actual state of affairs and not an erroneous or biased view. Complete yet Parsimonious: The model should be as simple as possible, but no simpler. It should concisely capture all the relevant dimensions of the problem without squeezing out the opportunity for serendipitous or creative insight. Perceptible: Models should be appropriately displayed in high fidelity as they won't be much use if we can't clearly see, hear, or feel them. Understandable: Once we perceive the model we must be able to make sense of it; it mustn't be too complicated or unfamiliar for us to understand. Descriptive: The model should clearly and objective describe the true situation. Emotive: In addition, the model should convey a subjective feel for the emotional and value-laden connotations of the situation being modeled. Inspiring: Because people are drawn to and inspired by thoughtful design, models should be elegant, i.e. they should synergistically combine style and substance. Memorable: Models are not of much use if they pass quickly from the mind, or if they cannot be used as a mnemonic device. Models should be easily accessible for future reference and to refresh our understanding. Flexible: As all models are, to some degree, inaccurate, irrelevant, mistaken, time-sensitive etc., they should be open to recursive revision to reflect new data, our growing understanding, or our evolving needs. Coherent: Models do not exist in isolation but in interlocking systems, thus any particular model should be coherent with other related models. Productive: Ultimately, the model has a purpose: the production of effective action. A good model should help define our goals and then specify the actions necessary to reach them. Useful: Usefulness is the sum of the above properties and the degree to which they combine to promote understanding and effective action. It is important to note that the most accurate, or the most complete, or the most elegant model is not necessarily the most useful. All models are incomplete. All models a compromise. The model maker's art lies in making those shrewd trade-offs that will render the model most useful to the problem at hand.

45. BRIDG Style Guide Rules

46. CTRR Project • The intent of the CTRR project is to create a comprehensive and generic interchange standard for Clinical Trial Registries that includes all required and optional elements of most external clinical trial registries; including, but not limited to, EudraCT, clinicaltrials.gov, PDQ, and WHO. • Developing a standard for exchanging information for Clinical Trial Registries and Databases was originally initiated as a formal project of the Health Level Seven (HL7) Regulated Clinical Research Information Management (RCRIM) Technical Committee in September of 2004. • The CDISC/HL7 clinical trial registries working group includes representatives from several pharmaceutical companies (eg., Novartis, J&J PRD, GSK), technology solution providers, CROs, NIH, clinicaltrials.gov, and observers from the FDA.

47. Using the BRIDG for CTRR

48. Define CTRR Data Requirements

49. Map Data Requirements to BRIDG

50. CTRR BRIDG Subset