The document provides an overview of domain analysis modeling presented by Abdul-Malik Shakir at an HL7 meeting. It discusses the purpose of domain analysis modeling, including revealing assumptions, reducing ambiguity, reconciling conflicts, expanding understanding, and consolidating ideas. It also covers the HL7 development framework methodology, modeling with the unified modeling language, and examples of use case diagrams and class diagrams for domain analysis modeling.
1. Domain Analysis Modeling Abdul-Malik Shakir Principal Consultant, Shakir Consulting January 2009 Working Group Meeting Lake Buena Vista, FL
2.
3.
4.
5. HDF Workflow Diagram January 2009 Domain Analysis Modeling Tutorial of 84 The HDF workflow is not a waterfall methodology. Each phase builds upon the prior and may cause prior activities to be revisited and their deliverables adjusted.
6.
7.
8.
9.
10.
11.
12.
13. HDF Workflow Diagram January 2009 Domain Analysis Modeling Tutorial of 84 The HDF workflow is not a waterfall methodology. Each phase builds upon the prior and may cause prior activities to be revisited and their deliverables adjusted. A Domain Analysis Model is a specification of requirements for a project or a domain of interest.
14. Domain Analysis Modeling January 2009 Domain Analysis Modeling Tutorial of 84 TEST RESULT Amount Amount Unit Code Code Date Description Description Code PARTY LOCATION Address Identification Number Name Setting Code Type Code SPECIMEN Collection Date Description Identification Number Name Source Code Type Code HEALTH RELATED ACTIVITY Begin Date Time Disposition Date Time Disposition Description End Date Identification Number Notification Indicator Priority Code Source Type Code Type Code HEALTH STATUS INQUIRY Amount Amount Unit Code Begin Date Description Description Code Duration Duration Unit Code End Date Live Births Number Manufacturer Lot Number Manufacturer Name Reason Text Result Date Result Text Status Code Status Date Travel Country Name Type Code DIAGNOSIS Classification Scheme Code Disease Code Diagnosis Code Diagnosis Date Source Code Source Text PUBLIC HEALTH NOTIFICATION Begin Date End Date Identification Number Reason Code INTERVENTION Amount Amount Number Amount Unit Code Description Duration Duration Unit Code Enrollment Code Enrollment Type Code Manufacturer Lot Number Manufacturer Name Name Route Code Status Code Status Date REFERRAL Referral Basis Code Referral Type Name Referral Acceptance Code BILLING ACCOUNT PARTY TO PARTY ASSOCIATION Begin Date Code End Date CASE DEFINITION Begin Date Category Code Description End Date Name PARTY CONDITION Begin Date Description End Date Name Name Status Text Status Date PARTY NOTIFICATION Begin Date End Date Notification Receiver Identification Number Notification Sender Identification Number PARTY ACTIVITY ROLE Begin Date End Date Role Code DISEASE CAUSING AGENT Agent Type Code Agent Name PARTY CASE ROLE Begin Date End Date Role Code PARTY CASE DEFINITION ROLE Begin Date End Date Role Code PARTY LOCATION ROLE Begin Date End Date Role Code Status Code Status Date TEST DISEASE ASSOCIATION Disease Code Disease Imported Code Etiologic Status Code Etiologic Status Date Exposure Begin Date Exposure End Date Infection (or Illness) Type Code(s) SPECIMEN LOCATION Begin Date End Date PERSON NAME Degree Name First Name Last Name Middle Name Prefix Name Suffix Name Type Code PATIENT COVERAGE Provider Code VEHICLE Description Name (Implication) Status Code Status Date Type Code CASE Begin Date Confirmation Method Code Count Count Type Code Detection Method Code End Date Identification Number Transmission Mode Code Status Code Status Date ADDRESS Begin Date City Name Country Name County Name End Date Postal Code Status Date State Code Street Address Text Type Code TELEPHONE Telephone Type Code Area Code Number CODE Code Description Coding System Name ORGANIZATION Alias Name Name Type Code Entity Name Type INDIVIDUAL PERSON Birth Date Death Date Ethnicity Code Race Code Sex Code Soundex Text Occupation Name NON PERSON LIVING ORGANISM Genus Name Species Name INFORMAL ORGANIZATION Formal Organization Industry Code PARTY IDENTIFICATION NUMBER Identification Number Issuing Authority Name Issue Begin Date Issue End Date Type Code TEST REFERENCE TABLE Method Code Name Samples Required Number Samples Required Unit Code Type Code PARTY SPECIMEN ROLE Begin Date End Date Role Code PARTY VEHICLE ROLE Begin Date End Date Role Code OUTBREAK STATISTIC Amount Category Code Type Code VEHICLE CONDITION Description Description Status Code Status Date Outbreak Begin Date End Date Extent Code Peak Date
15.
16.
17. Reveal Assumptions January 2009 Domain Analysis Modeling Tutorial of 84 Revealing assumptions is an essential component of effective communication. Data models are an effective means of documenting our assumptions about a domain Yes, I do play football. Do you play football?
18. Reduce Ambiguity January 2009 Domain Analysis Modeling Tutorial of 84 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 A C B 0..* 0..* 0..* 1
19. Reconcile Conflicts January 2009 Domain Analysis Modeling Tutorial of 84 Sharing models provides an opportunity to identify and reconcile conflicts in our understanding and to validate our assumptions. A C B 0..* 0..* 0..* 1 X C B 0..* 0..* 0..* 1
20. Expand Understanding January 2009 Domain Analysis Modeling Tutorial of 84 Sharing models also provides an opportunity to identify gaps in our understanding. No one of individual has the complete view of domain of interest. A C B 0..* 0..* 0..* 1 D A B 0..* 0..* 0..* 1
21. Consolidate Ideas January 2009 Domain Analysis Modeling Tutorial of 84 Model I Model II Model III B X F E C A D G 1 0..* 0..* 1 0..* 1 0..* 0..1 0..* 1 A C B 0..* 0..* 0..* 1 X C B 0..* 0..* 0..* 1 D A B 0..* 0..* 0..* 1
22.
23.
24. Introduction to UML Modeling January 2009 Domain Analysis Modeling Tutorial of 84
25.
26.
27.
28.
29. UML Diagram Types January 2009 Domain Analysis Modeling Tutorial of 84
52. Class Relationship Types January 2009 Domain Analysis Modeling Tutorial of 84 Association Generalization Aggregation Composition Mother Child Parent Mother Building BuildingFloor Team TeamMember Father 1 1..* 1..* 1 0..* 1..*
53.
54. Sample Class Diagram With Relationships January 2009 Domain Analysis Modeling Tutorial of 84
55.
56. Relationship Assertion January 2009 Domain Analysis Modeling Tutorial of 84 A(n) Class {always / sometimes } relationship name {one / one or more} Class 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. A Patient Service always is provided in one Encounter