Huli FHIR Core Implementation Guide (R4)
0.1.0 - Release
Huli FHIR Core Implementation Guide (R4) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
| Huli FHIR R4 Server Capabilities |
Declared capabilities of the Huli Public FHIR R4 API at https://api.huli.io/fhir/R4. |
These are custom operations that can be supported by and/or invoked by systems conforming to this implementation guide.
| Subscription $deliveries |
Recent per-attempt delivery trail for a subscription, newest first. Sanitized — never exposes payloads, endpoints, or secrets. Read-only; requires system/Subscription.rs. |
| Subscription $replay |
Re-enqueue past events whose occurred_at falls in a [from,to] window, for outage recovery / backfill. Only an active subscription may replay; the window is clamped to the retention horizon and one call re-enqueues at most 500 events. Requires system/Subscription.crud. |
| Subscription $stats |
Aggregate delivery metrics for a subscription. Read-only; requires system/Subscription.rs. |
| Upload a DocumentReference binary |
Create a DocumentReference together with its binary in one request. Two intake modes are accepted: (1) an inline DocumentReference whose binary rides in content[0].attachment.data (base64); (2) a multipart/form-data body with a |
These define constraints on FHIR resources for systems conforming to this implementation guide.
| Huli Appointment |
Appointment profile for the Huli healthcare platform. Covers scheduling workflows including multi-resource participants (practitioners, rooms, equipment), FHIR-aligned status lifecycle, and SNOMED-coded appointment types. Key design decisions:
|
| Huli Composition |
Clinical-note projection of a Huli encounter.
|
| Huli Condition |
Minimal Condition profile for encounter-level diagnoses. Used as the target
of Diagnoses in Huli are ICD-10 coded with
system URI |
| Huli DocumentReference |
Pointer to an uploaded patient document. |
| Huli Encounter |
Encounter profile for the Huli healthcare platform. Represents ambulatory, emergency, inpatient, and virtual encounters with the SOAP-structured clinical workflow. Key design decisions:
|
| Huli Observation |
Observation profile covering vital signs, laboratory results, and clinical exam findings recorded against a Huli patient and (optionally) encounter. Key design decisions:
|
| Huli Organization |
Organization profile for the clinics, practices, and health systems that use Huli. Read-only on the Public API; provisioning happens during organization onboarding rather than through partner-facing FHIR writes. Each Huli organization maps to a single Organization resource. |
| Huli Patient |
Patient profile for the Huli healthcare platform. Encodes the Huli patient data model including multi-surname naming conventions (LATAM, Iberian, Filipino, etc.), national identifiers (CURP, RFC, NSS, INE for MX; CED, DIMEX for CR; DPI for GT; PPN passports; MR medical record numbers), and demographics required by Mexican NOM-024. Key design decisions:
Identifier system URIs:
|
| Huli Practitioner |
Practitioner profile for clinicians registered in Huli. Read-only on the Public API; provisioning happens through the operator-facing Huli platform rather than through partner-facing FHIR writes. The Public API emits the practitioner's display name (given +
primary surname, plus an optional second surname carried on the
|
These define constraints on FHIR data types for systems conforming to this implementation guide.
| Huli Blood Type |
The patient's blood type. Emitted by the runtime as Mapping: the patient's recorded blood type. |
| Huli Cancellation Info |
Audit detail about an appointment cancellation. The structured FHIR
Sub-extensions:
|
| Huli Confirmation Status |
Patient confirmation status for an appointment, representing whether the
patient has confirmed, declined, or not yet responded to the appointment.
This is distinct from Runtime values (emitted by the runtime):
Mapping: server-derived; emits one of the runtime codes above. Read-only on write. |
| Huli Created By |
Audit attribution: the internal Huli user who created the appointment. Distinct from Appointment.participant, which records clinical participants rather than the actor who booked the slot. The actor can be ANY staff identity — practitioner, receptionist,
accountant, a service account, or the Huli "Sistema" sentinel — and is not
exposed as a resource on this API. The value is therefore a logical
reference: Mapping: the id of the user who created the appointment, projected as
|
| Huli Ethnicity (experimental — IG-only) |
Ethnicity classification for Latin American healthcare contexts, aligned with Mexican NOM-024-SSA3 requirements for tracking indigenous and Afro-descendant populations. Status — experimental and IG-only. This extension defines a
forward-compatible contract for ethnicity data. The Public API does
not emit it on Mapping shape: sourced from the patient demographics' ethnicity
sub-object. A |
| Huli Insurance Snapshot |
Point-in-time insurance snapshot captured at the moment an appointment was booked. Independent of the patient's current insurance list — the snapshot is immutable history attached to the appointment. Sub-extensions:
Mapping: the insurance details captured on the appointment at booking time. |
| Huli Modified By |
Audit attribution: the internal Huli user who last modified the appointment. Companion
to Mapping: the id of the user who last modified the appointment, projected as
|
| Huli Private Insurance |
Private insurance entry attached to a patient. The runtime emits one
Sub-extensions:
|
| Huli Second Lastname |
The patient's second family name, following multi-surname naming
conventions (LATAM, Iberian, Filipino, etc.). Placed on In Mexico, this maps to the |
These define sets of codes used by systems conforming to this implementation guide.
| Huli Appointment Type Value Set |
SNOMED CT-coded appointment types used in the Huli scheduling system. |
| Huli Cancellation Reason Value Set |
Reasons for appointment cancellation. Includes SNOMED-coded reasons where available and Huli-defined codes for operational reasons. |
| Huli Confirmation Status Value Set |
Patient confirmation statuses for appointment workflows. |
| Huli Ethnicity Value Set |
Ethnicity categories for Latin American healthcare contexts. |
These define new code systems used by systems conforming to this implementation guide.
| Huli Address Source Code System |
Provenance of an address value emitted by the Huli Public API. |
| Huli Cancellation Reason Code System |
Appointment cancellation reasons that do not have standard SNOMED CT codes. Used as a supplement to SNOMED-coded reasons. |
| Huli Confirmation Status Code System |
Patient confirmation status for appointments. Represents whether the patient
has responded to the appointment notification or whether the appointment was
cancelled before confirmation. The Public API emits one of
|
| Huli Ethnicity Code System |
Ethnicity categories for Latin American healthcare contexts, aligned with Mexican NOM-024-SSA3 requirements for demographic tracking. |
| Huli Organization Service Code System |
Identity of an entry in an organization's service catalog. The code is the org-service UUID. Emitted on HealthcareService.type.coding so a booking client can copy it verbatim onto Appointment.serviceType. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| Ejemplo: Cita consulta general |
Synthetic booked appointment with practitioner and patient participants. |
| Ejemplo: Consulta ambulatoria |
Synthetic ambulatory encounter with a diagnosis. |
| Ejemplo: Paciente Maria |
Synthetic patient demonstrating LatAm naming, CURP, and demographics. |