Version 1.0 ● Draft
Date/Time Generated: / 11/1/2015 9:55:34 PM
Author: / AbdulMalik Shakir
EA Repository : C:\Users\AbdulMalik\Documents\Clients\Active\Health Level Seven\PHER\Initial Public Health Case Report Domain Analysis Model.EAP
CREATED WITH /
Table of Contents
Initial Public Health Case Reporting Domain Analysis Model
Introduction
Purpose
Background
Initial Public Health Case Reporting Dynamic Model
Use Cases
UC01: Patient Encounter
UC02: Laboratory Activity
UC03: Medication Activity
UC04: Reportable Condition Evaluation
UC05: Initial Public Health Case Reporting
UC06: Initial Public Health Case Reporting with Intermediary
UC07: Initial Public Health Case Report Follow-up
UC08: Maintain eICR Reporting Triggers
Use Case Actors
Association of Public Health Labs (APHL)
Care Delivery Organization
Electronic Medical Record System
Laboratory Information Management System
Patient
Pharmacy Information System
Public Health Agency
Public Health Case Reporting Interrmediary
Reportable Condition Evaluator
Reportable Conditions Knowledge Management System
Responsible Provider
Use Case Activity Flows
AF01: Patient Encounter
AF04: Reportable Condition Evaluation
AF05: Initial Public Health Case Reporting
AF07: Initial Public Health Care Report Follow-up
Interactions
Initial Public Health Case Reporting Static Model
Static Model Classes
01: Suspected Case Report
InitialPublicCaseReport
ReportSubmission
02: Patient Encounter
AdministeredMedication
EncounterDiagnosis
LaboratoryOrder
PatientEncounter
03: Care Delivery Facility
CareDeliveryFacility
CareDeliveryOrganization
ElectronicMedicalRecordSystem
04: Provider
Provider
ProviderFacility
05: Patient
Patient
PatientGuardian
06: Reportable Condition
ReportableCondition
ReportableConditionSymptom
Static Model Objects
Encounter Data
Encounter Data[Updated]
Initial Public Health Case Follow-up
Laboratory Order
Laboratory Result
Matched Reportable Condition Trigger
Public Health Case Report
eICR Reportable ConditionTtrigger Codes
Model Specification / Page: 1Initial Public Health Case Reporting Domain Analysis Model
Introduction
Purpose
The purpose of this Domain Analysis Model (DAM) is to specify the information and behavioral requirements for submission of an electronic Initial Public Health Case Report (eICR) from health care providing entities to local, state, and territorial Public Health Agencies (PHAs).
Background
The content of this DAM is derived from an analysis of works conducted by the United States' Office of the National Coordinator for Health Information Technology (ONC) Standards and Interoperability (S&I) Framework's "Public Health Case Reporting Initiative (PHRI)" and the "Minimum EHR Data for an Electronic Initial Case Report" published by the Council of State and Territorial Epidemiologists (CSTE).
The eICR DAM is a Platform Independent Model (PIM) intended to support the design of Platform Specific Models and the eventual design and development of Platform Specific Implementations.
The DAM is specified in two major components a Dynamic Model and a Static Model. The dynamic model details the Use Cases, Actors, Activities Flows, and Interactions relevant to submission of an eICR. The static model details the information requirements of the eICR in the form of class and object diagrams with supporting class and attribute definitions.
Initial Public Health Case Reporting Dynamic Model
The Dynamic Model portion of the eICR DAM describes the behavioral context for the eICR. It includes a description of:
Use Cases
Use Case Actors
Activities and Activity flows
Interactions
Use Cases
The Use Case specification provides the conceptual context for the behaviors within scope of the eICR DAM. Although the scope of the eICR DAM is limited to Initial Public Health Case Reporting, the Use Case specification includes out of scope predecessor and successor Uses Cases in an attempt to provide the broader context for the eICR.
Use Cases - (Use Case diagram)
Figure: 3
UC01: Patient Encounter
The Patient Encounter use case encompasses activities related to the provision of healthcare services to a Patient by a Responsible Provider under the auspices of a Care Delivery Organization. The Patient Encounter use case contains optional Medication Activity and Laboratory Activity as use case extensions. All data collected during the provision of care services are record in an Electronic Medical Record System.
UC02: Laboratory Activity
The Laboratory Activity use case encompasses the activities related to the placement and fulfillment of laboratory orders as documented in a Laboratory Information System.
Laboratory Activity is an optional extension to the Patient Encounter use case.
UC03: Medication Activity
The Medication Activity use case encompasses the activities related to the placement and fulfillment of medication orders as documented in a Pharmacy Information System.
Medication activity is an optional extension to the Patient Encounter use case.
UC04: Reportable Condition Evaluation
The Reportable Condition Evaluation use case encompasses the activities related to evaluation of encounter data for the purpose of detecting the presence or absence of medical conditions (diagnoses, test results, test orders, and symptoms) that trigger the submission of an initial public health case report.
The detection of reportable medical conditions can be a manual process performed by a Responsible Provider or an automated function performed by an Electronic Medical Record System.
UC05: Initial Public Health Case Reporting
The Initial Public Health Case Reporting use case encompasses the activities related to submission of an eICR by an Electronic Medical Record System to a Public Health Agency. The submission of an eICR may or may not include the participation of a Public Health Case Reporting Intermediary.
UC06: Initial Public Health Case Reporting with Intermediary
The Initial Public Health Case Reporting use case encompasses the activities related to submission of an eICR by an Electronic Medical Record System to a Public Health Agency including the participation of a Public Health Case Reporting Intermediary. The value added by the Public Health Care Reporting Intermediary will vary from implementation to implementation.
The types of activities performed by the Public Health Care Reporting Intermediary include but are not limited to:
eICR Routing
Transformation of data structures used for the eICR
Translation of coded semantics used in the eICR
Normalization or enhancement of patient demographic data
UC07: Initial Public Health Case Report Follow-up
The Initial Public Health Case Report Follow-up use case encompasses the set of activities conducted by the Public Health Agency as a consequence of having received an eICR. These activities include contacting the Responsible Provider and/or Care Delivery Organization to perform one or more of the following:
acknowledge receipt of the eICR,
confirm reportability of the case,
request additional data,
initiate investigation, contact tracing, or countermeasures.
UC08: Maintain eICRReporting Triggers
The Maintain eICR Reporting Triggers use case encompasses the set of activities necessary for the development and ongoing maintenance of a list of reportable condition trigger codes used to match against. clinical diagnoses and lab orders and results to identify possible reportable conditions.
An initial list has been developed by the Association of Public Health Labs (APHL) working with the Association of State and Territorial Health Officers (ASTHO) and the Council of State and Territorial Epidemiologists (CSTE).
The list of reportable condition trigger codes is maintained using the Reportable Conditions Knowledge Management System (RCKMS).
Use Case Actors
Use Case Actors - (Use Case diagram)
Figure: 4
Association of Public Health Labs (APHL)
Care Delivery Organization
Care delivery organization (CDO) is a legal entity whose primary mission is the delivery of healthcare-related products and services. A CDO owns and operates one or more Care Delivery Facility. The CDO is the custodian of patient care documents maintained in one or more Electronic Medical Record System.
Electronic Medical Record System
AElectronic Medical Record System (EMR) is an electronic record of health-related information on an individual that can be created, gathered, managed, and consulted by authorized clinicians and staff within one Care Delivery Organization. The EMR is the authoring device of the eICR.
Laboratory Information Management System
A Laboratory Information Management System (LIMS), sometimes referred to as a Laboratory Information System (LIS) or Laboratory Management System (LMS), is a software-based laboratory and information management system with features that support a modern laboratory's operations. A LIMS maintain information concerning the status laboratory orders placed by clinicians.
Patient
A Patient is a person receiving or registered to receive medical treatment.
Pharmacy Information System
A Pharmacy Information System (PIS) is a complex computer system designed to meet the needs of a pharmacy department. The PIS maintains information concerning the status of medication orders placed by clinicians.
Public Health Agency
A Public Health Agency (PHA) is a government entity responsible for some aspect of Public Health concerning persons in a particular geopolitical jurisdiction. Public health refers to "the science and art of preventing disease, prolonging life and promoting health through organized efforts and informed choices of society, organizations, public and private, communities and individuals. The PHA is the recipient of aeICR and is accountable for its follow-up.
Public Health Case Reporting Interrmediary
A Public Health Case Reporting Intermediary is an organization that serves as a conduit between an EMR and PHA for the purpose of information exchange.
Reportable Condition Evaluator
A Reportable Condition Evaluator is a person or device with the capability to inspect a patient's electronic health record to determine the presences of medical conditions of interest to public health.
Reportable Conditions Knowledge Management System
Responsible Provider
A Responsible Provider is the member of the clinical team involved in the delivery of health services to a Patient that is ultimately accountable for the actions of the team.
Use Case Activity Flows
Activities by Actor - (Activity diagram)
Figure: 5
Activities by Use Case - (Package diagram)
Figure: 6
AF01: Patient Encounter
The Patient Encounter activity flow is a realization of the Patient Encounter use case. The flow of activities include the provision of patient care by a responsible provider followed by an update of the patient's electronic medical record maintained by the electronic medical record system.
Patient Encounter - (Activity diagram)
Figure: 7
AF04: Reportable Condition Evaluation
The Reportable Condition Evaluation activity flow is a realization of the Reportable Condition Evaluation use case. The flow of activities begins with a review of encounter data by a Reportable Condition Evaluator and subsequent attempt to match diagnostic and laboratory data to eICR reportable condition triggers. When a match is found the patient's medical record is updated to indicate that a match was found.
Reportable Condition Evaluation - (Activity diagram)
Figure: 8
AF05: Initial Public Health Case Reporting
The Initial Public Health Case Reporting activity flow is a realization of the Initial Public Health Case Reporting use case. The flow of activities begins with receipt of a reportable condition observation by an Electronic Medial Record System triggering it to generate the Initial Public Health Case report (eICR) and submit it to a Public Health Agency. The flow of activities ends with the receipt of the eICR by the Public Health Agency.
The submission of an eICR may include the participation of a Public Health Case Reporting Intermediary. The value added by the Public Health Care Reporting Intermediary will vary from implementation to implementation.
The types of activities performed by the Public Health Care Reporting Intermediary include but are not limited to:
eICR Routing
Transformation of data structures used for the eICR
Translation of coded semantics used in the eICR
Normalization or enhancement of patient demographic data
Initial Public Health Case Reporting - (Activity diagram)
Figure: 9
AF07: Initial Public Health Care Report Follow-up
The Initial Public Health Care Report Follow-up activity flow is a realization of the Initial Public Health Care Report Follow-up use case. The flow of activities begins with the Public Health Agency initiating follow-up activity. These activities include contacting the Responsible Provider and/or Care Delivery Organization to perform one or more of the following:
acknowledge receipt of the eICR,
confirm reportability of the case,
request additional data,
initiate investigation, contact tracing, or countermeasures.
The activity flow ends with the participation of Responsible Provider in follow-up activities.
Intial Public Health Care Report Follow-up - (Activity diagram)
Figure: 10
Interactions
Interactions - (Interaction diagram)
Figure: 11
Initial Public Health Case Reporting Static Model
The static model portion of the Initial Public Health Case Reporting DAM defines classes that form the information content of the eICR and the objects that participate in inter-activity information flows.
Static Model Classes
The eICR static model classes depict the data content of the eICR as specified by the Council of State and Territorial Epidemiologists (CSTE).
Initial Public Health Case Reporting -(Package diagram)
Figure: 13
Initial Public Health Case Reporting -(Class diagram)
Figure: 14
01: Suspected Case Report
Suspected Case Report - (Class diagram)
Figure: 15
InitialPublicCaseReport
Relationships
Type / Source / ParentAggregationis part of / InitialPublicCaseReport / ReportSubmission
Associationis triggered by / PatientEncounter / InitialPublicCaseReport
Attributes
Attribute / Attribute DetaileffectiveDate
/ Conformance ID: 2210-11
Default Value:
Source Mapping:
1: Date of the Report
ReportSubmission
Relationships
Type / Source / ParentAssociationgenerates / ReportSubmission / ElectronicMedicalRecordSystem
Aggregationis part of / InitialPublicCaseReport / ReportSubmission
Attributes
Attribute / Attribute DetaileffectiveDateTime
/ Conformance ID: 2210-77
Default Value:
Source Mapping:
2: Report Submission Date/Time
02: Patient Encounter
Patient Encounter - (Class diagram)
Figure: 16
AdministeredMedication
Relationships
Type / Source / ParentAggregationis part of / AdministeredMedication / PatientEncounter
Attributes
Attribute / Attribute DetailtypeCode
/ Conformance ID:
Default Value:
Source Mapping:
39: Medications Administered (list)
EncounterDiagnosis
Relationships
Type / Source / ParentAggregationis part of / EncounterDiagnosis / PatientEncounter
Generalizationis a type of / ReportableCondition / EncounterDiagnosis
Attributes
Attribute / Attribute DetailtypeCode
/ Conformance ID:
Default Value:
Source Mapping:
37: Diagnoses
effectiveDate
/ Conformance ID:
Default Value:
Source Mapping:
38: Date of Diagnosis
LaboratoryOrder
Relationships
Type / Source / ParentAggregationis part of / LaboratoryOrder / PatientEncounter
Attributes
Attribute / Attribute DetailtypeCode
/ Conformance ID:
Default Value:
Source Mapping:
35: Lab Order Code
identifier
/ Conformance ID:
Default Value:
Source Mapping:
36: Placer Order Number
PatientEncounter
Relationships
Type / Source / ParentAssociationis subject of / PatientEncounter / Patient
Associationis responsible for / PatientEncounter / Provider
Associationis triggered by / PatientEncounter / InitialPublicCaseReport
Associationis location of / PatientEncounter / CareDeliveryFacility
Aggregationis part of / EncounterDiagnosis / PatientEncounter
Aggregationis part of / LaboratoryOrder / PatientEncounter
Aggregationis part of / AdministeredMedication / PatientEncounter
Attributes
Attribute / Attribute DetailstartDateTime
/ Conformance ID: 2210-62
Default Value:
Source Mapping:
29: Visit Date/Time
30: Admission Date/Time
typeCode
/ Conformance ID: 2210-49
Default Value:
Source Mapping:
presentIllnessHistoryText
/ Conformance ID:
Default Value:
Source Mapping:
31: History of Present Illness
reasonCode
/ Conformance ID:
Default Value:
Source Mapping:
32: Reason for Visit
03: Care Delivery Facility
Care Delivery Facility - (Class diagram)
Figure: 18
CareDeliveryFacility
Relationships
Type / Source / ParentAssociationis operated by / CareDeliveryFacility / CareDeliveryOrganization
Associationis location of / PatientEncounter / CareDeliveryFacility
Attributes
Attribute / Attribute Detailidentifier
/ Conformance ID: 2210-68; 2210-84
Default Value:
Source Mapping:
11: Facility ID Number
typeCode
/ Conformance ID: 2210-59
Default Value:
Source Mapping:
13: Facility Type
postalAddress
/ Conformance ID: 2210-71; 2210-87
Default Value:
Source Mapping:
15: Facility Address
CareDeliveryOrganization
Relationships
Type / Source / ParentAssociationis operated by / CareDeliveryFacility / CareDeliveryOrganization
Associationis operated by / ElectronicMedicalRecordSystem / CareDeliveryOrganization
Attributes
Attribute / Attribute Detailname
/ Conformance ID: 2210-72; 2210-85
Default Value:
Source Mapping:
12: Facility Name
telecomAddress
/ Conformance ID: 2210-73; 2210-86
Default Value:
Source Mapping:
14: Facility Phone
ElectronicMedicalRecordSystem
Relationships
Type / Source / ParentAssociationis operated by / ElectronicMedicalRecordSystem / CareDeliveryOrganization
Associationgenerates / ReportSubmission / ElectronicMedicalRecordSystem
Attributes
Attribute / Attribute Detailname
/ Conformance ID: 2210-78
Default Value:
Source Mapping:
3: Sending Application
04: Provider
Provider - (Class diagram)
Detail:Created on10/13/2015. Last modified on10/18/2015
Figure: 19
Provider
Relationships
Type / Source / ParentAssociationis contact location for / Provider / ProviderFacility
Associationis responsible for / PatientEncounter / Provider
Attributes
Attribute / Attribute Detailidentifier
/ Conformance ID: 2210-63; 2210-90
Default Value:
Source Mapping:
4: Provider ID
name
/ Conformance ID: 2210-65; 2210-96
Default Value:
Source Mapping:
5: Provider Name
telecomAddress
/ Conformance ID: 2210-64; 2210-95
Default Value:
Source Mapping:
6: Provider Phone
7: Provider Fax
8: Provider Email
ProviderFacility
Relationships
Type / Source / ParentAssociationis contact location for / Provider / ProviderFacility
Attributes
Attribute / Attribute Detailname
/ Conformance ID: 2210-66; 2210-97
Default Value:
Source Mapping:
9: Provider Facility/Office Name
postalAddress
/ Conformance ID: 2210-67; 2210-98
Default Value:
Source Mapping:
10: Provider Address
05: Patient
Patient - (Class diagram)
Figure: 20
Patient
Relationships
Type / Source / ParentAssociation is legally responsible for / Patient / PatientGuardian
Associationis subject of / PatientEncounter / Patient
Attributes
Attribute / Attribute Detailidentifier
/ Conformance ID: 2210-21
Default Value:
Source Mapping:
16: Patient ID Number
name
/ Conformance ID: 2210-24
Default Value:
Source Mapping:
17: Patient Name
telecomAddress
/ Conformance ID: 2210-23
Default Value:
Source Mapping:
19: Patient or Parent/Guardian Phone
20: Patient or Parent/Guardian Email
postalAddress
/ Conformance ID: 2210-22
Default Value:
Source Mapping:
21: Street Address
birthDate
/ Conformance ID: 2210-28
Default Value:
Source Mapping:
22: Birth Date
sexCode
/ Conformance ID: 2210-17
Default Value:
Source Mapping:
23: Patient Sex
raceCode
/ Conformance ID: 2210-30; 2210-79
Default Value:
Source Mapping:
24: Race
ethnicityCode
/ Conformance ID: 2210-80
Default Value:
Source Mapping:
25: Ethnicity
preferredLanguage
/ Conformance ID: 2210-35
Default Value:
Source Mapping:
26: Preferred Language
occupationCode
/ Conformance ID:
Default Value:
Source Mapping:
27: Occupation
isPregnantIndicator
/ Conformance ID:
Default Value:
Source Mapping:
28: Pregnant
deathDate
/ Conformance ID: 2210-37
Default Value:
Source Mapping:
40: Death Date
PatientGuardian
Relationships
Type / Source / ParentAssociation is legally responsible for / Patient / PatientGuardian
Attributes
Attribute / Attribute Detailname
/ Conformance ID: 2210-46
Default Value:
Source Mapping:
18: Parent/Guardian Name
telecomAddress
/ Conformance ID: 2210-45
Default Value:
Source Mapping:
19: Patient or Parent/Guardian Phone
20: Patient or Parent/Guardian Email
06: Reportable Condition