OncIOS admissions never appear in planned_movement because ADT and ORU messages disagree on the subspecialty at source
Summary
Two admissions to "OncIOS" (Oncology – Interventional Oncology Service) never appear anywhere in planned_movement — it records an Interventional Radiology code instead (IntRad INR / IntRad Gen). This isn't a planned_movement defect: the HL7 messages for these encounters disagree with each other before either downstream system reads them.
Evidence
For both encounters, checking the raw HL7 feed directly:
ADT messages for the encounter carry "IntRad Gen" as the subspecialty throughout.
ORU (results) messages for the same encounter carry "OncIOS" instead.
The two message types disagree with each other at the point of origin. Since planned_movement is built from the ADT stream, "OncIOS" was never available to it — it isn't a value that got dropped or missed downstream, it simply never appears in the message type planned_movement reads from.
Scope
Confirmed in 2 cases so far, both under this specific service.
Why this is being raised here
planned_movement is behaving as expected given its inputs — there's no ingestion change that would fix this, since the correct value is never present in the ADT stream it's built from. This is raised so it's on record, and so whoever owns HL7 interface configuration for this service can look into why ADT and ORU messages carry different subspecialty codes for the same encounter.
Open question
Why do ADT and ORU messages disagree on the subspecialty code for OncIOS specifically? Is this specific to how the Interventional Oncology service is configured in the source system, or could it affect other services too?
OncIOS admissions never appear in
planned_movementbecause ADT and ORU messages disagree on the subspecialty at sourceSummary
Two admissions to "OncIOS" (Oncology – Interventional Oncology Service) never appear anywhere in
planned_movement— it records an Interventional Radiology code instead (IntRad INR / IntRad Gen). This isn't aplanned_movementdefect: the HL7 messages for these encounters disagree with each other before either downstream system reads them.Evidence
For both encounters, checking the raw HL7 feed directly:
ADTmessages for the encounter carry "IntRad Gen" as the subspecialty throughout.ORU(results) messages for the same encounter carry "OncIOS" instead.The two message types disagree with each other at the point of origin. Since
planned_movementis built from the ADT stream, "OncIOS" was never available to it — it isn't a value that got dropped or missed downstream, it simply never appears in the message typeplanned_movementreads from.Scope
Confirmed in 2 cases so far, both under this specific service.
Why this is being raised here
planned_movementis behaving as expected given its inputs — there's no ingestion change that would fix this, since the correct value is never present in the ADT stream it's built from. This is raised so it's on record, and so whoever owns HL7 interface configuration for this service can look into why ADT and ORU messages carry different subspecialty codes for the same encounter.Open question
Why do ADT and ORU messages disagree on the subspecialty code for OncIOS specifically? Is this specific to how the Interventional Oncology service is configured in the source system, or could it affect other services too?