HL7_DAM_VR_R4

 

HL7-International-Logo_2_x2

 

 

 

HL7 Cross-Paradigm Domain Analysis Model: Vital Records, Release 4

May 2020

 

HL7 Standard for Trial Use 1, Ballot Edition

 

Sponsored by:
Public Health Work Group

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2018 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.  HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off .

Use of this material is governed by HL7's IP Compliance Policy .


I MPORTANT NOTES:

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.

If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material") , the following describes the permitted uses of the Material.

A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.

INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.

B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement.

C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part.

NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7.

Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

 

Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Materials. Licensee shall take no action contrary to, or inconsistent with , the foregoing.

 

Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”).  Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability.

 

Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology

Owner/Contact

Current Procedures Terminology (CPT) code set

American Medical Association
http://www.ama-assn.org/ama/pub/physician-resources/solutions-managing-your-practice/coding-billing-insurance/cpt/cpt-products-services/licensing.page?

SNOMED CT

International Healthcare Terminology Standards Development Organization (IHTSDO) http://www.ihtsdo.org/snomed-ct/get-snomed-ct or info@ihtsdo.org

Logical Observation Identifiers Names & Codes (LOINC)

Regenstrief Institute

International Classification of Diseases (ICD) codes

World Health Organization (WHO)

NUCC Health Care Provider Taxonomy code set

American Medical Association. Please see 222.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services)

 


Table of Contents

Introduction

Background

Project Team

Development History

Development of VR DAM Release 4

Vital Records Reporting Data Collection Forms

Vital Records Information Exchange Standards

VR DAM Conformance Criteria

Continuous Maintenance

Vital Records Domain Analysis Model - Information Viewpoint

Components of the VR DAM Information Viewpoint

Subject Area Specification

Class Specifications

Relationship Assertions

Attribute Specifications

Inherited attributes

Datatype Designations

Data Collection Form Cross-References

Health Information Exchange Standard Cross-References

Terminology Bindings

Example Class and Attribute Specification:

VR DAM R4 Information Viewpoint Modifications

Subject Area: 01.0 Vital Records Report

Class: 1.01 Vital Records Report

Class: 1.02 Death Report

Class: 1.03 Live Birth Report

Class: 1.04 Fetal Death Report

Subject Area: 02.0 Vital Record Event

Class: 2.01 Vital Records Event

Class: 2.02 Event Location

Class: 2.03 Facility

Class: 2.04 Responsible Party

Class: 2.05 Responsible Party Role

Subject Area: 02.1 Death Event

Class: 2.1.01 Death Event

Class: 2.1.02 Cause of Death

Class: 2.1.03 Injury

Class: 2.1.04 Decedent Disposition

Subject Area: 02.2 Birth Event

Class: 2.2.01 Live Birth Event

Subject Area: 02.3 Fetal Death Event

Class: 2.3.01 Fetal Death Event

Class: 2.3.02 Cause of Fetal Death

Class: 2.3.03 Congenital Anomaly

Class: 2.3.04 Fetal Abnormality

Subject Area: 03.0 Vital Records Report Subject Entity

Class: 3.01 Subject Entity

Class: 3.02 Decedent

Class: 3.03 DeliveredEntity

Class: 3.04 Newborn

Class: 3.05 Newborn Abnormality

Class: 3.06 Fetus

Subject Area: 04.0 Subject Entity Family Member

Class: 4.01 Subject Entity Family Member

Class: 4.02 Parent

Class: 4.03 Mother

Class: 4.04 Smoking History

Class: 4.05 Father

Class: 4.06 Spouse

Subject Area: 05.0 Pregnancy and Delivery

Class: 5.01 Pregnancy

Class: 5.02 Pregnancy Risk Factor

Class: 5.03 Infection During Pregnancy

Class: 5.04 Delivery

Class: 5.05 Delivery Characteristic

Class: 5.06 Fetus Delivery

Subject Area: 06.0 Labor and Delivery Encounter

Class: 6.01 Labor and Delivery Encounter

Class: 6.02 Maternal Morbidity

Class: 6.03 Encounter Event

Class: 6.04 Obstetric Procedure

Coded Element Value Sets

Vital Records Domain Analysis Model - Behavioral Viewpoint

Scope of the VR DAM

VR DAM R4 Use Cases

1.0 Vital Records Event Reporting

2.0 Disposition of Remains

3.0 Event Record Management

4.0 Vital Records Statistical Analysis

VR DAM R4 Use Case Actors

Actors Families

Use Case Primary and Secondary Actors

VR DAM R4 Use Case Activities

1.0 Event Registration

2.0 Death Certification and Disposition of Remains

3.0 Event Record Management

4.0 Records Analysis and Inter-Agency Data Sharing


Introduction

Background

The Vital Records Domain Analysis Model (VR DAM) is the authoritative statement of foundational requirements for the design and development of health information exchange standards in Health Level Seven (HL7) related to vital records information flows. It facilitates consistency in the content and encoding of required vital records data and helps to ensure that HL7 standards developed for the vital records domain are derived from a common authoritative set of workflow and information requirements.

Health Level Seven (HL7) defines a Domain Analysis Model (DAM) as:

“A representation of the static and/or dynamic semantics of a subject-area-of-interest (i.e., domain) in a manner that enables harmonization of the various perspectives of the stakeholders in the domain while also providing the foundations required to create logical platform-independent and implementation platform-dependent models of information artifacts and/or applications whose semantics involve concepts from the domain"

In keeping with that definition, the VR DAM includes both an information viewpoint and a behavioral viewpoint. The information viewpoint provides the static semantics of the data classes and information objects of interest to the vital records domain. The behavioral viewpoint provides the dynamic semantics of the use cases and process flows of interest to the vital records domain.

Project Team

The VR DAM mapping project has a cross-functional project team consisting of representatives from the National Center for Health Statistics (NCHS) at the Centers for Disease Control and Prevention (CDC), vital records domain subject matter experts, HL7 Vital Records information exchange standards specification authors, and professional modeling facilitators/business analysts.

The project team includes the following individuals:

Project Facilitator:

Hetty Khan, NCHS/CDC,

 



 

 

Alaina Gregory , NCHS/CDC

 

Cynthia Bush, NCHS/CDC

 

 

 

Modeling Facilitators:

AbdulMalik Shakir, Hi3 Solutions,

 

Salimah Shakir, Hi3 Solutions
 

 

 

Domain Expert Representatives:

Alaina Gregory , NCHS/CDC,

 

Mead Walker, Walker Consulting,

 

Paula Braun, CDC,

 

The Vital Records Domain Analysis Model is a work product of the Health Level Seven Public Health Workgroup sponsored by the Centers for Disease Control and Prevention/National Center for Health Statistics (CDC/NCHS).

Development History

In 2003-2004, the Centers for Disease Control and Prevention/National Center for Health Statistics (CDC/NCHS) , the National Association for Public Health Statistics and Information Systems (NAPHSIS) and the Social Security Administration (SSA) partnered via the Model Vital Events Re-Engineered System (MoVERS) project to standardize functional requirements for re-engineered electronic birth, death and fetal death registration systems, and to document these requirements as model use cases. The MoVERS use cases describe system behavior for the Electronic Birth Registration System (EBRS) with fetal death functionality, Electronic Death Registration System (EDRS), Point of Service (POS, including certificate issuance), and generic system requirements.

The MoVERS project served as an initial foundation for the design, development, and implementation of web-based vital records and statistics systems for states. These requirements incorporate standardized data-collection instruments, improved methods for capturing data, immediate query of suspect data, query and edit guidelines, and detailed item definitions. The MoVERS project was the predecessor to the Vital Records Domain Analysis Model projects.

The following is a brief history of the Vital Record Domain Analysis Model projects and work products from the first release in April 2011 to the current release published in September 2019.

  • April 2011 - The HL7 Version 3 Domain Analysis Model: Vital Records (VR DAM), Release 1 describes the workflows and stakeholders for transmitting birth and death data to and from U.S. vital records systems. The VR DAM describes how birth, death, and fetal death records are processed in the U.S. and identifies the stakeholders participating in the data exchange. The goal of the VR DAM is to serve as a framework to guide future standards development for vital records exchange. http://bit.ly/2TRHonV
  • October 2017 - HL7 Cross-Paradigm Domain Analysis Model: Vital Records, Release 2 presents information viewpoint of the vital records domain as a single domain with five sub-domains:
  1. Items common to two or more sub-domains , such as: vital records reporting; vital record event location and responsible parties; and demographic observations related to event subject entities (decedent, newborn, and fetus) and subject family members (mother, father, and spouse).
  2. Items within scope of death events only , such as: the death report; death event details; and decedent related clinical observations.
  3. Items within scope of live birth events only , such as: the live-birth report; Live Birth event details; and newborn related clinical observations.
  4. Items within scope of fetal death events only , such as: the fetal death report, fetal death event details; and fetus related clinical observations.
  5. Items within the scope of pregnancy events , such as: pregnancy, labor, and delivery event details; the labor and delivery encounter; and clinical observations related to maternal morbidity and risk factors.

Release 1 of the Vital Records Domain Analysis Model presented Death, Birth, and Fetal Death as three independent vital records domains, each with its own information and behavioral viewpoints. Recasting the three VR DAM R1 viewpoints into a single consolidated vital records domain perspective required considerable re-engineering of the underlying information and behavioral models. http://bit.ly/3cJNP4Q

  • September 2019 - HL7 Cross-Paradigm Domain Analysis Model: Vital Records, Release 3 is the byproduct of the VR DAM Mapping project initiated in January 2017, sponsored by the HL7 Public Health Workgroup and co-sponsored by the HL7 Electronic Health Records Workgroup. The VR DAM Mapping project had the following as its objectives:
  1. Establish a procedure for development and on-going maintenance of mappings between the VR DAM and HL7 standard specifications for the Vital Records domain.
  2. Highlight where concepts in common across HL7 standard specifications have substantive differences in their implementation, such as differences in vocabulary bindings, differences in cardinality, or differences in datatypes or units of measures.
  3. Highlight where relevant data items from the DAM have been omitted from the standard specifications, or when data items have been included in the standard specifications but are missing from the DAM.

The VR DAM was updated to include data items present in standard specifications but omitted from prior versions of the DAM. Data elements in prior versions of the DAM not tracible to any information exchange specification were assessed by NCHS subject matter experts. Upon recommendation of the SMEs, a small subset was removed from the DAM. http://bit.ly/3avTIkq .

Development of VR DAM Release 4

Release IV of the Vital Record Domain Analysis Model represents a transition from an informative specification to a draft standard for trial use (STU) on the way to becoming a normative specification. This release includes formal mapping and cross-references to two vital records related health information exchange specifications – the HL7 v2.6 Vital Records Death Reporting Implementation Guide and the HL7 FHIR R4 Vital Records Death Reporting Implementation Guide.

Health Information Exchange standard cross-references and terminology bindings are specified for relevant portions of the VR DAM information model. These mappings serve a dual purpose. They assist in gap analysis and harmonization of the death reporting v2.6 and FHIR IGs and they provide a foundation for future vital records domain work products to draw upon that will minimize rework and facilitate consistency.

  1. VRDR v2.6 Mapping

Prepare a list of the HL7 v2.6 Vital Records Death Reporting Implementation Guide message elements. Note the location (segment.field.component) and terminology binding (code system, code system term, value set) of each message element. Identify the VR DAM subject area, class, and attribute corresponding to each message element.

VR DAM Class

2.1.01 Death Event

VR DAM Class Attribute

autopsyFindingsIndicator

autopsyPerformedIndicator

deathDateTime

MEID

OBX.5

OBX.5

PID.29

Message Element Name

Observation Value

Observation Value

Patient Death Date and Time

OBX.3.1

69436-4

69436-4

 

OBX.3.2

Autopsy Results Available

Autopsy Results Available

 

Valueset Name

PHVS_YesNoNotApplicable_NCHS

PHVS_YesNoNotApplicable_NCHS

 

  1. VRDR FHIR Mapping

Prepare a list of the HL7 FHIR R4 Vital Records Death Reporting Implementation Guide resource profiles. Note the base FHIR resource and attribute for each element in the resource profile. Identify the VR DAM subject area, class, and attribute corresponding to each resource profile element.

VR DAM Class

2.1.01 Death Event

VR DAM Class Attribute

autopsyFindingsIndicator

autopsyPerformedIndicator

deathDateTime

VRDR Profile Name

Autopsy Performed Indicator.
Autopsy Results Available

Autopsy Performed Indicator

Death Date

VRDR Profile Element

Observation.component.value

Observation. value

valueDateTime

Code / Datatype

"69436-4"

"85699-7"

 

Value set / Datatype

v2-0532

v2-0532

 

  1. HIE Standard XREF

Document the HIE standard, element location, and element name corresponding to the DAM subject area, class, and attribute.

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Autopsy Performed Indicator) – Observation.component.value

 

  1. Terminology Binding

Reconcile differences in terminology bindings. Document the harmonized terminology binding as a binding to IHE element value, element code, or element code and value.

Terminology Bindings:

  • Code: (CST) - " 69436-4", Autopsy Results Available, LN
  • Value: (VS) - PHVS_YesNoNotApplicable_NCHS

 

Vital Records Reporting Data Collection Forms

The descriptive text for class attributes in the VR DAM R4 information viewpoint includes a cross-reference to applicable national data collection forms and form locations. The set of data collection forms (DCF) specified in cross-references are listed in the following table:

Label

Name

Publisher

Publication Date

Death

U.S. Standard Certificate of Death (DCF)

NCHS

November 2003

FDeath

U.S. Standard Report of Fetal Death (DCF)

NCHS

November 2003

LBirth

U.S. Standard Certificate of Live Birth (DCF)

NCHS

November 2003

MWork

Mother’s Worksheet for Child’s Birth Certificate (DCF)

NCHS

December 2016

FWork

Facility Worksheet for the Live Birth Certificate (DCF)

NCHS

December 2016

Vital Records Information Exchange Standards

The vital records information exchange standards referenced in the VR DAM Mapping Project are listed in the following table:

Type

Name

Publication Date

HL7 v2

HL7 Version 2.5.1 Implementation Guide: Vital Records Death Reporting, Release 1.1

February 2015

HL7 v2

Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2

December 2017

HL7 v2

HL7 Version 2.6 Implementation Guide: Vital Records Death Reporting, Release 1.1

March 2018

HL7 v2

HL7 Version 2.6 Implementation Guide: Vital Records Death Reporting, Release 1 STU 2

Pending

HL7 CDA R2

CDA R2 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1

February 2015

HL7 CDA R2

CDA R2 Implementation Guide: Vital Records Death Reporting, Release 1 STU 2

September 2017

HL7 CDA R2

HL7 CDA R2 Ambulatory and Hospital Healthcare Provider Reporting to Birth Defect Registries Release 1, STU 2

September 2017

HL7 FHIR

Death on FHIR resource profiles and composition document implementation guide

January 2017

HL7 FHIR

Vital Records Mortality and Morbidity Reporting FHIR Implementation Guide, Release 1, STU 1

Pending

The descriptive text for class attributes in the VR DAM R4 information viewpoint begins the process of including cross-references to data elements in applicable information exchange standards. The cross-references provide a bases for assessing the conformance of information exchange standards to the VR DAM.

VR DAM Conformance Criteria

Conformity to the VR DAM is determined by the adherence and compatibility of usage, cardinality, and terminology constraints specified in downstream health information exchange standards to cross-referenced attributes in the DAM. The default cardinality for attributes in the DAM is (1..1). A corresponding cross-referenced element in an HIE specification shall have a usage of SHALL and a cardinality of (1..1). Note that the minimum cardinality of one does not imply that the HIE specification must use the attribute in its specification. Inclusion of the attribute in the HIE specification is totally within the discretion of the HIE specification author based upon the applicability of the attribute to the problem space domain addressed. However, when the attribute is included, to be conformant with the VR DAM it shall have a usage of SHALL and a cardinality of (1..1).

Where the DAM specifies a minimum cardinality of zero, then the corresponding cross-referenced element in the HIE standard may have a usage of MAY, SHOULD, or SHALL. The maximum cardinality of the corresponding cross-referenced element in the HIE standard need not match but shall not exceed the maximum cardinality of the DAM attribute.

Terminology bindings in corresponding cross-referenced elements in the HIE standard must be compatible with the terminology bindings specified in the DAM. Terminology bindings in the DAM are expressed as Code System (CS), Code System Term (CST), or Value Set (VS) bindings. To be conformant the terminology bindings for corresponding cross-referenced elements in the HIE standard shall represent a concept space having a non-empty intersection with the concept space represented in the DAM. For example, a DAM attribute having a CST binding would be compatible with an HIE standard having the same CST binding or a binding to a CS or VS that includes the CST as a member.

Continuous Maintenance

The VR DAM continuous maintenance process runs concurrent with ballot and publication of new vital records related HL7 specifications. Vital records related specification development or maintenance projects are encouraged to include updating of the Vital Records Domain Analysis Model as a milestone activity in their project scope statements.

As these standards are developed their data elements will be mapped to the VR DAM for use in conformance alignment and terminology binding harmonization. The VR DAM will be balloted and republished following reconciliation of any gaps and inconsistencies discovered during the standard mapping process.

Release four of the VR DAM contains cross-reference mappings to the vital records information exchange standards scheduled for publication in 2020:

  • Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2
  • Vital Records Mortality and Morbidity Reporting FHIR Implementation Guide, Release 1, STU 1

The data element cross-references produced during the development of these specifications were instrumental in facilitating the harmonization of terminology bindings between the two specifications enabling superior interoperability between implementations of the two standards.

 


Vital Records Domain Analysis Model - Information Viewpoint

Components of the VR DAM Information Viewpoint

Subject Area Specification

The VR DAM R4 information viewpoint is presented as a single information model with nine subject areas as depicted in the following subject area diagram:

Each subject area specification includes a class diagram followed by a detailed specification for each class in the subject area. The subject area class diagrams use standard Unified Modeling Language (UML) notation. Classes display their native attributes and inherited attributes. Associative relationships are labeled with a prepositional phrase adorned with an arrowhead indicating the direction from which the relationship is defined. Relationships to classes outside the subject area are attached to an instance of the foreign class. Attributes of the foreign class instances are suppressed in the subject area diagram and the foreign class is shaded gray.

The color coding in the subject area diagram indicates which of the five sub-domains the classes in the subject area are most closely affiliated. The five sub-domains are Universal – common to all of vital records reporting, Death – specific to vital records death reporting, Live Birth – specific to vital records birth reporting, Fetal Death – specific to vital record fetal death reporting, and Pregnancy – specific to vital records birth and fetal death reporting.

Class Specifications

Each class specification includes


  • the class name,
  • descriptive text,
  • a list of relationship assertions,
  • a list of native attributes,
  • a list of inherited attributes.

Relationship Assertions

Relationship assertions are intended to assist subject matter experts that may not be well-versed in UML notation. They are written using the following sentence pattern:

Each <source className> {always | sometime} <relationship predicate> {one | one or more} <target className> .

Example:

         Each Vital Records Event always occurs at one Event Location.

Attribute Specifications

Each attribute specification includes descriptive text, a datatype designation, and a list of cross-references to relevant data collection form locations.

Inherited attributes

Inherited attributes are a byproduct of using generalization relationships. A generalization relationship appears in the class diagram as a line with a solid arrowhead. The relationship connects the specialization class to the generalization class. A specialization class is a type of the generalization class.

In this example, Facility is the specialization class and Event Location is the generalization class. The relationship assertions for the generalization relationship are written as: “Each Facility always is a type of Event Location” and “Each Event Location sometimes is of type Facility”.

The specialization class “inherits” the attributes and relationships of the generalization class. The Facility class inherits the attributes physicalAddress, description, and locationType from the Event Location class. It also inherits the “occurs at” relationship to Vital Records Event. Attribute details and relationship assertions are specified in the generalization class only.

Datatype Designations

The datatype designations are a subset drawn from the HL7 Version 3 Standard: Data Types - Abstract Specification, Release 2 .

The subset of datatypes used in this specification include:


  • AD - Postal Address
  • BL - Boolean
  • CD - Concept Descriptor
  • ED - Encapsulated Data
  • II - Instance Identifier
  • INT - Integer
  • PN - Person Name
  • PQ - Physical Quantity
  • ST - String
  • TS - Point in Time Specification

The concept descriptor datatype (CD) is used in this specification to represent concepts that “may” be coded. In some cases, the code for the concept may yet to have been assigned and in such a case the original text portion of the CD datatype would contain a free-text expression of the concept. There are several codable concepts that are routinely not assigned a code until after they are first communicated to the NCHS by the jurisdiction (e.g., cause of death). NCHS assigns a code to the concept upon receipt of the original text and returns the code to the reporting jurisdiction. The original text portion of the CD datatype is also used when the nullflavor of “Other” is used as the concept code. In this case, original text includes the free-text concept not defined as part of the predefined set of permitted values.

Data Collection Form Cross-References

Data collection form cross-references have three components: The Form Identifier, the Form Location Reference, and the Form Location Name. The form identifier is drawn from the following list:

  • Death U.S. Standard Certificate of Death (DCF)
  • FDeath U.S. Standard Report of Fetal Death (DCF)
  • LBirth U.S. Standard Certificate of Live Birth (DCF)
  • MWork Mother’s Worksheet for Child’s Birth Certificate (DCF)
  • FWork Facility Worksheet for the Live Birth Certificate (DCF)

The form location reference is an alpha-numeric designation enclosed in parentheses. The form location name is an adaptation of the caption used for the item on the designated data collection form.

Health Information Exchange Standard Cross-References

Health Information Exchange Standard (HIES) cross-references have three components: The HIES identifier, the exchange standard data element location, and the name of the HIES data element. The HIES identifier is drawn from the following list:

  • VRDR v2.6 - HL7 Version 2.6 Implementation Guide-Vital Records Death Reporting, Release 1 STU 2
  • VRDR FHIR – HL7 FHIR R4 Vital Records Death Reporting Implementation Guide, Release 1 STU 1

Exchange standard data element location and name for HL7 v2 standards are expressed as segment id and field/field component reference followed by the element name (e.g., OBX.5 – Observation Value). For HL7 FHIR standards the standard’s data element location is specified as the profile name followed by the name of the base resource and data element (e.g., VRDR FHIR (Death Certificate) – Composition.date).

Terminology Bindings

Coded attributes in the VR DAM, those with a datatype of CD, require a specification of their allowable code values. The terminologies bound to these coded attributes are based upon harmonization of terminology bindings present within the health information exchange standard(s) to which the attribute is cross referenced. Terminology bindings are expressed in one of three flavors:

  • Code System (CS) – a collection of coded concepts within a concept domain.
  • Code System Term (CST) – a single coded concept with a code system.
  • Value Set (VS) – a collection of coded concepts from one or more code system.

Terminology bindings are only specified for coded attributes which include information exchange standard cross-references. Terminology bindings are expressed as code system name and mnemonic for code system bindings, code value, preferred concept name, and code system mnemonic for code system terms, and value set name and value set OID or URL for value sets. Coded attributes are represented as conceptual observation with a code and value. Terminology bindings are specified at the code, value, or code and value .

Example Class and Attribute Specification:

VR DAM R4 Information Viewpoint Modifications

The following modifications were applied to the VR DAM in response to requests received from the Vital Records Birth Defects Reporting project team in anticipation of a new release of their specification in 2021. The Vital Records Birth Defects Reporting health information exchange specification is expected to be among the next set of published health information exchange specification to be cross-referenced to the Vital Records DAM.

Class

Action

Attribute

2.04 Responsible Party

Add

telecommunicationAddress

2.2.01 Live Birth Event

Remove

priorPregnancyOutcomes

4.01 Subject Entity Family Member

Rename

address to postalAddress

 

Add

deathDateTime

 

Add

deceasedInd

 

Add

sex

 

Add

spokenLanguage

 

Add

telecommunicationAddress

4.02 Parent

Rename

ethnicity to ethnicityCode

4.03 Mother

Remove

deliveryWeight

 

Remove

ethnicityCode

 

Remove

marriedDuringPregnancyIndicator

 

Remove

prePregnancyWeight

 

Remove

telecommunicationAddress

5.01 Pregnancy

Add

marriedDuringPregnancyIndicator

 

Add

prePregnancyWeight

 

Add

priorPregnancyOutcomes

5.04 Delivery

Add

maternaldeliveryWeight

 


Subject Area: 01.0 Vital Records Report

The vital records report subject area contains the classes pertaining to reports sent to vital records registrars to provide notification or to amend a prior notification of vital record events.

 


Class: 1.01 Vital Records Report

A vital records report is a notification sent to a vital records registrar to report the occurrence of a vital records event such as death, birth, or fetal death.

Relationships:

         Each Vital Records Report always is a notification of one Vital Records Event.

         Each Vital Records Event sometimes is subject of one or more Vital Records Report

         Each Fetal Death Report always is a type of Vital Records Report

         Each Vital Records Report sometimes is of type Fetal Death Report

         Each Death Report always is a type of Vital Records Report.

         Each Vital Records Report sometimes is of type Death Report.

         Each Vital Records Report Amendment always amends one VR Report.

         Each VR Report sometimes is amended by one or more Vital Records Report Amendments.

         Each Live Birth Report always is a type of Vital Records Report.

         Each Vital Records Report sometimes is of type Live Birth Report.

Native Attributes:

         auxiliaryFileNumber

An auxiliary filing identifier for the report. It may be used to indicate the file's number with a local (as opposed to state or other central jurisdictional) registry. Note that the auxiliary file number is only provided by the local registry.

Datatype: ST 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         fileNumber

A filing identifier that is assigned to a vital record when it is registered by the jurisdiction, either electronically or manually; also, known as a State File Number (SFN). The number format is unique to each jurisdiction. If an original birth record is sealed, the replacement record will retain the original certificate file number.

Datatype: ST 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         registrarName

The name of the individual filing the vital records report at the local or jurisdictional level.

Datatype: EN.PN 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         identifier

A unique identifier used to identify a digital record of the vital records report. This identifier is retained with the digital record throughout its life cycle.

Datatype: ST 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         filedDate

The calendar date upon which the vital records report was filed with the vital records registrar.

Datatype: TS.DATE 

DCF Cross-References:

  • Death (50) - Date Filed
  • LBirth (13) - Date Filed by Registrar

HIE Cross-References:

  • VRDR v2.6 (MSH.7) - Date/Time of Message
  •  
  • VRDR FHIR (Death Certificate) – Composition.date

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

Class: 1.02 Death Report

A death report is a type of vital records report used to provide notification of the death of an individual. It includes information related to the decedent, the death event, and observations concerning the causes of death.

Relationships:

         Each Death Report always is a type of Vital Records Report.

         Each Vital Records Report sometimes is of type Death Report.

         Each Death Report always reports one Death Event.

         Each Death Event sometimes is reported in one or more Death Report.

Native Attributes:

         linkedBirthCertificateNumber

The identifier of the birth certificate which is linked to this certificate. This information is only captured for death certificates. For NCHS purposes, the linking birth certificate number is part of the death file for infant deaths only to derive linked birth/infant death file. Since the birth certificate number itself is not unique, it must be used in conjunction with the year of birth and jurisdiction of birth for linkage purposes.  Many VR jurisdictions link the birth and death certificates for all deaths, not just infant deaths.

Datatype: ST 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

 

Terminology Bindings:

  • None

 

         filingMethod

A coded indication of the way the certificate or report was filed. This information is only captured for death certificates.

Datatype: CD 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

 

Terminology Bindings:

  • None

Inherited Attributes:

  • 1.01 Vital Records Report.amendedReportIndicator
  • 1.01 Vital Records Report.auxiliaryFileNumber
  • 1.01 Vital Records Report.filedDate
  • 1.01 Vital Records Report.fileNumber
  • 1.01 Vital Records Report.identifier
  • 1.01 Vital Records Report.registrarName
  • 1.01 Vital Records Report.voidedReportedIndicator

 

 


Class: 1.03 Live Birth Report

A live birth report is a type of vital records report used to provide notification of a live birth event. It includes information related to the newborn, the birth event, and observations related to the pregnancy, labor, and delivery.

Relationships:

         Each Live Birth Report always reports one Live Birth Event.

         Each Live Birth Event sometimes is reported in one or more Birth Report.

         Each Live Birth Report always is a type of Vital Records Report.

         Each Vital Records Report sometimes is of type Live Birth Report.

Native Attributes:

         newbornLiveAtReportTime

A Boolean indicator that states whether the baby was living at time of completion of the facility worksheet. If the baby has already been discharged to home care, the answer should be "Yes".

Datatype: BL 

DCF Cross-References:

  • LBirth (57) - Is Infant Living at Time of Report?

 

         linkedDeathCertificateNumber

The identifier of the death certificate which is linked to this certificate. This information is only captured for birth certificates.

Datatype: ST 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • 1.01 Vital Records Report.amendedReportIndicator
  • 1.01 Vital Records Report.auxiliaryFileNumber
  • 1.01 Vital Records Report.filedDate
  • 1.01 Vital Records Report.fileNumber
  • 1.01 Vital Records Report.identifier
  • 1.01 Vital Records Report.registrarName
  • 1.01 Vital Records Report.voidedReportedIndicator

 


Class: 1.04 Fetal Death Report

A fetal death report is a type of vital records report used to provide notification of a fetal death event. It includes information related to the fetus, the fetal death, and observations related to pregnancy, labor, and delivery.

Relationships:

         Each Fetal Death Report always reports one Fetal Death Event.

         Each Fetal Death Event sometimes is reported in one or more Fetal Death Report.

         Each Fetal Death Report always is a type of Vital Records Report

         Each Vital Records Report sometimes is of type Fetal Death Report

Native Attributes:

         reporterName

The name of the individual responsible for completion of the Fetal Death Report.

Datatype: EN.PN 

DCF Cross-References:

  • FDeath (15a) - Name of Person Completing Report

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         reportedDate

The date on which the fetal death was reported by the responsible practitioner.

Datatype: TS 

DCF Cross-References:

  • FDeath (16) - Date Report Completed

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         reporterTitle

The professional title of the person responsible for completion of the Fetal Death Report.

Datatype: CD 

DCF Cross-References:

  • FDeath (15b) - Title of Person Completing Report

HIE Cross-References:

  • None

Terminology Bindings:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         filedDate

The date that the record was filed with the vital records registrar.

Datatype: TS 

DCF Cross-References:

  • FDeath (17) - Date Received by Registrar

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • 1.01 Vital Records Report.amendedReportIndicator
  • 1.01 Vital Records Report.auxiliaryFileNumber
  • 1.01 Vital Records Report.filedDate
  • 1.01 Vital Records Report.fileNumber
  • 1.01 Vital Records Report.identifier
  • 1.01 Vital Records Report.registrarName
  • 1.01 Vital Records Report.voidedReportedIndicator

 

 


Subject Area: 02.0 Vital Record Event

The vital records event subject area contains the classes pertaining to the event that is the subject of the event notification reports sent to vital records registrars.

 


Class: 2.01 Vital Records Event

A vital records event is a life event reportable to the jurisdictional Vital Records Reporting agency and the National Center for Health Statistics. Within the scope of this DAM vital record events include death, live birth, and fetal death.

Relationships:

         Each Vital Records Event always occurs at one Event Location.

         Each Event Location always is the location of one or more Vital Records Events.

         Each Vital Records Event always involves one Subject Entity.

         Each Subject Entity always is involved in one or more Vital Records Event.

         Each Vital Records Report always is a notification of one Vital Records Event.

         Each Vital Records Event sometimes is subject of one or more Vital Records Report

         Each Death Event always is a type of Vital Records Event.

         Each Vital Records Event sometimes is of type Death Event.

         Each Responsible Party Role always participates in one Vital Records Event.

         Each Vital Records Event always has the participation of one or more Responsible Party Role.

         Each Fetal Death Event always is a type of Vital Records Event.

         Each Vital Records Event sometimes is of type Fetal Death Event.

         Each Live Birth Event always is a type of Vital Records Event.

         Each Vital Records Event sometimes is of type Live Birth Event.

Native Attributes:

         eventTypeCode

A coded value indicating which type of vital record event is being reported (i.e., Death, Birth, Fetal Death).

Datatype: CD 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         certificationDate

A date specifying when certification of the vital records event was completed.

Datatype: TS 

DCF Cross-References:

  • Death (28) - Date Signed
  • Death (49) - Date Certified
  • FWork (20) - Date Certified
  • LBirth (12) - Date Certified

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR v2.6 (PDA.4) - Death Certificate Signed Date/Time
  • VRDR FHIR (Death Date) - Observation.effectiveDateTime
  • VRDR FHIR  (Death Certification) - Procedure.performedDateTime

Terminology Bindings:

  • Code: (CST) - "80616-6", Date/time pronounced dead, LN

 

         identifier

A unique identifier used to identify the vital records event.

Datatype: II 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

 


Class: 2.02 Event Location

An event location is the place where the vital record event occurred (i.e., place of birth, place of death, or place of delivery.

Relationships:

         Each Vital Records Event always occurs at one Event Location.

         Each Event Location always is the location of one or more Vital Records Events.

         Each Facility always is a type of Event Location.

         Each Event Location sometimes is of type Facility.

Native Attributes:

         physicalAddress

The street address or other location designation for the place where the vital record event took place.  This differs from postalAddress in that this may not be an address to which mail can be directed, such as a national park or a geographic location designated by longitude and latitude.

Datatype: AD [0..1]

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         description

Descriptive text for the location where the vital records event took place. This attribute is to be used when the event location does not have a defined street address. For example, "US 95 10 miles south of Burlington New Jersey."

Datatype: ST [0..1]

DCF Cross-References:

  • Death (14b) - Place of Death - other than a Hospital

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         locationType

A coded value indicating the type of the location where the vital records event took place.

Datatype: CD 

DCF Cross-References:

  • Death (14a) - Place of Death - in a hospital
  • Death (14b) - Place of Death - other than a Hospital
  • FDeath (07) - Place Where Delivery Occurred
  • FWork (05) - Place Where Birth Occurred
  • LBirth (26) - Place Where Birth Occurred

HIE Cross-References:

  • VRDR v2.6 (PDA.2.6) - Person Location Type
  • VRDR FHIR (Death Location) - Location.type

Terminology Bindings:

  • Value: (VS) - PHVS_PlaceOfDeath_NCHS (OID: 2.16.840.1.114222.4.11.7216)

 

Inherited Attributes:

  • None


Class: 2.03 Facility

A facility is a type of event location, typically a place of business such as a healthcare facility or funeral home.

Relationships:

         Each Facility always is a type of Event Location.

         Each Event Location sometimes is of type Facility.

Native Attributes:

         licenseIdentifier

An identifier of the license awarded to the facility that indicates its eligibility to provide the types of services it provides.

Datatype: II 

DCF Cross-References:

  • Death (23) - License Number
  • Death (48) - License Number
  • FDeath (09) - Facility ID.
  • FWork (02) - Facility I.D.
  • LBirth (17) - Facility ID. (NPI)

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         postalAddress

The address used to direct mail to the facility. The postal address is not necessarily the same as the physical address of the location.

Datatype: AD 

DCF Cross-References:

  • Death (16) - City or Town, State, and Zip Code
  • Death (17) - County of Death
  • Death (21b) - Address of Funeral Facility
  • FDeath (05a) - City, Town, of Location of Delivery
  • FDeath (05b) - Zip Code of Delivery
  • FDeath (06) - County of Delivery
  • FWork (03) - City, Town, or Location of Birth
  • FWork (04) - County of Birth
  • LBirth (06) - City, Town, or Location of Birth
  • LBirth (07) - County

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Death Location) - Location.address
  • VRDR FHIR (Death Location) - Location.address.district
  • VRDR FHIR (Funeral Home) - Organization.address

Terminology Bindings:

  • Code: (CST) - "69435-6", Address of location where death occurred, LN
  • Code: (CST) - "94133-6", Funeral Facility Address, LN

 

         name

The designation by which the facility is referred.

Datatype: ST 

DCF Cross-References:

  • Death (15) - Facility Name
  • Death (21a) - Name of Funeral Facility
  • FDeath (08) - Facility Name
  • FWork (01) - Facility Name
  • LBirth (05) - Facility Name

HIE Cross-References:

  • VRDR v2.6 (PDA.2.9) - Location Description
  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Death Location) - Location.name
  • VRDR FHIR (Funeral Home) - Organization.name

Terminology Bindings:

  • Code: (CST) - "94132-8", Funeral Facility Name, LN
         nationalProviderIdentifier

A National Provider Identifier or NPI is a unique 10-digit identification number issued to health care providers in the United States by the Centers for Medicare and Medicaid Services (CMS).

Datatype: II [0..1]

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • 2.02 Event Location.description
  • 2.02 Event Location.locationType
  • 2.02 Event Location.physicalAddress

 

 


Class: 2.04 Responsible Party

A responsible party is an individual that plays some role in the process of reporting a vital records event. A responsible party can play the role of certifier, attendant, funeral director, or witness.

Relationships:

         Each Responsible Party Role always is played by one Responsible party.

         Each Responsible Party always plays one or more Responsible Party Role.

Native Attributes:

         relationshipToSubject

A coded value indicating the relationship of the responsible party to the subject entity of the vital records event.

Datatype: CD 

DCF Cross-References:

  • Death (13b) - Relationship to Decedent
  • MWork (27b) - Relationship to baby's mother

HIE Cross-References:

  • VRDR FHIR (Death Certificate.Informant) - US-Core-Patient:contact.relationship

Terminology Bindings:

  • Value: (VS) - v2 Contact Role (URL: http://hl7.org/fhir/ValueSet/v2-0131)

 

         name

The designation by which the responsible party is known or referred.

Datatype: EN.PN 

DCF Cross-References:

  • Death (13a) - Informant's Name
  • Death (22) - Signature of Funeral Service Licensee or Other Agent
  • Death (26) - Signature of Person Pronouncing Death
  • Death (45b) - Signature of Certifier
  • Death (46a) -  Name of Person Completing Cause of Death
  • FDeath (14a) - Attendant's Name
  • FWork (19a) - Certifier's Name
  • FWork (24a) - Attendant's name
  • LBirth (11a) - Certifier's Name
  • LBirth (27a) - Attendant's Name
  • MWork (27a) - Informant's Name

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR v2.6 (PDA.5) - Death Certified By
  • VRDR FHIR (Mortician) - Practitioner.name
  • VRDR FHIR (Death Pronouncement Performer) - Practitioner.name
  • VRDR FHIR (Death Certificate.Informant) - US-Core-Patient:contact.name
  • VRDR FHIR (Certifier) - Practitioner.name

Terminology Bindings:

  • Code: (CST) - "94134-4", Name of Funeral Service Licensee or other agent, LN
  • Code: (CST) - "74499-5", Death pronouncer details, LN

 

         title

A coded indication of the professional credential held by the responsible party.

Datatype: CD 

DCF Cross-References:

  • Death (47) - Title of Certifier
  • FDeath (14c) - Attendant's Title
  • FWork (19b) - Certifier's Title
  • FWork (24b) - Attendant's Title
  • LBirth (11b) - Title
  • LBirth (27c) - Attendant's Title

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         licenseIdentifier

The identifier of a license issued to the responsible party, that indicates their authority to assume the role indicated by the related responsible party role.

Datatype: ST [1..*]

DCF Cross-References:

  • Death (23) - License Number
  • Death (27) - License Number
  • FDeath (14b) - Attendant's NPI
  • LBirth (27b) - Attendant's NPI

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR v2.6 (PDA.5.1) - Death Certified By Id Number
  • VRDR FHIR (Mortician) - Practitioner.qualification.identifier
  • VRDR FHIR (Death Pronouncement Performer) - Practitioner.qualification.identifier
  • VRDR FHIR (Certifier) - Practitioner.qualification.identifier

Terminology Bindings:

  • Code: (CST) - "94135-1", Funeral Service Licensee License Number, LN
  • Code: (CST) - "74499-5", Death pronouncer details, LN

 

         address

The postal address or other geographic designation used to locate the responsible party.

Datatype: AD 

DCF Cross-References:

  • Death (13c.) - Mailing Address
  • Death (46b.) - Address and Zip Code of Person Completing Cause of Death

HIE Cross-References:

Terminology Bindings:

  • Code: (CST) - "69439-8", Death certifier (address), LN

 

         telecommunicationAddress

The telecommunication address (phone, email, URL) used to contact the Responsible Party.

Datatype: TEL [1..*]

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 


Class: 2.05 Responsible Party Role

A responsible party role is one of the possibly many roles played by a responsible party regarding a vital records event.

Relationships:

         Each Responsible Party Role always participates in one Vital Records Event.

         Each Vital Records Event always has the participation of one or more Responsible Party Role.

         Each Responsible Party Role always is played by one Responsible party.

         Each Responsible Party always plays one or more Responsible Party Role.

Native Attributes:

         roleCode

A coded value indicating the role played by the responsible party regarding participation in reporting of the vital records event.

Datatype: CD 

DCF Cross-References:

  • Death (45a.) - Certifier's Role

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Certifier Role) – valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69437-2", Death certifier (type), LN
  • Value: (VS) - Death certificate_certifier (OID: 1.3.6.1.4.1.12009.10.1.1119)

 

Inherited Attributes:  

  • None

 


Subject Area: 02.1 Death Event

The death event subject area is a type of vital records event containing the classes pertaining to a death event.

 


Class: 2.1.01 Death Event

A death event is a type of vital records event in which a person has died.

Relationships:

         Each Death Event always is a type of Vital Records Event.

         Each Vital Records Event sometimes is of type Death Event.

         Each Death Event always involves one Decedent.

         Each Decedent always is involved in one Death Event.

         Each Decedent Disposition always follows one Death Event.

         Each Death Event sometimes is followed by one Decedent Disposition.

         Each Injury always contributes to one Death Event.

         Each Death Event sometimes influences one or more Injuries.

         Each Cause of Death always resulted in one Death Event.

         Each Death Event sometimes is the result of one or more Cause of Deaths.

         Each Death Report always reports one Death Event.

         Each Death Event sometimes is reported in one or more Death Report.

Native Attributes:

  • autopsyDateTime

The date and time that the autopsy was performed.

Datatype: TS 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         autopsyFindingsIndicator

An indicator that states whether findings from an autopsy are available.

Datatype: BL 

DCF Cross-References:

  • Death (34) - Were Autopsy Findings Available to Complete the Cause of Death?

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Autopsy Performed Indicator.Autopsy Results Available) - Observation:component.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - " 69436-4", Autopsy Results Available, LN
  • Value: (VS) - PHVS_YesNoNotApplicable_NCHS (OID: 2.16.840.1.114222.4.11.7486)

 

         autopsyPerformedIndicator

An indicator that states whether an autopsy is to be or has been performed.

Datatype: BL 

DCF Cross-References:

  • Death (33) - Was an Autopsy Performed?

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Autopsy Performed Indicator) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69436-4", Autopsy Results Available, LN
  • Value: (VS) - PHVS_YesNoNotApplicable_NCHS (OID: 2.16.840.1.114222.4.11.7486)

 

         deathEventInjuryIndicator

Indicates whether there was an injury associated with the cause of death.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         deathManner

A coded indication of the way the person died.

Datatype: CD 

DCF Cross-References:

  • Death (37) - Manner of Death

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Manner of Death) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69449-7", Manner of death, LN
  • Value: (VS) - PHVS_MannerOfDeath_NCHS (OID: 2.16.840.1.114222.4.11.6002)

 

         deathDateTime

The date on which the person died. It is relevant to note that the exact date will not always be available. Therefore, in implementations, it is necessary to support partial dates that only identify year and month or year.

Datatype: TS 

DCF Cross-References:

  • Death (29) - Actual or Presumed Date of Death
  • Death (30) - Actual or Presumed Time of Death

HIE Cross-References:

  • VRDR v2.6 (PID.29) - Patient Death Date and Time
  • VRDR FHIR (Death Date) - Observation.valueDateTime

Terminology Bindings:

  • None

 

         significantContributingCause

Descriptive text that provides information on a significant condition or conditions that contributed to the death but did not result in the underlying cause that is elsewhere described. Note, this is not to include pregnancy or smoking status since they are elsewhere described.

Datatype: CD 

DCF Cross-References:

  • Death (32II) - Other Significant Conditions Contributing to Death

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Condition Contributintg To Death) - Condition.code.code
  • VRDR FHIR (Condition Contributintg To Death) - Condition.code.text

Terminology Bindings:

  • Code: (CST) - "80359-3", Cause of death.underlying [Manual], LN
  • Code: (CST) - "69441-4", Death Cause Other Significant Conditions, LN
  • Value: (VS) - PHVS_CauseOfDeath_ICD-10_CDC (OID: 2.16.840.1.114222.4.11.3593)

 

         deathDateEstimatedIndicator

An indicator that shows whether the date of death is directly known or whether it has been estimated.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         deathTimeEstimatedIndicator

An indicator that shows whether the time of death is directly known or whether it has been estimated.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         pronouncedDeathDateTime

The date on which the responsible clinician pronounced the person as dead.

Datatype: TS 

DCF Cross-References:

  • Death (24) - Date Pronounced Dead
  • Death (25) - Time Pronounced Dead

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Death Date.Date Pronounced Dead) - Observation:component.valueDateTime

Terminology Bindings:

  • Code: (CST) - "80616-6", Date/time pronounced dead, LN

 

         medicalExaminerReferralIndicator

An indication of whether the person was referred to the medical examiner for further investigation of the manner and cause of death. This is most commonly done when the death is not by natural causes.

Datatype: BL 

DCF Cross-References:

  • Death (31) - Was Medical Examiner or Coroner Contacted?

HIE Cross-References:

  • VRDR v2.6 (PDA.9) - Coroner Indicator
  • VRDR FHIR (Medical Examiner Contacted) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "74497-9", Medical examiner or coroner was contacted   , LN
  • Value: (VS) - PHVS_YesNoUnknown_CDC (OID: 2.16.840.1.114222.4.11.888)

 

  • referralNote

The note left by the referring party.

Datatype: ST 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

Inherited Attributes:

  • 2.01 Vital Records Event.certificationDate
  • 2.01 Vital Records Event.eventTypeCode

 

 


Class: 2.1.02 Cause of Death

A cause of death is a clinical finding of a condition, disease, or sequence of events that directly caused or indirectly contributed to the death of an individual.

Relationships:

         Each Cause of Death always resulted in one Death Event.

         Each Death Event sometimes is the result of one or more Cause of Deaths.

Native Attributes:

         causalSequence

The causal sequence number that was provided for the disease or condition description item that the code value was extracted from.

Datatype: INT 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         causeCode

A coded indication of the reason for the person's death. Cause of death codes are assigned based on the disease or condition descriptive information provided by the responsible clinician, coroner, or medical examiner. Cause of death code contains only original text as it traverses from provider to local and jurisdictional Vital Records Office and from the jurisdictional Vital Records Office to NCHS. The coded value is added by NCHS and sent to the jurisdictional Vital Records Office.

Datatype: CD 

DCF Cross-References:

  • None

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Cause Of Death Condition) - Condition.code.code

Terminology Bindings:

  • Code: (CST) - "many", Cause of death 80359-3, 80358-5, 80357-7, 80356-9, LN
  • Value: (VS) - PHVS_CauseOfDeath_ICD-10_CDC (OID: 2.16.840.1.114222.4.11.3593)

 

         preDeathTimeInterval

A measure of the time interval between the onset of the disease, injury or complication, and the person's death.

Datatype: PQ 

DCF Cross-References:

  • Death (32I-2) - Interval onset to death

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Cause Of Death Condition) - Condition.onsetQuantity

Terminology Bindings:

  • Code: (CST) - "69440-6", Disease onset to death interval, LN

 

         supportingDescriptiveText

Descriptive text that indicates which part of the cause of death information section a death cause appears in, if it is in Part I, which line it was in.

Datatype: ST 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         causeDescription

A textual indication of the reason for the person's death.

Datatype: ST 

DCF Cross-References:

  • Death (32I-1) - Cause of Death

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Cause Of Death Condition) - Condition.code.text

Terminology Bindings:

  • Code: (CST) - "69453-9", Cause of death, LN

 

Inherited Attributes:

  • None

 


Class: 2.1.03 Injury

Information about an injury-producing event that was suffered by the decedent and which contributed to his or her death.

Relationships:

         Each Injury sometimes contributes to one Death Event.

         Each Death Event sometimes involves one or more Injuries.

Native Attributes:

         locationPostalAddress

The street address for the place where the injury occurred.

Datatype: AD 

DCF Cross-References:

  • Death (42) - Location of Injury

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Injury Location) - Location.address

Terminology Bindings:

  • Code: (CST) - "69447-1", Injury location narrative, LN

 

         workInjuryIndicator

An indicator of whether the injury occurred while the person was at work.

Datatype: BL 

DCF Cross-References:

  • Death (41) - Injury at Work?

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Injury Incident Description.Work Injury Indicator) - Observation:component.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69444-8", Did death result from injury at work, LN
  • Value: (VS) - PHVS_YesNoNotApplicable_NCHS (OID: 2.16.840.1.114222.4.11.7486)

 

         injuryDateComment

The comment made about the injury date.

Datatype: ST 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         injuryDateTime

The date on which the injury occurred.

Datatype: TS 

DCF Cross-References:

  • Death (38) - Date of Injury
  • Death (39) - Time of Injury

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Injury Incident Description) - Observation.effectiveDateTime

Terminology Bindings:

  • Code: (CST) - "69445-5", Injury date, LN

 

         estimatedInjuryDateIndicator

An indicator that shows whether the date of injury is directly known or whether it has been estimated.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         injuryOccurrenceDescription

A text description of how the injury occurred.

Datatype: ST 

DCF Cross-References:

  • Death (43) - Describe How Injury Occurred

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Injury Incident Description) - Observation.valueString

Terminology Bindings:

  • Code: (CST) - "11374-6", Injury incident description, LN

 

         locationDescription

A text description of the kind of place where the injury occurred.

Datatype: ST 

DCF Cross-References:

  • Death (40) - Place of Injury

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Injury Incident Description.Place of Injury) - Observation:component.valueString

Terminology Bindings:

  • Code: (CST) - "11376-1", Injury location, LN
  • Value: (VS) - PHVS_PlaceOfInjury_NCHS (OID: 2.16.840.1.114222.4.11.7374)

 

         estimatedInjuryTimeIndicator

An indicator that shows whether the time of injury is directly known or whether it has been estimated.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         transportationInjuryIndicator

An indicator that shows whether the injury was related to transportation.

Datatype: BL 

DCF Cross-References:

  • Death (44.b) - Transportation Injury?

HIE Cross-References:

  • VRDR FHIR (Injury Incident Description.Transportation Event Indicator) - Observation:component.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69448-9", Injury leading to death associated with transportation event, LN
  • Value: (VS) - PHVS_YesNoUnknown_CDC (OID: 2.16.840.1.114222.4.11.888)

 

         transportationInjuryRole

A coded value that states, if the injury was related to transportation, the specific role played by the decedent, e.g. driver, passenger.

Datatype: CD 

DCF Cross-References:

  • Death (44.a) - If Transportation Injury, specify [the role of the decedent]

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Decedent Transportation Role) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69451-3", Transportation Role of Decedent, LN
  • Value: (VS) - PHVS_TransportationRelationships_NCHS (OID: 2.16.840.1.114222.4.11.6005)

 

Inherited Attributes:

  • None

 

 


Class: 2.1.04 Decedent Disposition

Information that relates to the disposition of the person's body, and to the funeral home that takes responsibility for that disposition.

Relationships:

         Each Decedent Disposition always follows one Death Event.

         Each Death Event sometimes is followed by one Decedent Disposition.

Native Attributes:

         bodyRecoveredIndicator

A Boolean indicator that makes it possible to note that the decedent's body has not been recovered, and will therefore not be available for disposition. This can happen if a person is lost at sea. This item is not currently collected for the standard death certificate.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         dispositionMethod

A coded indication of the method of disposition of the body.

Datatype: CD 

DCF Cross-References:

  • Death (18) - Method of Disposition

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Decedent Disposition Method) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "80905-3", Method of disposition, LN
  • Value: (VS) - PHVS_MethodsOfDisposition_NCHS (OID: 2.16.840.1.114222.4.11.7379)

 

         dispositionLocationAddress

The city or town within whose limits the person's body is to be, or has been disposed .

Datatype: AD 

DCF Cross-References:

  • Death (20) - Location - City, Town, and State

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Disposition Location) - Location.address

Terminology Bindings:

  • Code: (CST) - "94131-0", Body disposition facility address, LN

 

         dispositionLocationName

The name of the place where the person's body is to be or has been buried or otherwise disposed of.

Datatype: ST 

DCF Cross-References:

  • Death (19) - Place of Disposition

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Disposition Location) - Location.name

Terminology Bindings:

  • Code: (CST) - "94130-2", Body disposition facility name [Identifier], LN

 

Inherited Attributes:   

  • None


Subject Area: 02.2 Birth Event

The birth event subject area is a type of vital records event containing the classes pertaining to event involving the delivery of a live newborn.

 


Class: 2.2.01 Live Birth Event

Information collected for each individual birth whether occurring in a single or multiple gestation pregnancies . To ease the exposition, the information collected for a birth is split into three classes, with Pregnancy (the prenatal experience), Labor and Delivery, and Delivery collected as separate classes.

Relationships:

         Each Live Birth Event always is a type of Vital Records Event.

         Each Vital Records Event sometimes is of type Live Birth Event.

         Each Live Birth Event always is a type of Delivery.

         Each Delivery sometimes is of type Live Birth Event

         Each Live Birth Event always involves one Newborn

         Each Newborn always is involved in one Live Birth Event

         Each Live Birth Report always reports one Live Birth Event.

         Each Live Birth Event sometimes is reported in one or more Live Birth Report.

Native Attributes:

  • None

 

Inherited Attributes:

  • 5.04 Delivery.deliveryDateTime
  • 5.04 Delivery.deliveryMethod
  • 5.04 Delivery.deliveryRoute
  • 5.04 Delivery.deliverySequence
  • 5.04 Delivery.fetalPresentation
  • 5.04 Delivery.unsuccessfulForcepsDeliveryIndicator
  • 5.04 Delivery.unsuccessfulVacuumExtractionIndicator
  • 2.01 Vital Records Event.certificationDate
  • 2.01 Vital Records Event.eventTypeCode  


Subject Area: 02.3 Fetal Death Event

The fetal death event subject area is a type of vital records event containing the classes pertaining to an event involving the delivery of a deceased fetus.

 


Class: 2.3.01 Fetal Death Event

The fetal death event is a type of vital records event involving the delivery of a deceased fetus.

Relationships:

         Each Fetal Death Event always is a type of Vital Records Event.

         Each Vital Records Event sometimes is of type Fetal Death Event.

         Each Fetal Death Event always is reported in one or more Fetal Death Report.

         Each Fetal Death Report always reports one Fetal Death Event.

         Each Fetal Death Event always involves one Fetus.

         Each Fetus sometimes is involved in one Fetal Death Event.

         Each Fetal Death Event sometimes includes one or more Fetal Abnormality.

         Each Fetal Abnormality always is present during one Fetal Death Event.

         Each Fetal Death Event sometimes includes one or more Congenital Anomaly.

         Each Congenital Anomaly always is present during one Fetal Death Event.

         Each Fetal Death Event sometimes results from one or more Cause of Fetal Death.

         Each Cause of Fetal Death always results in one Fetal Death Event.

Native Attributes:

         autopsyFindingsIndicator

An indicator that states whether findings from an autopsy are available.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         significantContributingCause

A text description of the significant condition or conditions that contributed to death , but did not result in the underlying cause that is elsewhere described. A coded indication for other significant cause(s)/condition(s) will be returned to the jurisdiction from NCHS. Note, this is not to include pregnancy.

Significant causes or conditions include conditions contributing to death other than the initiating cause. These conditions may be conditions that are triggered by the initiating cause or causes that are not among the sequence of events triggered by the initiating cause. The clinician completing the cause of death must enter medical conditions using their own terminology. Significant causes must also support capturing whether any of the listed Complications of Placenta, Cord, or Membranes are contributing causes: Rupture of membranes prior to the onset of labor; Abruptio placenta; Placental insufficiency; Prolapsed cord; and Chorioamnionitis.

Datatype: CD 

DCF Cross-References:

  • FDeath (18b) - Other Significant Causes or Conditions

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         initiatingCause

The initiating cause/condition is used for reporting a single condition that most likely began the sequence of events resulting in the death of the fetus. The clinician completing the cause of death must enter medical conditions using their own terminology. Initiating Causes must also support capturing whether any of the listed Complications of Placenta, Cord, or Membranes are initiating causes: Rupture of membranes prior to onset of labor; Abruptio placentae; Placental insufficiency; Prolapsed cord; and Chorioamnionitis.

Datatype: CD 

DCF Cross-References:

  • FDeath (18a) - Initiating Cause/Condition

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         objectiveFindingsUsedIndicator

A Boolean indicator that states whether an autopsy or histological placental examination results were used in determining the cause of fetal death.

Datatype: BL 

DCF Cross-References:

  • FDeath (18h) - Were Autopsy or Histological Placental Examination Results Used in Determining the Cause of Fetal Death

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         autopsyPerformedIndicator

An indicator that states whether an autopsy is to be, or has been performed.

Datatype: BL 

DCF Cross-References:

  • FDeath (18f) - Was an Autopsy Performed

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         remainsDispositionMethod

A coded indication of the method of disposition of the body.

Datatype: CD [0..1]

DCF Cross-References:

  • FDeath (13) - Method of Disposition

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         estimatedDeathDateTime

A coded value that indicates the relationship between the delivery of the fetus, and the time of fetal death.

Datatype: CD 

DCF Cross-References:

  • FDeath (18e) - Estimated Time of Fetal Death

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         histologicalExaminationPerformedIndicator

An indicator that states whether a histological placental examination has been performed.

Datatype: BL 

DCF Cross-References:

  • FDeath (18g) - Was a Histological Placental Examination Performed?

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • 2.01 Vital Records Event.certificationDate
  • 2.01 Vital Records Event.eventTypeCode

 

 


Class: 2.3.02 Cause of Fetal Death

Information relating to the fetus's cause of death.   The cause of death content is carried within the contained classes as descriptive and coded information.

Relationships:

         Each Cause of Fetal Death always results in one Fetal Death Event.

         Each Fetal Death Event sometimes results from one or more Cause of Fetal Death.

Native Attributes:

         causeCode

A coded value indication of a type of cause of fetal death. If there is no suitable code to describe the cause, then the descriptive attribute should be used instead.

Datatype: CD 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

 


Class: 2.3.03 Congenital Anomaly

A malformation of the fetus that was diagnosed prenatally or after delivery. Following the conventions of vital statistics reporting, each recognized type of malformation is captured as a type code value, and whether it is present during the delivery process is indicated by the value of the morbidity indicator.

Relationships:

         Each Congenital Anomaly always is present during one Fetal Death Event.

         Each Fetal Death Event sometimes includes one or more Congenital Anomaly.

Native Attributes:

         conditionIndicator

A Boolean indicator that states whether the fetus suffers from the malformation indicated by the type code value.

Datatype: BL 

DCF Cross-References:

  • FDeath (40) - Congenital Anomalies of the Fetus

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         conditionType

A coded indication of a type of malformation experienced by the infant.

Datatype: CD 

DCF Cross-References:

  • FDeath (40) - Congenital Anomalies of the Fetus
  • LBirth (55) - Congenital Anomalies of the Newborn

HIE Cross-References:

  • None

Terminology Bindings:

  • None

Inherited Attributes:

  • None

 

 


Class: 2.3.04 Fetal Abnormality

An abnormality of the fetus that was diagnosed prenatally or after delivery. Following the conventions of vital statistics reporting, each recognized type of abnormality is captured as a type code value, and whether it is present during the delivery process is indicated by the value of the morbidity indicator.

Relationships:

         Each Fetal Abnormality always is present during one Fetal Death Event.

         Each Fetal Death Event sometimes includes one or more Fetal Abnormality.

Native Attributes:

         abnormalityIndicator

A Boolean indicator that states whether the fetus displays the malformation indicated by the type code value.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         abnormalityType

A coded indication of a type of malformation displayed by the fetus.

Datatype: CD 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:   

  • None

 


Subject Area: 03.0 Vital Records Report Subject Entity

The vital records report subject entity subject area contains the classes pertaining to the entity (decedent, newborn, or deceased fetus) that is the subject of a vital records report.

 


Class: 3.01 Subject Entity

The vital records report subject entity is the entity (decedent, newborn, or deceased fetus) that is the subject of a vital records report.

Relationships:

         Each Subject Entity sometimes has one or more Subject Entity Family Member.

         Each Subject Entity Family Member always is a family member of one Subject Entity.

         Each Subject Entity always is involved in one or more Vital Records Event.

         Each Vital Records Event always involves one Subject Entity.

         Each Subject Entity sometimes is of type Decedent.

         Each Decedent always is a type of Subject Entity

         Each Subject Entity sometimes is of type Delivered Entity.

         Each Delivered Entity always is a type of Subject Entity.

Native Attributes:

Indicates whether the subject is deceased.

Datatype: BL

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         name

The subject entity’s legal name. The name by which they are referred to in official documents and correspondence.

Datatype: EN.PN [0..1]

DCF Cross-References:

  • Death (01) - Decedent's Legal Name
  • FDeath (01) - Name of Fetus
  • LBirth (01) - Child's Name
  • MWork (02) - Baby's Legal Name

HIE Cross-References:

  • VRDR v2.6 (PID.5) - Patient Name
  • VRDR FHIR (Decedent) - US-Core-Patient.name

Terminology Bindings:

  • None

 

  • raceCode

A coded value indicating the person's racial affiliation.  If there is no suitable code to describe the person's race, then designate race as ‘other’ and include a descriptive text in the original text component of the CD datatype.

Datatype: CD

DCF Cross-References:

  • Death (53) - Decedent's Race

HIE Cross-References:

  • VRDR v2.6 (PID.10) - Race
  • VRDR FHIR (Decedent) - US-Core-Patient.race

Terminology Bindings:

  • Value: (VS) - PHVS_Race_CDC (OID: 2.16.840.1.114222.4.11.876)

 

         sex

A coded indication of the gender of the subject entity.

Datatype: CD 

DCF Cross-References:

  • Death (02) - Sex
  • FDeath (03) - Sex
  • FWork (31) - Sex
  • LBirth (03) - Sex

HIE Cross-References:

  • VRDR v2.6 (PID.8) - Administrative Sex
  • VRDR FHIR (Decedent) - US-Core-Patient.gender

Terminology Bindings:

  • Value: (VS) - PHVS_Sex_MFU (OID: 2.16.840.1.114222.4.11.1038)

 

Inherited Attributes:

  • None

 

 


Class: 3.02 Decedent

Relationships:

         Each Decedent always is a type of Subject Entity.

         Each Subject Entity sometimes is of type Decedent.

         Each Decedent always is involved in one Death Event.

         Each Death Event always involves one Decedent.

Native Attributes:

A coded indication of the Hispanic origin of the person. If there is no suitable code for the person's Hispanic origin, the descriptive attribute should be used instead.

Datatype: CD

DCF Cross-References:

  • Death (52) - Decedent of Hispanic Origin

HIE Cross-References:

  • VRDR v2.6 (PID.22) - Ethnic Group
  • VRDR FHIR (Decedent) - US-Core-Patient.ethnicity

Terminology Bindings:

  • Value: (VS) - PHVS_Ethnicity_CDC (OID: 2.16.840.1.114222.4.11.877)

 

  • deathCertificateID

The number identifying the death certificate.

Datatype: II

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

  • deathDateComment

The comment made about the death date.

Datatype: ST

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

  • deathPregnancyTiming

A coded value indicating the pregnancy progress at the time of death.

Datatype: CD

DCF Cross-References:

  • None

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Timing of Recent Pregnancy) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69442-2", Timing of Recent Pregnancy Related to Death, LN
  • Value: (VS) - PHVS_PregnancyStatus_NCHS (OID: 2.16.840.1.114222.4.11.6003)

 

         reportedName

The name under which the person was certified dead. This attribute is provided to allow for situations in which the name under which the decedent was certified dead differs from their legal name.

Datatype: EN.PN 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         pregnancyStatus

A code that provides information regarding whether the person was pregnant at the time of her death, or whether she was pregnant around the time of death.

Datatype: CD 

DCF Cross-References:

  • Death (36) - Pregnancy - If Female

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Timing of Recent Pregnancy) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69442-2", Timing of Recent Pregnancy Related to Death, LN
  • Value: (VS) - PHVS_PregnancyStatus_NCHS (OID: 2.16.840.1.114222.4.11.6003)

 

         educationLevel

A coded indication of the highest level of education attained by the person.

Datatype: CD 

DCF Cross-References:

  • Death (51) - decedent’s Education

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Decedent Education Level) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "80913-7", Decedent education level, LN
  • Value: (VS) - PHVS_DecedentEducationLevel_NCHS (OID: 2.16.840.1.114222.4.11.7385)

 

         tobaccoUse

A coded indication of the extent of the person's use of tobacco. The data is captured if tobacco use may have contributed to their death.

Datatype: CD 

DCF Cross-References:

  • Death (35) - Did Tobacco use contribute to death?

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Tobacco Use Contributed To Death) - Observation.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "69443-0", Did tobacco use contribute to death, LN
  • Value: (VS) - PHVS_ContributoryTobaccoUse_NCHS (OID: 2.16.840.1.114222.4.11.6004)

 

         usualIndustry

Title that identifies the kind of business, i.e., primary business activity, in which the decedent worked for the longest time while in their Usual Work Occupation.

Datatype: CD 

DCF Cross-References:

  • Death (55) - Kind of Business/Industry

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Decedent Employment History.Usual Industry) - Observation:component.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "21844-6", Industry, LN
  • Value: (VS) - PHVS_Industry_CDC_Census2010 (OID: 2.16.840.1.114222.4.11.7187)

 

         maritalStatus

A coded indication of the person's relationship with a significant other.

Datatype: CD 

DCF Cross-References:

  • Death (09) - Marital Status at Time of Death

HIE Cross-References:

  • VRDR v2.6 (PID.16) - Marital Status
  • VRDR FHIR (Decedent) - US-Core-Patient.maritalStatus

Terminology Bindings:

  • Value: (VS) - PHVS_MaritalStatus_NCHS (OID: 2.16.840.1.114222.4.11.7380)

 

         usualOccupation

Title that identifies the type of work the decedent performed (occupation) for the longest amount of time during his or her life, regardless of the decedent's last occupation and regardless of whether or not the decedent performed this type of work for a continuous time.

Datatype: CD 

DCF Cross-References:

  • Death (54) - decedent’s Usual Occupation

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Decedent Employment History.Usual Occupation) - Observation:component.valueCodeableConcept

Terminology Bindings:

  • Code: (CST) - "21843-8", Occupation, LN
  • Value: (VS) - PHVS_Occupation_CDC_Census2010 (OID: 2.16.840.1.114222.4.11.7186)

 

         birthAddress

The city and state or foreign country in which the person was born.

Datatype: AD 

DCF Cross-References:

  • Death (06) - Birthplace

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Decedent) - US-Core-Patient.address

Terminology Bindings:

  • Code: (CST) - "21842-0", Birthplace, LN

 

         residentialAddress

The street address for the place where the decedent lived.

Datatype: AD 

DCF Cross-References:

  • Death (07a) - Residence-State
  • Death (07b) - County
  • Death (07c) - City or Town
  • Death (07d) - Street and Number
  • Death (07e) - Apt. No.
  • Death (07f) - Zip Code

HIE Cross-References:

  • VRDR v2.6 (PID.11) - Patient Address
  • VRDR FHIR (Decedent) - US-Core-Patient.address

Terminology Bindings:

  • None

 

         socialSecurityNumber

The social security number assigned to the decedent.

Datatype: ST 

DCF Cross-References:

  • Death (03) - Social Security Number

HIE Cross-References:

  • VRDR v2.6 (PID.3) - Patient Identifier List
  • VRDR FHIR (Decedent) - US-Core-Patient.identifier

Terminology Bindings:

  • None

 

         armedForcesIndicator

An indicator of whether the person has served within the United States armed forces.

Datatype: BL 

DCF Cross-References:

  • Death (08) - Ever in the Armed Forces?

HIE Cross-References:

  • VRDR v2.6 (PID.27) - Veterans Military Status
  • VRDR FHIR (Decedent Employment History.Military Service) - Observation:component.valueBoolean

Terminology Bindings:

  • Code: (CST) - "55280-2", Military service Narrative, LN
  • Value: (VS) - PHVS_YesNoUnknown_CDC (OID: 2.16.840.1.114222.4.11.888)

 

         birthDate

The date of the person's birth. It is relevant to note that the exact date will not always be available. Therefore, in implementations, it is necessary to support partial dates that only identify year and month or year.

Datatype: TS 

DCF Cross-References:

  • Death (05) - Date of Birth

HIE Cross-References:

  • VRDR v2.6 (PID.7) - Date/Time of Birth
  • VRDR FHIR (Decedent) - US-Core-Patient.birthdate

Terminology Bindings:

  • None

 

         deathAge

The person's chronological age at the time of death.

Datatype: PQ 

DCF Cross-References:

  • Death (04a) - Age - Years
  • Death (04b) - Age - Months and Days
  • Death (04c) - Age - Hours and Minutes

HIE Cross-References:

  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Decedent Age) - Observation.valueQuantity

Terminology Bindings:

  • Code: (CST) - "39016-1", Age at death, LN

 

Inherited Attributes:

  • 3.01 Subject Entity.name
  • 3.01 Subject Entity.sex

 

 


Class: 3.03 DeliveredEntity

A delivered entity is the newborn or deceased fetus that is delivered as the product of conception.

Relationships:

         Each Delivered Entity always is a type of Subject Entity.

         Each Subject Entity sometimes is of type Delivered Entity.

         Each Delivered Entity sometimes is of type Newborn

         Each Newborn is a type of Delivered Entity.

         Each Delivered Entity sometimes is of type Fetus.

         Each Fetus is always a type of Delivered Entity.

Native Attributes:

         estimatedGestationalAge

The delivery attendant's estimate of the gestational age of the fetus at delivery. It is based on all perinatal factors and assessments, but not the neonatal exam. The gestation estimate should not be computed based on the date of the last menstrual period and the date of delivery.

Datatype: PQ 

DCF Cross-References:

  • FDeath (18d) - Obstetric Estimate of Gestation at Delivery
  • FWork (30) - Obstetric Estimate of Gestation at Delivery
  • LBirth (50) - Obstetric Estimate of Gestation

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         deliveryWeight

The weight of the delivered entity (fetus or newborn) at delivery.

Datatype: PQ 

DCF Cross-References:

  • FDeath (18c) - Weight of Fetus
  • FWork (29) - Birthweight
  • LBirth (49) - Birthweight

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • 3.01 Subject Entity.name
  • 3.01 Subject Entity.sex

 

 


Class: 3.04 Newborn

A newborn is a type of delivered entity that is delivered live.

Relationships:

         Each Newborn always is a type of Delivered Entity.

         Each Delivered Entity sometimes is of type Newborn.

         Each Newborn is always involved in one Live Birth Event.

         Each Live Birth Event always involves a Newborn.

         Each Newborn sometimes has one or more Newborn Abnormality.

         Each Newborn Abnormality always pertains to one Newborn.

Native Attributes:

         medicalRecordNumber

The medical record number assigned to the newborn by the birthing facility.

Datatype: ST 

DCF Cross-References:

  • FWork (22) - Infant's Medical Record Number
  • LBirth (48) - Newborn Medical Record Number

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         fiveMinuteApgar

The Apgar score at five minutes after birth.

Datatype: INT 

DCF Cross-References:

  • FWork (32a) - Apgar Score at 5 minutes
  • LBirth (51a) - APGAR Score at 5 min
  • LBirth (51b) - APGAR Score at 10 min

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         tenMinuteApgar

The Apgar score at 10 minutes after birth. The score will normally only be recorded if the 5 minute Apgar score was less than 6.

Datatype: INT 

DCF Cross-References:

  • FWork (32b) - Apgar Score at 10 minutes

 

Inherited Attributes:

  • 3.03 DeliveredEntity.deliveryWeight
  • 3.03 DeliveredEntity.estimatedGestationalAge
  • 3.01 Subject Entity.name
  • 3.01 Subject Entity.sex

 

 

Class: 3.05 Newborn Abnormality

An abnormality of the newborn that was diagnosed prenatally or after delivery. Following the conventions of vital statistics reporting, each recognized type of abnormality is captured as a condition type code value, and whether it is present during the delivery process is indicated by the value of the condition indicator.

Relationships:

         Each Newborn Abnormality always pertains to one Newborn.

         Each Newborn sometimes has one or more Newborn Abnormality.

Native Attributes:

         conditionIndicator

A Boolean indicator that states whether the infant experienced the abnormal condition indicated by the type code value.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         conditionType

A coded indication of a type of abnormal condition experienced by the infant.

Datatype: CD 

DCF Cross-References:

  • FWork (36) - Abnormal Newborn Conditions
  • FWork (37) - Congenital Newborn Abnormalities
  • LBirth (54) - Abnormal Conditions of the Newborn

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

 


Class: 3.06 Fetus

A fetus is a type of delivered entity that is deceased upon delivery, having died prior to or during delivery.

Relationships:

         Each Fetus is always a type of Delivered Entity.

         Each Delivered Entity sometimes is of type Fetus.

         Each Fetus sometimes is involved in one Fetal Death Event.

         Each Fetus Death Event always involves one Fetus.

Native Attributes:

         medicalExaminerReferralIndicator

An indication of whether the fetus was referred to the medical examiner for further investigation of the manner and cause of death. This is most commonly done when the death is not by natural causes.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • 3.03 DeliveredEntity.deliveryWeight
  • 3.03 DeliveredEntity.estimatedGestationalAge
  • 3.01 Subject Entity.name
  • 3.01 Subject Entity.sex  

 


Subject Area: 04.0 Subject Entity Family Member

The subject entity family member subject area contains the classes pertaining to family members (mother, father, or spouse) of the subject entity (decedent, newborn, or deceased fetus).

 


Class: 4.01 Subject Entity Family Member

A family member (mother, father, or spouse) of the subject entity (decedent, newborn, or deceased fetus).

Relationships:

         Each Subject Entity Family Member always is a family member of one Subject Entity.

         Each Subject Entity sometimes has one or more Subject Entity Family Member.

         Each Parent always is a type of Subject Entity Family Member.

         Each Subject Entity Family Member sometimes is of type Parent.

         Each Spouse always is a type of Subject Entity Family Member.

         Each Subject Entity Family Member sometimes is of type Spouse.

Native Attributes:

         name

The name of the person's family member.

Datatype: EN.PN [1..*]

DCF Cross-References:

  • Death (10) - Surviving Spouse’s Name
  • Death (11) - Father's Name
  • Death (12) - Mother's Name Prior to First Marriage
  • FDeath (10a) - Mother's Current Legal Name
  • FDeath (10c) - Mother's Name Prior to First Marriage
  • FDeath (12a) - Father's Current Legal Name
  • LBirth (08a) - Mother's Current Legal Name
  • LBirth (08c) - Mother's Name Prior To First Marriage
  • LBirth (10a) - Father's Current Legal Name
  • MWork (01) - Mother's Current Legal Name
  • MWork (17) - Mother's Maiden Name
  • MWork (19) - Father's Legal Name

HIE Cross-References:

  • VRDR FHIR (Decedent Mother) - RelatedPerson.name
  • VRDR v2.6 (OBX.5) - Observation Value
  • VRDR FHIR (Decedent Father) - RelatedPerson.name
  • VRDR FHIR (Decedent Spouse) - RelatedPerson.name

Terminology Bindings:

  • Code: (CST) - "80909-5", Father's surname, LN

 

         sex

A coded indication of the gender designation of the Subject Entity Family Member.

Datatype: CD

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         spokenLanguage

A coded value designating the human language with which the subject entity family member has some proficiency in communicating verbally.

Datatype: CD [1..*]

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         postalAddress

The postal address used to send mail to the family member.

Datatype: AD 

DCF Cross-References:

  • FDeath (11a) - Residence of Mother's State
  • FDeath (11b) - County
  • FDeath (11c) - City, Town, or Location
  • FDeath (11d) - Street and Number
  • FDeath (11e) - Apt. No.
  • FDeath (11f) - Zip Code
  • FDeath (11g) - Inside City Limits
  • LBirth (09a) - Residence of Mother-State
  • LBirth (09b) - County
  • LBirth (09c) - City, Town, or Location
  • LBirth (09d) - Street and Number
  • LBirth (09e) - Apt. No.
  • LBirth (09f) - Zip Code
  • LBirth (09g) - Inside City Limits
  • LBirth (14) - Mother's Mailing Address
  • MWork (03) - Mother's Postal Address
  • MWork (05) - Mother's Mailing Address

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         telecommunicationAddress

The telecommunication address (phone, email, URL) used to contact the subject entity family member.

Datatype: TEL [0..*]

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         identifier

A unique identifier used to identify the family member.  Examples of identifier include Social Security Number, Medical Record Number, and Driver’s License. These special identifiers also appear as separate attributes when applicable for a given use case, such as Medical Record Number for Mother, where the mother is a patient.

Datatype: II 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         relationshipTypeCode

A code indicating the familiar relationship of the subject entity family member to the subject entity. Examples include mother, father, and spouse.

Datatype: CD 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

  • deceasedInd

An indication as to whether the Subject Entity Family Member is deceased.

Datatype: BL

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         deathDateTime

The time of death of a deceased Subject Entity Family Member.

Datatype: TS 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

 


Class: 4.02 Parent

A parent is a type of subject entity family member. It is the type that is the biological, surrogate, or adoptive parent of the subject entity. A biological parent is a person whose gamete resulted in a child, a male (father) through the sperm, and a female (mother) through the ovum. A female can also become a parent through surrogacy. Some parents may be adoptive parents, who nurture and raise an offspring, but are not actually biologically related to the child.

Relationships:

         Each Parent always is a type of Subject Entity Family Member.

         Each Subject Entity Family Member sometimes is of type Parent.

         Each Mother always is a type of Parent.

         Each Parent sometimes is of type Mother.

         Each Father always is a type of Parent.

         Each Parent sometimes is of type Father.

Native Attributes:

         educationLevel

A coded indication of the highest level of education attained by the mother or father.

Datatype: CD 

DCF Cross-References:

  • FDeath (19) - Mother's Education
  • LBirth (20) - Mother's Education
  • LBirth (23) - Father's Education
  • MWork (08) - Mother's Highest Education
  • MWork (22) - Father's Highest Education

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         ethnicityCode

A coded indication of the Hispanic origin of the person. If there is no suitable code for the person's Hispanic origin, the descriptive attribute should be used instead.

Datatype: CD [0.*]

DCF Cross-References:

  • FDeath (20) – Mother is of Hispanic Origin
  • LBirth (21) - Mother of Hispanic Origin?
  • LBirth (24) - Father of Hispanic Origin?
  • MWork (09) - Mother's Ethnicity
  • MWork (23) - Father's Ethnicity

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         race

A coded value indicating the person's racial affiliation. If there is no suitable code to describe the person's race, then the descriptive attribute should be used instead.

Datatype: CD [0.*]

DCF Cross-References:

  • FDeath (21) - Mother's Race
  • LBirth (22) - Mother's Race
  • LBirth (25) - Father's Race
  • MWork (10) - Mother's Race
  • MWork (24) - Father's Race

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         birthDate

The date on which the mother or father was born.

Datatype: TS 

DCF Cross-References:

  • FDeath (10b) - Date of Birth (Mother)
  • FDeath (12b) - Date of Birth (Father)
  • LBirth (08b) - Date of Birth (Mother)
  • LBirth (10b) - Date of Birth (Father)
  • MWork (06) - Mother's Birth Date
  • MWork (20) - Father's Birth Date

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         birthPlace

A text description of the state, territory, or country where the mother or father was born.

Datatype: AD 

DCF Cross-References:

  • FDeath (10d) - Birthplace (Mother)
  • FDeath (12c) - Birthplace (Father)
  • LBirth (08d) - Birthplace (Mother)
  • LBirth (10c) - Birth Place (Father)
  • MWork (07) - Mother's Birth State, US Territory, or Foreign Country
  • MWork (21) - Father's State, US Territory, or Foreign Country of Birth

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         socialSecurityNumber

An identifier for mother or father's social security account. In the United States, this is known as the Social Security Number, and is often used as a national identifier for the person. It also may be legally shared with child support programs.

Datatype: ST 

DCF Cross-References:

  • LBirth (18) - Mother's Social Security Number
  • LBirth (19) - Father's Social Security Number
  • MWork (25a) - Mother's SSN
  • MWork (25b) - Father's SSN

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • 4.01 Subject Entity Family Member.name
  • 4.01 Subject Entity Family Member.relationshipTypeCode
  • 4.01 Subject Entity Family Member.deceasedInd
  • 4.01 Subject Entity Family Member.postalAddress
  • 4.01 Subject Entity Family Member.identifier
  • 4.01 Subject Entity Family Member.spokenLanguage
  • 4.01 Subject Entity Family Member.telecommunicationAddress
  • 4.01 Subject Entity Family Member.sex
  • 4.01 Subject Entity Family Member.deathDateTime

 


Class: 4.03 Mother

A mother is a type of parent; she is the female parent.

Relationships:

         Each Mother always is a type of Parent.

         Each Parent sometimes is of type Mother.

         Each Mother sometimes is involved in one or more Labor and Delivery Encounter.

         Each Labor and Delivery Encounter always involves one Mother.

         Each Mother sometimes has one or more Smoking History.

         Each Smoking History always pertains to one Mother.

         Each Mother sometimes is involved in one or more Pregnancy.

         Each Pregnancy always involves one Mother.

Native Attributes:

         height

The mother's height in inches.

Datatype: PQ 

DCF Cross-References:

  • FDeath (25) - Mother's Height
  • LBirth (31) - Mother's Height
  • MWork (13) - Mother's Height

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         locationType

A coded indication to identify the type of location the Mother resides.

Datatype: CD

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         medicalRecordNumber

The medical record number assigned to the mother by the facility in which the delivery took place.

Datatype: ST 

DCF Cross-References:

  • LBirth (40) - Mother's Medical Record Number

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         maritalStatus

A Boolean indication of whether the mother has ever been married.

Datatype: BL 

DCF Cross-References:

  • MWork (16a) - Mother Married
  • FDeath (22) - Mother Married

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         wicRecipientIndicator

A Boolean indicator to show whether the mother is registered as a recipient of aid from the WIC food (special supplemental nutrition program for Women, Infants, and Children) for herself for this pregnancy.

Datatype: BL 

DCF Cross-References:

  • FDeath (28) - Did Mother Get WIC Food for Herself During This Pregnancy?
  • LBirth (34) - Did Mother Get WIC Food for Herself During This Pregnancy?
  • MWork (11) - Did Mother Get WIC Food for Herself During This Pregnancy?

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • 4.02 Parent.birthDate
  • 4.02 Parent.birthPlace
  • 4.02 Parent.educationLevel
  • 4.02 Parent.ethnicityCode
  • 4.02 Parent.race
  • 4.02 Parent.socialSecurityNumber
  • 4.01 Subject Entity Family Member.name
  • 4.01 Subject Entity Family Member.relationshipTypeCode
  • 4.01 Subject Entity Family Member.deceasedInd
  • 4.01 Subject Entity Family Member.postalAddress
  • 4.01 Subject Entity Family Member.identifier
  • 4.01 Subject Entity Family Member.spokenLanguage
  • 4.01 Subject Entity Family Member.telecommunicationAddress
  • 4.01 Subject Entity Family Member.sex
  • 4.01 Subject Entity Family Member.deathDateTime

 

 


Class: 4.04 Smoking History

Information about the mother's tobacco smoking experience during and before pregnancy.

Relationships:

         Each Smoking History always pertains to one Mother.

         Each Mother sometimes has one or more Smoking History.

Native Attributes:

         measurementPeriod

A coded indication of the period(s) before and during pregnancy within which the mother smoked cigarettes.

Datatype: CD 

DCF Cross-References:

  • FDeath (31a) - Cigarette Smoking Before and During Pregnancy
  • LBirth (37a) - Cigarette Smoking Before and During Pregnancy
  • MWork (15a) - Number of Cigarettes

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         smokingQuantity

The average number of cigarettes or cigarette packs (as indicated by the smoking unit) smoked during the period of interest.

Datatype: PQ 

DCF Cross-References:

  • FDeath (31b) - Cigarette Smoking Before and During Pregnancy
  • LBirth (37b) - Cigarette Smoking Before and During Pregnancy
  • MWork (15) - Number of Packets

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 


Class: 4.05 Father

A father is a type of parent; he is the male parent.

Relationships:

         Each Father always is a type of Parent.

         Each Parent sometimes is of type Father.

         Each Father sometimes is involved in one or more Pregnancy.

         Each Pregnancy sometimes involves one Father.

Native Attributes:

  • None

 

Inherited Attributes:

  • 4.02 Parent.birthDate
  • 4.02 Parent.birthPlace
  • 4.02 Parent.educationLevel
  • 4.02 Parent.ethnicityCode
  • 4.02 Parent.race
  • 4.02 Parent.socialSecurityNumber
  • 4.01 Subject Entity Family Member.name
  • 4.01 Subject Entity Family Member.relationshipTypeCode
  • 4.01 Subject Entity Family Member.deceasedInd
  • 4.01 Subject Entity Family Member.postalAddress
  • 4.01 Subject Entity Family Member.identifier
  • 4.01 Subject Entity Family Member.spokenLanguage
  • 4.01 Subject Entity Family Member.telecommunicationAddress
  • 4.01 Subject Entity Family Member.sex
  • 4.01 Subject Entity Family Member.deathDateTime

 


Class: 4.06 Spouse

A spouse is a type of subject entity family member. It is the type that is in a marital relationship with the subject entity.

Relationships:

         Each Spouse always is a type of Subject Entity Family Member.

         Each Subject Entity Family Member sometimes is of type Spouse.

Native Attributes:

  • None

 

Inherited Attributes:

  • 4.01 Subject Entity Family Member.name
  • 4.01 Subject Entity Family Member.relationshipTypeCode
  • 4.01 Subject Entity Family Member.deceasedInd
  • 4.01 Subject Entity Family Member.postalAddress
  • 4.01 Subject Entity Family Member.identifier
  • 4.01 Subject Entity Family Member.spokenLanguage
  • 4.01 Subject Entity Family Member.telecommunicationAddress
  • 4.01 Subject Entity Family Member.sex
  • 4.01 Subject Entity Family Member.deathDateTime
  •  

 


Subject Area: 05.0 Pregnancy and Delivery

The pregnancy and delivery subject area contains the classes pertaining to a pregnancy and its associated delivery events.

 


Class: 5.01 Pregnancy

Pregnancy is treated as a component of the delivery process.  It includes information on the mother's experience within the period between conception and delivery.

Relationships:

         Each Pregnancy always involves one Mother.

         Each Mother sometimes is involved in one or more Pregnancy.

         Each Pregnancy sometimes involves one Father.

         Each Father sometimes is involved in one or more Pregnancy.

         Each Pregnancy sometimes has one or more Pregnancy Risk Factor.

         Each Pregnancy Risk Factor always pertains to one Pregnancy.

         Each Pregnancy sometimes has one or more Infection During Pregnancy.

         Each Infection During Pregnancy always pertains to one Pregnancy.

         Each Pregnancy sometimes includes one or more Delivery.

         Each Delivery is part of one Pregnancy.

Native Attributes:

         paternityAcknowledgedIndicator

A Boolean indicator that states whether a paternity acknowledgment form has been completed for infants born to unmarried mothers.

Datatype: BL 

DCF Cross-References:

  • LBirth (15b) - Has Paternity Acknowledgement Been Signed in The Hospital?
  • MWork (16b) – A Paternity Acknowledgement Has Been Completed

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         firstPrenatalVisitDate

The date of the first prenatal care visit.

Datatype: TS 

DCF Cross-References:

  • FDeath (23a) - Date of First Prenatal Care Visit
  • FWork (06) - Date of First Prenatal Care Visit
  • LBirth (29a) - Date of First Prenatal Care Visit

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         lastLiveBirthDate

The date of the mother's last live birth before this pregnancy.

Datatype: TS 

DCF Cross-References:

  • FWork (11) - Date of Last Live Birth

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         noMaternalMorbidityIndicator

A Boolean indicator that states whether any maternal morbidity was recorded.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         lastNormalMensesDate

The date of the woman's last normal menstrual period.

Datatype: TS 

DCF Cross-References:

  • FDeath (32) - Date Last Normal Menses Began
  • FWork (08) - Date last normal menses began
  • LBirth (39) - Date Last Normal Menses Began

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         marriedDuringPregnancyIndicator

A Boolean indicator that states whether the mother was married during the period between conception and birth.

Datatype: BL 

DCF Cross-References:

  • FDeath (22) - Mother Married
  • LBirth (15a) - Mother Married?
  • MWork (18) - Mother Married during pregnancy

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         prePregnancyWeight

The mother's weight prior to becoming pregnant.

Datatype: PQ 

DCF Cross-References:

  • FDeath (26) - Mother's PrePregnancy Weight
  • LBirth (32) - Mother's PrePregnancy Weight
  • MWork (14) - Mother's Pre-pregnancy Weight

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         priorPregnancyOutcomes

The count of pregnancy outcomes prior to the current pregnancy. This includes fetal losses of any gestational age. If there were multiple deliveries, all live births and fetal losses delivered before this pregnancy should be included in the count of outcomes.

.

Datatype: INT 

DCF Cross-References:

  • FDeath (30) - Number of Other Pregnancy Outcomes
  • FDeath (30a) - Other Outcomes
  • FWork (12) - Number of Other Pregnancy Outcomes
  • LBirth (36) - Number of Other Pregnancy Outcomes
  • LBirth (36a) - Number of Other Pregnancy Outcomes

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         lastPregnancyNonLiveBirthOutcomeDate

The date on which the mother's last pregnancy that did not result in a live birth ended.

Datatype: TS 

DCF Cross-References:

  • FDeath (30b) - Date of last other pregnancy outcome
  • FWork (13) - Date of Last other Pregnancy Outcome

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         laborOnsetCode

A coded indication that characterizes the way labor commenced.

Datatype: CD 

DCF Cross-References:

  • LBirth (44) - Onset of Labor

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         lastPrenatalVisitDate

The date of the last (most recent) prenatal care visit.

Datatype: TS 

DCF Cross-References:

  • FDeath (23b) - Date of Last Prenatal Care Visit
  • LBirth (29b) - Date of Last Prenatal Care Visit

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         plurality

The number of live births and fetal deaths resulting from the pregnancy.

Datatype: INT 

DCF Cross-References:

  • FDeath (33) - Plurality - Single, Twin, Triplet, etc.
  • FWork (33) - Plurality
  • LBirth (52) - Plurality

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         noPregnancyRiskFactorIndicator

A Boolean indicator that states whether the mother was reported to have any of the pregnancy risk factors listed within the Risk Factors concept domain.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         noPrenatalVisitsIndicator

A Boolean indicator that is used to state whether the woman received no prenatal care during her pregnancy.

Datatype: BL 

DCF Cross-References:

  • FWork (06a) - No Prenatal care indicator

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         liveBirths

The number of live births resulting from the pregnancy.

Datatype: INT 

DCF Cross-References:

  • FWork (35) - Number of Live Births

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         prenatalVisits

The total number of visits recorded in the record.

A prenatal visit is one in which the physician or other health care professional examines or counsels the pregnant woman for her pregnancy

Do not include visits for laboratory and other testing in which a physician or health care professional did not examine or counsel the pregnant woman.

Datatype: INT 

DCF Cross-References:

  • FDeath (24) - Total Number of Prenatal Visits for This Pregnancy
  • FWork (07) - Total number of Prenatal care visits for this pregnancy
  • LBirth (30) - Total Number of Prenatal Visits for This Pregnancy

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         priorCesareanDeliveries

The number of previous cesarean deliveries experienced by the mother.

Datatype: INT 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         priorLiveBirthsNowDeceased

The number of children born in previous pregnancies who are now dead.

Datatype: INT 

DCF Cross-References:

  • FDeath (29b) - Number of Previous Live Births Now Dead
  • FWork (10) - Number of Previous Live Births Now Dead
  • LBirth (35b) - Number of Previous Live Births Now Dead

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         plannedHomeDeliveryIndicator

A Boolean indicator stating whether the mother planned to give birth at home.

Datatype: BL 

DCF Cross-References:

  • FWork (5) - Place Where Birth Occurred

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         priorLiveBirthsNowLiving

The number of children born to previous pregnancies who are now living.

Datatype: INT 

DCF Cross-References:

  • FDeath (29a) - Number of Previous Live Births Now Living
  • FWork (09) - Number of Previous Live Births Now Living
  • LBirth (35a) - Number of Previous Live Births Now Living

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         noPregnancyInfectionsIndicator

A Boolean indicator that states whether the mother was diagnosed with or treated for any of the infections listed within the Infections concept domain.

Datatype: BL 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         fetalDeaths

The number of fetal deaths resulting from this and any prior pregnancies for the same mother.

Datatype: INT 

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None


Class: 5.02 Pregnancy Risk Factor

Information about whether various types of infection relevant to pregnancy were present or treated during pregnancy. Following the conventions of vital statistics reporting, each recognized type of infection is captured as a risk factor type code value, and whether it is present during the delivery process is indicated by the value of the risk factor indicator.

Relationships:

         Each Pregnancy Risk Factor always pertains to one Pregnancy.

         Each Pregnancy sometimes has one or more Pregnancy Risk Factor.

Native Attributes:

         riskFactorType

A coded indication of a risk factor that was present during this pregnancy.

Datatype: CD 

DCF Cross-References:

  • FDeath (36) - Risk Factors in This Pregnancy
  • FWork (14b) - Risk Factors in the Pregnancy Type
  • LBirth (41) - Risk Factors in This Pregnancy
  • MWork (12) - Infertility Treatments

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

 


Class: 5.03 Infection During Pregnancy

Information about whether various known infections which may have been present and/or treated during the mother's pregnancy. Following the conventions of vital statistics reporting, each recognized infection type is captured as a type code value, and whether it is present during the delivery process is indicated by the value of the infection indicator.

Relationships:

         Each Infection During Pregnancy always pertains to one Pregnancy.

         Each Pregnancy sometimes has one or more Infection During Pregnancy.

Native Attributes:

         infectionIndicator

A Boolean indicator that states whether the mother experienced an infection during pregnancy as indicated by the type code value.

Datatype: BL 

DCF Cross-References:

  • FDeath (37) - Infections Present And/or Treated During This Pregnancy
  • FWork (15a) - Infections during this Pregnancy

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         infectionType

A coded indication of an infection that might be present during pregnancy. Note, either a description or a type code value must be provided.

Datatype: CD 

DCF Cross-References:

  • FDeath (37) - Infections Present and/or Treated During This Pregnancy
  • FWork (15a) - Infections during this Pregnancy Type

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 


Class: 5.04 Delivery

Information collected for a single delivery.

Relationships:

         Each Delivery is part of one Pregnancy.

         Each Pregnancy sometimes includes one or more Delivery.

         Each Delivery sometimes involves one Labor and Delivery Encounter.

         Each Labor and Delivery Encounter sometimes is involved in one or more Delivery.

         Each Delivery sometimes includes one or more Delivery Characteristic.

         Each Delivery Characteristic always is part of one Delivery.

         Each Delivery is sometimes of type Live Birth Event.

         Each Live Birth Event always is a type of Delivery.

         Each Delivery is sometimes of type Fetus Delivery.

         Each Fetus Delivery is a type of Delivery.

Native Attributes:

         deliveryRoute

A coded indication of the final route of delivery of the newborn.

Datatype: CD 

DCF Cross-References:

  • FWork (27d) - Final Route and Delivery Method
  • LBirth (46d1) - Final route of delivery

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         deliveryMethod

A coded indication of the physical process by which the complete delivery of the fetus was affected.

Datatype: CD 

DCF Cross-References:

  • FDeath (38) - Method of Delivery
  • FWork (27) - Method of Delivery
  • LBirth (46d2) - Final method of delivery

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         fetalPresentation

A coded indication of the position of the fetus at birth.

Datatype: CD 

DCF Cross-References:

  • FWork (27c) - Fetal Presentation at Birth
  • LBirth (46c) - Fetal presentation at birth

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         deliverySequence

The element will only be valued in the case of multiple deliveries. The order that the fetus was delivered in the pregnancy. The value should include all live births and fetal losses resulting from the pregnancy.

Datatype: INT 

DCF Cross-References:

  • FDeath (34) - If Not Single Birth
  • FWork (34) - Birth Order
  • LBirth (53) - If Not Single Birth

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         deliveryDateTime

The date at which the delivery took place.

Datatype: TS 

DCF Cross-References:

  • FDeath (02) - Time of Delivery
  • FDeath (04) - Date of Delivery
  • FWork (17) - Birth Date
  • FWork (18) - Birth Time
  • LBirth (02) - Time of Birth
  • LBirth (04) - Date of Birth

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         maternalDeliveryWeight

The weight of the mother at the time of delivery.

Datatype: PQ 

DCF Cross-References:

  • FDeath (27) - Mother's Weight at Delivery
  • FWork (25) - Mother's weight at Delivery
  • LBirth (33) - Mother's Weight at Delivery

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         unsuccessfulForcepsDeliveryIndicator

A Boolean indicator that shows whether there was an unsuccessful forceps delivery.

Datatype: BL 

DCF Cross-References:

  • LBirth (46a) - Was delivery with forceps attempted but unsuccessful?

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         unsuccessfulVacuumExtractionIndicator

A Boolean indicator that shows whether there was an unsuccessful attempt to deliver the baby using vacuum extraction.

Datatype: BL 

DCF Cross-References:

  • LBirth (46b) - Was delivery with vacuum extraction attempted but unsuccessful?

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None


Class: 5.05 Delivery Characteristic

A record of possible diagnoses, procedures, or occurrences that took place during the process of labor and delivery. Following the conventions of vital statistics reporting, each recognized labor and delivery characteristic is captured as a type code value, and whether it is present during the delivery process is indicated by the value of the indicator.

Relationships:

         Each Delivery Characteristic always is part of one Delivery.

         Each Delivery sometimes includes one or more Delivery Characteristic.

Native Attributes:

         deliveryCharacteristicIndicator

A Boolean indicator that states whether the mother experienced a labor and delivery characteristic as indicated by the type code value.

Datatype: BL 

DCF Cross-References:

  • FWork (26) - Characteristics of Labor and Delivery
  • LBirth (45) - Characteristics of Labor and Delivery

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         deliveryCharacteristicType

A type of diagnosis, procedure, or occurrence that could take place during the process of labor and delivery.

Datatype: CD 

DCF Cross-References:

  • FWork (26) - Characteristics of Labor and Delivery
  • LBirth (45) - Characteristics of Labor and Delivery

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 


Class: 5.06 Fetus Delivery

Information collected for each individual fetus delivery whether occurring in a single or multiple gestation pregnancy.

Relationships:

         Each Fetus Delivery is a type of Delivery.

         Each Delivery is sometimes of type Fetus Delivery.

         Each Fetus Delivery always involves one Fetus.

         Each Fetus is always involved in one Fetus Delivery.

Native Attributes:

  • None

 

Inherited Attributes:

  • 5.04 Delivery.deliveryDateTime
  • 5.04 Delivery.deliveryMethod
  • 5.04 Delivery.deliveryRoute
  • 5.04 Delivery.deliverySequence
  • 5.04 Delivery.fetalPresentation
  • 5.04 Delivery.maternaldeliveryWeight
  • 5.04 Delivery.unsuccessfulForcepsDeliveryIndicator
  • 5.04 Delivery.unsuccessfulVacuumExtractionIndicator

 

 


Subject Area: 06.0 Labor and Delivery Encounter

The labor and delivery subject area contains the classes pertaining to a patient encounter involving labor and potential delivery of a subject entity (newborn or fetus).

 

 


Class: 6.01 Labor and Delivery Encounter

Information about the encounter involving a labor and delivery component of the birth process.

Relationships:

         Each Labor and Delivery Encounter always involves one Mother .

         Each Mother sometimes is involved in one or more Labor and Delivery Encounter .

         Each Labor and Delivery Encounter sometimes is involved in one or more Delivery.

         Each Delivery sometimes involves one Labor and Delivery Encounter .

         Each Labor and Delivery Encounter sometimes includes one or more Maternal Morbidity.

         Each Maternal Morbidity always is part of one Labor and Delivery Encounter.

         Labor and Delivery Encounter sometimes includes one or more Encounter Event.

         Each Encounter Event always is part of one Labor and Delivery Encounter.

         Each Labor and Delivery Encounter sometimes includes one or more Obstetric Procedure.

         Each Obstetric Procedure always is part of one Labor and Delivery Encounter.

Native Attributes:

         motherTransferredFromDescription

A text description of, or name for, the facility the mother was transferred from.

Datatype: ST 

DCF Cross-References:

  • FDeath (35b) - Name of Facility Mother Transferred From
  • FWork (23b) - Mother Transferred for Maternal Medical or Fetal Indications for Delivery
  • LBirth (28b) - If Yes, Enter Name of Facility Mother Transferred From

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         motherTransferredFromIndicator

A Boolean indicator that shows whether the mother was transferred to the delivery site from another facility.

Datatype: BL 

DCF Cross-References:

  • FDeath (35a) - Mother Transferred for Maternal Medical or Fetal Indications for Delivery?
  • FWork (23a) - Mother Transferred for Maternal Medical or Fetal Indications for Delivery
  • LBirth (28a) - Mother Transferred for Maternal Medical or Fetal Indications for Delivery

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         noObstetricProcedureIndicator

A Boolean indicator that states whether any of the obstetric procedures listed within the Obstetric Procedures concept domain was performed on the mother during this pregnancy.

Datatype: BL 

DCF Cross-References:

  • FWork (16) - Obstetric Procedures

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         paymentSource

A coded indication of the source of payment for the costs of labor and delivery. This is an indication of the type of insurance coverage for the mother and baby.

Datatype: CD 

DCF Cross-References:

  • FWork (21) - Delivery Payment
  • LBirth (38) - Principal Source of Payment for This Delivery

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         newbornTransferredToDescription

A text name of the facility that the newborn was transferred to.

Datatype: ST 

DCF Cross-References:

  • LBirth (56b) - Was Infant Transferred Within 24 Hours of Delivery? If Yes, Name of Facility Infant Transferred To

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         newbornTransferredToIndicator

A Boolean indicator that shows whether the infant was transferred from the birth site to another facility within 24 hours of delivery.

Datatype: BL 

DCF Cross-References:

  • LBirth (56a) - Was Infant Transferred Within 24 Hours of Delivery?

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

 


Class: 6.02 Maternal Morbidity

Complications affecting the mother associated with labor and delivery. Following the conventions of vital statistics reporting, each recognized morbidity is captured as a type code value, and whether it is present during the delivery process is indicated by the value of the morbidity indicator.   If no morbidity is present, this will be explicitly indicated.

Relationships:

         Each Maternal Morbidity always is part of one Labor and Delivery Encounter.

         Each Labor and Delivery Encounter sometimes includes one or more Maternal Morbidity.

Native Attributes:

         morbidityType

A coded indication of a type of disease or condition experienced by the mother during her pregnancy.

Datatype: CD 

DCF Cross-References:

  • FDeath (39) - Maternal Morbidity
  • FWork (28) - Maternal Morbidity
  • LBirth (47) - Maternal Morbidity

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

 


Class: 6.03 Encounter Event

Information about administrative events that may have happen during the period of a labor and delivery encounter.

Relationships:

         Each Encounter Event always is part of one Labor and Delivery Encounter.

         Labor and Delivery Encounter sometimes includes one or more Encounter Event.

Native Attributes:

         attemptedTrialOfLaborIndicator

A Boolean indicator that states, in the case of a cesarean delivery, whether a trial of labor was attempted.

Datatype: BL [0..1]

DCF Cross-References:

  • LBirth (46d3) - Was a trial of labor attempted?

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         birthCertificateID

The number identifying the birth certificate.

Datatype: II

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         hysterectomyIndicator

A Boolean indicator that states whether a hysterectomy has been performed.

Datatype: BL 

DCF Cross-References: 

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         newbornBreastfedAtDischargeIndicator

A Boolean indicator stating whether the infant is being breastfed at discharge.

Datatype: BL 

DCF Cross-References:

  • LBirth (58) - Is the Infant Being Breastfed at Discharge?

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         newbornSSNRequestedIndicator

A Boolean indicator stating whether assignment of a social security number is being requested for the child.

Datatype: BL 

DCF Cross-References:

  • LBirth (16) - Social Security Number Requested
  • MWork (26a) - Newborn SSN Request

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         newbornSSNRequesterAuthenticated

A text block with the name of person requesting assignment of the social security number.

Datatype: ST 

DCF Cross-References:

  • MWork (26b) - Parent Signature

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         newbornSSNRequestDate

The date on which the request for social security number was signed.

Datatype: TS 

DCF Cross-References:

  • MWork (26c) - Parent's Signature Date

HIE Cross-References:

  • None

Terminology Bindings:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 

 


Class: 6.04 Obstetric Procedure

Information about whether specified obstetric procedures were undertaken during the labor and delivery process. Following the conventions of vital statistics reporting, each recognized obstetric procedure is captured as a type code value, and whether it is present during the delivery process is indicated by the value of the morbidity indicator.  If no procedure has been performed, this will be explicitly indicated.

Relationships:

         Each Obstetric Procedure always is part of one Labor and Delivery Encounter.

         Each Labor and Delivery Encounter includes one or more Obstetric Procedure.

Native Attributes:

         effectiveDate

The date the obstetric procedure took place.

Datatype: DT

DCF Cross-References:

  • None

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         procedureIndicator

A Boolean indicator that states whether the obstetric procedure was undertaken as indicated by the type code value.

Datatype: BL 

DCF Cross-References:

  • LBirth (43) - Obstetric Procedures

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

         procedureTypeCode

A type of obstetric procedure that might be performed during the labor and delivery process.

Datatype: CD 

DCF Cross-References:

  • LBirth (43) - Obstetric Procedures

HIE Cross-References:

  • None

Terminology Bindings:

  • None

 

Inherited Attributes:

  • None

 


Coded Element Value Sets

Coded attributes in the VR DAM, those with a datatype of CD, require a specification of their allowable code values. The terminologies bound to these coded attributes are based upon harmonization of terminology bindings present within the health information exchange standard(s) to which the attribute is cross referenced. Terminology bindings are only specified for coded attributes which include information exchange standard cross-references. Terminology bindings are expressed as code system name and mnemonic for code system bindings, code value, preferred concept name, and code system mnemonic for code system terms, and value set name and value set OID or URL for value sets. The table below list the value sets bound to attributes in the VR DAM R4.

Value Set Code

Value Set OID

PHVS_CauseOfDeath_ICD-10_CDC

2.16.840.1.114222.4.11.3593

PHVS_CertifierTypes_NCHS

2.16.840.1.114222.4.11.6001

PHVS_MaritalStatus_NCHS

2.16.840.1.114222.4.11.7380

PHVS_CauseOfDeath_ICD-10_CDC

2.16.840.1.114222.4.11.3593

PHVS_ContributoryTobaccoUse_NCHS

2.16.840.1.114222.4.11.6004

PHVS_DecedentEducationLevel_NCHS

2.16.840.1.114222.4.11.7385

PHVS_Ethnicity_CDC

2.16.840.1.114222.4.11.877

PHVS_Industry_CDC_Census2010

2.16.840.1.114222.4.11.7187

PHVS_MannerOfDeath_NCHS

2.16.840.1.114222.4.11.6002

PHVS_MethodsOfDisposition_NCHS

2.16.840.1.114222.4.11.7379

PHVS_Occupation_CDC_Census2010

2.16.840.1.114222.4.11.7186

PHVS_PlaceOfDeath_NCHS

2.16.840.1.114222.4.11.7216

PHVS_PlaceOfInjury_NCHS

2.16.840.1.114222.4.11.7374

PHVS_PregnancyStatus_NCHS

2.16.840.1.114222.4.11.6003

PHVS_Race_CDC

2.16.840.1.114222.4.11.876

PHVS_Sex_MFU

2.16.840.1.114222.4.11.1038

PHVS_TransportationRelationships_NCHS

2.16.840.1.114222.4.11.6005

PHVS_YesNoNotApplicable_NCHS

2.16.840.1.114222.4.11.7486

PHVS_YesNoUnknown_CDC

2.16.840.1.114222.4.11.888

v2 Contact Role

http://hl7.org/fhir/ValueSet/v2-0131

PHVS_YesNoNotApplicable_NCHS

2.16.840.1.114222.4.11.7486

V ital Records Domain Analysis Model - Behavioral Viewpoint

The VR DAM R4 behavioral viewpoint details the activities that create and consume the vital records data content.

Scope of the VR DAM

The following activity diagram depicts the major flows of information between the primary stakeholders of the vital records domain. The relevant information flows are:

  1. Provider to local jurisdictional Vital Records Office
  2. Provider to jurisdictional Vital Records Office (1 of the 57)
  3. Local jurisdictional Vital Records Office to Jurisdictional Vital Records Office (1 of the 57)
  4. Jurisdictional Vital Records Office (1 of the 57) to NCHS
  5. NCHS to jurisdictional Vital Record Office (1 of the57)

The scope of the VR DAM includes the receipt of vital records reports by 1 of the 57 jurisdictional Vital Records Offices directly from providers or indirectly by way of local jurisdictional Vital Records Offices and the reporting of vital record events by 1 of the 57 jurisdictional Vital Records Office to the National Center for Health Statistics.

 

VR DAM R4 Use Cases

1.0 Vital Records Event Reporting

Vital record event reporting and registration encompasses the provider reporting of vital record events to local or jurisdictional vital record offices; reporting from local vital records offices to jurisdictional offices, and the reporting from jurisdictional vital record offices to the National Center for Health Statistics. ​   In addition, NCHS returns coded cause of death and coded race and ethnicity back to the jurisdictional Vital Records Office.

Details concerning the vital record event are registered in a database by the receiving vital records office. Vital record events included within the scope of this DAM are person deaths, newborn births, and fetal deaths.

2.0 Disposition of Remains

Disposition of remains encompasses release of the decedent’s body for disposition once the cause of death has been determined to the satisfaction of the competent authority and the attainment of any necessary permits in accordance with jurisdictional requirements.

3.0 Event Record Management

Event record management encompasses the maintenance of a vital records registry by the vital records office. Maintenance includes acceptance and application of amendments and corrections to event reports, responding to request for event certifications.

4.0 Vital Records Statistical Analysis

Vital records statistical analysis encompasses the reporting and national vital records office calculation of relevant statistical measures and sharing of vital records data with other agencies. Statistics are multidimensional measure of vital record events.

VR DAM R4 Use Case Actors

Actors Families

The use case actors used within the VR DAM have been grouped into three “families” of actors: affected parties, providers, and government agencies. Each actor family is a single actor hierarchy. The hierarchy of actors is arranged from the general to the specific. Higher level actors in the generalization hierarchy are surrogates for all their more specific specializations.

  • Affected parties

The affected parties’ family of actors includes the entities that are the subject of the vital records event (newborns, fetus, and decedent) and related parties (family members and other related parties). The hierarchy of actor types in the affected parties’ family of actors is depicted in the following diagram:

  • Providers

The provider actor family of actors includes the entities that are the providers of services on behalf of the affected parties. These services include administrative, professional, and clinical services. Providers include organizations such medical facilities, funeral homes, and birthing facilities. Providers also include provider individuals such as clinicians, funeral directors, and medical examiners.

The full hierarchy of provider actors is depicted in the following diagram:


  • Government Agencies

The government agencies family of actors includes the governmental entities responsible for the collection, reporting, and statistical analysis of vital records events. They include vital record offices and other governmental agencies such as the social security administration. The hierarchy of vital record offices is divided into reporting vital records offices (local and jurisdictional) and the national vital records office, the National Center for Health Statistics.

The full hierarchy of government agency actors is depicted in the following diagram:


Use Case Primary and Secondary Actors

Each use case has one or more participating actor. When a use case involves more than one participating actor, one or more actor is designated as primary and the remaining actors are designated as supporting or secondary. The concept of the “primary” actors is borrowed from the writings of Alistair Cockburn in his book “ Writing Effective Use Cases ”. Cockburn defines the primary actor of a use case as follows:

“The primary actor of a use case is the stakeholder that calls upon the system to deliver one of its services. The primary actor has a goal with respect to the system, one that can be satisfied by its operation. The primary actor is often, but not always, the actor who triggers the use case.”

Each leaf level use case has one primary actor and zero, one, or more secondary actors. The following table designates which actors participate in which use case and the primacy of the actor as primary ( ) or secondary (S). For this purpose of this specification the designation of primary actor influences where the activity appears in actor designated swim lanes and is typically the actor that triggers, initiates, or fulfills the activities described in the use case.


VR DAM R4 Use Case Activities

1 .0 Event Registration

 

1 .1 Labor and Delivery

 

 

Figure 1:     Labor and Delivery

1.1.1 Conception

The logical point of initiation for the model is the conception of a fetus.

  1.1.2 Labor and Delivery

Within the US, most births occur in birthing facilities, which are either hospitals or freestanding birthing centers. Recording and submission of a birth record to the jurisdiction is the responsibility of the birthing facility where the event took place, even when the mother and/or baby are transferred to another facility immediately after the birth.

When a baby is delivered at home or en-route to a birthing facility, it is considered an out-of-facility birth. Home deliveries may be planned or unplanned. They are often attended by a nurse midwife, who would be responsible for recording the birth and reporting it to Vital Records. Births occurring en-route to a facility will usually be recorded and submitted to the Vital Records office within the jurisdiction by the facility where the mother is admitted after the birth. The birth of a foundling is usually reported by the hospital where the newborn is taken for medical care.


1.2 Death Event Registration

 

 

Figure 2:     Death Event Registration

1.2.1 Create/Update Funeral Home Case

Before a person's death can be registered, it is necessary to obtain the personal data that will be required for the death certificate, as well as the medical data provided by the certifying clinician, medical examiner or coroner. This is done by the funeral director or person acting as such who first assumes custody of the body.

The creation of a case allows the funeral home to manage the data for the decedent within a death registration application or through using some other method. As new information is obtained, or as changes need to be recorded, the case is updated. Once needed information is complete, the funeral director will provide the needed signature for the personal information.

In some jurisdictions, the funeral director will provide a notification of death to the vital statistics registry in advance of formally filing the death certificate.

1.2.2 Provide Decedent Information

On request from the funeral director, family members or other informed parties will provide the personal data that is needed for the death record.

1.2.3 Register Death Case

When the needed information has been assembled, the death registration is filed with the jurisdictional office of vital statistics. This will normally be done within 5 days after death or the finding of a dead body.


1.3 Birth Event Registration

 

 

Figure 3:     Register a Birth

1.3.1 Create/Update Birth Record for Live Birth

Information needed to officially record a live birth is defined by the U.S. Standard Certificate of Birth. The latest revision of the standard certificate was released in 2003, and most jurisdictions closely follow its format or are in transition to using the 2003 revision. Jurisdictions may add additional data items to their certificates. The collection of birth event data is required whether the birth takes place in a facility, at home (planned or unplanned), or en-route to a facility.

For births recorded by the birthing facility, information needed to complete the certificate is collected from the mother on the Mother’s Worksheet, and from the facility medical records, which should also include the mother’s prenatal care record obtained from the prenatal care provider prior to the birth. Generally, these data are collected on paper and entered into an electronic birth registration system (EBRS) by authorized personnel at the birthing facility. For an attended home delivery, the attendant (nurse midwife or other attendant) collects and reports these data to the jurisdiction. Usually reporting is paper-based, but some jurisdictions with web-based EBRS allow certified nurse midwives to become authorized users and report electronically.

Records may be voided if entered in error or modified by the facility until submitted to the jurisdiction for registration. In most jurisdictions, the birth records are electronically transmitted to the jurisdiction’s vital records administration for official recordation and registration. Some hospitals exclusively or additionally submit a paper record to a local registrar and/or to the jurisdiction, depending on state requirements. Once a birth has been registered by the jurisdiction, restrictions are usually placed on hospital access to the record, and any corrections must be submitted to the vital records office.

1.3.2 Create Declaration of Paternity

Information is collected from the declared father to be added to a birth certificate when the mother is not married to the father of the baby. (Also known as Paternity Acknowledgement, Acknowledgement of Paternity, etc.) Most birth hospitals attempt to process paternity at the time of the birth when possible, but paperwork may be submitted at any time. State statute governs the collection and incorporation of these data into the registered birth record. Most jurisdictions require the signature of both parents and a witness. Some jurisdictions require a court order of paternity after the birth has been registered. The mother may refuse to sign a declaration of paternity, in which case the presumptive father must pursue a court-based acknowledgement.

1.3.4 Create Delayed Birth Record

Each jurisdiction sets a time frame for the registration of a live birth, generally within one year of the event. If the registration of a live birth is delayed beyond the period defined by the jurisdiction's law, a request to register a delayed birth must be submitted. In addition to the required live birth information, additional documentary evidence must be submitted showing proof of residence, pregnancy and delivery. The delayed registration application is subject to acceptance and approval of the jurisdiction, and may be ordered by court. Delayed birth registrations are usually associated with unattended births, but may also be filed for hospital births that were not recorded in a timely matter due to omissions.

1.3.5 Create Foreign Born Adoption Record

The activity takes place to support the registering of a foreign-born child adopted by a U.S. citizen who is a resident of the registration jurisdiction. At least one parent must meet the citizenship and residency requirement. Registration of a foreign-born adoption does not acquire and is not proof of citizenship for the adopted child, and most jurisdictions mark this condition on the issued birth certificate.

1.3.6 Register a Birth

Each jurisdiction’s registrar officially registers all live and delayed birth records submitted by a birthing facility, out of institution birth attendant (or by the mother), or delayed birth applicant. The process of registration involves reviewing each record for accuracy and completeness and assigning a state or other jurisdiction file number (SFN) and filing date to each record. Jurisdictions use specific SFN formats for live births. Delayed births are numbered in sequence within the year of birth. Registration creates an officially recorded birth which may not be changed unless formally amended per jurisdiction law or by rules or policies set forth by the Vital Registrar’s Office.


1.4 Fetal Death Event Registration

 

 

Figure 4:     Fetal Death Registration

1.4.1 Create/Update Fetal Death Record

Hospitals in some jurisdictions report fetal deaths electronically. However, in most jurisdictions, the Report of Fetal Death is filled out and submitted to the vital records office on paper. If a fetal death occurs in a birthing facility, demographic information usually will be collected on a Patient Worksheet, like the Mother’s Worksheet used to record a live birth. Medical information is collected from the medical records and recorded on the Facility Worksheet. If a hospital uses an electronic fetal death system (EFDS), this information is entered into the EFDS by the facility and electronically submitted to the vital records office.

1.4.2 Register a Fetal Death Record

Once a record of Fetal Death has been filed with a jurisdiction’s vital records office, a state file number will be assigned to officially register the record. State statute sets the time limit for the filing of a fetal death after it is recorded. Jurisdictions that allow fetal deaths to be filed with a local office may also contain a local file number.  The state assigned file number is represented in the information model using the attribute VitalRecordsReport.fileNumber.  The local file number is represented in the information model by the attribute VitalRecordsReport.auxiliaryFileNumber.


2.0 Death Certification and Disposition of Remains

 


2 .1 Cause of Death Certification

 

 

Figure 5:     Cause of Death Certification

2.1.1 Death of a Person

The process of death registration starts with the death of a person.

2.1.2 Create/Update Medical Certifier Case

When a person dies, persons with legal authority to do so will pronounce death and record the time of death to the extent possible. These individuals may be the attending clinician, clinician last in attendance, medical examiner, coroner, or other persons with legal authority to pronounce death.

After a person dies, and the case has been recorded, the medical provider may initiate creation of a death certificate, or begin entering data on a death certificate that has no medical provider associated with it. If necessary, the certificate will be updated as new or changed information needs to be recorded.

2.1.3 Certify Cause of Death

When a person dies, the fact of death and its cause must be certified. The certification of cause of death is normally completed by attending clinician, clinician last in attendance, medical examiner, coroner, or other persons with legal authority to pronounce death. However, in some circumstances - which vary depending on the controlling jurisdiction - further inquiry will be required. In those situations, the body will be referred to the medical examiner or coroner who will provide the cause of death information.

2.1.4 Accept Death Case

Law in the controlling jurisdiction defines the circumstances under which a medical examiner or coroner will take control of a decedent's case to clearly determine the cause of death. In all jurisdictions, if the manner of the person's death is not due to natural causes, e.g., homicide, a further inquiry into the cause of death will be mandated. However, such an inquiry may be required for natural deaths depending on the circumstances and the applicable legislation.

The goal of the inquiry is to clearly determine the circumstances surrounding the death, and to definitively establish the cause(s) of death and especially the underlying cause(s) that led to death.


2.2 Decedent Remains Disposition

 

 

Figure 6:     Decedent Remains Disposition

2.2.1 Dispose of Decedent Remains

 

2.2.2 Issue Disposition Permit

Once the cause of death has been determined to the satisfaction of the competent authority (state, local or other jurisdictional type registrar), the body of the decedent can be released for disposition. For the disposition to take place, depending on the jurisdiction, it may be necessary to provide the necessary permits.

In those cases, in which determination of the cause of death is still underway, there may be a need for a permit (cremation approval) to allow cremation of the decedent's remains.


2.3 Cause of Fetal Death Certification

 

 

Figure 7:     Cause of Fetal Death Certification

2.3.1 Certify Cause of Fetal Death

The physician attending the mother during delivery must certify the cause of death of a fetus. If the fetus died because of a violent act, or in other specific circumstances defined by a jurisdiction, the cause must be determined and certified by the jurisdiction’s medical examiner or coroner.

2.3.2 Accepts Fetal Death Case

State law defines the circumstances under which a medical examiner or coroner will take control of a case to determine the cause of death. In all jurisdictions, if the manner of death is not due to natural causes, the fetal death case will be referred to the medical examiner or coroner to clearly determine the circumstances and to definitively establish the cause(s) of fetal death.


2.4 Fetal Remains Disposition

 

 

Figure 8:     Fetal Remains Disposition

2.4.1 Contact Funeral Home

If the hospital where a fetal death occurred is not disposing of the remains, a funeral home will be contacted at the request of the family to make the necessary arrangements.

2.4.2 Dispose of Remains

The clinical setting caring for the mother will record whether it, usually a hospital, is going to take responsibility for disposing of the remains of the fetus. In some cases, for example, that of miscarriage, disposition of remains may not be an issue.

2.4.3 Record Disposition of Fetal Remains

If a fetal death occurs in a facility and the hospital disposes of fetal remains, hospital staff must record the method of disposition of the fetal remains on the fetal death report: burial, cremation, donation, hospital disposition, or removal out of state.


3.0 Event Record Management

 


3 .1 Death Record Management

 

 

Figure 9:     Death Record Management

3.1.1 Medical Amendment

The death certificate may need to be filed before all the information needed to certify the cause or causes of death is available. In such cases, when more information becomes available, for example if toxicity reports have been received, it may be necessary to file a medical amendment to the death certificate. This process is likely to be followed whenever additional information is received which requires modification of the medical sections of the death record. This is more common among medical examiner/coroners.

3.1.2 Request Amendment to Registered Death

If needed, a family member of the decedent or another interested party may request an amendment to the death record to correct mistakes that appear on the record. Depending on the circumstances, the registrar may request judicial review of the request and/or judicial sanction for any changes.

3.1.3 Request Copy of Death Certificate

A record of the death certificate may be issued on request by to an authorized applicant as defined by statute. In such circumstances, it is common for funeral directors to request the copy on behalf of the family.

It is also possible for organizations involved in program activities or data analysis to request a copy of the certificate.

3.1.4 File/Manage Death Record

The registrar or Office of Vital Statistics of the pertinent jurisdiction, is responsible for receiving and filing the death certificate that records pertinent facts surrounding a person's death and for maintaining this information so that it can be made available for administrative, statistical and epidemiologic uses.

The organization of vital statistics registration varies across jurisdictions. In some cases, there is a single state or other jurisdictional office, while in other cases records can be filed with local registrars.

Maintenance of death records requires, among other activities, managing requests for records and mortality statistics and data files, the issuing of certified copies, and requests for amendments to the record.

3.1.5 Issue Certified Copy of Death Record

One responsibility of the jurisdictional Office of Vital Statistics is to issue death certificates when these are needed for such purposes as claiming life insurance payments and settling estates. Selling these certificates is often a significant source of revenue for carrying out vital statistics functions. The certified copy is provided to authorized applicants as defined by law.

3.1.6 Notify Birth Registry

When a person dies, and a death record is filed with the Vital Registries System, it is important that the Birth Registry be notified to allow proper synchronization of a person's birth and death records. This is particularly important when the death occurs shortly after birth.


3.2 Birth Record Management

 

 

Figure 10: Manage Birth Record

3.2.1 Submit Amendment to Registered Record

A registered vital record may be amended in accordance with individual state statute and the guidance issued under Section 21 of the Model State Vital Statistics Act and Regulations, also known as Model Law. Guidance for modifying a registered record is also found in MoVERS Use Case 06. Requests for modifications to a registered record may originate with the record holder, a family member with legitimate right to the record, the healthcare facility, or by an official court order. Amendments may only be processed by selected state vital records staff, and must be accompanied by adequate documented evidence of the basis for requesting the amendment. State registrars retain the right to reject an amendment request without sufficient evidence, even if that request comes from a court order.

All amended records must be flagged as amended within the vital records system and must include a complete audit trail of all amendment dates and identities of those processing the amendments. Multiple amendments may be made to a single record, and the system must retain a complete history of those amendments. Some birth records, such as adoptions, require the original record to be sealed once the amendment has been completed; generally, sealed records are not marked as amended when issued. Other types of birth record amendments, such as paternity acknowledgements, name changes, gender reassignments, and other modifications or additions to the demographic or medical portion of the record, follow individual statute in regards to issuance. Typically, non-sealed amended records, when issued as an abstract from an electronic record, show the word "amended" in the certificate title and may list the date(s) and amended items (new and old value) at the bottom of the certificate. When an amended record is issued from a copy of the original, it may show the old data lined through and the amended information above.

Amendments are to be differentiated from minor corrections or additions allowed to be requested to a record within a specific time after recordation without the record indicating that it has been amended. The governance over minor corrections and additions will vary per jurisdictional statute.

3.2.2 Request a Birth Record

A certified copy of the birth certificate may be requested by the person named on the certificate, an eligible family member, or another individual with a tangible interest in receiving a copy of the record, as defined by jurisdiction law. Most jurisdictions require proof of identity from an applicant requesting a birth record before providing a certified copy, as well as proof that the applicant is entitled to receive the record. In some jurisdictions, a non-certified copy of a record may be issued. Issued copies of birth certificates contain the legal portion of the record only. The medical portion of the birth record is never issued and is used for statistical purposes only.

3.2.3 File/Manage Birth Record

Once a birth has been registered, and a birth vital record created, this record must be stored and managed over time. The vital statistics administration in each jurisdiction is responsible for a) reporting to national statistics agencies, b) securely storing the record for an extended period, c) securely issuing certified copies to qualified requestors, d) recording any corrections and amendments to the record, e) sealing original records as required by statute, f) developing policies and procedures for data release for research and statistical use.

If an original birth record is sealed, the replacement record will retain the original certificate file number.

3.2.4 Issue Certified Copy of Birth Record

Each jurisdiction issues certified copies of birth certificates to authorized applicants as defined by statute. Only the jurisdiction in which the birth event was registered may issue a copy of the birth record. Certified birth records are needed to obtain a passport and a driver’s license as well as to prove citizenship and assure entry into school or the military, etc. Each jurisdiction sets fees for conducting a record search and issuing copies. Under certain circumstances, and when allowed by statute, a jurisdiction may issue a non-certified (informational) copy of a birth record.


3.3 Fetal Death Record Management

 

 

Figure 11: Fetal Death Record Management

3.3.1 Amend/Correct Medical Information

The fetal death report may need to be filed before all the information needed to certify the cause of fetal death is available. In such cases, when more information becomes available, for example if toxicity reports have been received, it may be necessary to amend the medical portion of the fetal death record. This process is likely to be followed whenever additional medical information is received from medical examiners/coroners.

3.3.2 Request Fetal Death Record Copy

Jurisdictions may be authorized in statute to issue a Report of Fetal Death in response to a request by a legitimate requestor.

3.3.3 File/Manage Fetal Death Record

Vital records offices in each jurisdiction are responsible for registering fetal deaths and maintaining this information electronically so that it can be made available for reporting and statistical uses. In fetal death cases referred to the medical examiner, a more definitive cause of death may be determined and added to the record after registration.

3.3.4 Issue Fetal Death Record Copy

Vital records offices may issue certified copies of fetal death records if allowed by statute, but this is not the general practice.


4.0 Records Analysis and Inter-Agency Data Sharing

 

 


4 .1 Vital Records Analysis

 

 

Figure 12: Event Data Analysis

4.1.1 Analyze Vital Event Data

Local, state and federal vital statistics organizations collect and disseminate vital statistics data for publication and research.

The National Center for Health Statistics (NCHS) is the federal entity responsible for the analysis and publication of national level vital statistics. NCHS receives information on birth vital events through transmissions from vital statistics offices for the controlling jurisdiction. Analytic functions are also carried out at state and local levels by the applicable vital statistics or public health agency.


4.2 Inter-Agency Information Sharing

 

 

Figure 13: Inter-Agency Information Sharing

4.2.1 Administer Social Security

In the United States, the Social Security Administration (SSA) provides identifiers for persons, and collects wage and salary information to provide income after retirement or injury. One aspect of this function is to verify the Social Security Number provided for the decedent. In addition, the SSA needs to receive information about a person's death to stop social security payments.

4.2.2 Program Activities

By formal agreement between a public health program and vital records, birth data may be used to populate other program databases, such as an immunization registry, or may be used for program outreach and intervention (as allowed by law). Jurisdictions may also provide birth data to other programs such as Medicaid for such purposes as establishing eligibility for coverage, or to Child Support Enforcement to obtain monetary support for the child.

It is expected that, in the future, there will be wider distribution of birth data to program activities such as newborn screening, newborn hearing and immunization records. Ideally, these data transfers will be automated based on the filing of the birth record.