Modernization: Tools and Technologies
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 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
- Electronic processing of death certificate amendments
Case management systems (CMS) are internet-enabled systems that provide Medical Examiners and Coroners with electronic capabilities for case management, including death investigation workflow, task management, digital imaging, chain-of-custody management, multiple death investigation, statistics and report development. Fostering widespread use of CMS and creating interoperability with electronic death registration systems (EDRS) is key to improving timeliness and quality of death records.
Simply put, interoperability means getting systems to “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.”
See other definitions on this page to learn about the tools we’re using to increase interoperability, such as APIs and FHIR.
- Learn more about the Four Levels of Interoperabilityexternal icon as defined by HIMSS.
As electronic health information has become the norm, technologies like application programming interfaceexternal icons (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.
- CDC Open Technology
- Death Data Hubexternal icon (GitHub Page from GTRI Team working on API Gateway for EDRS)
HL7’s FHIR® (“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 which 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
- 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
- FHIR Profiles for Interoperabilityexternal icon: FHIR Vital Records Death Reporting Implementation Guide
- Executive Summaryexternal icon
- Clinical Introductionexternal icon
- Interview with Grahame Grieve – Georgia Tech – Health Informatics in the Cloud (length 12:39 – introduction to FHIR)
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.
GitHubexternal icon 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 death data with NCHS. Recognizing that vital records death reporting has its own set of challenges and requirements, the Vital Records Death Reporting FHIR implementation guide (VRDR FHIR IG) is designed to facilitate bidirectional exchange of mortality data between vital records offices and NCHS.
The VRDR FHIR IG lays a foundation for the expansion of automated, standards-driven information exchange, including the flow of information from physicians, medical examiners, coroners, funeral directors, and family members to public health agencies and between public health agencies and secondary users of detailed mortality data and statistics.
Developed by MITRE, 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 library helps developers translate VRDR information into Nightingale.
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.
Validations and Interactive Edits Web Service (VIEWS) is an online service developed by 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 an “intelligent” 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.
Natural language processing (NLP) is a method for using computers to recognize and extract keywords and other important information from unstructured (narrative) text, such as that written in the literal text portion of the death certificate.
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.
This prototype app gives medical certifiers the ability to report and certify to jurisdiction electronic death registration systems (EDRS) from a hospital setting. It uses SMART on FHIRexternal icon to pull decedent information from hospital electronic health record (EHR) systems and FHIR profiles for mortality dataexternal icon to submit information to EDRS. This app is based on softwareexternal icon originally created as part of a collaboration between Georgia Tech and CDC.
Georgia Tech Research Institute is developing a Case Management System (CMS) reference implementation for cause-of-death certification. Using SMART on FHIRexternal icon, they are moving toward an enterprise-level application that can be launched from a FHIR-enabled CMS or electronic medical record and bring in needed information from different data sources to support cause-of-death certification by physicians and medical examiners/coroners.
The goal is to use FHIR to support the workflow between the CMS and EDRS. A dashboard app will read data from the FHIR server, display the information in death certificate format, convert it to the Vital Records Death Reporting (VRDR) format, and submit it to the EDRS.
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.
General Implementation Guidance
- Vital Records Death Reporting FHIR Implementation Guideexternal icon (VRDR FHIR IG – contains FHIR profiles for interoperability)
- GitHub Page for the Nightingale Projectexternal icon: Contains source code for work MITRE has been doing with NCHS
Tools for Implementing an EDRS
- Nightingaleexternal icon Electronic Death Registration System (EDRS) prototype
Using FHIR with EDRS
- Canary Testing Frameworkexternal icon for FHIR messaging validation with Electronic Death Registration Systems
- .NET libraryexternal icon of code for implementing VRDR in Nightingale
- Death Data Hubexternal icon: GitHub Page for GTRI Team working on API Gateway
Connecting EHR to EDRS
- Blackbird prototypeexternal icon for connecting Electronic Health Records to Electronic Death Registration systems
SMART on FHIR
- SMART Tech Stack for Health Apps (note approaches to authorization and authentication): http://docs.smarthealthit.org/external icon and https://github.com/smart-on-fhirexternal icon
Natural Language Processing