Not exactly. HL7 has many segments and trigger events, each having a specific purpose and action. Out of that whole lot, when someone is designing a healthcare interfacing application, they have to choose the right segments and trigger events. That is called cardinality which requires a definition of:
- Mandatory segments (MSH,PID,PV1 etc)
- Optional Segments (DG1,PR1,AL1 etc)
- Repeating Segments (OBX)
Once cardinality is defined, then the message starts taking its shape.
A patient demographics trigger event shall include MSH, EVN, PID, PV1, IN1, GT1. But not necessarily DG1, PR1 and AL1.
Similarly, a charge message should definitely include FT1 (financial transactions) segment in the message. An order message should definitely include OBR and ORC segments.
Each segment in HL7 has a defined purpose. There isn't any point in including FT1 in demographics message or an OBR in an SIU message (just an example).
What an application can or cannot send out is called specification of that application.
It is required to understand message cardinality. One cannot create an HL7 message on the fly. It is neither technically feasible nor logically correct.