Export exmatriculations
How Fuxam builds and sends Meldegrund 30 exmatriculation notices via the daily Dakota export — prerequisites, what the export contains, what appears on Sent notices, and when operators trigger a manual run.
When a student’s exmatriculation date approaches or passes, Fuxam must notify their Krankenkasse with a Meldegrund 30 (end of study) notice via the Dakota service. Export exmatriculations is that outbound path: a scheduled job selects eligible users from the study timeline, builds Meldegrund 30 payloads, transmits them in rate-limited batches, and records successes so the same notice is not sent twice.
This page explains the automated daily export, what the Meldegrund 30 notice conceptually contains, what staff see afterward on the Krankenkasse tab, how manual triggers work for Fuxam operators, and which prerequisites must be true before anything useful leaves the institution. It does not cover Meldegrund 20 immatriculation traffic or inbound Krankenkasse responses — those run on separate jobs.
Why it matters
In the statutory Studenten-Meldeverfahren, Hochschulen report the end of study so Krankenkassen can end or adjust student membership correctly. Meldegrund 30 typically reflects exmatriculation at or with effect to the end of a semester (and related end-of-study cases under § 199a SGB V). If notices never leave — or leave with wrong dates — insurers keep stale student status, contribution calculations drift, and your institution fails a core compliance obligation.
Fuxam’s export exists so registrar staff do not hand-build XML for every leaver. Instead:
- Study-timeline exmatriculation drives who is selected.
- Institution configuration and Absendernummer / Dakota connectivity drive whether transmission can succeed.
- Sent notices on the user tab provide an auditable trail next to the same identity used in User Management.
Treat this export as a specialized statutory channel. It complements statistics exports (Prüfungsstatistik, Studierendenstatistik, Report Builder) but is not configured or run from the Statistics Center.
How it fits
| Related area | Relationship |
|---|---|
| Configure GKV integration | Must be complete (integration switched on, Absendernummer, insurance start date). |
| Manage insurance data | Where staff verify Sent notices and correct bad transmissions. |
| Study programs and cohorts | Cohort membership and study plans determine exmatriculation dates on the timeline. |
| Reporting reasons and lifecycle | Domain meaning of Meldegrund 30 and related insurer responses. |
| Statistics | Parallel compliance reporting for ministries and accreditation — different schemas and UI. |
Key concepts
| Concept | Meaning |
|---|---|
| Meldegrund 30 | Hochschule Meldegrund for end of study / exmatriculation reporting. |
| Daily exmatriculation export | Scheduled job that performs the Meldegrund 30 export (in production, typically 03 UTC). |
| Platform GKV export schedule | When this platform schedule is disabled, the daily job completes successfully but processes zero records. |
| Dakota rate limits | Configured GKV Dakota limits that batch outbound notices during each run. |
| Insurance start date | Institution setting: exports respect this start date so older timelines are not re-sent from before go-live. |
| Prior sent notices | Already-recorded transmissions prevent duplicate Meldegrund 30 sends for the same eligibility. |
What a Meldegrund 30 notice contains (domain context)
The electronic Meldeverfahren defines structured Hochschule notices. For end of study, Meldegrund 30 typically carries identity and membership facts such as:
| Content area | Typical meaning in the procedure |
|---|---|
| Student identity | Name, date of birth, address where required, and KV number (Krankenversichertennummer) when available. |
| Absendernummer | The Hochschule (and, where applicable, Dienstleister) sender ID so the Krankenkasse can trust and route the notice. |
| End of semester | The semester end date with which membership at the Hochschule ends. |
| Day of exmatriculation | Reported when exmatriculation happens before semester end (statutory detail under § 199a SGB V as amended). |
| Meldegrund code | 30 — Ende des Studiums. |
Fuxam builds these Meldegrund 30 payloads from eligible study-timeline records and transmits them through Dakota. Staff do not edit raw XML in Settings; they correct Study Plan dates and then verify outcomes under Sent notices.
How insurers typically respond after Meldegrund 30
Once the Krankenkasse receives end-of-study reporting, it can adjust student membership and contribution treatment for that person. From the Hochschule’s operational view:
- You should see the outbound notice recorded under Sent notices.
- You should not expect Meldegrund 30 itself to appear as an inbound “Insurance notice” — inbound codes are mainly 10–13.
- If the student later re-enrolls (for example after arrears were settled), the cycle restarts with insurer status (10) and Hochschule start-of-study (20), not another casual Meldegrund 30.
See Reporting reasons and lifecycle for the full code set and scenarios (including Meldegrund 30 after arrears-driven refusal of re-enrollment).
Automated daily export
Fuxam runs the exmatriculation insurance export on a daily schedule (03 UTC in production). Each run:
- Finds users whose study timeline indicates an exmatriculation eligible for export (respecting institution start date and prior sent notices).
- Builds Meldegrund 30 payloads.
- Sends notices in batches using configured GKV Dakota rate limits.
- Records successful transmissions so the same notice is not sent twice.
The job runs only when the platform GKV export schedule is enabled. If that schedule is disabled, the job returns success with zero processed records.
What selection depends on
| Input | Effect on the run |
|---|---|
| Study timeline exmatriculation status and dates | Primary eligibility signal — wrong dates mean wrong or missing Meldegrund 30. |
| Institution insurance start date | Limits how far back Fuxam considers notifications for the institution. |
| Prior Sent notices | Suppresses duplicate transmission of the same notice. |
| Complete insurance information on the user | Missing KV or provider data can block or fail transmission. |
| Health-insurance integration switched on | Institution must be fully configured. |
What appears on the user tab
After export, each transmitted notice shows under OrgHub → User Management → [User] → Krankenkasse → Sent notices. Staff can review M20 and M30 history and initiate corrections when a notice was sent incorrectly (see Manage insurance data).
For day-to-day operations, rely on the nightly job and verify outcomes on student Sent notices lists the following morning (accounting for the 03 UTC schedule in your local timezone).
Manual trigger
Institution admins do not have a self-service button in Settings to rerun exmatriculation export. Fuxam operators with access to internal platform tools can manually trigger the same export function used by the daily job — useful after fixing study-timeline data or when testing the Dakota connection.
Typical situations where an operator-triggered run helps:
- Bulk correction of exmatriculation dates on study plans after a data migration.
- Dakota connectivity testing in a controlled window (without waiting for 03 UTC).
- Catch-up after the platform GKV export schedule was temporarily disabled.
Outside those cases, prefer the nightly schedule so rate limits and duplicate protection behave consistently.
Prerequisites for successful export
| Requirement | Why it matters |
|---|---|
| Health-insurance integration fully set up and switched on | Institution integration fully configured. |
| Valid Absendernummer and Dakota connectivity | Notices must reach the GKV middleware. |
| Accurate exmatriculation dates on the study timeline | Export selection is driven by timeline status. |
| Student insurance information complete | Missing KV or provider data can block or fail transmission. |
| Platform GKV export schedule enabled | Otherwise the daily job processes zero records. |
Best practices
- Close the academic record first. Confirm exmatriculation on the study plan (and cohort context) before expecting Meldegrund 30 — insurance export will not invent an end-of-study date.
- Spot-check Sent notices after go-live or large leavers cohorts. A quiet job can mean success with nothing eligible, a disabled schedule, or systemic Dakota failure — the per-user tab distinguishes “not selected” from “sent”.
- Coordinate with student services on leave vs exmatriculation. Leave statuses on the timeline are not the same as end-of-study Meldegrund 30; keep statuses precise so the export selects the right population.
- Keep Statistics and GKV mentally separate. Use Statistics Center for ministry and internal tables; use this export only for Krankenkasse Meldegrund 30 obligations.
- After corrections, decide whether to wait or escalate. If you fixed timelines today, either wait for the next 03 UTC run or ask a Fuxam operator for a manual trigger — there is no institution Settings button to rerun export.
- Remember mid-semester exmatriculation. When a student leaves before semester end, statutory reporting expects the exmatriculation day in addition to semester end — keep the study timeline precise so the Meldegrund 30 payload reflects reality.
Common pitfalls
| Symptom | Likely cause | What to do |
|---|---|---|
| Job “succeeds” but nothing is sent | Platform GKV export schedule disabled, or no eligible timelines | Confirm the schedule is enabled and study-timeline eligibility; check insurance start date. |
| Expected student missing from Sent notices | Exmatriculation not yet eligible, duplicate already sent, or incomplete insurance data | Review timeline, prior Sent notices, and KV / provider completeness on the Krankenkasse tab. |
| Wrong Meldegrund 30 content | Incorrect exmatriculation date on Study Plan | Correct the timeline, then use correction workflows / operator re-run as appropriate. |
| Staff look for a Settings “Run export” control | Not provided for institutions | Rely on nightly job or request an operator manual trigger. |
| Confusion with Meldegrund 20 | Different job family | Immatriculation and inbound responses use separate notification-processing jobs, not this daily export. |
FAQ
When does the daily export run?
In production, the exmatriculation insurance export runs daily at 03 UTC, subject to the platform GKV export schedule being enabled.
Can my institution click a button to rerun Meldegrund 30 export?
No. Institution admins do not have a self-service button in Settings. Fuxam operators with internal platform tools can manually trigger the same export function the daily job uses.
Does this job also send Meldegrund 20?
No. Meldegrund 20 immatriculation notices and inbound Krankenkasse responses are handled by separate jobs — including notification processing that typically runs every 30 minutes.
Where do I verify that an export worked for one student?
OrgHub → User Management → [User] → Krankenkasse → Sent notices.
What happens if we exmatriculate someone mid-semester?
Domain rules expect Meldegrund 30 to reflect end of the relevant semester and, when exmatriculation is earlier, the day of exmatriculation. Keep those dates accurate on the study timeline before relying on the export.
Related pages
Configure GKV integration
Enable the interface and set the insurance start date before exports matter.
Manage insurance data
Verify sent notices and correct study-timeline issues per student.
Health insurance overview
GKV domain context and how Meldegründe fit OrgHub.
Reporting reasons and lifecycle
Full Meldegrund reference and insurer response patterns.