Keywords
Laboratory information systems - standards - FHIR - HLA antigens - platelet transfusion
1. Background
More than 50,000 patients undergo Hematopoietic Stem Cell Transplantation (HSCT) worldwide
annually [[1]], with close to 20,000 being carried out in the United States alone [[2]]. Thrombocytopenia, which can lead to life-threatening bleeding, is a common complication
of HSCT, and many of the 2 million platelet units transfused annually in the United
States are used for patients who develop thrombocytopenia while undergoing HSCT [[3], [4]]. Hospitals that purchase platelets pay on average more than $500 per unit, with
the total cost (including staffing, storage, and adverse events) substantially higher
[[5]]. Unlike other blood products, platelets have a shelf life of 5 days, with an estimated
10–20% of platelet units becoming outdated instead of transfused, creating inventory
challenges.[[6]] Additionally, platelet transfusions can be associated with numerous adverse events,
including febrile non-hemolytic transfusion reactions, allergic/anaphylactic reactions,
transfusion-related acute lung injury (TRALI), sepsis, and hemolysis [[7]].
Platelet Transfusion Refractoriness (PTR), defined as a less-than-expected increase
in platelet count after transfusion, is a common clinical problem for patients with
thrombocytopenia undergoing HSCT. There are many reasons for platelet refractoriness,
from non-immune causes like sepsis, disseminated intravascular coagulation (DIC),
and splenomegaly, to immune causes like alloimmunization to Human Leukocyte Antigen
(HLA) antigens. The HLA system is a critical component of immune response. The HLA
genes, located on the short arm of chromosome 6, are a component of the Major Histocompatibility
Complex (MHC), and code proteins that present antigens to T-cells – an essential step
in distinguishing self from non-self. HLA genes are located within the class I and
class II regions of the MHC [[8]]. In addition to platelet-specific antigens, platelets express HLA class I antigens,
and the development of antibodies to these antigens can lead to immune-mediated destruction
of transfused platelets. Patients primarily become alloimmunized to HLA through pregnancy
or exposure to leukocytes in blood products [[9]].
Even with leukoreduction, however, approximately 20% of patients can become HLA-sensitized
with chronic transfusions [[10]]. The calculated Panel Reactive Antibody (cPRA) quantifies the sensitization of
a patient to “unacceptable” HLA antigens, based on frequencies in a United States
kidney donor population. The score – from 0 to 99% – indicates the extent of sensitization,
with anything greater than 20% suggesting HLA alloimmunization. Patients that are
sensitized are more likely to develop PTR due to immune-mediated destruction of transfused
platelets, and may require HLA-matched platelets. Patients that are not sensitized
are more likely to respond appropriately to random donor platelet products [[11], [12]].
Patients that are HLA antigen-sensitized could receive HLA-matched platelets, increasing
the chance of an appropriate response to transfusion. However, the current clinical
practice is to transfuse random donor platelet units and wait for sensitized patients
to clinically demonstrate PTR based on inadequate platelet count increases, which
may take several days and result in wasted platelet units. Therefore, strategies to
determine which patients could benefit from HLA-matched platelets could not only improve
platelet utilization, but also minimize dangerous thrombocytopenia, decreasing significant
hemorrhagic events. HSCT patients are often sensitized as a result of previous transfusions
and will trend towards a platelet count of 0 for several weeks following transplantation.
Therefore, during this time period it is essential that HSTC patients get the most
optimal and effective platelet transfusions possible.
To improve clinical review of platelet transfusions for patients undergoing HSCT we
set out to build a visualization tool that would allow the oncology, blood bank, and
blood donor center teams to view a patient’s platelet count trend with superimposed
transfusion events (along with the date of induction chemotherapy and stem-cell transplant
infusion). Additionally, the tool would calculate a cPRA based on the patient’s HLA
antibodies, and display that value to the oncology team. Our explicit goals were to
improve utilization of platelet units and increase the time spent over a platelet
count of 10 × 109 cells/L (the current AABP guidelines for a prophylactic transfusion threshold for
patients with therapy-induced thrombocytopenia [[4]]).
2. Methods
We designed our application to be compliant with the Substitutable Medical Applications
and Reusable Technologies on Fast Health Interoperability Resources (SMART on FHIR)
framework for clinical application development. SMART on FHIR, a clinical application
development framework that fosters portability and interoperability, would allow our
visualization tool to be used across other healthcare systems, provided they were
SMART on FHIR compliant, substantially increasing the potential footprint of our application
[[13]].
As we began gathering requirements, we realized that one of the essential data elements
– a patient’s full HLA data from our tissue-typing lab – was held in a database with
minimal external interfaces. When a patient was scheduled to undergo HSCT, the tissue-typing
lab generated a PDF-based report which was uploaded to the Electronic Health Record
(EHR) system. A cPRA is not routinely calculated for subsequent platelet transfusion
purposes, because the currently available cPRA calculator website requires manual
input of antibody data and the current clinical and transfusion workflows could not
make easy use of this. For our application, we therefore needed to develop a FHIR
interface for the HLA database and create a RESTful cPRA calculator web service (using
antigen frequencies from the Organ Procurement and Transplantation Network’s cPRA
calculator [[14]]), so that the HLA antibody data could be electronically transmitted to the calculator,
which would return a cPRA that could be incorporated into our application, maintaining
its SMART on FHIR compliance. This case report describes the implementation specifics,
challenges, and “lessons learned” of that effort.
3. Results
3.1 Existing Standards: HML and MIRING
Histoimmunogenetic Markup Language (HML, version 1.0), is an XML-based messaging format
for typing results from systems like HLA [[15]]. HML is used by the National Marrow Donor Program (NMDP), a US-based registry of
over seven million volunteer donors, for reporting genotyping results [[16]]. Leveraging HML 1.0, and our requirements for product development, we sought to
develop an interface that would support the complex structures needed for modern,
HLA data, while supporting the “utilitarian” [[17]] clinical requirements of genetic data, as well as maintaining SMART on FHIR compliance.
One important requirement was the ability to properly handle the transmission of results
from different HLA typing technologies, which generally represent tradeoffs between
typing resolution/ambiguity and assay time.
Next Generation Sequencing (NGS) is an umbrella term for a set of technologies that
have substantially decreased the price and increased the speed and efficiency of DNA
sequencing in the past decade [[18]]. While NGS has altered the HLA typing landscape, it has also raised new issues
in data representation, as well as new challenges around allelic polymorphism and
the need for complex metadata and the future-proofing of sequencing results.[[19]] In 2015, the Minimum Information for Reporting Immunogenomic NGS Genotyping (MIRING)
guidelines were developed to describe standards for reporting NGS-based HLA genotyping
data. Though not a technical specification, the MIRING guidelines were subsequently
incorporated into an extension of the HML, version 1.0.
3.2 Existing System
Our Tissue Typing lab currently processes and reports HLA data for patients at our
institution as well as other centers. The lab uses PCR-based methodologies for HLA
typing and Luminex bead-based anti-HLA antibody detection assays to process patient
samples. The results are stored in “URSUS,” a 4th Dimension (4D) relational database management system. For patients at our institution,
a report is finalized, a Portable Document Format (PDF) file is generated, and this
file is uploaded to the EHR (►[Figure 1]–[Figure 1]). No structured fields are reported to the EMR due to the complexity and interpretation
of the underlying data, an approach that also limits automation around point-of-care
alerts. For results generated on patients from external institutions, PDFs are also
generated, and sent via fax. A standard format for expressing HLA data, in this case
for patients undergoing stem-cell transplantation, would not only support our SMART
on FHIR application, but could also foster improved data exchange with other institutions.
Fig. 1 Section of a sample test HLA tissue-typing report from our laboratory. The top section
details the HLA alleles for our test patient, including the genotypes located on the
A, B, C DRB1, DQB1, and DRB3/4/5 Loci. Antigens, not part of this report, are generated
automatically from their associated allele by our proprietary typing database. Typing
is done twice for quality purposes. The bottom section contains the results of the
antibody screens for MHC Class I and Class II. (2) Simplified, overall structure of
DiagnosticReport FHIR resource shows the hierarchy, with 3 extensions, and antigens/
antibodies within the “contained” reference. (3) Sample FHIR response in Javascript
Object Notation (JSON). For ease of display, several sections have been simplified
or removed.
3.3 FHIR and HLA
Fast Healthcare Interoperability Resources (FHIR) is a standards framework created
by Health Level 7 International (HL7) focused on implementation, open specifications,
and modern web standards (like RESTful architectures). FHIR is built from “Resources,”
which are extendable components that express clinical and administrative data. An
example of a FHIR Resource is the Patient resource, which might have a patient’s name,
gender, birthdate, etc [[20]]. As of this writing, the current official published version is 1.0.2, corresponding
to Draft Standard for Trial Use 2 (DSTU2). Future versions, corresponding to the Standard
for Trial Use 3 (with planned publication in 2017), offer genomics implementation
guidance and features, including commentary around HLA data, so we turned to this
guide [[17]] (recognizing it is still unpublished), for guidance on modeling HLA data for our
FHIR interface.
3.4 Our Approach
Structurally, an HLA report issued by our tissue-typing laboratory is a single, encapsulated
report that includes basic patient demographics, alleles, antigens, and antibodies.
Therefore, similar to the FHIR Genomics Implementation Guidance [[17]], we used the DiagnosticReport FHIR Resource. The DiagnosticReport Resource is designed
to describe, “the findings and interpretation of diagnostic tests performed on patients,
groups of patients, devices, and locations, and/or specimens derived from these.”
[[21]]. Within the DiagnosticReport resource, we included extensions and other “Observation”
resources to describe the specific elements of a full HLA report for a patient undergoing
HSCT. This includes Observations for antibodies and antigens, as well as a Genotype
List (GL) String extension, a text format that can completely represent an individual’s
HLA genotype [[22]], and a resultsAlleleDatabase extension, which describes the international ImMunoGeneTics
Information System (IMGT) allele database version used.
To include antibody and antigen data, we decided to use the “contained” feature of
FHIR instead of Observation.related. As described in the FHIR specification, “Observation.related”
can help assemble different resources when there is a need for these resources to
be processed as independent, “stand alone” resources [[23]]. A “Contained Resource,” on the other hand, does “not have an independent existence
apart from the resource that contains it” [[24]]. Since, the testing mechanisms and assays for HLA reports differ based on the clinical
use case, we felt that “Contained Resources” might prevent incorrect re-interpretation
of HLA data. For example, a low-resolution limited-loci HLA typing donor screening
should not be used to subsequently evaluate HLA diseases or adverse drug reaction
associations. Additionally, HLA typing performed for kidney transplantation has less
stringent resolution, allele ambiguity, and sequenced loci requirement then that for
HSCT. As such, it is important that HLA results are interpreted with knowledge of
the methodology used to perform the typing. To address this, we included the hla-genotyping-resultsMethod
extension to describe the platform and methodology that we use in our laboratory.
Within the “Contained” object, we included our antibody and antigen data. Each antibody
is an Observation resource, because antibodies have clinically relevant, unique additional
data – for example, Mean Fluorescence Intensity (MFI) and titers. While not included
in our example, these could be added to each antibody Observation resource through
the Observation.component feature [[23]]. For antigens, however, we decided to transmit all antigenic equivalents as a single
Observation resource, since this is how the data is reported by our laboratory.
Finally, the Sequence resource (described in FHIR STU3) is designed to represent sequencing
data, and is heavily connected to HLA reports (for example, displaying exon sequencing
data of individual alleles). Though future states of our interface might include this,
as it was not necessary for our use-case, we did not incorporate Sequence resources
into our initial interface. Please see [Figure 1] for an example of a current report from our laboratory, an overview of our DiagnosticReport
resource, and sample JSON.
3.5 Data Extraction, Interface and Updates
Instead of putting the FHIR interface in front of the native HLA database, we decided
to mirror HLA data into a separate, standalone system, which would be used as the
source of the FHIR JSON. We designed two complementary update processes to transfer
the data to this standalone system – a batch process and a streaming process—that
ensures the data is both accurate and up to date (►[Figure 2]). The batch process runs nightly, replacing all of the prior data. We do this to
ensure our data mirrors the source HLA system, providing resiliency and redundancy
for the streaming process. The streaming process is triggered when the tissue-typing
laboratory finalizes a HLA report for a patient undergoing HSCT. In addition, running
a standalone server mitigates the impact that our clinical application has on the
laboratory production systems.
Fig. 2 Simplified UML component architecture. New HLA reports are generated and finalized
by the tissue typing laboratory. Once finalized, each report is sent to the HLA database.
Every night, the entire HLA database is exported to the application database. The
application DB is used for retrieval of patient HLA data. Requests to the application
database return FHIR (in Javascript Objection Notation (JSON)) resources of type DiagnosticReport.
The cPRA service returns a cPRA value based on antibody data. Not shown are the services
that provide other data, like laboratory values.
While most of the generated reports are new reports for patients with no prior HLA
testing, antibody data is occasionally updated, and a new screening report is issued.
In these cases, we generate an entirely new report even if only certain components
have changed. This ensures that clinicians are always looking at the latest, full
HLA reports.
4. Discussion
In this report, we describe a clinical application designed to improve the utilization
of platelets and maintain patients at appropriate therapeutic platelet counts for
as long as possible. By structuring HLA data using FHIR, we were able to feed a cPRA
calculator, which allows risk stratification of patients who are more likely to experience
PTR. Data that was not readily accessible before – previously cPRAs required manual
calculation and were only done when specifically requested by the clinical team –
would now be readily viewable, allowing oncology clinicians and the blood bank and
donor centers to use HLA-matched platelets earlier in an at-risk patient’s hospitalization.
In essence, our application allowed HLA data, previously collected for transplantation,
to be seamlessly reevaluated for platelet transfusion support, in this case supporting
a platelet visualization tool that allowed clinicians and blood-bank staff a detailed,
summary view of a patient’s platelet trajectory, transfusion events, and cPRA. Our
hope is that this will lead to increased patient-time spent above transfusion thresholds,
as well as improve platelet utilization overall, as units of platelets that would
have been wasted (due to rapid in vivo clearance of HLA mismatched platelets), can now be used therapeutically for other
patients. Additionally, the cPRA web service could be used in other contexts, like
kidney and pancreas allocation, or by other centers. Future work will include a formal
description and assessment of this web service, as well as validation in a variety
of contexts.
Much work is being done in the standards community around structuring and expressing
genetic information, and we used many of the draft recommendations of FHIR Genomics
Implementation Guide [[17]] for expressing HLA data, including the overall structure using DiagnosticReport.
However, our approach has several potential caveats. First, we opted not to use the
Sequence resource, as this information is not routinely re-evaluated after the initial
HLA typing determination. Second, we used the “contained” reference, instead of the
“Observation.related” reference, to nest antibodies and antigens as discrete Observation
resources. By doing this, we are asserting that an HSCT patient’s HLA data should
not necessarily be used for other purposes, since the tests may be asking different
questions, and the nature of FHIR (resource-driven) could allow disparate pieces of
data to be used in contexts that are not relevant or accurate. Third, with our approach,
antigenic equivalents are communicated without relation to their alleles. While this
worked for our specific implementation, future work could expand on this point, for
example, creating custom FHIR extensions to better represent these relationships.
Lastly, like many information technology projects, implementation and workflow optimization
will be essential for adoption and efficacy of the broader visualization tool. Our
hope is that we can drive usage by making clinically actionable but previously obsufcated
information available to clinicians at the point of care.
Building systems that rely on the electronic exchange of genetic information is challenging
due to the varied use-cases – clinicians and researchers may have differing needs
from this data. Our application – software used by clinicians to visualize and surface
data – clearly focused more on a clinical application. Even so, we were cognizant
of other use cases when developing our interface, and if fu- ture needs should expand
on our use case, we will be able to adapt as needed. Designing interoperable systems
involves managing the tension between the various data stakeholders. By defining our
requirements, we were able to focus implementation around our needs, while still generating
value for other potential users.
Clinical Relevant Statement
Clinical Relevant Statement
Patients undergoing Hematopoietic Stem Cell Transplantation (HSCT) are high-risk for
therapy-induced thrombocytopenia and platelet transfusion refractoriness due to HLA
alloimmunization. By defining a FHIR interface to an internal tissue-typing HLA database,
we were able to facilitate a platelet visualization tool and calculated Panel Reactive
Antibody (cPRA) web service. As a result, clinical teams will more readily identify
patients in need of HLA-matched platelets, and our institution will be able to better
utilize platelet inventory.
Multiple Choice Question
Calculated Panel Reactive Antibody (cPRA) is based on which of the following?
-
Anti-HLA antibodies present in donor.
-
Percentage of reactive single antigen beads bound by recipient anti-HLA antibodies.
-
Calculated based on the recipient’s weight.
-
Percentage of donors to which the recipient anti-HLA antibodies would bind.
Answer: D
