Appl Clin Inform 2017; 08(02): 603-611
DOI: 10.4338/ACI-2017-01-CR-0010
Case Report – Special Topic Interoperability and EHR
Schattauer GmbH

A FHIR Human Leukocyte Antigen (HLA) Interface for Platelet Transfusion Support

William J Gordon
1   Clinical Informatics and Innovation, Brigham and Women’s Hospital, Boston, MA
3   Department of Medicine, Massachusetts General Hospital, Boston, MA
4   Harvard Medical School, Boston, MA, USA
,
Jane Baronas
2   Department of Pathology, Brigham and Women’s Hospital, Boston, MA
,
William J Lane
2   Department of Pathology, Brigham and Women’s Hospital, Boston, MA
4   Harvard Medical School, Boston, MA, USA
› Author Affiliations
Further Information

Correspondence to:

William Gordon, MD
41 Avenue Louis Pasteur #209
Boston MA 02115
Phone: 617–264–08711   

Publication History

14 January 2017

16 March 2017

Publication Date:
21 December 2017 (online)

 

Summary

Platelet transfusions are a cornerstone of therapy for patients who develop thrombocytopenia while undergoing Hematopoietic Stem Cell Transplantation (HSCT). Many patients who develop Platelet Transfusion Refractoriness (PTR) require HLA-matched platelets. Identifying these patients early could lead to better utilization of platelets as well as increased platelet counts. We built a SMART on FHIR visualization tool to aid the oncology, blood bank, and blood donor center teams in identifying these patients by showing trends in thrombocytopenia along with a computer generated calculated Panel Reactive Antibody (cPRA) level. To do this, we required a FHIR interface to our HLA database. We describe our methods and outcome for constructing this FHIR interface, as well as the architecture and data flow of HLA data from its proprietary database to the SMART on FHIR environment and application database along with RESTful cPRA web service calculator. Future work will evaluate the clinical impact of this platelet visualization tool and overall success of our FHIR implementation.

Citation: Gordon WJ, Baronas J, Lane WJ. A FHIR human leukocyte antigen (HLA) interface for platelet transfusion Support. Appl Clin Inform 2017; 8: 603–611 https://doi.org/10.4338/ACI-2017-01-CR-0010


#

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.

Zoom Image
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.

Zoom Image
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

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


#
#

Conflicts Of Interest

The authors declare that they have no conflicts of interest in the research.

Acknowledgements

We would like to thank Gil Alterovitz, PhD and Robert Milius, PhD for their assistance with our work.

Protection of Human and Animal Subjects

The study was performed in compliance with the World Medical Association Declaration of Helsinki on Ethical Principles for Medical Research Involving Human Subjects. As a Case Report of an internal information system, no Institutional Review Board approval was sought.



Correspondence to:

William Gordon, MD
41 Avenue Louis Pasteur #209
Boston MA 02115
Phone: 617–264–08711   


Zoom Image
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.
Zoom Image
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.