public health and emergency response committee immunization domain analysis model
DESCRIPTION
Public Health and Emergency Response Committee Immunization Domain Analysis Model. Abdul-Malik Shakir Principal Consultant, Shakir Consulting HL7 Educational Summit, Los Angeles, CA November 2007. About Me. Abdul-Malik Shakir Principal Consultant, Shakir Consulting, La Verne, CA - PowerPoint PPT PresentationTRANSCRIPT
Public Health and Emergency Response CommitteePublic Health and Emergency Response CommitteeImmunization Domain Analysis Model
Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting
HL7 Educational Summit, Los Angeles, CA
November 2007
November 2007 PHER Immunization Domain Analysis Model 2 of 54
About Me
Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting, La Verne, CA
HL7 Member since 1991
• Principal Consultant with Shakir Consulting
• Chief Technical Architect with Cal2Cal Corporation
• Co-Chair of the HL7 Education Committee
• Member of the HL7 Architectural Review Board
• Member of the HL7 Public Health and Emergency Response Committee
• Member of the HL7 Regulated Clinical Research Information Management Committee
• Member of the HL7 Modeling and Methodology Committee
November 2007 PHER Immunization Domain Analysis Model 3 of 54
Session Outline
Part I
• Background
HL7 v3: What and Why
HL7 Message Development Framework
HL7 Development Framework
• Domain Analysis Models
Requirements Specification
UML Diagram Classifications
UML Diagram Types
Part II
• POIZ DAM
Project Scope
Project Progression
Development Approach
Reference Materials
Model Diagrams Walkthrough
Source Models
Next Steps
Questions and Discussion
November 2007 PHER Immunization Domain Analysis Model 4 of 54
Health Level Seven Version 3.0What and Why
November 2007 PHER Immunization Domain Analysis Model 5 of 54
World-class System Interface Standards
• The community of users served by HL7 is continually increasing in size. As the size of the community increases so does the complexity and the diversity of their needs.
• HL7 v3.0 adds rigor to the standards development process and make use of modern advances in information technologies.
• The HL7 v3.0 development methodology includes the use of a reference information model, robust datatype and vocabulary specifications, and modeling of the dynamic requirements of messages.
• HL7 v3.0 increases the quality and reduces the variability in HL7 standards enabling it to address the more complex and diverse needs of the HL7 members.
November 2007 PHER Immunization Domain Analysis Model 6 of 54
International
National
Inter-Enterprise
Enterprise
Institution
Standards Moving in Ever-Increasing Circles
Source: Gartner
November 2007 PHER Immunization Domain Analysis Model 7 of 54
HL7 Version 3.0: What and Why
• Version 3.0 is a fundamental shift in the methodology HL7 uses to develop its standards specifications.
• Version 3.0 is a model-driven methodology based upon the Object Management Group’s Unified Modeling Language (UML).
• Version 3.0 uses datatype specifications, vocabulary specifications, and a Reference Information Model (RIM), to derive the information component of V3 message specifications.
• Version 3.0 reduces optionality, maximizes reuse, and increases consistency in HL7 message specifications.
• Version 3.0 improves the quality of HL7 message specifications and includes support for conformance validation.
• Version 3.0 enables HL7 implementers to leverage emerging web services standards, conventions, and technologies.
November 2007 PHER Immunization Domain Analysis Model 8 of 54
HL7 Message Development
Framework
November 2007 PHER Immunization Domain Analysis Model 9 of 54
HL7 V3 Message Development Framework
Use Case Modeling
Interaction Modeling
Message Design
Information Modeling
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
MessageType
Example
Storyboard
StoryboardExample
D-MIM
Derive
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Content
InteractionReferences
November 2007 PHER Immunization Domain Analysis Model 10 of 54
HL7 V3 Conceptual Model
• An Application Role is the sender or receiver of one or more Interaction.
• An Interaction fulfills a information exchange requirement defined in Storyboards and exemplified in Storyboard Examples.
• An Application Role sends an Interaction in response to a Trigger Event or as part of its receiver responsibility.
• A Trigger Event is associated with a state transition of a Reference Information Model (RIM) class or with a temporal event.
• An Interaction contains one or more Message Type defined in an Hierarchal Message Description (HMD).
• An HMD is a constrained tabular view of hierarchically ordered data structures from a Refined Message Information Model (R-MIM).
• A R-MIM is a constrained refinement of a Domain Message Information Model (D-MIM).
• A D-MIM is a domain specific instantiation of a subset of classes, attributes, and relationships derived from the RIM.
November 2007 PHER Immunization Domain Analysis Model 11 of 54
HL7 V3 Message Development Framework
Use Case Modeling
Interaction Modeling
Message Design
Information Modeling
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
MessageType
Example
Storyboard
StoryboardExample
D-MIM
Derive
ApplicationRole
Sender Receiver
TriggerEvent
Triggers
Content
InteractionReferences
November 2007 PHER Immunization Domain Analysis Model 12 of 54
HL7 V3 Methodology (in English)
• What application interface problem are we trying to solve?
• What application systems are within the scope of the problem domain?
• What information needs to be communicated between the in-scope applications?
• What is the definition, format, and interrelationship of the information to be communicated?
• What events initiate communication between applications?
• How should the information to be communicated between applications be structured and packaged?
November 2007 PHER Immunization Domain Analysis Model 13 of 54
HL7 Development Framework
November 2007 PHER Immunization Domain Analysis Model 14 of 54
Seven Phases of the HDF Methodology
1. Project initiation
2. Requirements Documentation
3. Specification Modeling
4. Specification Documentation
5. Specification Approval
6. Specification Publication
7. Specification Profiling
November 2007 PHER Immunization Domain Analysis Model 15 of 54
HDF Workflow DiagramInitiateProject
ProjectCharter
SpecifyRequirements
ReferenceModels
RequirementSpecification
Prepare SpecificationDesign Models
SpecificationDesign Models
PrepareSpecification
ApproveSpecification
ApprovedSpecification
PublishApproved
Specification
PublishedSpecification
Prepare SpecificationProfiles
SpecificationProfile
ConformanceStatement
ProposedSpecification
The HDF workflow is not a waterfall methodology.Each phase builds upon the prior and may causeprior activities to be revisited and their deliverablesadjusted.
November 2007 PHER Immunization Domain Analysis Model 16 of 54
Project initiation
During project initiation the project is defined, a project plan is produced, and project approval is obtained. The primary deliverable produced during project initiation is the project charter.
ProjectInitiation
ProjectCharter
1. Define project scope, objectives, and intended deliverables
2. Identify project stakeholders, participants, and required resources
3. Document project assumptions, constraints, and risk
4. Prepare preliminary project plan and document inter-project dependencies
5. Obtain project approval and launch the project
November 2007 PHER Immunization Domain Analysis Model 17 of 54
Requirements Documentation
During requirements documentation the problem domain is defined, a model of the domain is produced, and the problem domain model is harmonized with HL7 reference models. The primary deliverable produced during requirements documentation is the requirements specification.
RequirementsDocumentation
Requirements Specification
1. Document Business Process: Dynamic Behavior and Static Structure
2. Capture Process Flow: UML Activity Diagram
3. Capture Structure: Domain Information Model and Glossary
4. Capture Business Rules: Relationships, Triggers, and Constraints
5. Harmonize the Domain Analysis Model with HL7 Reference Models
ProjectCharter
November 2007 PHER Immunization Domain Analysis Model 18 of 54
Specification Modeling
During specification modeling reference models are constrained into design models through a process of iterative refinement driven by requirements specifications and following specification design rules, conventions, and guidelines. The primary deliverable produced during specification modeling is a set of specification design models.
SpecificationModeling
SpecificationDesign Models
1. Build design models of static information views
2. Construct design models of behavioral views
3. Define reusable design model components
4. Construct design models of collaboration and interaction
5. Harmonize design models with HL7 Reference Models
RequirementsSpecification
November 2007 PHER Immunization Domain Analysis Model 19 of 54
Specification Documentation
During specification Documentation the specification design models are packaged into logical units, supplemented with explanatory text, and prepared for approval. The primary deliverable produced during specification documentation is a proposed specification.
SpecificationDocumentation
ProposedSpecification
1. Organize design model elements into logical packages
2. Compose explanatory text, examples, and design rationale
3. Update design models and requirement specifications
4. Assemble a proposed specification package
5. Submit specification for approval
SpecificationDesign Models
November 2007 PHER Immunization Domain Analysis Model 20 of 54
Specification Approval
During specification approval the pre-approval specification is subjected to a series of approvals steps. The specific approval steps vary by kind of specification, level of approval, and realm of interest. The primary deliverable produced during specification approval is an approved specification.
SpecificationApproval
ApprovedSpecification
1. Obtain TSC and Board approval to ballot specification
2. Form a ballot pool and conduct specification ballot
3. Assess negative ballots and affirmative comments
4. Modify specification in response to ballot comments
5. Resolve negative ballot responses and if necessary re-ballot
ProposedSpecification
November 2007 PHER Immunization Domain Analysis Model 21 of 54
Specification Publication
During specification publication the approved specification is prepared for prepared for publication and distribution. The primary deliverable produced during specification publication is a published specification.
SpecificationPublication
PublishedSpecification
1. Obtain TSC and Board approval to publish specification
2. Prepare specification for publication
3. Submit publication to standards authorities (ANSI/ISO)
4. Render the specification in various forms of publication media
5. Post and distribute approved specifications
ApprovedSpecification
November 2007 PHER Immunization Domain Analysis Model 22 of 54
Specification Profiling
During specification profiling specification models are further refined and specifications furthered constrained following the same set of design rules, conventions, and guidelines used in the development of the specification to produce a profile of the specification for use in a particular environment by a defined community of users. The primary deliverable produced during specification profiling is a set of specification profiles and conformance statements.
SpecificationProfiling
SpecificationProfiles and
ConformanceStatements
1. Identify community of uses for published specification
2. Further refine and constrain specification design models
3. Document exceptions, extensions, and annotations to specifications
4. Prepare and publish specification profile
5. Prepare and publish conformance statements
PublishedSpecification
November 2007 PHER Immunization Domain Analysis Model 23 of 54
HDF Workflow DiagramInitiateProject
ProjectCharter
SpecifyRequirements
ReferenceModels
RequirementSpecification
Prepare SpecificationDesign Models
SpecificationDesign Models
PrepareSpecification
ApproveSpecification
ApprovedSpecification
PublishApproved
Specification
PublishedSpecification
Prepare SpecificationProfiles
SpecificationProfile
ConformanceStatement
ProposedSpecification
The HDF workflow is not a waterfall methodology.Each phase builds upon the prior and may causeprior activities to be revisited and their deliverablesadjusted.
RequirementSpecification
RequirementSpecification
A Domain Analysis Model is a specification of requirements for a project or domain. The PHER POIZ Domain Analysis Model (DAM) is a requirement specification for PHER sponsored projects in the immunization domain.
November 2007 PHER Immunization Domain Analysis Model 24 of 54
PHER POIZ Domain Analysis Model
• The PHER POIZ Domain Analysis Model is a UML model representing the structural and behavioral requirements of PHER sponsored projects in the immunization domain.
• The PHER POIZ DAM is a collection of UML diagrams and supporting text illustrating the information and processing requirements of the immunization domain from a variety of perspectives.
• The PHER POIZ DAM will continually evolve as requirements are discovered and analyzed and as solutions are constructed and evaluated.
• The development process for the PHER POIZ DAM is an iterative activity that combines a top-down analytical approach with bottom-up reverse engineering techniques.
• Contribution of content, critique, and complements are welcome and encouraged. Those with an interest in this project are requested to subscribe to the PHER list server, participate in PHER conference calls, and attend PHER working group meetings.
November 2007 PHER Immunization Domain Analysis Model 25 of 54
UML Diagram Classifications
• There are three classifications of UML diagrams:
Behavior diagrams. A type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams.
Interaction diagrams. A subset of behavior diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams.
Structure diagrams. A type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, composite structure, component, deployment, object, and package diagrams.
November 2007 PHER Immunization Domain Analysis Model 26 of 54
UML Diagram TypesDiagram Description Classification
Activity Diagram Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system.
Behavior
Class Diagram Shows a collection of static model elements such as classes and types, their contents, and their relationships.
Structure
Communication Diagram Shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages.
Interaction
Component Diagram Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted.
Structure
Composite Structure Diagram Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system.
Structure
Deployment Diagram Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them.
Structure
Interaction Overview Diagram A variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram.
Interaction
Object Diagram Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram.
Structure
Package Diagram Shows how model elements are organized into packages as well as the dependencies between packages.
Structure
Sequence Diagram Models the sequential logic, in effect the time ordering of messages between classifiers. Interaction
State Machine Diagram Describes the states an object or interaction may be in, as well as the transitions between states.
Behavior
Timing Diagram Depicts the change in state or condition of a classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events.
Interaction
Use Case Diagram Shows use cases, actors, and their interrelationships. Behavior
POIZ DAM
November 2007 PHER Immunization Domain Analysis Model 27 of 54
Project Scope Statement
• Project Name:
Immunization Domain Analysis Model
• Sponsoring Committee:
PHER SIG
• Project Scope:
The scope of this project is to develop a Domain Analysis Model for Immunization related projects sponsored by the Public Health and Emergency Response Special Interest Group.
• Project Dependencies:
All PHER sponsored immunization related projects.Project Objectives:
• Project Objectives:
The objective of this project create a Domain Analysis model describing the Use Cases, Stakeholders, Activities, Interactions, and Static Information Models needed to express the requirements of PHER sponsored immunization projects. This includes support for V2 and V3 messages, structured documents, EHR and PHR profiles, Service Specifications, Implementation Guides, Templates and Terminologies needed for Immunization.
November 2007 PHER Immunization Domain Analysis Model 28 of 54
Project Progression
• 05/01/07: Project Approved – Scope Statement
• 06/01/07: Project Initiated – Data Gathering
• 07/20/07: POIZ DAM v0r1 – Vaccine Admin Message
• 08/03/07: POIZ DAM v0r2 – Use case diagram
• 08/17/07: POIZ DAM v0r3 – Activity diagram
• 08/31/07: POIZ DAM v0r4 – Class Diagram (DIM)
• 09/18/07: POIZ DAM v0r5 – Source Data Models
• 10/12/07: POIZ DAM v0r6 – HTML Publication
November 2007 PHER Immunization Domain Analysis Model 29 of 54
PHER POIZ DAM Development Process
• The starting point of development is research; source material is reviewed and analyzed.
• The next step is to model; create a UML model of the insights gain during research.
• Modeling is followed by review; the models are reviewed by SMEs and interested parties.
• The review step is followed by revise; the model is update to reflect the input from peer review.
• Additional research is conducted to create the next iteration of the model and the cycle continues.
Model
Review
Research
Revise
uc PHER Immunization DAM Use Cases
1.0 Vacc ine Dev elopment
5.0 Va ccine Inv e ntory
Managment
4.0 Va ccine Administration
2.0 Vaccine Protocol Mainte nance
6.0 Va ccine Administration
Tracking
3.0 Pa tient Administration
7.0 Vaccine Adv erse Ev ent Ma nagement
A.2 Patient
A.4 Prov ider
A.8 Va ccine Manufa cturer
A.1 Immunization Registry
A.7 Researcher
A.5 Regulator
A.6 Research Subject
A.3 Patient Registry
8.0 Vaccine Planning
November 2007 PHER Immunization Domain Analysis Model 30 of 54
Research
• Subject matter experts are asked to provide source materials for use in informing the DAM.
• Source materials include existing models, data dictionaries, works in progress, email threads, and other references.
• The source material is analyzed to discover behavioral or structural requirements.
• One-on-one dialog between the DAM analyst and the submitter of source material help to improve understanding and implications for the DAM.
November 2007 PHER Immunization Domain Analysis Model 31 of 54
Model
• Insights gained from research are used to adjust or confirm the DAM.
• Functional scope is reflected in a Use Case diagram.
• Activity control and information flows are reflected in Activity diagrams.
• Information requirements are reflected in Class diagrams.
• Questions and open issues related to modeling are noted for use in model review.
class V3 POIZ Message
A_Immunization
«choice»
R_InformationSource
A_Assessment
A_HealthDocument
P_ImmunizationSubject
«CMET»
R_AssignedPerson
P_ImmunizationInformant
«CMET»
R_Subject
P_ImmunizationResponsibleParty
P_ImmunizationPerformer
P_Immuniza tionAuthor
P_Cons umable
«CMET»
R_AdministeredMedication
A_Prescription
P_Prescrip tionAuthor
A_ImmunizationPlan
A_Annotation
P_AnnotationAuthor
A_Inv estigationEv ent
A_IntoleranceCondition
A_Consent
P_ImmunizationLocation
«CMET»
R_Serv iceDeli v eryLocation
«choice»
A_ImmunizationReason
1
hasRe ason
0..*
0. .1
isReferencedBy
0..*
1
involves 1
1
involves
0. .1
1
involves
0. .1
1
involves
1
1
involves
0. .1
1
isFulfi l lmentOf
0. .1
1
isFulfi l lmentOf
0. .1
1
isSubjectOf
0..*
1
isCauseOf
0. .1
1
isCauseOf
0..*
1
involves
0. .1
1 involves 0. .1
1
isParticipationOf
1
1isComponentOf
0..*
0..*
isParticipationOf1
0..*
isParticipationOf 1
0..*
isParticipationOf
1
0..*
isParticipationOf
1
0..*
isParticipationOf
1
0. .1
isParticipationOf1
1
involves0. .1
0..*
isParticipationOf
1
1
involves
1
0..*
isParticipationOf
1
1
isAuthorizedBy
0. .1
November 2007 PHER Immunization Domain Analysis Model 32 of 54
Review
• The model is posted to the PHER email list server.
• A peer review of the model is scheduled as an agenda item for PHER conference calls.
• Subject matter experts and interested parties attending the PHER call provide confirmation, criticism, and insights related to the model.
• The peer review dialog is documented as email threads and conference call minutes.
uc PHER Immunization DAM Use Cases
1.0 Vacc ine Dev elopment
5.0 Va ccine Inv e ntory
Managment
4.0 Va ccine Administration
2.0 Vaccine Protocol Mainte nance
6.0 Va ccine Administration
Tracking
3.0 Pa tient Administration
7.0 Vaccine Adv erse Ev ent Ma nagement
A.2 Patient
A.4 Prov ider
A.8 Va ccine Manufa cturer
A.1 Immunization Registry
A.7 Researcher
A.5 Regulator
A.6 Research Subject
A.3 Patient Registry
8.0 Vaccine Planning
November 2007 PHER Immunization Domain Analysis Model 33 of 54
Revise
• The peer review comments create an improved understanding of requirements.
• Comments also reveal difficulty in understanding the model.
• The model is revised to reflect the improved understanding or to make the model content more comprehensible.
• The revised model is then used during analysis of additional input.
November 2007 PHER Immunization Domain Analysis Model 34 of 54
Reference Materials (as of Oct 07)
• POIZ Vaccine Administration RMIM
• SNHD Immunization System Data Export
• CA SIIS SIP Immunization Message Profile
• DSS Conformance Profile for Vaccine Forecasting
• Implementation Guide for Immunization Data Transactions Using HL7 V.2.3.1
• IHE transactions for Patient Identity Feed, utilizing HL7 2.3.1 messages
• IHE Patient Identifier Cross-Referencing (PIX) transaction, utilizing HL7 2.5 messages.
• Patient Demographics Query (PDQ) transaction, utilizing HL7 2.5 messages.
• HSSP Retrieve, Locate, Update Service (RLUS)
• HSSP Entity Identification Service (EIS)
• AIRA Messaging Workgroup IIS Standards Working Document
• Preparatory meeting materials for AIRA Modeling Immunization Registry Operations Workgroup (MIROW)
• Recommended Immunization Schedule for Persons Aged 0–6 Years—UNITED STATES • 2007
• Vaccine Adverse Event Reporting System (VARS)
• PeDS SIG Immunization Registry Storyboard
• Dynamical model for the Dutch national youth immunization program
• PHII – Taking Care of Business
• HL7 v3 pan-Canadian Messaging Standards Implementation Guide Volume 10 –Immunization
• U.S. DHHS Immunizations & Response Management Prototype Use Case
• HL7 v3 Immunization Project Business Scenario Survey
• AIRA Vaccination Level Deduplication in Immunization Information Systems
November 2007 PHER Immunization Domain Analysis Model 35 of 54
Vaccine Administration Message RMIM
November 2007 PHER Immunization Domain Analysis Model 36 of 54
POIZ DAM v0r1 – Vaccine Admin Messageclass V3 POIZ Message
A_Immunization
«choice»R_InformationSource
A_Assessment
A_HealthDocument
P_ImmunizationSubject
«CMET»R_AssignedPerson
P_ImmunizationInformant
«CMET»R_Subject
P_ImmunizationResponsibleParty P_ImmunizationPerformerP_Immuniza tionAuthor
P_Cons umable «CMET»R_AdministeredMedication
A_Prescription
P_PrescriptionAuthor
A_ImmunizationPlan
A_Annotation
P_AnnotationAuthor
A_InvestigationEv ent
A_IntoleranceCondition
A_Consent
P_ImmunizationLocation
«CMET»R_Serv iceDeliv eryLocation
«choice»A_ImmunizationReason 1
hasRe ason
0..*
0. .1
isReferencedBy
0..*
1 involves
1
1
involves
0. .1
1
involves
0. .1
1
involves
1
1
involves
0. .1
1
isFulfi l lmentOf
0. .1
1
isFulfi l lmentOf
0. .1
1
isSubjectOf
0..*
1
isCauseOf
0. .1
1
isCauseOf0..*
1
involves
0. .1
1
involves
0. .1
1
isParticipationOf
1
1
isComponentOf
0..*
0..*
isParticipationOf
1
0..*
isParticipationOf
1
0..*
isParticipationOf
1
0..*
isParticipationOf
1
0..*
isParticipationOf
1
0. .1
isParticipationOf
1
1involves
0. .1
0..*
isParticipationOf
1
1
involves
1
0..*
isParticipationOf
1
1
isAuthorizedBy 0. .1
November 2007 PHER Immunization Domain Analysis Model 37 of 54
POIZ DAM v0r2 – Use case diagramuc PHER Immunization DAM Use Cases
1.0 Vacc ine Dev elopment
5.0 Va ccine Inv e ntory
Managment
4.0 Va ccine Administration
2.0 Vaccine Protocol Mainte nance
6.0 Va ccine Administration
Tracking
3.0 Pa tient Administration
7.0 Vaccine Adv erse Ev ent Ma nagement
A.2 Patient
A.4 Prov ider
A.8 Vaccine Manufacturer
A.1 Immunization Registry
A.7 Researcher
A.5 Regulator
A.6 Research Subject
A.3 Patient Registry
8.0 Vaccine Planning
November 2007 PHER Immunization Domain Analysis Model 38 of 54
POIZ DAM v0r3 – Activity diagrampkg PHER Immunization DAM Activ ity Model
1.0 Vacc ine Dev elopment
2.0 Vaccine Protocol Mainte nance
3.0 Pa tient Administration
4.0 Va ccine Administration
5.0 Va ccine Inv e ntory
Managment
6.0 Va ccine Administration
Tracking
F1.0 Vaccine Research
+ F1.1 Develop Vaccine
+ F1.2 Test Vaccine
+ F1.3 Approve Vaccine
F2.0 Vaccine Protocol Maintenance
+ F2.1 Maintain Vaccine Protocol
+ F2.2 Communicate Vaccine Protocol
+ F2.3 Evaluate Vaccine Protocol
F4.0 Vaccine Administration
+ F4.1 Communicate Vaccine Safety and Risk
+ F4.2 Obtain Required Consents
+ F4.3 Prepare Vaccine for Administration
+ F4.4 Administer Vaccine
+ F4.5 Document Vaccine Administration
+ Generat patient copy of history
+ Printed Record
F6.0 Vaccine Administration Tracking
+ F6.1 Report Vaccine Admininstration History
+ F6.2 Store Vaccine Administration History
+ F6.3 Retrieve Vaccine Administration History
+ F6.4 Assess Vaccine Administration History
F7.0 Vaccine Adv ers e Ev ent Management
+ F7.1 Report Vaccine Adverse Event
+ F7.2 Investigate Vaccine Adverse Event
F5.0 Vaccine Inv e ntory Management
+ F1.1 Manage Vaccine Funds
+ F5.2 Manufacture Vaccine
+ F5.3 Order Vaccine
+ F5.4 Distribute Vaccine
+ F5.5 Store Vaccine
F3.0 Patient Administration
+ F3.1 Maintain Patient Demographics
+ F3.2 Resolve Patient Identity
+ F3.3 Retrieve Patient Demographics
F8.0 Vaccine Planning
+ F8.1 Validate Vaccine History
+ F8.2 Forcast Vaccine Needs
+ F8.3 Prepare Vaccine Plan
8.0 Vaccine Planning
November 2007 PHER Immunization Domain Analysis Model 39 of 54
Vaccine Administration Tracking Activity Diagramact F6.0 Vaccine Administration Tracking
Reporter Immunization Registry Rev iewer
F6.1 Report VaccineAdmininstration History
F6.2 Store VaccineAdministration History
F6.3 Retriev e VaccineAdministration History
F6.4 Assess VaccineAdministration History
Vacc ine Administration
Rec ord
Vacc ine Administration
History
Vacc ine Administration
Assessment
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
November 2007 PHER Immunization Domain Analysis Model 40 of 54
POIZ DAM v0r4 – Class Diagram (DIM)class PHER Immunization DIM - Classes
PatientPostalAddress
ImmunizationEncounter ImmunizationEv ent
Immunogen ImmunizationProduct VaccineGroupVaccineKind
ImmunogenKind
ProductManufacturer
Prov iderOrganization Prov ider
VaccineScheduleDose
ScheduleVaccineDoseSeriesVaccineSchedule
AdministeredVaccine
AdministeredVaccineIngredient
ProductProductIngredient
Antibody
Antigen
VaccineAdministrationProtocol
VaccineInformationStatement
VaccineForcastDose
VaccineForcastDoseSeries
VaccineForcast
0..*
involves1
0..*
pertai ns to
1
0..*is part of
1 0. .1
0..*
contains
0..*
is an instance of
1
0..*
is base d upon
0..*
0..*
is a member of
0..*
0..*
includes
1. .*
10..*
1
involves
0..*
1
involves
0..*
pertai ns to
0..*
is part of
0..*
is part ofcontains
1. .*
1. .*
pertai ns to
involves
is part of
0..*
is affi l i ated with
1
November 2007 PHER Immunization Domain Analysis Model 41 of 54
POIZ DAM v0r4 – Class Package Diagram
class PHER Immunization DIM - Packages
Patients
+ Patient
+ PostalAddress
Immunization Ev ents
+ ImmunizationEncounter
+ ImmunizationEvent
Prov iders
+ Provider
+ ProviderOrganization
Vaccine Products
+ Antibody
+ Antigen
+ ImmunizationProduct
+ Immunogen
+ Product
+ ProductIngredient
+ ProductManufacturer
+ VaccineInformationStatement
Vaccine
+ ImmunogenKind
+ VaccineGroup
+ VaccineKind
Vaccine Schedule
+ ScheduleVaccineDoseSeries
+ VaccineAdministrationProtocol
+ VaccineSchedule
+ VaccineScheduleDose
Administered Vaccine
+ AdministeredVaccine
+ AdministeredVaccineIngredient
November 2007 PHER Immunization Domain Analysis Model 42 of 54
POIZ DAM v0r4 – Vaccine Product Packageclass Vaccine Products
Product ProductManufacturer
ImmunizationProduct
ProductIngredient
Immunogen Vaccine::VaccineKind
Administered Vaccine::AdministeredVaccineIngredient
0..*
contains
1. .*
0..*
is an instance of
1
10..*
November 2007 PHER Immunization Domain Analysis Model 43 of 54
09/18/07: POIZ DAM v0r5 – Source Models
• POIZ Vaccine Administration RMIM
• SNHD Immunization System Data Export
• CA SIIS SIP Immunization Message Profile
• Preparatory meeting materials for AIRA Modeling Immunization Registry Operations Workgroup (MIROW)
• PHII – Taking Care of Business
November 2007 PHER Immunization Domain Analysis Model 44 of 54
Vaccine Administration Message RMIM
November 2007 PHER Immunization Domain Analysis Model 45 of 54
SNHD Immunization System Data Exportclass SNHD IZ Staging Area
Facility
*PK identifier: int*FK providerOrganizationIdentifier: int name: varchar(50) addressTypeCode: varchar(50) addressLine1Text: varchar(50) addressLine2Text: varchar(50) cityName: varchar(50) statePostalCode: varchar(50) postalZoneIdentifier: varchar(50) countryCode: varchar(50)
«FK»+ FK_Facility_ProviderOrganization(providerOrganizationIdentifier)
«PK»+ PK_Facility(identifier)
Patient
*PK identifier: int*FK personIdentifier: int FK primaryCareFacilityIdentifier: int birthDate: datetime birthStateCode: varchar(50) multipleBirthIndicator: bit deathIndicator: bit sexCode: varchar(50) raceCode: varchar(50) ethnicityCode: varchar(50) primaryLanguageCode: varchar(50)
«FK»+ FK_Patient_Facility(primaryCareFacilityIdentifier)+ FK_Patient_Person(personIdentifier)
«PK»+ PK_Patient(identifier)
PersonPostalAddress
*PK identifier: int*FK personIdentifier: int* addressTypeCode: varchar(50) addressLine1Text: varchar(50) addressLine2Text: varchar(50)* cityName: varchar(50)* stateCode: varchar(50) postalZoneIdentifier: varchar(50) countyCode: varchar(50)
«FK»+ FK_PersonPostalAddress_Person(personIdentifier)
«PK»+ PK_PersonPostalAddress(identifier)
PersonTelecommunicationAddress
*PK identifier: int*FK personIdentifier: int* telecomAddressTypeCode: varchar(50) telecomAddressUseCode: varchar(50)* telecomAddressValue: varchar(50) areaCode: varchar(50) phoneNumber: varchar(50) extensionNumber: varchar(50)
«FK»+ FK_PersonTelecommunicationAddress_Person(personIdentifier)
«PK»+ PK_PersonTelecommunicationAddress(identifier)
Person
*PK identifier: int* personRoleTypeCode: varchar(50)* lastName: varchar(50)* givenName: varchar(50) middleName: varchar(50) nameSuffix: varchar(50)
«PK»+ PK_Person(identifier)
PersonIdentifier
*PK identifier: int*FK personIdentifier: int FK assigningAuthorityIdentifier: int identifierTypeCode: varchar(50)* identifierValue: varchar(50)
«FK»+ FK_PersonIdentifier_Organization(assigningAuthorityIdentifier)+ FK_PersonIdentifier_Person(personIdentifier)
«PK»+ PK_PersonIdentifier(identifier)
PersonAlte rnateName
*PK identifier: int*FK personIdentifier: int* nameTypeCode: varchar(50)* lastName: varchar(50)* givenName: varchar(50) middleName: varchar(50) nameSuffix: varchar(50)
«FK»+ FK_PersonAlternateName_Person(personIdentifier)
«PK»+ PK_PersonAlternateName(identifier)
PatientRel ationship
*PK identifier: int*FK patientIdentifier: int*FK personIdentifier: int* relationshipTypeCode: varchar(50)
«FK»+ FK_PatientRelationship_Patient(patientIdentifier)+ FK_PatientRelationship_Person(personIdentifier)
«PK»+ PK_PatientRelationship(identifier)
Organi zation
*PK identifier: int* name: varchar(50)
«PK»+ PK_Organization(identifier)
FacilityIdentifier
*PK identifier: int*FK facilityIdentifier: int FK assigningAuthorityIdentifier: int identifierTypeCode: varchar(50)* identifierValue: varchar(50)
«FK»+ FK_FacilityAlternateIdentifier_Facility(facilityIdentifier)+ FK_FacilityAlternateIdentifier_Organization(assigningAuthorityIdentifier)
«PK»+ PK_FacilityAlternateIdentifier(identifier)
Treatmen tRefusal
* refusalReasonCode: varchar(50)*FK vaccineAdministrationIdentifier: int*PK identifier: int
«FK»+ FK_TreatmentRefusal_VaccineAdministration(vaccineAdministrationIdentifier)
«PK»+ PK_TreatmentRefusal(identifier)
VaccineAdministration
*PK identifier: int*FK patientIdentifier: int FK facilityIdentifier: int FK administeringProviderIdentifier: int doseSequenceNumber: int* administeredSubstanceCode: varchar(50)* administrationDateTime: datetime administeredSubstanceQuantity: float unitOfMeasureCode: varchar(50) administrationRouteCode: varchar(50) administrationSiteCode: varchar(50) substanceLotNumber: varchar(50) substanceManufacturerCode: varchar(50)
«FK»+ FK_VaccineAdministration_Facility(facilityIdentifier)+ FK_VaccineAdministration_Patient(patientIdentifier)+ FK_VaccineAdministration_Person(administeringProviderIdentifier)
«PK»+ PK_VaccineAdministration(identifier)
OrganizationIdentifier
*PK identifier: int*FK organizationIdentifier: int FK assigningAuthorityIdentifier: int identifierTypeCode: varchar(50)* identifierValue: varchar(50)
«FK»+ FK_OrganizationIdentifier_AssigningAuthorityOrganization(assigningAuthorityIdentifier)+ FK_OrganizationIdentifier_Organization(organizationIdentifier)
«PK»+ PK_OrganizationIdentifier(identifier)
0..*
(personIdentifier =identifier)
1
0..*
(assigningAuthorityIdentifier =identifier)
+assigningAuthority
1
0..*
(patientIdentifier =identifier)
1
0..*
(administeringProviderIdentifier = identifier)
1
0..*
(facilityIdentifier = identifier)
1
0..*
(vaccineAdministrationIdentifier = identifier)
1
0..*
(assigningAuthorityIdentifier = identifier)
0. .1
0..*
(organizationIdentifier =identifier)
+identifiedOrganization
1
0..*
(patientIdentifier =identifier)
1
0..*
(providerOrganizationIdentifier =identifier)
1
0..*
(personIdentifier = identifier)
1
0..*
(personIdentifier = identifier)
1
0..*
(assigningAuthorityIdentifier =identifier)
0. .1
0..*
(personIdentifier = identifier)
10..*
(personIdentifier = identifier)
1
0. .1
(personIdentifier = identifier)
1
0..*
(primaryCareFacilityIdentifier= identifier)
+PK_Facility 1
0..*
(facilityIdentifier = identifier)
1
November 2007 PHER Immunization Domain Analysis Model 46 of 54
CA SIIS SIP Immunization Message Profilead InteractionActiv ityModel
Requesting Registry System SIIS SIP Immunization Information Exchange System Responding Registry System
1.1 Request ImmunizationData
«message»
M.01 Immunization Data Request (VXQ)
2.2 Validate ImmunizationData Request Message
«message»
M.02 Request Error Message (ACK)
2.3 Route ImmunizationData Request Message2.4 Notify System
Administrator
«message»
M.03 Immunization Data Request (VXQ)
3.1 Retriv e RequestedImmunization Data
«datastore»
D.04 Immunization Registry
3.2 RetrivalResult?
3.2.1 Return "No MatchingRecord" Response
3.2.2 Return "MultipleMatching Records"
Response
3.2.3 Return RequestedImmunization Data
«message»
M.04 No Matching Record Response (QCK)
«message»
M.05 Multiple Matching Records Response (VXX)
«message»
M.06 Requested Immunization Data (VXR)
4.2 Validate ResponseMessage
«message»
M.07 Response Message Error (ACK)
4.3 Route ResponseMessage
4.4 Notify SystemAdministrator
«message»
M.08 No Matching Record Message (QCK)
«message»
M.09 Multiple Matching Record Message (VXX)
«message»
M.10 Requested Immunization Data Message (VXR)
5.1 Refine DemographicData
5.2 Select Desired Record
5.3 Merge ImmunizationData with existing data
«datastore»
D.01 Immunization Registry
[Valid Message][Invalid Message]
[Valid Message]
[No Matching Record]
[Desired Record Not Present]
[Multiple Matching Records]
[Single Matching Record]
[Desired Record Selected]
[Invalid Message]
November 2007 PHER Immunization Domain Analysis Model 47 of 54
MIROW
Data Quality Assurance in Immunization Information Systems
Preparatory materials for the August 21-23, 2007 meeting of the Modeling Immunization Registry Operations Workgroup (MIROW)
of the American Immunization Registry Association (AIRA)
July 21, 2007
November 2007 PHER Immunization Domain Analysis Model 48 of 54
Figure 5. Domain diagram - work in progress
November 2007 PHER Immunization Domain Analysis Model 49 of 54
PHII TCB: Immunization Administration
November 2007 PHER Immunization Domain Analysis Model 50 of 54
10/12/07: POIZ DAM v0r6 – HTML Publication
November 2007 PHER Immunization Domain Analysis Model 51 of 54
Next Steps
• Continue collection and analysis of reference materials
• Prepare descriptive text for model elements, diagrams, and glossary of terms
• Continue modeling and peer review conference calls and meetings
• Identify relationship to the work products of other HL7 committees and form collaborations as needed
• Consider inclusion of the DAM as a background or informative document in the HL7 v3 ballot
November 2007 PHER Immunization Domain Analysis Model 52 of 54
Questions / Discussion / Feedback
November 2007 PHER Immunization Domain Analysis Model 53 of 54
Health Level Seven: When and Where
January 13 - 18, 2008Working Group Meeting
Hyatt Regency on the RiverwalkSan Antonio, TX, USA
May 04 - 09, 2008Working Group Meeting
Pointe Hilton at Squaw Peak
Phoenix, AZ, USA
September 14 - 19, 2008Plenary and Working Group Meeting
Sheraton Wall Centre HotelVancouver, BC, Canada
November 2007 PHER Immunization Domain Analysis Model 54 of 54
Thank You
Abdul-Malik ShakirPrincipal Consultant
Shakir Consulting1911 Foothill Blvd., Suite 148
La Verne, CA 91750
Office: (909) 596-6790 Mobile: (626) 644-4491Email: [email protected]