Modernization: Tools and Technologies
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
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 HIMSSexternal icon.
- 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 interfacesexternal icon (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.
– 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 iconexternal 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 platformexternal icon.( https://1up.health/docs/external icon)
– 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 iconpdf 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.
The .NET libraryexternal icon 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 libraryexternal icon – 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.
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 icon[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.
This 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.
Canary is an open source testing framework that provides tests and tools to aid developers in implementing the Vital Records Death Reportingexternal iconexternal icon (VRDR) FHIR death record format by validating FHIR messages for VRDR.
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.
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.