HL7 CWE Coded with Exceptions
HL7 datatype components CWE components from HL7 v2.5.1 Hide components
These are the generated components for the version selected at the top of the page. The article stays practical, and this panel follows the chosen HL7 version.
Components
| Pos | Component | Name | Type | Table | Description |
|---|---|---|---|---|---|
| 1 | CWE.1 | Identifier | ST | Identifier; Type ST. | |
| 2 | CWE.2 | Text | ST | Text; Type ST. | |
| 3 | CWE.3 | Name of Coding System | ID | 0396 | Name of Coding System; Type ID; HL7 table 0396. |
| 4 | CWE.4 | Alternate Identifier | ST | Alternate Identifier; Type ST. | |
| 5 | CWE.5 | Alternate Text | ST | Alternate Text; Type ST. | |
| 6 | CWE.6 | Name of Alternate Coding System | ID | 0396 | Name of Alternate Coding System; Type ID; HL7 table 0396. |
| 7 | CWE.7 | Coding System Version ID | ST | Coding System Version ID; Type ST. | |
| 8 | CWE.8 | Alternate Coding System Version ID | ST | Alternate Coding System Version ID; Type ST. | |
| 9 | CWE.9 | Original Text | ST | Original Text; Type ST. |
CWE is the flexible coded-value datatype. It carries the code, display text, coding system, optional alternate code, coding-system versions, and original text. You see it in fields where a value should be coded but real interfaces still have to deal with local extensions, incomplete code sets, user-entered text, and implementation guides that allow more than one coding system.
It is common in lab, pharmacy, immunization, public health, scheduling, orders, specimens, consents, and patient-administration workflows. Think specimen types, vaccine codes, allergy/adverse reaction details, blood product statuses, schedule reasons, consent types, tribal citizenship, and other fields where "just send a string" is not enough.
The trap is sending a code without the coding system, or sending display text as if it were the code. A value like 1234 means very little by itself. A value like 1234^Influenza vaccine^CVX gives the receiver a fighting chance. CWE exists so the message can say both what the sender meant and where that meaning came from.
This example has a primary code from LOINC, a local alternate code, a coding-system version for the primary code, and original text from the source. In a real interface, the exact code system and versions depend on the implementation guide, but the pattern is the important part: code, text, and system travel together.
CWE-1 to CWE-3: The Primary Code
CWE-1 is the identifier, CWE-2 is the text, and CWE-3 is the name of the coding system. These three components should be treated as a set. The identifier is the machine value, the text is the human-readable label, and the coding system tells the receiver which vocabulary the identifier belongs to.
Do not send a naked identifier unless the field definition or implementation guide truly makes the coding system unambiguous. Even then, including CWE-3 is often kinder to the next system in the chain. Codes get copied, transformed, stored, and reported. Somewhere downstream, someone will ask whether POS means positive, position, point of service, or a local status.
Text components still need HL7 escaping. If your source text can contain separators such as ^, |, ~, &, or backslash, use encoded writes or helpers such as HL7Encode(). A coded value should not become a broken component structure just because the display text included a special character.
CWE-4 to CWE-6: The Alternate Code
CWE-4 is the alternate identifier, CWE-5 is the alternate text, and CWE-6 is the name of the alternate coding system. This is where a local code can travel alongside a standard code, or where a receiver-requested code can be preserved alongside the sender's native code.
The alternate code should be equivalent to the primary code, not a second unrelated fact. If you need to send multiple different concepts, repeat the field when the field allows repetition. Do not put a diagnosis code in the primary components and a procedure code in the alternate components just because both were nearby in the source system.
This is a natural place for an integration engine such as Integration Soup to do lookup-table mapping: local code in, receiver code out, with both preserved when the profile benefits from it. The mapping decision is the important part. A helper cannot know that COVPCR maps to a specific LOINC code unless you tell it.
CWE-7 and CWE-8: Coding System Version IDs
CWE-7 is the version ID for the primary coding system, and CWE-8 is the version ID for the alternate coding system. These are often empty in everyday feeds, but they matter when code systems change over time or when a reporting guide requires a specific release.
If the receiver is validating against a value set, version can be more than bookkeeping. A code that is valid in one release may be retired, replaced, or interpreted differently in another. Do not invent version values. Send them when the source or implementation guide can state them accurately.
CWE-9: Original Text
CWE-9 carries the original text that was available before a code was assigned. This can be very useful when a human typed something, a local system mapped it to a standard code, and the receiver still needs to see the raw phrase for audit, review, or fallback display.
Original text is not a place to hide a missing code. If a guide says the field must be coded, send the required code or fail the message validation honestly. But when the profile allows exceptions, original text can preserve context that would otherwise disappear during mapping.
Where CWE Shows Up Most
CWE is common in fields where local and standard vocabularies have to meet. Specimen, allergy, immunization, blood product, scheduling, consent, certificate, patient-status, and public-health fields all use CWE in different versions and profiles. In this guide's generated data, CWE also appears inside other datatypes such as CX and XCN for coded jurisdiction, agency, or context details.
It is especially useful when the field may accept local extensions or when text is allowed because no code is available. That flexibility is not permission to be vague. CWE gives you a place to be precise about the code you have, the text you showed the user, the coding system you used, and the original wording that caused the mapping.
Practical Implementation Advice
Start by identifying the required code system for the receiver. If the receiver wants LOINC, SNOMED CT, CVX, ICD, a local table, or an HL7 table, put that in the interface spec and map to it deliberately. Then decide whether the local source code should be carried as the alternate code.
Be careful with Default() in coded fields. It is fine to supply a default display text when the profile explicitly allows it, but it is dangerous to turn an empty code into UNK just to make validation pass unless the guide tells you that is the correct unknown value. A bad code is worse than an empty code because it looks deliberate.
CWE is one of the places where HL7 Soup Web can be especially helpful. The interpretation view can show the exact component you are on, translate table-backed codes into descriptions, and link you back to the raw message so you can see whether the code, text, coding system, alternate code, and original text are really in the components you expect.
Official Description and References
The HL7 v2+ logical model describes CWE as a coded element with associated detail, used when more than one table may apply, a table may be extended with local values, or text may be present when a code is omitted. The v2.5.1 component panel in this guide lists the nine CWE components used by the default reference version.
For formal reference, compare the generated component panel above with the HL7 v2+ CWE detailed definitions and HL7 table 0396 coding system terminology.
Related Datatypes and Segments
For nearby datatype work, look at CE for the older six-component coded element, CX for identifiers that include coded jurisdiction/agency details, XCN for person identifiers and names, and HD for assigning authorities. For common segment uses, look at specimen, allergy, immunization, consent, and patient-demographic fields such as SPM, AL1, IAM, RXA, and PID-39.