Referral intake needs a minimum usable data set
The minimum data set is not bureaucratic overhead. It is the information the receiving organization needs to decide whether the request is for the right patient, the right service, at the right urgency, with enough context to act.
FHIR and HL7 give you transport structures, but local programs still need explicit validation rules. In practice, identity fields, requester identity, requested service, reason, urgency, and supporting evidence are the difference between straight-through processing and expensive rework.
Referral intake example
A representative ServiceRequest showing the kinds of fields that intake teams validate before routing or triage.
Click on an annotation to highlight it in the JSON
This chart does not define the referral minimum data set by itself, but it helps explain why validation rules exist in the first place: incomplete requests are common enough to change workload, delay diagnosis, and force clarification loops.
HISO 10008.2 pathology and radiology messaging standard
Health New Zealand messaging standard for adapting HL7 v2.4 pathology and radiology payloads to the national context.
Read HISO 10008.2Incomplete radiology requests audit
Peer-reviewed audit illustrating how often real-world radiology requests arrive without enough information to proceed cleanly.
Read the quality auditValidation gates keep automation honest
Intake systems should make unsafe referrals visible early. That means explicit states for accepted, waiting-for-information, and rejected requests rather than burying uncertainty inside free text notes or ad hoc work queues.
Referral intake validation states
Loading diagram...
Validation is not the same as triage
Validation asks whether the referral can be acted on safely. Triage asks how quickly and by whom it should be acted on. Mixing those steps creates inconsistent queues and opaque statuses.
Contained HISO 10011.3 referral implementation guide
Contained legacy business-event guide for representing referral state changes such as receive, validate, assign, triage, and discharge.
Read HISO 10011.3 (contained guide)ServiceRequest - FHIR v4.0.1
Official FHIR order resource used by many modern referral and diagnostic-request implementations.
Review the order resourceNormalization happens before smart routing
Real intake queues receive variable source data: old patient identifiers, partial provider names, local service mnemonics, and free-text urgency labels. A workflow engine cannot safely route those values until they are mapped into canonical identities and service definitions.
Normalization is where the platform decides whether two identifiers refer to the same person, whether the requester is a trusted sender, which service-catalog entry the request actually maps to, and which priority vocabulary the local program recognizes.
Normalization before routing
Loading diagram...
Normalization is not cosmetic cleanup
If the intake platform normalizes poorly, every later step inherits the error: the wrong queue, the wrong service, the wrong patient record, or the wrong clarification target.
Health identity developer guidance (NHI and HPI)
Health New Zealand developer guidance on using national NHI and HPI services when systems need authoritative patient and provider identity data.
Review identity integration guidanceHISO 10008.2 pathology and radiology messaging standard
National messaging standard that illustrates the local field and code constraints intake engines need to normalize and validate.
Read HISO 10008.2Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.