This presentation is intended to
help with getting started with
FHIR-based morality data
interoperability for the
National Vital Statistics
System. I'll provide a
high-level overview of some
of the concepts, approaches,
technologies, and tools that
support FHIR-based mortality
data interoperability. The
focus will be on the exchange of
mortality data between
jurisdictions and NCHS using
FHIR. We'll touch on a lot of
different topics but stay at a
high level on all of them.
Future presentations will drill
down in detail into specific
topics. There are also many
other opportunities to learn
more, such as weekly office
hours organized by NCHS, or the
technical-track events of the
NVSS community of practice.
We'll start by discussing a
high-level picture of the
overall goals and then we'll
dive into specific areas. These
start with the Vital Records
Death Reporting FHIR
Implementation Guide, and then
continue with FHIR messaging
for supporting the business
processes of VRDR record
exchange, the VRDR .NET and Java
libraries for implementation,
and the Canary testing tool.
We'll also discuss the value of
Connectathons and cover some of
the typical steps towards
interoperability. Let's start
with some of the general
concepts. The National Vital
Statistics System, or NVSS,
is the longest-running
intergovernmental public-health
data-sharing effort. Vital
records data are provided to
NCHS by federal registration
systems operated by the
jurisdictions that are legally
responsible for the registration
of vital events, such as births
and deaths. If we consider the
current state of mortality data
interoperability, we can look at
a few areas where data exchange
comes into play. Starting on the
left side of the diagram, there
are a lot of participants in the
ecosystem who are using existing
systems to manage the data. For
example, most medical examiners
use some type of case-management
system. If that case management
system is not directly connected
to the jurisdiction EDRS, then
double data entry is required
when registering a death with
the jurisdiction. Further to the
right of the diagram, you can
see data exchange with
surveillance systems like cancer
registries. In many cases, these
exchanges use ad hoc standards.
Finally, at the far right of the
diagram are the exchanges among
jurisdictions and between
jurisdictions at NCHS. These
exchanges at the moment make
use of IJE, which is the batch
format. There are a lot of
potential opportunities for
using FHIR for improving
mortality data exchange but it
doesn't make sense to try to
tackle all of them at once.
There are currently a few key
areas where use of FHIR is being
explored for data exchange.
On the left-hand side of the
diagram, you can see exchange
between case-management systems
and jurisdiction electronic
death registration systems. That
will be covered elsewhere. The
area of data exchange that I'll
be focusing on is between
jurisdictions and NCHS. One
thing that you'll note in this
diagram is the role of the State
and Territorial Exchange of
Vital Events System, or STEVE,
plays. STEVE 2.0 is currently
used for exchange of data
between jurisdictions and NCHS
and that is not expected to
change when moving to FHIR. This
diagram also includes a line
directly between the
jurisdictions and NCHS. NCHS
expects to provide a backup
capability for direct submission
to NCHS in addition to
submission through STEVE. You
may have heard of a health
standard called FHIR. FHIR
stands for Fast Healthcare
Interoperability Resources. Very
briefly, FHIR is a standard
for the electronic exchange of
health information. FHIR was
created by the Health Level
Seven, or HL7, International
standards organization. One of
the key benefits of FHIR is
that it uses standard data
representations that let health
information be reused in a lot
of different contexts. By
"standard data representations"
what I mean is that it makes
use of some common Internet
technologies like RESTful data
exchange and the JSON data
format, which many developers
are already familiar with. This
contrasts with other, prior HL7
standards that are more specific
to healthcare, as well as the
IJE standard, which is very
specific to vital records. FHIR
follows something called the
80/20 rule. The base standard
for FHIR covers about 80% of
health use cases. That's
intentional because those 80%
are common across many
scenarios. The remaining 20%
differ from scenario to
scenario. So FHIR was developed
to be extensible in a way
that allows each distinct data
exchange use case to be
supported by extending the base
FHIR standard. The Vital
Records Death Reporting FHIR
Implementation Guide, which
we'll touch on shortly, is
essentially that 20% extension
for the exchange of mortality
data. So why use FHIR for vital
records? Using FHIR provides a
few benefits. First, it
offers some opportunities for
standardization within vital
records. Using FHIR can support
reuse across different
workflows. There's a lot of
ongoing work on creating and
improving automated flow of data
both from EHR systems and from
medical examiner and coroner
case management systems. Those
automated flows reduce the
amount of manual data entry,
which improves both timeliness
and data quality. Using a
standard like FHIR means less
investment in custom data
feed development for those
activities. That should lead
to reduced implementation costs
over time because any
content-management system or EHR
that supports the FHIR standard
should be able to interoperate
with any EDRS that supports the
same standard. There are also
commonalities across different
vital records. So birth
reporting can share foundational
pieces with death reporting.
There are also some benefits at
the data level. It's just one
small example. Compared to IJE,
FHIR is not limited to a certain
number of characters for cause
of death. Using FHIR also
supports standardization against
non-vital record systems. The
common use of FHIR can lead to
possibilities for leveraging and
consuming EHR data for public
health and vitals reporting in
ways that haven't happened
before. FHIR also offers the
possibility of developing
standardized and consistent
approaches for data flows to
systems that make use of vitals
data -- for example, from state
vital records systems to state
surveillance programs like
cancer registries. FHIR
encourages the use of standard
terminologies, which can
facilitate linkage to other
datasets using those standard
terminologies. Using FHIR
positions vitals data for future
data needs, places where vital
records is relevant and for
secondary use of vital records
data. An added benefit is that
the FHIR ecosystem has
significant support in the
health sector and easily works
in multiple languages and
platforms. FHIR makes use
of internet-based standards,
including for security, which
provides a strong foundation
that aligns with overall IT
industry best practices. FHIR
can contribute to timeliness
of data exchange. Record-level
processing can result in
significant improvements and
timeliness in both sending data
to NCHS and in return of coded
data, such as cause-of-death
coding, leading to
near-real-time flow of
data. Note that the idea of
record-level processing is
somewhat orthogonal to FHIR, but
vital-records business processes
developed around FHIR and using
FHIR messaging align very well
with that goal. FHIR can also
contribute to business-process
improvements. As one example,
moving to FHIR helps address
workflow challenges related to
updating case information and
amendments when there's, say,
out-of-order delivery and, say,
if an update arrives after an
initial submission. FHIR also
provides solid governance
processes organized through HL7
for maintaining the use of the
standard for vital records over
time. This allows the standard
to evolve based on programmatic
needs in an organized and
sustainable way. We've mentioned
the Vital Records Death
Reporting Implementation Guide,
commonly referred to as the VRDR
IG. From the guide itself, the
VRDR FHIR IG provides guidance
regarding the use of FHIR
resources as a conduit for data
required in the bidirectional
exchange of mortality data
between state-run vital records
offices and U.S. Centers for
Disease Control and Prevention
National Center for Health
Statistics. The guide provides
guidance on how to use FHIR as a
way to bidirectionally
exchange mortality data between
jurisdictions and NCHS. Here I'm
displaying the actual site for
the implementation guide at HL7,
which is available online. The
guide describes how an
individual death record is
represented. At the time this
video is being recorded, we're
operating with a draft standard
and there is ongoing work to
finalize it, incorporating
feedback from the community,
including from events like
Connectathons where the standard
is tested. To show a bit of how
the guide is organized, I'll
start by visiting the table of
contents and from there show the
UML data model. This is a
diagram of how all the FHIR
resources are used and combined
to make a death record. Without
zooming in, you can see
that there's quite a bit of
complexity here. This video will
try to do two things: First,
introduce you to navigating
through the implementation guide
to understand that complexity
and then, later, to show some
tools that have the goal
of really simplifying this
complexity and hiding a lot of
it from implementers. We have
some tools that help with the
complex structure of a FHIR
record and allow developers to
focus on just pulling the data
together. A good place to start
with the implementation guide is
the Artifact Index. This
breakdown, a death record into a
few different sections. The
first is decedent demographics.
This is an area where the 80% of
the base FHIR specification is
heavily made use of. The
implementation guide relies on
the concept of a patient to
capture a lot of the information
about the decedent. Other
sections are the death
investigation section, the death
certification section and the
decedent disposition section. As
an example of how the individual
artifacts within the record
work, I'll jump into one in
particular. Under decedent
demographics, there is the
concept of the decedent's
military service. This is a
straightforward concept
representing whether the
decedent served in the military.
Now that we've clicked on this
concept, we can see that the
concept is based on the FHIR
observation resource. An
observation is typically a
measurement or an assertion
about an individual. In this
case, the observation is used
to assert whether or not the
decedent served in the military.
Each observation has a status
showing whether it's preliminary
or final. The implementation
guide requires it to have a
fixed value of "final." The
observation also has a code
that describes what is being
observed. In this case, it has
a fixed value of 55280-2, or
"Military service Narrative."
The observation has a subject,
which is a reference to the
decedent. And, finally, the
observation has a value. When
building the record, only the
value really needs to be
considered. The other fields are
fixed to specific values. Later
we'll show how tools make it
particularly easy to construct
a FHIR value because the tools
take care of all the fixed
values. The key part of this
specification is that it tells
us what the valid values are for
this observation. If we click
on "binding" next to the value
field, this brings up the value
set, which tells us that this
particular field can have values
of "No," "Unknown," or "Yes."
Moving back to the guide,
in addition to defining the
structure of the record, there's
also examples. Up at the top of
this page, there's an examples
section. If I click on
"Examples" and then the
"Decedent Military Service
Example," I can take a look at
the XML for this section of the
record. We can see that it's an
observation, we see that it's a
military service narrative, and
that there's an actual value of
"Yes." The implementation guide
can be somewhat imposing at
first glance because there are
many different sections. But
once you're familiar with
navigating it, you can quickly
understand the different pieces
of the guide and how they fit
together. This was just a very
brief, high-level introduction
to the implementation guide and
navigating to a particular piece
of it. The intent of this video
is just to provide this type of
high-level overview across a few
different areas, which will be
explored in more depth
elsewhere. Now I'm going to move
on to FHIR messaging for
VRDR record exchange business
processes. What we just looked
at with the implementation guide
is a way of representing an
individual death record. When we
think about the exchange of
death records, there are a few
business processes that are
regularly supported that we
handled using a part of FHIR
called FHIR messaging. There are
several common use cases. A
record can be submitted. That's
simply sending the record from
the jurisdiction to NCHS. A
record might also be updated
if it's changed or amended. A
record can be voided. We also
have as part of this process the
return of coded information from
NCHS to jurisdictions and this
includes coding of race and
ethnicity along with coding of
the cause of death. We also have
some additional concepts like
sending of errors or
acknowledgments for messages.
The approach for handling these
business processes is to use a
part of FHIR called FHIR
messaging to handle these common
use cases. FHIR messaging
supports the concept of
asynchronous communication.
We know that when a record is
submitted to NCHS, coding of the
record may be fairly quick if it
can be handled in an automated
way or it might take some time
if a person is involved in a
manual coding process. Because
of this potential time lag,
we need to support a business
process where the coded response
may be returned after some time
has elapsed. It's also helpful
to have the concepts of delivery
status or error response let us
know how the underlying business
processes are proceeding. We
also want to make sure that the
use of FHIR is flexible so that
it can be used via different
data-exchange mechanisms. We've
talked about how STEVE 2.0 is a
key system for vital records
data exchange. If and when STEVE
2.0 in the future offers a FHIR
API or NCHS offers a FHIR API,
the same FHIR messaging approach
should be used for both.
Finally, there needs to be
reliable delivery of messages
with confidence that the
messages that are sent will be
received. As mentioned earlier,
FHIR messaging is just a part of
the overall FHIR specification.
And the use of FHIR messaging
for vital records exchange is
a fairly straightforward way of
building on existing work to
address the requirements from
the previous slide. It uses
the FHIR VRDR IG to represent
records. It adds as a message
header with contents that are
used for liability and error
handling. It adds some simple
messages for voiding records and
updating records. FHIR messaging
addresses the other requirements
just mentioned. Out of the box,
it supports asynchronous
exchange of messages, it can be
used to cover different
transport interfaces, and
provides reliable message
exchange. The specification
itself is available online on
GitHub. This diagram shows at a
high level how FHIR messaging is
used to exchange vital-records
data. In this simple case, a
jurisdiction submits a death
record. Data from that record
is extracted. If that extraction
happens successfully, an
acknowledgment is immediately
sent back to the jurisdiction
indicating the message was
received successfully. At a
later time, one or more coding
responses are sent from NCHS
back to the jurisdiction and the
jurisdiction acknowledges
receipt of the coding responses.
This text diagram shows the
structure of a FHIR message. You
can think of the message as
an envelope that wraps a death
record. The first section is
the header, which contains
information on the sender and
the recipient, like an envelope.
The second section contains
some additional information
identifying the record, like the
certificate number. The third
section is the record itself,
which is described by the VRDR
implementation guide that we
previously discussed. I'm going
to now provide a brief demo of
some FHIR messaging concepts.
I'm going to show a simulation
of two systems engaging in
exchange of mortality data using
FHIR messaging. On the left-hand
side is a system called
Nightingale. Nightingale is an
example electronic
death-registration system that
allows us to demonstrate
concepts and conduct
proof-of-concept exploration
to test out ideas and here
represents a jurisdiction system
that will be submitting records.
Nightingale has been loaded with
100 different records. On the
right-hand side is a system that
stands in for the NCHS National
Vital Statistics System as the
recipient of FHIR records during
this demo. I want to emphasize
that the dashboards that you'll
see during the demo are intended
just for the purpose of allowing
you to see what's taking place
during the demo. FHIR messages
will be sent back and forth
between the two systems and it's
difficult to show automated data
transfer on a screen without
some type of dashboard. Any
production systems that would be
engaged in the exchange of FHIR
messages would be expected to
provide different and more
production-focused dashboards.
So what I'll do to start is log
into the Nightingale system. And
you can see the records that
have been loaded into the
system. I'm going to navigate
to the admin panel where I can
submit records. Here we can see
again the list of the records
loaded into Nightingale and none
of them have yet been submitted.
For this demo, we have a
button to submit records and a
production-system submission of
records would have to be some
type of automated process. Once
I click the button, the system
begins to submit the 100
records. As the screen updates,
you can see records being
submitted and then received on
the right-hand side of the
screen. Then, on the left-hand
side, you can see
acknowledgement message coming
back and then also
coded-response messages coming
back. As the process completes,
we'll see 100 records received
by the system on the right
representing NCHS's National
Vital Statistics System and
then 100 acknowledgments and 100
coded responses received by the
system on the left representing
the jurisdiction. There's a
five-second delay built into the
coding responses to simulate
the concept of asynchronous
communication. Now that we
have all the records submitted,
acknowledged, and coded, we can
briefly see what the different
messages look like. If we look
at a submission message, we can
see the message header with
the source and destination
information, like an envelope,
and we can see the record
itself. When we look at the
coding-response message, we can
see the ICD-10-coded
cause-of-death information
that's sent back from NCHS to
the jurisdictions. That's just a
very brief demo of FHIR
messaging showing conceptually
how data can move between
systems. Earlier, I mentioned
that there are some tools to
make the complexity of using
FHIR for mortality data simpler.
These tools include libraries
that provide infrastructure code
for creating FHIR records and
managing FHIR messages. The VRDR
.NET and VRDR.Messaging .NET
libraries provide code for both
producing and consuming death
records built according to the
VRDR implementation guide that
we looked at earlier, as well as
for producing and consuming FHIR
messages that we just showed
in the previous demonstration.
There is also some utility
functionality such as converting
between different formats. The
.NET libraries are open-source
and free to use. The code
is available in the GitHub
repository shown here. The code
is intended to be used as either
a reference implementation or be
directly incorporated into other
software. The Apache 2.0
open-source licensing that's
used is intended to make the
software as easy to use as
possible. The libraries include
a README. That provides an
introduction, including some
sample code. There's a separate
section of the documentation
linked in the README that covers
messaging in significant detail
and provides examples as well.
As mentioned earlier, while
there's a fair amount of
complexity in the actual FHIR
data format, a record can be
created using just a few lines
of code, which we'll demonstrate
in a moment. In addition to the
libraries themselves, there's
also a command-line tool that
allows you to interact directly
with FHIR data and a simple
microservice that offers
format-conversion services.
I'll now briefly demonstrate how
straightforward it is to use the
.NET library to create a valid
record. What you see on the
screen is a very simple program
with just a few lines of code.
While this code is not building
what would be considered a
complete death record, since
there are quite a number of
fields to cover in that complete
record, it is building a
partial record that includes the
certificate number, the given
names, and the family name of
the decedent, and four different
cause-of-death literal strings
with the matching interval
information. The final line
creates the JSON version of this
partial record. If we run the
program, what we see on the
screen is an actual JSON FHIR
death record. If we scroll up,
we can look at the information
that was inserted into the
record. For example, we can see
the cause-of-death literal
strings that we specified in the
code. You can see that, while
there's a lot of complexity when
we look at the format of the
data that's produced, the actual
code to produce this was fairly
straightforward, which is really
the intent of the library. In
addition to the .NET libraries,
there's also a Java
implementation of the VRDR
implementation guide, also
available on GitHub. A number of
jurisdictions have successfully
used each of these libraries
within their implementations.
The next thing we'll cover is
the Canary testing tool. We've
discussed the FHIR VRDR standard
and we've talked about some
tools to help create read
records that implement that
standard. In a complex domain
like vital records it's also
useful to have tools to test
implementations. Canary is an
open-source tool that supports
the development of systems that
exchange mortality data using
the FHIR standard. For example,
Canary allows you to test that
your system is correctly
producing FHIR messages. Canary
also provides some utilities
that let you investigate FHIR
data and examine it in detail.
Essentially, Canary is intended
to be a Swiss Army knife for
dealing with mortality data in
the FHIR format. Like the
previously mentioned .NET and
Java libraries, Canary is
an open-source project also
available on GitHub. A README
provides information on what
Canary is and the features it
offers, as well as describing
how Canary can be run. Now
I'll provide a very brief
demonstration of Canary. There
is a separate video that is
specifically on Canary
that provides more complete
information. If you recall in
the previous demonstration, we
use the VRDR .NET library to
create a simple partial death
record with a few of the fields
filled in. We can take this
record that we just created and
look at it in Canary. Canary is
divided into record testing,
for testing the production of
individual FHIR records; and
message testing, for testing
records wrapped in FHIR
messaging envelopes. I'm going
to use the FHIR Death Record
Inspector tool and paste the
record we just created into
Canary. I'll submit the record.
And you can see information from
the record we just created: for
example, the certificate
number and the cause-of-death
information. If we're interested
in the actual structure of a
particular section, we can
dive in deeper to view it in
isolation. If you remember from
the beginning of this video, we
looked at the concept of
military service in the VRDR
implementation guide. We can
see how quickly it is to add
military-service information to
the death record using the .NET
library. This is the example,
which we now can update to add
information on military
service. We simply set
deathRecord.MilitaryServiceBoole
an to true, which is shorthand
for indicating that the decedent
did serve in the military. We
can then recreate the record
and use Canary to look at the
change. We can see that now the
record contains information on
the military service of the
decedent. As expected, we see
that the military service is set
to "Y," meaning "Yes." That's a
very high-level overview of
Canary. Hopefully through this
brief demonstration, you can see
how these tools and libraries
are all intended to work
together to make it easier to
navigate some of the complexity
within a death record. Canary
provides one type of testing.
With any type of data exchange,
it's also helpful to have
specific testing events. Nothing
provides quite as much
confidence that things are
working as actually testing
connections between systems.
Having technical teams in a
room together -- whether it's
in-person or a virtual room --
and actually trying to connect
systems and see how well they
communicate with each other is
something that Connectathons
are intended to facilitate.
Connectathons are organized
activities that could be hosted
by different organizations. HL7,
the standards organization that
manages FHIR, is one of those
organizations that hosts
Connectathons. IHE is another
standards organization that does
the same thing. Connectathons
provide both an opportunity to
test interoperability between
systems, as well as an
environment for interacting
with others who are developing
similar systems. There has been
previous testing of mortality
data exchange at Connectathons.
Over the past few Connectathons,
there has been testing of
submission of FHIR mortality
records from jurisdictions to
NCHS, testing of the return of
coding-response messages from
NCHS back to jurisdictions, and
testing the actual format of
the record combined with FHIR
messaging. These tests have not
only been useful to test the
systems under test but they've
also provided valuable feedback
on the VRDR implementation
guide and on the FHIR messaging
approach. Testing has been
completed using STEVE 2.0 and
has been structured to support
progressively testing FHIR
message-processing capabilities,
ranging from simple to more
complex test cases. What's
currently shown is the test plan
for a Connectathon in September
of 2021. It starts with some
overview information and
instructions for using STEVE 2.0
for testing. As we scroll down,
we come to a set of structured
tests that walk through the
different parts of the process.
The tests start with the basic
step of submitting an individual
FHIR message with success
conditions to confirm that the
test is successful. Tests also
cover submission of an update
message and submission of void
message. From there, the tests
move on to more complex
scenarios that are not the
happy-path tests. In addition to
testing successful cases, it's
also important to test what
happens if some type of error
occurs. We've just had a
whirlwind tour of a number of
the technologies, tools, and
approaches for mortality-data
interoperability using FHIR. To
wrap up this presentation, we'll
briefly cover some of the
steps for working on FHIR-based
interoperability. The first step
to consider is assembling the
right team. Implementing FHIR
for mortality-data exchange is a
technical activity that's
going to require expertise in
informatics for data-mapping
activities and in software
development for implementing
data-transformation and API
interactions. This might mean
working with your EDRS vendor or
an existing technical team that
has those capabilities. This
team then needs to spin up on
FHIR, the VRDR implementation
guide, and the tools and
technologies that support
implementation, like the
open-source libraries and Canary
that we've just covered.
The next step to consider is
producing a death record
that aligns with the VRDR
implementation guide. A good
approach for doing that is to
first understand how the data
should be structured by looking
at the examples that Canary can
produce using Canary's synthetic
record tool. It's also possible
to look at the examples in the
implementation guide as we did
earlier. Another approach that
might be helpful if you're
familiar with the IJE data
format is to take an IJE record
and use Canary to convert that
into a FHIR record to provide an
example using known data. Once
you understand the format, then
it's important to start mapping
the data in your EDRS or data
warehouse to that FHIR format.
That mapping can be made
significantly easier by using
the .NET or Java libraries.
Those allow you to just consider
the data without having to think
so much about the structure.
Finally, once you have an
implementation for producing
records, Canary has tests that
allow you to enter data into
your system and test your
system's ability to produce a
FHIR record containing that
data. Once you've produced a
record using that data, Canary
will examine the record,
stepping through all the fields
one by one to confirm that
they're all correctly
represented. Step three is to
implement the business processes
of mortality-data exchange using
FHIR messaging. Messaging is the
way that records are sent back
and forth supporting the
business processes of
mortality-data exchange.
To recap the exchanges that
messaging supports, they include
submitting records, updating
records, voiding records,
returning coded cause of death,
returning coded race and
ethnicity, confirming receipt of
messages, and notifying
participants of errors. As with
creating the records themselves,
all of these messages are easier
to create and manage using the
VRDR .NET messaging library.
Step four is to test your
implementation using Canary.
During development of a VRDR IG
FHIR implementation, Canary is a
helpful tool for testing
the correctness of that
implementation, both ensuring
that the syntax is correct and
that your data mapping is
semantically correct. Canary
also provides the ability to
test FHIR messages and allows
you to ensure that your FHIR
implementation is on par with
your current IJE implementation.
Canary provides valuable
feedback and can let you know
when your FHIR implementation is
complete and ready for testing
at a Connectathon. Finally, once
there is confidence that the
implementation is correct based
on Canary and NCHS feedback, a
Connectathon is an important way
to get final confirmation
that the implementation is
interoperable with other systems
by progressing through a series
of test cases. As mentioned
before, Connectathons are also a
good opportunity to learn from
and share with others who are
working towards the same goals.
There are a number of future
planned activities that we
won't discuss as part of this
presentation. We expect
those activities to include
integration with new FHIR APIs
in the STEVE 2.0 system and at
NCHS, pilot testing,
certification of systems, and
then, finally, transition to
production use of FHIR. That
concludes this high-level
introductory presentation.
Hopefully, it's provided a good
overview of the topics related
to the use of FHIR for
mortality-data exchange,
providing a good foundation
for future, more detailed
exploration of the
topic. Thanks very much.