HL7 CQU messages query a clinical trials database or patient record repository for study-related patient data. A CQU message is sent from the requesting clinical trial management system (CTMS) or research system to retrieve clinical observations, history, and enrollment data for a specific study subject or trial protocol. This page explains what a CQU message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how a CQU query relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a CQU message represents
A CQU message — CQU stands for Clinical Study Data Query — is an original-mode query used to request research-related data. The core of the message is the QRD segment (Original Query Definition), which specifies the study identifier in QRD-8, the query date/time, and the query ID. An optional QRF segment (Query Filter) provides additional criteria, such as subject numbers or date range filters, to focus the query's scope.
The sender is the clinical trial management system (CTMS) or analysis system that requires study outcomes or patient data, and the receiver is the EHR or laboratory repository holding the clinical observations. CQU initiates a request-response exchange: the CTMS sends a CQU^C09 query, and the clinical repository returns the study data in a CSU response.
When a CQU message is sent
A CQU message is sent when a clinical trial coordination system needs to retrieve patient data on demand. Common scenarios include:
- A researcher opens a patient study file in the CTMS, triggering a real-time query to retrieve their latest laboratory observations from the EHR.
- An automated study audit script queries the LIS for all observations logged against a specific trial ID.
Trigger event
The CQU message type carries a single trigger event:
CQU^C09– Clinical study data query message.
The receiver acts on the study ID in QRD-8 and filters in QRF, returning the results in a CSU message.
Integration topology
The diagram shows the clinical trial management system (CTMS) querying the clinical system through the integration engine, which returns the data.
{{diagram: clinical trial system (CTMS) → CQU query → integration engine → clinical system (EHR) → CSU response → integration engine → CTMS}}
Typical senders: clinical trial management system (CTMS), research database client, data analysis application.
Typical receivers: EHR, LIS, clinical data repository holding study observations.
Direction: request in a request-response exchange; the response is delivered in a CSU message.
Segments in an CQU message
The CQU_C09 message structure is minimal: a required MSH header, a required QRD segment, and an optional QRF query filter. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every CQU message. It names the sending and receiving applications, stamps the creation time, declares the trigger event in MSH-9 (CQU^C09), carries the message control id in MSH-10, and pins the HL7 version. |
QRD | Original Query Definition. Required. Carries the query date and time, query ID in QRD-4, and the study identifier in QRD-8 (Who/What Subject Filter). |
[QRF] | Query Filter. Carries additional filters, such as patient demographics or specific subject IDs. Optional. |
[ ] = optional, { } = repeating
Sample CQU message
Note. Constructed for illustration. Study IDs and query identifiers are fictional.
MSH|^~&|CTMS|MERCY|EHRSYS|MERCY|20260604090000||CQU^C09^CQU_C09|MSG00048|P|2.5.1
QRD|20260604090000|R|I|QRY20260604001|||1^RD|STUDY-8831^Diabetes Trial Phase II^L|RES|ALL
QRF|@CSR.2^SUBJ-1200|||||||||
What this sample shows
The CQU^C09 in MSH-9 marks a clinical study data query. QRD stamps the query time, sets the query control ID to QRY20260604001 (QRD-4), and filters by study ID STUDY-8831 (Diabetes Trial Phase II) in QRD-8. The QRF segment filters by subject identifier SUBJ-1200 in the first field.
Working with CQU messages
Track Query Identifiers for Correlation
QRD-4 carries the unique query control ID. Responding applications must echo this identifier in the QAK and QRD segments of the CSU response. If query IDs are duplicated, the querying system will not be able to match incoming study data to its original request.
Filter by Study and Subject ID
The receiving application must parse both QRD-8 (study ID) and the subject filters in QRF to determine the dataset to return. A broad query by study ID alone can return data for hundreds of subjects, causing performance overhead. Restrict queries to specific subject IDs whenever possible.
Vendor variance. Clinical systems differ in how they support search filters in
QRF. Some systems support complex filters (e.g. date ranges, specific laboratory codes), while others only allow filtering by subject ID. Confirm the receiver's query capabilities before building integration clients.
FHIR equivalent
A clinical study data query corresponds conceptually to a FHIR RESTful search on the ResearchSubject or Observation resources (e.g., GET /ResearchSubject?study=STUDY-8831&identifier=SUBJ-1200 or GET /Observation?patient.identifier=SUBJ-1200).
The HL7 v2-to-FHIR Implementation Guide publishes no message map for CQU_C09 and no ConceptMap for the query segments (QRD/QRF). A CQU query has no direct FHIR message equivalent; the conceptual correspondence is to the FHIR RESTful search API.
Common pitfalls
Pitfall. Reusing query control IDs across requests. If
QRD-4is not unique, asynchronous response correlation will fail, causing study observations to be loaded against the wrong research subjects.
Pitfall. Ignoring the
QRFsubject filters. Returning a study's entire dataset when a query specifies a single subject ID will cause severe network and parsing overhead.
How Vorro handles CQU messages
Vorro accepts CQU queries over MLLP, validates the study and subject filters in QRD and QRF, and routes the query to the clinical database. Vorro correlates the eventual CSU response using the query identifier from QRD-4 and returns it to the CTMS. Where a FHIR destination is configured, Vorro translates the query into a RESTful search request on ResearchSubject or Observation resources, since the HL7 v2-to-FHIR guide provides no published map for this message.
Related messages
- CRM — the clinical study registration message.
- CSU — the clinical study unsolicited data response message.
- QRY — the original-mode query message.
