HL7 GT1 Guarantor
HL7 field reference GT1 fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| GT1.1 | Set ID - GT1 | Yes | No | SI | |
| GT1.2 | Guarantor Number | No | Yes | CX | |
| GT1.3 | Guarantor Name | Yes | Yes | XPN | |
| GT1.4 | Guarantor Spouse Name | No | Yes | XPN | |
| GT1.5 | Guarantor Address | No | Yes | XAD | |
| GT1.6 | Guarantor Ph Num - Home | No | Yes | XTN | |
| GT1.7 | Guarantor Ph Num - Business | No | Yes | XTN | |
| GT1.8 | Guarantor Date/Time Of Birth | No | No | TS | |
| GT1.9 | Guarantor Administrative Sex | No | No | IS | 0001 |
| GT1.10 | Guarantor Type | No | No | IS | 0068 |
| GT1.11 | Guarantor Relationship | No | No | CE | 0063 |
| GT1.12 | Guarantor SSN | No | No | ST | |
| GT1.13 | Guarantor Date - Begin | No | No | DT | |
| GT1.14 | Guarantor Date - End | No | No | DT | |
| GT1.15 | Guarantor Priority | No | No | NM | |
| GT1.16 | Guarantor Employer Name | No | Yes | XPN | |
| GT1.17 | Guarantor Employer Address | No | Yes | XAD | |
| GT1.18 | Guarantor Employer Phone Number | No | Yes | XTN | |
| GT1.19 | Guarantor Employee ID Number | No | Yes | CX | |
| GT1.20 | Guarantor Employment Status | No | No | IS | 0066 |
| GT1.21 | Guarantor Organization Name | No | Yes | XON | |
| GT1.22 | Guarantor Billing Hold Flag | No | No | ID | 0136 |
| GT1.23 | Guarantor Credit Rating Code | No | No | CE | 0341 |
| GT1.24 | Guarantor Death Date And Time | No | No | TS | |
| GT1.25 | Guarantor Death Flag | No | No | ID | 0136 |
| GT1.26 | Guarantor Charge Adjustment Code | No | No | CE | 0218 |
| GT1.27 | Guarantor Household Annual Income | No | No | CP | |
| GT1.28 | Guarantor Household Size | No | No | NM | |
| GT1.29 | Guarantor Employer ID Number | No | Yes | CX | |
| GT1.30 | Guarantor Marital Status Code | No | No | CE | 0002 |
| GT1.31 | Guarantor Hire Effective Date | No | No | DT | |
| GT1.32 | Employment Stop Date | No | No | DT | |
| GT1.33 | Living Dependency | No | No | IS | 0223 |
| GT1.34 | Ambulatory Status | No | Yes | IS | 0009 |
| GT1.35 | Citizenship | No | Yes | CE | 0171 |
| GT1.36 | Primary Language | No | No | CE | 0296 |
| GT1.37 | Living Arrangement | No | No | IS | 0220 |
| GT1.38 | Publicity Code | No | No | CE | 0215 |
| GT1.39 | Protection Indicator | No | No | ID | 0136 |
| GT1.40 | Student Indicator | No | No | IS | 0231 |
| GT1.41 | Religion | No | No | CE | 0006 |
| GT1.42 | Mother's Maiden Name | No | Yes | XPN | |
| GT1.43 | Nationality | No | No | CE | 0212 |
| GT1.44 | Ethnic Group | No | Yes | CE | 0189 |
| GT1.45 | Contact Person's Name | No | Yes | XPN | |
| GT1.46 | Contact Person's Telephone Number | No | Yes | XTN | |
| GT1.47 | Contact Reason | No | No | CE | 0222 |
| GT1.48 | Contact Relationship | No | No | IS | 0063 |
| GT1.49 | Job Title | No | No | ST | |
| GT1.50 | Job Code/Class | No | No | JCC | 0327 |
| GT1.51 | Guarantor Employer's Organization Name | No | Yes | XON | |
| GT1.52 | Handicap | No | No | IS | 0295 |
| GT1.53 | Job Status | No | No | IS | 0311 |
| GT1.54 | Guarantor Financial Class | No | No | FC | 0064 |
| GT1.55 | Guarantor Race | No | Yes | CE | 0005 |
| GT1.56 | Guarantor Birth Place | No | No | ST | |
| GT1.57 | VIP Indicator | No | No | IS | 0099 |
GT1 is the guarantor segment. It tells the receiver who or what is financially responsible for a patient account. That might be the patient, a spouse, a parent, a guardian, an employer, a trust, a government agency, or some other organisation that can be billed or contacted when the account needs a responsible party.
The easiest mistake is to make GT1 sound like IN1 or NK1. IN1 is coverage: what insurance might pay. NK1 is an associated party: who to contact or who is related to the patient. GT1 is financial responsibility: who ultimately carries the account balance if the billing workflow needs a person or organisation behind it. The same human can appear in all three places, but the role is different each time.
In real integrations, a small handful of GT1 fields do most of the useful work: guarantor number, guarantor name or organisation, address, phone numbers, type, relationship, begin and end dates, priority, billing hold, employer details, and billing contact details. The later demographic and social fields can matter in financial assistance, collections, public-program, or highly local billing workflows, but they are also sensitive and often excluded by modern profiles. When those values drive billing routes or statement suppression, I would rather see the rule made explicit in Integration Soup than buried in a downstream billing-system assumption.
A useful FHIR mental model is the Account guarantor idea: the guarantor can be a patient, related person, or organisation, and it can have a period, hold status, responsibility, limit, and rank. HL7 v2 does not express all of that quite as neatly in one place, but it is the same general story. GT1 is about the party that balances the account when the normal payment options are not enough.
So let's go through each of the GT1 fields and talk about how they tend to behave in real interfaces.
When a message carries more than one guarantor, this is the little sequence number that keeps the repeated GT1 segments in order. The first one is normally 1, the second 2, and so on. It makes the message readable and gives a receiver a stable way to process the repeated segments within that one message.
Do not treat it as the guarantor's permanent identifier. A later message can renumber the list, especially if the sender sends a full replacement set. If you need to recognise the same guarantor across messages, GT1-2 is the better field. If you need to know who is primary versus secondary, GT1-15 is the clearer field.
The guarantor number is the identifier assigned to the guarantor. This is usually the field a billing system wants when it needs to match the incoming GT1 to an existing account guarantor record. It uses CX, so a value like G12345^^^CITYHOSP^AN is much better than a bare G12345, because the assigning authority and identifier type help explain who issued the number.
It is not the patient's MRN, and it is not automatically the visit number. Some systems use the patient as their own guarantor and therefore the numbers look similar, but that is still a local design choice. If this field is missing, receivers often fall back to name, date of birth, address, and relationship matching. That works until Robert Smith moves house, changes phone numbers, or two people with similar names appear in the same account workflow. Send the guarantor number if the source system has one.
For a person guarantor, this is one of the main fields in the segment. It uses XPN, just like patient and contact names, so use the structure: family name, given name, middle names, prefix, suffix, and name type where you have them. A tidy value like Smith^Robert^James^^Mr^^L is much easier to match than a single display string.
If the patient is their own guarantor, GT1-3 often matches PID-5. That is common in self-pay, adult outpatient, and simple billing workflows. If the guarantor is a parent, spouse, guardian, or other responsible person, GT1-3 should describe that other person, not the patient. And if the guarantor is an organisation, do not squash the organisation into a person-name field unless your receiver explicitly asks for that. HL7's guidance is to leave the person name empty and use GT1-21 for the organisation name.
This is a legacy-feeling field, and many implementation profiles simply do not use it. It can carry the spouse name of the guarantor, but it does not make that spouse the guarantor, and it does not replace the relationship field. If the spouse is actually financially responsible, send that spouse as their own GT1 segment.
I would be very deliberate before populating it. Spouse details can be sensitive, can become stale quickly, and often do not help the receiver do the job. If a billing system only wants the responsible party, GT1-3 and GT1-11 tell a cleaner story than a side-channel spouse name.
Billing letters, statements, and collections workflows often start here. This is the guarantor's address, not automatically the patient's address. If the patient is a child and the guarantor is a parent at a different home, copying PID-11 into GT1-5 will send the bill to the wrong place.
Use XAD properly, repeat it for multiple addresses, and use the address type when you can. Older guidance and some receivers assume the first repeat is the mailing address, so put the best statement mailing address first if order matters in your environment. Some billing systems fall back to the patient address when GT1-5 is empty, but I would not rely on that unless the interface guide says so. A silent fallback can hide a missing guarantor address for years.
The two phone fields split personal contact and business contact. GT1-6 is the home or personal phone number, and GT1-7 is the business phone number. Both are XTN fields, which means they can carry mobile, landline, fax, email, country code, area code, and telecom-use detail if the sender takes the trouble to structure them.
Put the best number first, but do not make position do all the explaining. ^PRN^CP^^64^21^5554321 says personal mobile much more clearly than a formatted string without context. If the guarantor should only be contacted at work during business hours, GT1-7 is the right place. If billing emails are being sent through this feed, make sure both sides agree how email is represented in XTN rather than hiding it in a note.
These demographics belong to the guarantor. That sounds obvious, but it is exactly the kind of thing that gets accidentally mapped into the patient record because the field names look familiar. GT1-8 is the guarantor's birth date or date/time, and GT1-9 is the guarantor's administrative sex.
For a person guarantor, date of birth can be useful for identity verification and matching, especially when the guarantor name is common. Administrative sex is less often critical to billing, but some registration and identity-matching workflows still carry it. For an organisation guarantor, both fields should normally be blank. Do not invent person demographics just to make the segment look complete.
This is the small field that tells you what sort of guarantor you are looking at. The standard table is user-defined and often local, but the practical distinction is usually person versus organisation or institution. That distinction affects how the rest of the GT1 should be read.
If the guarantor type says person, GT1-3 should carry the person name. If it says organisation, GT1-21 should carry the organisation name. In practice you may see codes like P, I, O, or local values depending on the system. The exact code is less important than having both sides agree what it means. Without that agreement, receivers end up guessing whether "Acme Trust" is a person name, an employer, or the party paying the bill.
Relationship is where the segment explains why this guarantor makes sense for this patient. Common values from table 0063 include SEL for self, SPO for spouse, PAR for parent, FTH for father, MTH for mother, GRD for guardian, CHD for child, OTH for other, and UNK for unknown.
This is not the same thing as insurance subscriber relationship, although the values look similar and the same human may appear in both places. A child might have the parent as insured in IN1 and the same parent as guarantor in GT1. The relationship direction should be documented locally: usually it is the guarantor's relationship to the patient, not the patient's relationship to the guarantor. Also watch for non-standard values like SELF in real feeds. You may need to accept them inbound, but outbound should use one documented code set.
This field exists for the guarantor's Social Security Number, and that alone should make everyone slow down. In older US-heavy billing workflows it might have been used for collections, identity verification, or matching. In many modern interfaces it is blank or excluded because the privacy risk is too high.
If a receiver says it needs this, ask whether it really needs the full SSN in this segment or whether a properly scoped identifier in GT1-2 would do the job. If you do send it, protect it like the sensitive identifier it is: secure transport, access control, logging discipline, and a clear reason for disclosure. Do not populate it from casual demographic data just because the field is available.
The responsibility period is one of the more useful parts of GT1 when life is not simple. GT1-13 says when the guarantor became responsible for the patient account. GT1-14 says when that responsibility ended. That can matter when a child turns 18, a guardianship begins or ends, a divorce decree changes responsibility, a long-term care account changes responsible party, or an employer or agency stops covering an account.
Do not treat these as admission and discharge dates. They are about guarantor responsibility, not the clinical encounter. If the guarantor is still active, GT1-14 can be empty. If responsibility ended, send the end date rather than deleting the guarantor from history, assuming the receiver supports historical guarantor records.
When there are multiple guarantors, priority tells the receiver the order in which they are responsible. HL7's basic idea is simple: 1 is the primary guarantor, 2 is secondary, and so on. This is much clearer than trying to infer priority from the physical order of GT1 segments.
Keep GT1-1 and GT1-15 consistent, but do not confuse them. GT1-1 is the segment sequence in the message. GT1-15 is the billing responsibility order. FHIR Account uses a similar idea with guarantor rank, which is a helpful way to think about it. If there is only one guarantor, priority is often blank or 1, depending on the receiving billing system's preference.
This block describes the guarantor's employment when that employment matters to the account. GT1-16 is the employer name when the employer is a person, GT1-17 is the employer address, GT1-18 is the employer phone, GT1-19 is the guarantor's employee ID number, and GT1-20 is the guarantor's employment status.
You see these fields in billing, financial assistance, employer-sponsored responsibility, workers-comp-adjacent registration, and collections workflows. They can also help staff contact the guarantor through work if that is appropriate and permitted. Use CX discipline for the employee ID in GT1-19: assigning authority and identifier type are strongly recommended. For GT1-20, table 0066 gives values such as full-time employed, part-time employed, unemployed, self-employed, retired, active military duty, and unknown.
There is a wrinkle here: if the employer is an organisation, HL7 points you to GT1-51 for the employer organisation name. GT1-16 is for an employer who is a person. A lot of real feeds are looser than that, but the cleaner mapping is worth knowing before you copy a company name into the first field that sounds like "employer".
Organisation guarantors are real: an employer, trust, agency, care facility, public body, or other entity may be financially responsible for the account. GT1-21 is where that organisation name belongs. It uses XON, so you can send more than a display string if the organisation has identifiers or name type details.
This field also avoids a messy person-versus-organisation ambiguity. If the guarantor is Acme Trust, GT1-21 should carry Acme Trust, and GT1-3 should not pretend there is a family name and given name hiding in there. Some implementation profiles make GT1-3 optional or exclude GT1-21 depending on their local needs, so read the profile, but conceptually the split is very useful: person name in GT1-3, organisation name in GT1-21.
This small yes/no flag can have a surprisingly visible effect. It tells the receiver whether to suppress printing of the guarantor's bills. In plain language, Y means do not print or send guarantor bills, and N means do not suppress them.
Do not ignore it just because it is late in the segment. Billing hold can be used for disputes, bankruptcy handling, charity-care review, legal review, sensitive address situations, returned mail work, or other local billing rules. The reason for the hold may live somewhere else, but the flag itself is operational. If your receiving system sends statements, this field needs a real mapping decision.
This is one of those fields that shows GT1's financial-management age. It can carry a guarantor credit rating code, usually from a local table. Many modern healthcare profiles exclude it, and that is usually a sensible decision unless a billing or collections system explicitly owns the value.
If you do receive it, treat it as sensitive financial data. It is not clinical context, and it is not something that should casually travel to every downstream system. Empty is usually better than a stale local credit label that nobody can interpret safely.
These fields describe whether the guarantor is deceased and, if known, when the death occurred. GT1-24 is the death date/time. GT1-25 is the yes/no death flag. They belong to the guarantor, not to the patient.
This can change billing and contact behaviour dramatically. A deceased guarantor may require estate handling, a new responsible party, a billing hold, or a change in statement routing. If the death flag is Y and the date is known, send both. If the date is not known, do not invent one.
Charge adjustment is a local billing field. HL7's own description points at adjustments such as a hospital agreeing to adjust charges to a sliding scale. That makes this field relevant to charity care, financial assistance, discount programs, or other account-level adjustment workflows.
Because the table is user-defined, the code only means something if both sides share the same code set. A value like SLIDE might be obvious to one billing department and meaningless to another. If the billing system calculates adjustments itself, do not let an upstream demographic feed overwrite that logic casually.
Financial-assistance workflows often need household income and household size. GT1-27 carries the combined annual income of the guarantor's household, and GT1-28 carries the number of people living at the guarantor's primary residence. Together, those values can support sliding-fee scales, charity-care eligibility, Medicaid-style screening, or other public-program assessments.
These are sensitive fields. Send them only when the receiver has a legitimate billing or eligibility reason, and keep the values current. A stale income value can be worse than no value because it looks precise. Also remember that the household is the guarantor's household, not necessarily the patient's household.
Employer identity can matter when the employer is part of the financial picture. GT1-29 identifies the guarantor's employer, and it may be a local employer code or something more formal such as a tax identifier, depending on jurisdiction and local policy.
Use the CX data type rather than a loose string. The assigning authority and identifier type are strongly recommended for CX values, and this is a good example of why. 123456789^^^IRS^TAX and 123456789^^^LOCALHR^EI tell very different stories even if the visible number is the same.
Marital status here is about the guarantor. It may be useful in account responsibility, financial assistance, family billing, or legal responsibility workflows, but it is usually not needed for ordinary clinical interfaces.
Be careful not to copy PID marital status into this field unless the patient is definitely the guarantor and the source is current. If the guarantor is the patient's parent or spouse, GT1-30 describes that person. Like most demographic fields in GT1, it should earn its place in the feed.
These two dates put a timeframe around the guarantor's employment. GT1-31 is when the guarantor's employment began, and GT1-32 is when it ended. That can matter when employer information supports billing, eligibility, financial assistance, or collections.
They are not plan effective dates and not guarantor responsibility dates. Employment can begin before the account exists and end while the guarantor remains responsible. If the employment status in GT1-20 says retired or unemployed, these dates can help explain the transition, but only if the source system actually knows them.
This is a social and functional-status corner of GT1. GT1-33 can describe living dependency, such as dependent children or a spouse dependency. GT1-34 can describe ambulatory status, such as mobility limitations, wheelchair or stretcher use, vision or hearing impairment, oxygen use, pregnancy, or unknown status depending on table 0009.
These fields are rare in ordinary guarantor feeds, and they are sensitive. They may make sense in long-term care, social-work, eligibility, or financial-assistance workflows where the guarantor's circumstances affect the account. They should not be populated from assumptions or copied from patient data just because the same table appears somewhere else.
Citizenship and primary language again describe the guarantor. HL7 points implementers toward country-style codes for citizenship and language codes for primary language. Primary language can be genuinely useful if billing staff need to speak with the guarantor or send correspondence in an appropriate language.
Citizenship is much more sensitive and often irrelevant to billing. If a public program or jurisdictional rule genuinely needs it, use the agreed code system and keep it scoped to that workflow. Do not treat citizenship, nationality, and language as interchangeable. They answer different questions.
Living arrangement describes how the guarantor lives at their residential address: alone, with family, in an institution, with a relative, with a spouse only, or unknown in the usual table. It is not the address itself; the address is still GT1-5.
This is another field that only makes sense when the receiver has a social, eligibility, or financial-assistance reason to care. For a straightforward statement-mailing workflow, it is probably just extra personal information.
Publicity code and protection indicator are privacy signals around the guarantor. GT1-38 can say things like no publicity or family only. GT1-39 can indicate that access to guarantor information should be restricted to users with adequate authority.
Preserve these if the sender provides them and the receiver can enforce them. Dropping a protection flag can expose billing contact details to the wrong users. At the same time, do not pretend these two fields are a complete privacy architecture. They are signals that need matching application behaviour.
Student status is a small eligibility-style field. The standard values cover full-time student, part-time student, and not a student. HL7 specifically notes that it does not describe degree level or field of study.
You might see it when student status affects financial responsibility, dependent coverage, public-program eligibility, or a local account rule. Outside those workflows, it is usually blank. If it is populated, make sure the value describes the guarantor, not the patient or insured person unless they are the same human in this account story.
Religion belongs to the guarantor in this field, and it is rarely relevant to billing. It may exist because demographic field sets were reused across segments, not because every guarantor feed should carry it.
I would leave it empty unless a very specific and lawful workflow requires it. This is sensitive personal information about someone who may not even be the patient, so it should not leak into general account interfaces by habit.
This is the guarantor's mother's maiden name. Historically it might have been used for identity verification, but it is also a well-known security question value and therefore quite sensitive.
If matching really needs another identifier, try to use a proper identifier in GT1-2 or an agreed demographic set before reaching for this. If a legacy receiver requires it, document the purpose and protect it. Do not send the patient's mother's maiden name here unless the patient is the guarantor and that is truly what the field is meant to contain.
Nationality and ethnic group are guarantor demographics. Nationality can be different from citizenship in places where national grouping and legal citizenship are not the same. Ethnic group may use jurisdictional codes, and US-oriented material often ties it to Hispanic-origin style reporting.
These fields are not common in ordinary billing feeds and can be highly sensitive. Only send them when a profile requires them for a specific reporting, eligibility, or jurisdictional purpose. Never use them as a substitute for patient demographics in PID.
Sometimes the person who should handle guarantor billing is not the guarantor. GT1-45 carries the contact person's name, and GT1-46 carries that person's telephone number. HL7's own example is the guarantor living out of the country while the guarantor's wife handles the bills.
This is a useful little patch of reality. A guarantor may have an attorney, power of attorney, spouse, adult child, or billing representative who is the better person to contact. Do not duplicate GT1-3 and GT1-6 here unless your receiver asks for that pattern. Use these fields when the billing contact is genuinely distinct from the guarantor.
These two fields explain the billing contact. GT1-47 says why that contact person should be contacted, such as late payments or another local reason. GT1-48 says the relationship between the guarantor and that contact person, such as spouse, attorney, power of attorney, self, or organisation.
The relationship direction is easy to muddle. GT1-11 is the guarantor's relationship to the patient. GT1-48 is the contact person's relationship to the guarantor. If your mapping collapses those into one field, you lose the difference between "Robert is Jane's spouse and guarantor" and "Kelly is Robert's attorney handling Robert's bills".
Job title and job code/class describe the guarantor's occupation or employee classification. GT1-49 is a descriptive title, such as senior accountant. GT1-50 is the structured job code and class field.
You might need this for employment verification, occupational billing rules, public-program eligibility, or financial-assistance assessment. Most simple guarantor interfaces leave it blank. If you use it, avoid making job title a free-text dumping ground for employer notes. The employer details have their own fields.
This is the organisation-name version of the guarantor's employer. If the guarantor works for Acme School, GT1-51 is where Acme School belongs as an XON value. GT1-16 is for an employer who is a person.
Many systems still put company names into GT1-16 because that is the earlier employer-looking field. If you control both sides, GT1-51 is the cleaner mapping. If you are receiving from a loose source, be prepared to accept either pattern and normalise it carefully inside your billing model.
This field carries a code describing the guarantor's disability or handicap status. It is sensitive, and many modern profiles exclude it.
Only send it when the receiving workflow has a legitimate need, such as eligibility or financial-assistance processing that explicitly depends on this data. Do not copy a patient's disability status into the guarantor field. They are different people unless the account has made them the same person.
Job status is a small employment classification field. The local table commonly includes values such as permanent, temporary, other, and unknown. It sits alongside employment status, hire date, stop date, job title, and employer details.
It can help when financial responsibility depends on employment context, but it is not a general clinical demographic. If the receiver does not use it, leave it out. A stale permanent-versus-temporary label does not help anyone.
This is a genuinely interesting late field. It carries the financial class assigned to the guarantor for identifying reimbursement sources, and HL7 notes that it can differ from the patient's financial class. If the guarantor's coverage for the patient is exhausted, reimbursement may fall back to the patient's financial class.
Because financial class is usually local, the code set must be documented. A value like self-pay, charity care, commercial, government, or bad debt may mean different things in different billing systems. If your receiver uses GT1-54, it should be because the guarantor has its own financial classification, not because someone needed another place to repeat PV1 financial class.
Race here refers to the guarantor, not the patient. The standard table in many US-oriented builds contains the usual broad race categories used for reporting. That does not mean the field belongs in every guarantor message.
This is sensitive demographic information about a financially responsible party. Unless a profile or jurisdictional workflow requires it, it is often better left blank. Patient race belongs in patient demographic workflows, not accidentally in GT1 because the same code table exists there too.
Birth place is a free-text description of where the guarantor was born. HL7's own examples treat it as descriptive text rather than a coded geography field. The actual address of the guarantor belongs in GT1-5.
This is rare in ordinary billing. If it is used for identity matching or a jurisdiction-specific requirement, send the value as recorded and understand that free text is weak for matching. Do not use it to store current address, nationality, or citizenship.
The last field can identify a VIP type for the guarantor. It is user-defined, so the exact values are local. A VIP flag might affect privacy handling, statement review, customer-service routing, or other special billing treatment.
Handle it carefully. VIP and special-handling flags are often visible to more people than intended once they leave the source system. Send it only to systems that need to act on it, and make sure they understand the local values. Otherwise, this is another field that can safely stay empty.