HL7 FHIR and pedigree data: FamilyMemberHistory, the Genomics IG, and how Evagene fits

Short version. FHIR is the dominant healthcare interoperability standard, and the FamilyMemberHistory resource is its primary anchor for pedigree data. The FHIR Genomics Implementation Guide extends it with genomic Observation profiles and MolecularSequence, but there is no single universal "FHIR Pedigree" resource. Evagene does not expose a native FHIR endpoint today; it exposes a scoped REST API with JSON payloads plus GEDCOM 5.5.1 import and export, and webhooks for event-driven sync. Teams that need FHIR today typically build a thin FHIR facade on top of Evagene's REST API, mapping Evagene individuals and conditions onto FamilyMemberHistory, Patient, Condition, and RiskAssessment. Native FHIR is on the roadmap.

If you are evaluating pedigree platforms against a FHIR procurement requirement, be honest with yourself about what "FHIR support" needs to mean for your service. A FHIR resource server that serves FamilyMemberHistory/{id} natively is one thing. A platform that exposes enough of its data model through a clean API that you can build a FHIR facade in a few days is another. This article walks through both ends of the spectrum, the resources involved, and how Evagene currently fits.

What FHIR actually is (in two minutes)

HL7 FHIR (Fast Healthcare Interoperability Resources) is the HL7 International standard for exchanging healthcare information electronically. Its core design is a set of modular resources — Patient, Encounter, Observation, Condition, MedicationRequest, and dozens more — each with a defined JSON and XML representation, a RESTful API for create, read, update, delete, and search, and extension points through profiles. FHIR R4 is the version most production deployments currently use; FHIR R5 and subsequent releases continue to evolve the standard.

For pedigree data, the resources that matter most are:

• Patient — the individual at the centre of the record, typically the proband.
• FamilyMemberHistory — a relative of the patient, with relationship, sex, age, conditions, and cause of death.
• Condition — a diagnosis or clinical concern attached to the patient (not directly used on relatives within FamilyMemberHistory itself).
• Observation — structured clinical findings, including genomic observations under the Genomics IG.
• RiskAssessment — a risk estimate for a condition (useful for recording BRCAPRO, MMRpro, and PancPRO outputs).
• MolecularSequence — sequence data, primarily under the Genomics IG.
• DocumentReference / Composition — containers for narrative reports, such as AI-generated clinical interpretation.

FamilyMemberHistory: the pedigree anchor

FamilyMemberHistory is the FHIR resource that represents "significant health events and conditions for a person related to the patient, with their relationship recorded." Each instance corresponds to one relative. Key fields include:

• patient — reference to the proband Patient resource.
• relationship — CodeableConcept using the v3-RoleCode or a similar value set (e.g. MTH for mother, FTH for father, SIS for sister).
• sex — AdministrativeGender.
• bornDate / age — either the date of birth or an age representation.
• deceasedBoolean / deceasedAge / deceasedDate — mortality status and, optionally, age or date at death.
• condition — a backbone element listing diagnoses, each with its own coding (SNOMED CT, ICD-10, or OMIM), optional onset, and an optional outcome concept.

The shape of a FamilyMemberHistory resource looks like this:

{
  "resourceType": "FamilyMemberHistory",
  "status": "completed",
  "patient": { "reference": "Patient/proband-123" },
  "relationship": {
    "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
                 "code": "MTH", "display": "mother" }]
  },
  "sex": { "coding": [{ "system": "http://hl7.org/fhir/administrative-gender",
                        "code": "female" }] },
  "bornDate": "1952-03-14",
  "deceasedBoolean": false,
  "condition": [{
    "code": { "coding": [{ "system": "http://hl7.org/fhir/sid/icd-10",
                           "code": "C50.9", "display": "Breast cancer" }] },
    "onsetAge": { "value": 47, "unit": "a" }
  }]
}

What FamilyMemberHistory does not capture natively:

• Relationships between relatives (only to the patient). A sister-of-sister relationship is implied via both sharing MTH/FTH of the proband, not explicitly linked.
• Pedigree drawing layout (x/y coordinates, symbol choice).
• Consanguinity loops explicitly; these must be inferred or carried as extensions.
• Monozygotic twin grouping beyond the standard extensions.

Pedigree tools that use FHIR as their interchange format therefore either stay within FamilyMemberHistory's limits or use FHIR extensions and/or the Genomics IG's additional resources to carry the missing information.

The FHIR Genomics Implementation Guide

The FHIR Genomics IG is the main place the standard addresses genomic findings. It profiles Observation for variant, diagnostic implication, molecular consequence, and therapeutic implication; it profiles MolecularSequence for the sequence data itself; and it defines diagnostic report bundles that tie observations, sequences, and interpretation together. For pedigree work, the Genomics IG provides:

• Profiles for representing genetic variants observed in the proband or in relatives.
• Links from variants back to Patient resources, which combined with FamilyMemberHistory yields the full pedigree-plus-variants picture.
• Patterns for inheritance pattern annotation (autosomal dominant, X-linked recessive, etc.).

In practice, a clinically useful FHIR representation of a pedigree is a bundle: one Patient (the proband), many FamilyMemberHistory entries, optional RiskAssessment instances carrying BRCAPRO/MMRpro/PancPRO outputs, and Genomics-IG Observations for any molecular findings.

Mapping an Evagene pedigree onto FHIR

Evagene's internal data model is a directed graph of individuals and relationships, with structured disease annotation from an ICD-10 / OMIM-backed catalogue of 200+ conditions, risk analysis outputs (BRCAPRO, MMRpro, PancPRO, Mendelian), and AI interpretation documents. Mapping this onto FHIR is mechanical:

• Evagene proband -> FHIR Patient. Conditions on the proband become Condition resources referencing the Patient.
• Evagene relatives -> FHIR FamilyMemberHistory, one per individual, with the relationship coded against v3-RoleCode. Evagene's disease annotations (ICD-10 / OMIM codes) drop into FamilyMemberHistory.condition.code.coding.
• Evagene risk analyses (BRCAPRO etc.) -> FHIR RiskAssessment resources, with basis referencing the relevant FamilyMemberHistory entries and prediction.probabilityDecimal carrying the computed risk.
• Evagene AI interpretations -> FHIR DocumentReference pointing to the stored interpretation text, or a Composition for a structured report.
• Evagene imports/exports (GEDCOM round-trip) -> the same FHIR bundle structure can be produced or consumed alongside GEDCOM.

This mapping is not unique to Evagene — it is the same translation most pedigree systems need to do to speak FHIR, whether natively or through a facade.

Native FHIR vs a FHIR facade: the honest trade-off

There are two ways a pedigree platform can "support FHIR":

1. Native FHIR resource server. The platform exposes endpoints such as /FamilyMemberHistory?patient=123 that return FHIR resources directly, conforming to a published CapabilityStatement. TrakGene, for example, advertises native FHIR integration. For institutions whose IT estate is organised around a FHIR gateway, this is the lowest-friction option.
2. REST API plus a thin FHIR facade. The platform exposes its own well-designed REST API with JSON payloads. A small adapter service (often written by the integrating team in a few hundred lines of Python or Node) translates between the platform's REST surface and FHIR resources. This is how most institutional integrations actually get built, because the facade is where organisation-specific coding conventions, value sets, and extensions live anyway.

Evagene today sits firmly in the second camp. It does not advertise a native FHIR resource server. It does expose a scoped, rate-limited REST API (keys in the format evg_<43 chars>, SHA-256 hashed at rest, with read/write/analyse scopes), webhooks with HMAC-SHA256 signed payloads, and GEDCOM 5.5.1 import and export. These are the building blocks a FHIR facade needs.

Whether that is acceptable for a given procurement depends on the buying organisation. Some hospitals will only accept a native FHIR endpoint; others are comfortable with a facade maintained by the integration team because it gives them control over terminology bindings and extensions. The answer is workflow-specific, not technology-specific.

How this works in Evagene

An integrating team building a FHIR facade on top of Evagene typically does the following:

1. Generate a read-scope API key in Evagene's account panel. Store it in the facade's secret manager.
2. Implement the facade as a small service that receives FHIR requests, translates them into Evagene REST API calls, and translates the JSON response back into FHIR resources.
3. Subscribe a webhook on Evagene (pedigree.updated, individual.updated, analysis.completed) so the facade can invalidate caches or push FHIR Subscription notifications downstream when data changes.
4. Embed the Evagene pedigree viewer (iframe, SVG, or JavaScript snippet) inside the EHR or portal's view layer so clinicians see the pedigree visually, while the FHIR layer carries the structured data.
5. Use Evagene Analysis Templates (with variable injection such as {{pedigree_description}}) to produce AI interpretations that are stored as DocumentReferences.

A request flowing through the facade looks, in shape, like this:

GET /FamilyMemberHistory?patient=Patient/proband-123
Accept: application/fhir+json

# Facade translates to:
GET /api/pedigrees/{pedigree_id}/individuals
X-API-Key: evg_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# Evagene returns individuals as JSON
# Facade maps each non-proband individual to a
# FamilyMemberHistory resource and returns a Bundle.

For teams with strong FHIR opinions, the facade is where those opinions live: your ValueSets, your extensions, your national IG profile. Evagene stays out of the way.

What is on the roadmap

Native FHIR support — a CapabilityStatement, FHIR R4 and R5 resource endpoints for FamilyMemberHistory, Patient, Condition, and RiskAssessment, and Genomics-IG-conformant Observation output — is an active area of platform work. If this is a procurement-blocker for your service today, please raise it via the Alpha waiting list so we can prioritise accordingly and, where useful, share design drafts with early adopters.

Frequently asked questions

Related reading

• Evagene platform overview: API, MCP, webhooks, embeds
• EHR pedigree integration: Epic, Cerner, SMART-on-FHIR
• Pedigree REST API: endpoints, auth, and worked examples
• GA4GH Phenopackets and pedigree data
• GEDCOM pedigree software
• Phenotips vs Evagene

Further reading: Evagene platform documentation at evagene.net/help/platform_overview.