Scope and Usage

Problem Statement

Tulip farmers today manage variety catalogues and bulb inventory through ad-hoc spreadsheets and paper logs. This makes it difficult to query stock across growing seasons, share information with other systems, or audit provenance. The TulipCare Implementation Guide (canonical https://fake-acme.org/fhir/TulipCare, package acme.tulip) solves this by defining a FHIR R4–based data exchange standard for two core domains:

1. Tulip Variety Catalogue – structured records of cultivar or species entries, capturing horticultural classification and bloom characteristics.
2. Bulb / Batch Inventory – records of individual bulbs or counted batches, including provenance, quantity, planting status, and linkage to a registered variety.

Actors

Three primary actors participate in the exchanges defined by this IG:

Tulip Farmer (End User) is the primary data owner. The farmer creates and updates variety and bulb records and queries the system to review inventory.

Farmer Client Application is the software the farmer directly interacts with — a UI or lightweight integration client. It translates the farmer's data-entry actions into conformant FHIR R4 REST requests (HTTP POST, PUT, GET with search parameters) and renders server responses in human-readable form.

TulipCare FHIR Server is the authoritative data store. It persists variety and bulb resources, enforces cardinality and terminology validation, exposes the defined search parameters, and returns FHIR resource bundles, individual resources, and OperationOutcomes.

An optional Terminology Service may be used by the server to validate coded values (tulip class, bloom season, bulb status) via $validate-code and $expand operations. In version 1, code validation may be performed locally.

Scope

In Scope

• A catalogue of tulip varieties with horticultural attributes: variety name, tulip class (13 KAVB groups), bloom season, height range, and flower colour.
• Bulb and batch inventory records with unique identifiers, quantity, supplier, acquisition date, planting location, planting date, and lifecycle status.
• Linking each bulb/batch record to its parent variety.
• FHIR R4 RESTful CRUD operations (create, read, update, search) on variety and bulb records.
• Terminology resources: local CodeSystems and ValueSets for TulipClass, BloomSeason, and BulbStatus.

Out of Scope

• Sales, invoicing, or supply-chain transactions.
• Soil, weather, or environmental sensor data.
• Disease or pest tracking (potential future extension).
• Harvest yield recording (potential future extension).
• Multi-farm or multi-tenant access control beyond basic FHIR security.
• Structured supplier or location entities (plain strings used in v1).

FHIR Version and Key Profiles

This IG targets FHIR R4 (4.0.1). The headline profiles are:

• TulipVariety – a profiled Basic resource (or domain-specific logical model projection) carrying all variety catalogue fields. Optional horticultural attributes are represented via dedicated extensions: ext-bloomSeason, ext-heightRangeMin, ext-heightRangeMax, ext-flowerColour, and ext-varietyRecordedDate.
• TulipBulb – a profiled resource carrying all bulb/batch inventory fields. Inventory-specific data is carried through extensions: ext-bulbStatus, ext-acquisitionDate, ext-plantingDate, ext-plantingLocation, ext-supplier, and ext-recordedDate.

Supporting logical models (TulipVariety and TulipBulb logical model StructureDefinitions) formally document the conceptual data model and are mapped to their profile counterparts via the TulipBulb ConceptMap. Terminology is governed by local CodeSystems and ValueSets for BloomSeason, BulbStatus, and TulipClass.