An official website of the United States government
Modernization: Tools and Technologies
Together, we are harnessing the power of technology to modernize vital records systems.
What's New
Modernization: Tools and Technologies Together, we are harnessing the power of technology to modernize vital records systems.
This page is designed to help those working to modernize the National Vital Statistics System explore the main technologies involved in our projects.
The tools and technologies behind our modernization efforts serve these basic principles:
- Information Systems: Moving from paper-based processes to electronic records
- Data Quality and Interoperability: Adopting common tools and standards for data
- Prototypes and Testing: Describing new approaches and testing their application
An Electronic Death Registration System (EDRS) is a secure, web-based system for electronically registering deaths. An EDRS simplifies the data collection process and enhances communication between medical certifiers (medical examiners/coroners and health care providers), funeral directors, and local and state registrars as they work together to register deaths.
Benefits of EDRS:
- Web-based and securely accessible at any time and across multiple locations
- Can incorporate error-checking applications to improve data quality
- Enables users to complete the death registration process faster and with fewer errors
- Enables electronic processing of death certificate amendments
Technical Resources
Case management systems (CMS) provide medical examiners and coroners with capabilities for case management, including tracking death investigation workflow, task management, digital imaging, and other record keeping activities. Electronic, internet-enabled CMS can be enabled to introduce interoperability — the ability to send and receive data t using standardized protocols and standards — with other electronic systems, Fostering use of CMS to provide interoperability with electronic death registration systems will improve timeliness and quality of death records, and reduce the need for duplicative manual entry of information by medical examiners and coroners.
– The ability to access, exchange, integrate and use data in different systems in a coordinated manner.
Simply put, interoperability means getting systems to freely “speak the same language” so that information can be shared quickly and accurately between them. Within the health ecosystem, HIMSS defines interoperability as “the ability of different information systems, devices and applications (‘systems’) to access, exchange, integrate and cooperatively use data in a coordinated manner, within and across organizational, regional and national boundaries, to provide timely and seamless portability of information and optimize the health of individuals and populations globally.”
- Interoperability is complex and involves a multi-pronged approach to creating connection between and across systems, data flows, processes and organizations. Learn more about interoperability in health care/public health including definitions, the use of standards, relevant public policies, key US government initiatives and the levels of interoperability as defined by HIMSS.
- See other definitions on that page to learn about the tools we’re using to increase interoperability, such as APIs and HL7 FHIR.
– An open API (often referred to as a public API) is a publicly available application programming interface that provides developers with programmatic access to a proprietary software application or web service.
As electronic health information has become the norm, technologies like application programming interfaces (APIs) and API-based data standards such as FHIR are making data more accessible and easier to integrate with existing tools. An API is a set of requirements that governs how one application can communicate and interact with another. Open APIs allow the owner of a network-accessible service to give universal access to that service to consumers.
Technical resources:
– The standards being supported by NCHS to enable interoperability in vital statistics reporting.
HL7’s FHIR® (pronounced “fire”) standards enable health systems to communicate information using a common framework. Similar to the way the internet works, FHIRexternal icon standards help break complex health information into small, reusable parts that can be combined, disassembled, and recombined over and over again to meet a variety of information needs.
Benefits of FHIR:
- Offers a “language” that developers can read, understand, and start applying quickly-
- Easier developer experience – FHIR® and SMART implement RESTful APIs and OAuth2 just like most other APIs developers are familiar with.
- Allows resources developed by one organization to be leveraged by another
- Can deliver more “real-time” and automated data feeds
- Helps make the transition to high-capacity cloud and web-based technologies
- Easy and hassle-free integration and implementation
- Reduces the time-consuming document-based information exchange system and feeding in the information in direct into workflows
- There are many tools and services that are availabile to support the FHIR® standard. Development can be faster by using one of them like 1upHealth’s FHIR® API platform.( https://1up.health/docs/)
Technical Resources
– A standardized way for health apps to connect to electronic health records systems with appropriate security guarantees.
SMART (Substitutable Medical Applications and Reusable Technologies) on FHIR is an open, free and standards-based API to develop “iPhone-like apps” that can run anywhere in the healthcare system. With federal investmentpdf iconexternal icon, the SMART on FHIR API was developed as standard to enable specialist external applications (applets) to interact securely with the data in an electronic medical record system.
Technical resources:
- SMART on FHIR – Definition
- SMART App Gallery – Listing of open source apps that have been designed for use in health care and public health
GitHub is a platform lets developers host and review code, manage projects, and build software alongside 40 million others who use the site. GitHub provides version control while enabling collaboration, allowing people to work together on projects from anywhere in the world.
Many of our technology projects, including mortality data projects being developed with partners like GTRI and MITRE, are hosted on GitHub and are free to access and use. A list of GitHub links can be found in our Developers’ Corner on this page.
Guidance is available to help jurisdictions use FHIR resources to exchange vital records data. Recognizing that vital records reporting has its own set of challenges and requirements, these FHIR implementation guides are designed to facilitate the exchange of data between information systems in the vital records ecosystem.
Vital Records Death Reporting FHIR Implementation Guide (VRDR FHIR IG)
- The VRDR FHIR IG lays a foundation for the expansion of automated, standards-driven bidirectional information exchange between jurisdictional vital records offices, STEVE, and NCHS. Future expansions of the VRDR IG may include additional work flows, such as between EDRS and state based surveillance systems.
Medicolegal Death Investigation FHIR implementation guide (MDI FHIR IG)
- Guidance is available to help vital records office use FHIR resources to exchange death data with medical examiner and coroner offices. The MDI FHIR IG is designed to facilitate exchange of data between users of MDI data, including vital records offices. The MDI FHIR IG provides guidance and definitions for the of automated, standards-driven information exchange of MDI data.
Birth and Fetal Death Reporting FHIR Implementation Guide (BFDR FHIR IG)
- Coming Soon
VRDR Code Library
- The .NET library is (C#) code that can be used for producing and consuming the Vital Records Death Reporting (VRDR) Fast Healthcare Interoperability Resources (FHIR) standard. The code also includes support for converting VRDR FHIR records to and from the Inter-Jurisdictional Exchange (IJE) Mortality format, as well as companion microservice for performing conversions.
- Java library – This library is Java code that can be used for producing and consuming the Vital Records Death Reporting (VRDR) Fast Healthcare Interoperability Resources (FHIR) standard.
MDI Code Library
- Java library – This library is Java code that can be used for producing and consuming the Medicolegal Death Investigation Fast Healthcare Interoperability Resources (FHIR) standard.
- .NET – Coming soon
Validations and Interactive Edits Web Service (VIEWS) is a web service developed by the National Center for Health Statistics (NCHS) that can be used when data is entered into Electronic Death Registration Systems (EDRS). VIEWS checks entries and sends an alert when a piece of information is incorrect or unusual. VIEWS contains a mortality-focused spellchecker and also checks records for rare words, ambiguous abbreviations, rare causes of death, ill-defined terms, as well as cross-checking age and sex information with cause of death. VIEWS can also consult a surveillance list to identify and flag additional conditions of interest.
VIEWS web service provides real time medical validation feedback to EDRS systems. VIEWS will enable states to improve the quality of their cause-of-death information submitted to the Division of Vital Statistics (DVS) in NCHS, thereby improving the throughput rate of the DVS automated coding system and reducing DVS’s need for manual coders.
Technical resources: VIEWS Techinical User Information [PDF – 1 MB]
Nightingale is a prototype electronic death registration system (EDRS) built to both demonstrate basic EDRS capabilities and act as a foundation for exploring next generation EDRS concepts. Developed in partnership with MITRE, this prototype represents a work-in-progress and is expected to change and grow over time in response to feedback from subject matter experts and users.
Technical resources
Raven is an open-source, proof-of-concept platform that serves as a reference implementation and provides testing tools for interoperability between case management systems (CMS) and other external actors. The external actors are those data sources with which CMS need to communicate to exchange Medicolegal Death Investigation (MDI) data, and may include, but not be limited to, electronic death registration systems (EDRS) and forensic toxicology laboratory information management systems (LIMS).
The current Raven tooling and tests aid developers in implementing the MDI FHIR record format by validating FHIR messages against MDI IG guidelines and FHIR-based extended API operations. Detail documentation is available from https://ravendocs.readthedocs.io/. Raven app is a link to a online Raven app.
Canary is an open source testing framework that provides tests and tools to aid developers in implementing the Vital Records Death Reportingexternal icon (VRDR) FHIR death record format by validating FHIR messages for VRDR.
Technical resources
Interoperability partners IHE and HL7 regularly host “Connectathon” events that bring developers together with each other and with technology users to fine-tune product interoperability and “complete months of development in minutes.” These multi-day events offer unprecedented opportunities for real-time, hands-on problem solving around health information systems.
More information:
Note that this is only intended as a technical demonstration; no testing has been performed to determine potential impact on data quality.
This proof-of-concept application demonstrates a technical approach for allowing medical certifiers to report and certify to jurisdiction electronic death registration systems (EDRS) from a hospital setting. It uses SMART on FHIR to pull decedent information from hospital electronic health record (EHR) systems and FHIR profiles for mortality data to submit information to EDRS. Note that the version of the VRDR IG currently supported by Blackbird is not the most recent version of that standard.