Public Health and Emergency Response Committee Immunization Domain Analysis Model

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


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


Health Level Seven Version 3.0What and Why


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.


International

National

Inter-Enterprise

Enterprise

Institution

Standards Moving in Ever-Increasing Circles

Source: Gartner


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.


HL7 Message Development

Framework


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


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.


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


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?


HL7 Development Framework


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


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.


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


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


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


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


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


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



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


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



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


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



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



HDF Workflow DiagramInitiateProject

ProjectCharter

SpecifyRequirements

ReferenceModels


Prepare SpecificationDesign Models


PrepareSpecification

ApproveSpecification


PublishApproved

Specification


Prepare SpecificationProfiles

SpecificationProfile

ConformanceStatement


The HDF workflow is not a waterfall methodology.Each phase builds upon the prior and may causeprior activities to be revisited and their deliverablesadjusted.



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.


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.


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.


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


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.


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


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


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


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.


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


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



Managment




Tracking



A.2 Patient

A.4 Prov ider

A.8 Va ccine Manufa cturer


A.7 Researcher

A.5 Regulator





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.


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


Vaccine Administration Message RMIM


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


POIZ DAM v0r2 – Use case diagramuc PHER Immunization DAM Use Cases



Managment




Tracking



A.2 Patient

A.4 Prov ider

A.8 Vaccine Manufacturer


A.7 Researcher

A.5 Regulator





POIZ DAM v0r3 – Activity diagrampkg PHER Immunization DAM Activ ity Model






Managment


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



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


History


Assessment

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»


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


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


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..*


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


Vaccine Administration Message RMIM


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..*


1

0..*

(assigningAuthorityIdentifier =identifier)

0. .1

0..*


10..*


1

0. .1


1

0..*

(primaryCareFacilityIdentifier= identifier)

+PK_Facility 1

0..*

(facilityIdentifier = identifier)

1


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]


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


Figure 5. Domain diagram - work in progress


PHII TCB: Immunization Administration


10/12/07: POIZ DAM v0r6 – HTML Publication


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


Questions / Discussion / Feedback


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


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]

Public Health and Emergency Response Committee Immunization Domain Analysis Model

Documents

Transcript of Public Health and Emergency Response Committee Immunization Domain Analysis Model