The Complete Guide to Building FAIR, Interoperable Genomics Software

What FAIR actually means

FAIR is not a genomics-specific concept. It comes from a 2016 paper in Scientific Data, written by a large group of researchers, funders, and publishers who set out to define a minimal, measurable set of principles for making scientific data reusable by both humans and machines. The four letters stand for the following.

It's worth being precise about one thing: the original paper describes FAIR as a set of guiding principles, not a technical standard or a checklist with a pass/fail test. This distinction matters practically. "Is our platform FAIR?" is not a yes/no question with an authoritative test behind it. The useful question is narrower: which specific standards, applied to which specific data flows, would move this platform closer to each of the four principles?

Why FAIR alone isn't enough for genomics specifically

FAIR describes the goal. It does not specify how to achieve it, and genomics has requirements that the original FAIR paper wasn't written to address directly, most importantly, the tension between openness and patient privacy.

Genomic data is a specific kind of sensitive data: it's immutable (a patient's genome doesn't change), it identifies not just the patient but their biological relatives, and re-identification risk persists even in seemingly de-identified datasets. A recent review of federated genomic data infrastructure makes this tension explicit: FAIR, applied to human genomic data, cannot be equated with unrestricted openness, and the "accessible" and "interoperable" principles have to be implemented with tiered access control and consent-aware data sharing built in from the start, not as an afterthought.

This is also where the harder half of interoperability shows up. Syntactic interoperability, agreeing on a file format or a message structure, is largely solved for genomics: VCF for variants, BAM/CRAM for aligned sequence data, and HL7 v2 or FHIR for clinical messages are all mature, widely adopted formats. Semantic interoperability, agreeing on what the fields inside those formats actually mean across institutions, is not solved, and multiple recent efforts, including large national genome archives, are still documenting where their metadata models diverge from international standards and where the gaps remain. A genomics platform that only solves the syntactic layer, valid file formats moving between systems, without addressing semantic consistency, still produces silos. They're just silos that pass a schema validator.

The standards stack

This is the part that turns FAIR from a principle into an architecture. Four groups of standards do the actual work.

HL7 v2 and FHIR: clinical data exchange

HL7 v2 is the older, pipe-delimited messaging standard still widely used for lab orders, results, and ADT (admit-discharge-transfer) messages between hospital systems. It's not going away, most EHR integrations in production today still speak it for at least some message types, which is why a genomics platform needs to support it even while building toward FHIR.

FHIR (Fast Healthcare Interoperability Resources) is the modern, RESTful, resource-based standard, and FHIR R4 is the version most EHR vendors, including Epic and Cerner, currently support in production. Genomic data specifically has its own FHIR profile, the HL7 FHIR Genomics Implementation Guide, which defines structured resources for representing variants, sequences, and clinical interpretations in a form other FHIR-compliant systems can consume without custom parsing logic.

Two details matter enough to call out explicitly, since getting them wrong is a common and expensive mistake. First, FHIR R4, R4B, and R5 are not interchangeable; a platform built against R4 resources will not automatically work against an R5 endpoint, and vendor support for each version varies. Second, SMART on FHIR is a separate, additional layer on top of FHIR, an authorization and app-launch framework that lets a genomics application launch from inside an EHR session (from within Epic or Cerner, for instance) with the right patient context and permissions already established, rather than requiring a separate login.

GA4GH: the genomics-specific standards body

The Global Alliance for Genomics and Health (GA4GH) develops the standards that HL7 FHIR doesn't cover, the genomics-specific discovery, retrieval, and representation layer. The stack includes several distinct pieces, each solving a different problem.

None of these standards require adopting all of them at once. A clinical genomics platform focused purely on internal reporting has little need for Beacon's federated discovery. A platform supporting multi-site research collaboration or a rare disease network has a direct need for it. The point of listing them separately is that "GA4GH compliant" is not a single, meaningful claim, and any platform or vendor using that phrase without specifying which GA4GH standards it implements is not being precise about scope.

File and data formats

Underneath both stacks sit the actual file formats: VCF and GVCF for variant calls, BAM and CRAM for aligned sequencing reads (CRAM being the more compression-efficient, increasingly standard successor to BAM), and FASTQ for raw sequencing output. These are mature and well-standardized at the syntactic level, which is precisely why the semantic interoperability problem described in Part 2 is the harder remaining challenge, the formats agree on structure; the platforms built on top of them don't always agree on meaning.

What this actually costs in engineering time

Building for real interoperability, not just claiming a standard is supported, has a genuine engineering cost, and it's worth being specific about where that cost actually sits.

Supporting HL7 v2 and FHIR R4 simultaneously, which most production environments require during any transition period, means maintaining two integration paths rather than one, since most hospital systems run a mix of both depending on the message type and the age of the connected system. SMART on FHIR app-launch support is a separate authorization implementation on top of basic FHIR support, not a checkbox that comes free with it. Each GA4GH standard adopted, Phenopackets, Beacon, htsget, is its own implementation surface with its own testing and validation burden, which is why platforms should adopt the specific standards their actual use case requires rather than implementing the full stack speculatively.

The semantic interoperability layer, the harder half described in Part 2, costs the most and is the easiest to underestimate, because it requires active data governance decisions, which ontology for disease terms, which reference genome build, how consent metadata is structured, rather than a one-time integration project. A platform that skips this and only implements syntactic format compliance will interoperate on paper and still produce inconsistent, hard-to-combine data in practice.

Architecting for this from the start

The practical implication of everything above is architectural, not just a checklist of standards to bolt on. A few patterns hold up consistently.

• Separate the integration layer from the core data model. A genomics platform's internal representation of a variant, a sample, or a report should not be the same structure used for every external exchange. Building a clean internal model and then mapping it to FHIR, HL7 v2, or a specific GA4GH format at the boundary is more maintainable than trying to make one structure serve every external standard at once.
• Version everything that participates in reproducibility. FHIR version, GA4GH standard version, reference genome build, pipeline version, and variant calling parameters all need to be recorded alongside the data itself, since "reusable" in the FAIR sense specifically requires this provenance to be attached, not reconstructable after the fact from a changelog.
• Treat semantic mapping as an ongoing governance function, not a one-time integration task. Which ontology represents a given disease term, how a specific lab's local terminology maps to a standard vocabulary, and how consent metadata gets structured are decisions that need an owner and a review process, not a setting configured once at launch and forgotten.
• Adopt GA4GH standards by use case, not by default. A platform serving a single lab's internal reporting workflow needs FHIR and HL7 v2 fluency more than it needs Beacon federated discovery. A platform supporting multi-institution research data sharing needs the opposite emphasis. Matching the standard to the actual data flow avoids both under-building (missing a capability a real workflow needs) and over-building (implementing federated discovery infrastructure nobody queries).

For genomics platforms operating in the US specifically, one regulatory deadline makes this architecture time-sensitive rather than optional. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires affected payers to implement HL7 FHIR R4–based APIs for patient access, provider access, payer-to-payer data exchange, and electronic prior authorization, with core API requirements due by January 1, 2027. Any genomics platform whose results or reports feed into prior authorization workflows therefore needs FHIR R4 conformance in production well before that date, not as a distant roadmap item. Labs and platforms that treat FHIR adoption as a "nice-to-have" standard are working against a fixed regulatory timeline, not an open-ended best practice.

How NonStop approaches this

NonStop builds the HL7 v2, FHIR R4, and SMART on FHIR integration layer directly into genomics platforms, connecting EHRs including Epic and Cerner, LIMS systems, and sequencing instruments so data moves as one traceable, auditable workflow rather than a set of point-to-point scripts. Variant representation and interpretation work is built around ACMG/AMP 2015 classification and integrates with reference knowledge bases including ClinVar, gnomAD, and OMIM, using the standard genomic file formats (VCF, GVCF, BAM/CRAM) throughout.

Audit trails, access controls, and human-in-the-loop review are engineered into the integration layer itself, so the interoperability work that makes a platform FAIR also satisfies the auditability a CLIA or CAP inspection expects. Across the six solutions NonStop has built for genomics and clinical labs, from requisition intake through signed clinical report, interoperability is treated as core architecture decided at the start of a build, not an integration project added once the rest of the platform is already in production.

Frequently asked questions

1. Wilkinson, M. et al., "The FAIR Guiding Principles for scientific data management and stewardship," Scientific Data, 2016
2. GA4GH, data-sharing overview and federated genomic data infrastructure review, ga4gh.org
3. GA4GH, international policies and standards for data sharing, ga4gh.org
4. HL7, SMART on FHIR implementation guide, hl7.org
5. GA4GH, Phenopacket schema documentation, ga4gh.org
6. GA4GH, Beacon v2 documentation, ga4gh.org
7. GA4GH, htsget and refget specifications, ga4gh.org
8. GA4GH, Cloud Work Stream (DRS, WES, TES), ga4gh.org
9. GA4GH, Variation Representation Specification (VRS), ga4gh.org
10. GA4GH, Data Use Ontology (DUO), ga4gh.org
11. CMS-0057-F, Interoperability and Prior Authorization Final Rule, cms.gov