SENAITEFHIRImplementationGuide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Concept Map

SENAITE Object Model and FHIR Concept Map

This page describes how SENAITE's internal object model relates to FHIR R5 resources as used in this Implementation Guide. Understanding this mapping is essential context before reading the workflow pages.

Representation vs. Origin

A key distinction in this IG is between representation (how a SENAITE object is expressed as a FHIR resource) and origin (how a SENAITE object may have been created). These are not always the same thing — see the AnalysisRequest section below for the most important example of this.

Object Mappings

AnalysisRequest (Sample)

An AnalysisRequest is SENAITE's central object representing a laboratory sample and the tests requested against it. Depending on context, it is represented by two FHIR resources:

Direction	SENAITE Object	FHIR Resource	Notes
SENAITE → FHIR	AnalysisRequest	DiagnosticReport	The completed or in-progress result report
SENAITE → FHIR	AnalysisRequest	Specimen	The physical specimen associated with the sample

Relationship to ServiceRequest

An AnalysisRequest may be traceable to an inbound ServiceRequest, but this is not always the case:

• EHR-originated requests: When an EHR submits a lab request via this API (as a SenaiteRequestBundle), SENAITE creates a new AnalysisRequest from the inbound ServiceRequest. In this case DiagnosticReport.basedOn references the originating ServiceRequest, recording the chain of custody.
• SENAITE-originated requests: AnalysisRequest objects created directly within SENAITE — for example, walk-in patients, paper requisition entry, or instrument-driven workflows — have no corresponding ServiceRequest. These are not exposed as ServiceRequest resources via this API.

In short: ServiceRequest → creates → AnalysisRequest, but not every AnalysisRequest has a ServiceRequest.

---

Patient

Direction	SENAITE Object	FHIR Resource	Notes
Bidirectional	Patient	Patient	Submitted inbound as part of a SenaiteRequestBundle; read back via the results API

---

Client Contact (Ordering Practitioner)

Direction	SENAITE Object	FHIR Resource	Notes
Bidirectional	Client Contact	Practitioner	A Practitioner submitted in a request bundle is used to derive or match a SENAITE Client Contact representing the ordering clinician; Client Contact records are also readable as Practitioner resources via the API

---

Client (Submitting Organisation)

Direction	SENAITE Object	FHIR Resource	Notes
Bidirectional	Client	Organization	An Organization submitted in a request bundle is used to derive or match the SENAITE Client; Client records are also readable as Organization resources via the API. Identified on the ServiceRequest via the SenaiteClient extension.

---

Analysis (Test Result)

Direction	SENAITE Object	FHIR Resource	Notes
SENAITE → FHIR	Analysis	Observation	Each individual test result within a sample maps to an Observation, grouped under a DiagnosticReport

---

Instrument

Direction	SENAITE Object	FHIR Resource	Notes
SENAITE → FHIR	Instrument	Device	SENAITE Instrument records are represented as Device resources; instruments are managed within SENAITE and identified in outbound instrument integration bundles

---

Summary Table

SENAITE Object	FHIR Resource	Relationship
AnalysisRequest	DiagnosticReport	Represented as
AnalysisRequest	Specimen	Represented as
Patient	Patient	Bidirectional
Client Contact	Practitioner	Bidirectional
Client	Organization	Bidirectional
Analysis	Observation	Represented as
Instrument	Device	Represented as
(new AnalysisRequest)	ServiceRequest	Created from inbound

Note: ServiceRequest appears in the table as a trigger for creation, not as a direct representation of an existing SENAITE object. A ServiceRequest arriving via the API causes SENAITE to create an AnalysisRequest; not all AnalysisRequest objects have a corresponding ServiceRequest.