La risorsa ServiceRequest (Richiesta di Servizio) è il punto di partenza per molte delle interazioni e dei flussi di lavoro clinici in FHIR. Serve a formalizzare la necessità di un’azione o di un servizio sanitario.

È essenzialmente l’ordine di servizio o la richiesta che avvia un processo, sia esso diagnostico, terapeutico, o assistenziale.

1. Funzione e Scopo Principale

• Definizione: ServiceRequest è l’istanza di una richiesta da parte di un operatore sanitario (o sistema) affinché venga eseguita una specifica attività per o sul paziente.
• Ruolo nel Workflow: Colma il divario tra una diagnosi (Condition) o un incontro (Encounter) e l’azione effettiva che ne consegue (Observation o Procedure). È la pre-condizione per risorse successive.
• Differenza chiave: A differenza di Observation (che è il risultato) o Procedure (che è l’azione eseguita), ServiceRequest è il desiderio o l’ordine di eseguire quell’azione.

2. Elementi Chiave di ServiceRequest

Come tutte le risorse FHIR, ServiceRequest ha elementi obbligatori e opzionali, ma alcuni sono fondamentali per capire la richiesta:

Elemento	Tipo di Dato	Descrizione
status (?!)	code	Lo stato corrente della richiesta: active, completed, draft, cancelled, ecc. È un modificatore (?!) perché un servizio annullato non può essere ignorato.
intent	code	Lo scopo della richiesta: plan (piano), order (ordine), proposal (proposta). Solitamente è order o plan.
subject	Reference(Patient)	Chi è il destinatario del servizio (il paziente). Obbligatorio.
requester	Reference(Practitioner/Organization)	Chi ha fatto la richiesta (es. il medico curante o l’ospedale).
code	CodeableConcept	Cosa deve essere fatto. Usa sistemi di codifica come LOINC o SNOMED CT per identificare l’esame o l’intervento.
occurrence[x]	dateTime/Period/ecc.	Quando il servizio dovrebbe essere eseguito (data o intervallo di tempo).

3. Esempio Italiano: La Ricetta per Esami di Laboratorio

ServiceRequest è la risorsa FHIR più adatta a rappresentare l’equivalente digitale strutturato di una Ricetta (Prescrizione) per Esami di Laboratorio o per una visita specialistica.

Scenario: Il Medico richiede un Emocromo

Un medico (dott. Rossi) visita il paziente Mario Rossi e ordina un emocromo completo.

Campo ServiceRequest	Esempio Valore (in JSON)	Note
"resourceType"	"ServiceRequest"	Indica il tipo di risorsa.
"id"	"SR-00123"	ID univoco della richiesta.
"status"	"active"	La richiesta è valida e in attesa di essere eseguita.
"intent"	"order"	È un ordine attivo per un servizio.
"subject"	{"reference": "Patient/456", "display": "Mario Rossi"}	Riferimento al paziente.
"requester"	{"reference": "Practitioner/789", "display": "Dott. Rossi"}	Riferimento al medico che ordina l’esame.
"code"	{"coding": [{"system": "http://loinc.org", "code": "58410-2", "display": "Complete Blood Count (CBC)"}]}	Codice LOINC per l’emocromo completo.
"occurrenceDateTime"	"2025-10-30"	Il medico desidera l’esame il 30 ottobre 2025.

Flusso di Lavoro (Workflow)

1. Il sistema del medico crea questa ServiceRequest.
2. Il Laboratorio Analisi riceve la ServiceRequest (status: active).
3. Il laboratorio preleva il campione (Specimen).
4. Il laboratorio esegue l’analisi e crea la risorsa Observation (il risultato dell’emocromo).
5. Il laboratorio crea la risorsa DiagnosticReport (il referto).
6. La ServiceRequest viene aggiornata a status completed (completata), con un riferimento (reasonReference) al DiagnosticReport generato.

In questo modo, ServiceRequest non solo ordina l’azione, ma ne traccia anche l’intero ciclo di vita all’interno del sistema sanitario.

The FHIR ServiceRequest Resource: The Workflow “Engine”

 

The ServiceRequest (Service Request) resource is the starting point for many clinical interactions and workflows in FHIR. It serves to formalize the need for a healthcare action or service.

It is essentially the service order or request that initiates a process, whether it is diagnostic, therapeutic, or care-related.

 

1. Function and Primary Purpose

 

• Definition: ServiceRequest is the instance of a request by a healthcare provider (or system) for a specific activity to be performed for or on the patient.
• Role in Workflow: It bridges the gap between a diagnosis (Condition) or an encounter (Encounter) and the actual resulting action (Observation or Procedure). It is the pre-condition for subsequent resources.
• Key Difference: Unlike Observation (which is the result) or Procedure (which is the action performed), ServiceRequest is the desire or order to perform that action.

 

2. Key Elements of ServiceRequest

 

Like all FHIR resources, ServiceRequest has mandatory and optional elements, but some are fundamental to understanding the request:

Element	Data Type	Description
status (?!)	code	The current status of the request: active, completed, draft, cancelled, etc. It is a modifier (?!) because a cancelled service cannot be ignored.
intent	code	The purpose of the request: plan, order, proposal. It is usually order or plan.
subject	Reference(Patient)	Who is the recipient of the service (the patient). Mandatory.
requester	Reference(Practitioner/Organization)	Who made the request (e.g., the treating physician or the hospital).
code	CodeableConcept	What needs to be done. It uses coding systems like LOINC or SNOMED CT to identify the exam or intervention.
occurrence[x]	dateTime/Period/etc.	When the service should be performed (date or time range).

 

3. Italian Example: The Lab Test Prescription

 

ServiceRequest is the most suitable FHIR resource to represent the structured digital equivalent of a Prescription for Lab Tests or for a specialist consultation.

 

Scenario: The Physician Requests a Complete Blood Count

 

A physician (Dr. Rossi) sees the patient Mario Rossi and orders a complete blood count.

ServiceRequest Field	Example Value (in JSON)	Notes
"resourceType"	"ServiceRequest"	Indicates the resource type.
"id"	"SR-00123"	Unique ID of the request.
"status"	"active"	The request is valid and pending execution.
"intent"	"order"	It is an active order for a service.
"subject"	{"reference": "Patient/456", "display": "Mario Rossi"}	Reference to the patient.
"requester"	{"reference": "Practitioner/789", "display": "Dr. Rossi"}	Reference to the ordering physician.
"code"	{"coding": [{"system": "http://loinc.org", "code": "58410-2", "display": "Complete Blood Count (CBC)"}]}	LOINC code for the Complete Blood Count.
"occurrenceDateTime"	"2025-10-30"	The physician wants the exam on October 30, 2025.

 

Workflow

 

1. The physician’s system creates this ServiceRequest.
2. The Clinical Lab receives the ServiceRequest (status: active).
3. The lab collects the sample (Specimen).
4. The lab performs the analysis and creates the Observation resource (the blood count result).
5. The lab creates the DiagnosticReport resource (the report).
6. The ServiceRequest is updated to status completed, with a reference (reasonReference) to the generated DiagnosticReport.

In this way, ServiceRequest not only orders the action but also tracks its entire lifecycle within the healthcare system.