HL7 QSB_Q16 Create Subscription
HL7 message structure QSB_Q16 groups and segments from HL7 v2.5.1 Hide structure
These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.
Message Structure
QSB_Q16 creates a subscription. Instead of asking for a one-time answer, the requester sends parameters that describe which future results or events it wants to receive.
This is a powerful shape and a risky one. A subscription that is too broad can create a long-running feed that nobody remembers to turn off.
A small QSB Q16 example
What systems do with it
The requester asks the responder to create a subscription using the parameters in QPD. The responder then uses the agreed response or notification pattern to deliver matching future data. RCP controls response priority, quantity, and timing expectations.
A subscription should have an owner, a scope, and a cleanup path. In a well-run interface, operations staff can answer who created it, what it matches, and how to cancel it.
How to read the structure
MSH identifies QSB^Q16^QSB_Q16. QPD carries the subscription definition and query tag. RCP tells the responder how the requester wants matching results returned. Optional DSC supports continuation when needed.
Implementation traps
Make the cancellation policy part of the interface, not an afterthought. A system that can create subscriptions but cannot find or cancel them will eventually generate stale feeds.
Also decide whether the subscription starts from now, from an explicit timestamp, or from the responder's last known state. That detail changes whether the requester misses data or receives duplicates.
Reference notes
HL7 v2 includes QSB_Q16 as a create subscription message built around QPD and RCP. See the HL7 v2.7.1 event page for Q16.