Reimbursed e-prescriptions from 13 September 2026: treatment duration and RPL packs in clinic software
On 13 September 2026 Centrum e-Zdrowia will switch on blocking validation for reimbursed prescriptions. Without duration of treatment, structured dosing and a pack size that matches the medicinal products register, P1 will refuse the document. This article sets out the fields your clinic software should hold before a queue stalls on an error message.
Centrum e-Zdrowia has announced that on 13 September 2026 it will switch on new validation rules for reimbursed prescriptions. The notice is here: Od 13 września 2026 r. zmienią się zasady walidacji recept refundowanych. The rules run in blocking mode. A prescription that fails the checks will not be accepted into the P1 system.
CeZ wants fewer ordinary prescriptions whose quantity of medicine exceeds 120 days of therapy. That horizon is reserved for annual prescriptions. The same notice also talks about data quality: fewer mismatches between dosing and the number and size of packs. For that to work, a reimbursed prescription must carry duration of treatment, structured dosing and a pack size that matches the Rejestr Produktów Leczniczych. From 13 September you will not be able to save a reimbursed prescription without those data.
In a small practice it looks simple until the waiting room fills. The doctor clicks issue, the clinic system posts to P1, an error code comes back, and the patient is watching the clock. Reception cannot tell whether the gap is an empty duration field, a pack outside the RPL, or a certificate that expired last week. Clinic software will not replace the P1 bus or gabinet.gov.pl. It should, however, show before send which field is missing, and refuse to push an empty card into the queue.
GESOFT — Paweł Matusiak, Laravel, Vue, Android — will build that panel beside the system that already issues e-prescriptions, or join the diary, the patient card and invoicing when a boxed product cannot hold your model. We do not scrap a working HIS. We do not pretend to be the authority. Write to contact: how many rooms, which system you run today, whether you issue reimbursement, who holds the TLS/WSS certificate. A proposal comes back in 24 hours. If an update from your current vendor is enough, we will say so.
The CeZ notice on validation from 13 September 2026
The text on ezdrowie.gov.pl is short and leaves little room for “it will sort itself out”. On 13 September 2026 the rules that already apply to annual prescriptions will be applied to all reimbursed prescriptions. Blocking mode means what CeZ wrote: documents that fail the requirements will not be accepted. There is no coaching period in the notice, and no “warning first, block later”.
The aim is stated plainly. The point is to cut cases where an ordinary prescription carries a quantity counted on more than 120 days of therapy. That time is reserved for prescriptions marked annual. The other side of the same change is data quality. CeZ writes about discrepancies between dosing and the number and size of packs prescribed. The field is filled in line with the RPL, or the prescription comes back with an error.
For the owner of a practice, 13 September sits in the diary next to other things already hanging over the rooms: the P1 certificate, the NFZ contract, KSeF on invoices for private visits. The appointment book stays in the online booking system. A reimbursed prescription travels a different pipe — to P1. If those two worlds do not talk, on Monday morning the doctor has a full list and an empty validation message.
The notice does not say how many prescriptions in Poland already fail these rules. It does not give a share of practices that already use structured dosing. We do not invent those figures. You have what stands on the CeZ page. The rest you check on your own stations: whether your system already requires duration of treatment on a reimbursed prescription now, or will still save a card without that field through 12 September.
Print the notice or drop the link into a folder named “P1 / e-prescription” and give it to the person who installs updates. That is often someone other than the prescribing doctor. The HIS engineer, the bookkeeper who signs contracts, reception with the passwords — three people, one certificate, one day when validation tightens. If nobody owns that folder, 13 September arrives as a surprise, even though the announcement is public.
Rules REG.WER.20540 and REG.WER.20584
CeZ lists two rules. REG.WER.20540 — a check that an ordinary prescription states duration of treatment. REG.WER.20584 — the same for an ordinary prescription with a medical device. Keep the numbers on the error card. Your software vendor will use them; the doctor in the room will only hear “P1 did not take it”.
An ordinary prescription in this notice is a reimbursed prescription that is not annual. Duration of treatment must be present on it in the same way as on a 365-day prescription. If your system still lets that field sit empty and “somehow calculates from packs”, that path closes on 13 September. A calculation in the doctor’s head is not a field in the XML message.
A medical device on a reimbursed prescription falls under 20584. In a general practice that is less common than a tablet, but in diabetes, pulmonology and vascular surgery, inserts, needles and kits land on the same form as a medicine. A panel that only handles “a drug from the RPL” and treats a device as a note will leave you with the second rule unhandled.
When P1 returns an error, the prescription card should keep the code, the wording, date and time, the patient’s PESEL and the working-document identifier. Without that, in the morning nobody can reconstruct which prescription failed. The doctor remembers a face, not a REG.WER number. Reception remembers the queue. The IT person gets a screenshot with three lines. An error log is dull until NFZ or the patient comes back asking why the pharmacy had no medicine the same day.
Not every P1 error is 20540 or 20584. A certificate, a bus timeout, a pack mismatch, a missing privilege — those are different codes. If the log folds everything into one status “P1 error”, on 13 September you will not tell validation of duration from a falling TLS. The certificate chapter comes later, because CeZ also announced a change of certification authority on 3 September at 16:00. Those two dates sit in the same working week.
Duration of treatment, structured dosing and the RPL pack
The three requirements in the notice are worth writing as fields, not as a slide. First: duration of treatment. Second: structured dosing. Third: pack size matching the Rejestr Produktów Leczniczych. CeZ calls them a “basic requirement” for reimbursed prescriptions.
Duration of treatment is not the same as the prescription’s period of validity. A prescription may be valid for 30 days and carry a 90-day course, or the other way round if someone prescribes short. The duration of treatment field has to be on the document, because validation uses it to test whether the quantity on an ordinary prescription exceeds 120 days. A doctor who types “as needed” into free-text dosing and leaves duration empty will not save reimbursement after 13 September.
Structured dosing means the system sends dose, unit and frequency in fields, not as one string. “2 × 1 tab. morning and evening after food” as a note is not structure. Structure is something P1 and the pharmacy can use to check that the packs match the declared course. If your HIS still has a single text field “dosing” and nothing else, ask the vendor now, not at 15:00 on 12 September.
An RPL-matching pack is a GTIN and a size taken from the register, not from a wholesaler price list three years old. The doctor picks “the usual one”, and underneath sits an old pack code the RPL no longer knows, or knows at a different volume. Validation will catch it. On the drug card keep the date of the last RPL sync and the person who ran it. A sync “sometime in June” is not an argument when P1 returns an error at 18:40 on a Wednesday.
A dental practice issues fewer reimbursed prescriptions, but antibiotics and pain relief after a procedure are still sometimes reimbursed. Dental practice software often sits beside a separate HIS for e-prescriptions. If the dentist issues reimbursement rarely, the duration field is easier to forget — and 13 September is more of a surprise. A physiotherapist usually does not prescribe; they share the diary and the card with you. A physiotherapy booking system does not need to know REG.WER.20540, but it should not overwrite the patient card from which the doctor reads allergies and regular medicines.
Prescriptions the new rules do not cover
CeZ lists the exceptions in the same way as for annual prescriptions. The new requirements will not apply to non-reimbursed (100%) prescriptions without the “365” mark, that is 30-day full-pay prescriptions. They do not apply to magistral (compounded) prescriptions, named-patient import, pharmacist prescriptions, or prescriptions with named packs of complex structure.
On complex structure CeZ is explicit: about 2.5 thousand GTINs, packs that contain more than one unit defining the pack’s capacity, for example 1 injector 3 ml / 4 needles. We take that figure from the notice and do not round it. We do not guess whether your insulin injector is on the list. You check the GTIN in the system or ask the vendor whether they handle that exception list and where they take it from.
A 100% prescription without “365” stays on the old rules for this particular validation. That does not waive the rest of pharmaceutical law or the checks P1 has run for years. In the panel, status reimbursed / 100% / 365 should be a field, not an icon colour. A doctor who flips the co-payment in a hurry so that “it goes through” leaves a trace in the log. That trace helps when the patient comes back from the pharmacy having paid full price and expected a flat fee.
Magistral prescriptions and named-patient import are narrow paths. In a general clinic they may not appear for months. In a specialist clinic — several times a week. If the system hides those types in the same form as ordinary reimbursement, validation on 13 September may block something CeZ did not intend to block, or the reverse: let reimbursement through without duration because someone mis-tagged the type. Type on the working card is therefore as important as the dose.
A pharmacist’s prescription is issued in the pharmacy, not in your consulting room. We leave it on the exception list because CeZ wrote it there. We do not build an offer on it. A clinic does not issue pharmacist prescriptions and should not have a button in the panel that pretends it does. A patient who returns saying “the pharmacist added something” is on a different path — that is not your P1 document from 13 September.
A Tuesday morning in the waiting room and a P1 error
Tuesday, 8:40. Three people in the waiting room, the doctor ten minutes late after an on-call shift, reception pulling a card. A patient with hypertension and diabetes asks for a repeat. The doctor opens the last prescription, clicks issue, waits. P1 returns an error. On the screen, three lines nobody reads aloud in front of the patient. Reception only hears “the system is down”.
If this is 16 September, not the 10th, the first hypothesis should be validation, not “P1 is down”. Duration empty, dosing in a note, a pack from the 2024 price list. The doctor adds a 90-day course, picks dosing from a list, saves again. A minute, two. The patient watches the clock. The next person is already in the doorway. This scenario does not need a nationwide outage. An empty field that nobody used to require is enough.
A worse variant: the error does not say which field is missing. The HIS shows “document rejected” and nothing more. The doctor guesses. They switch the co-payment to 100% because “that used to go through”. The prescription enters, the patient pays the full amount at the pharmacy, comes back angry. The log has neither a REG.WER code nor a note that someone changed co-payment. That log will not help you with a complaint and will not help the vendor with a ticket.
Reception can take some of that mess off the doctor if the appointment list shows a flag “draft prescription — no duration” before the patient walks in. It is a checklist of fields that have to be on the document anyway. An assistant does not prescribe for the doctor. They can open the regular-medicines card and ask whether the 90-day course from the last visit still stands. The doctor confirms or changes it. The send goes with a full set.
In a clinic with three rooms the same error will repeat for three doctors the same morning if the HIS update never landed. Someone needs a station list: which PC, which version, whether the certificate is the same. Otherwise the first room “sort of works”, the second stalls, the third issues 100% on purpose so the queue moves. That is 13 September when nobody ran a test environment a week earlier.
Friday, 17:50, a locum from the neighbouring clinic. They log into your station for the first time since June. The HIS password came on a slip, the certificate is “whatever is there”, dosing is typed the way they do it at home — one string. From September that will not pass on your form. Nobody gave them five minutes at the chair because “they have been prescribing for ten years”. They have — on another form, in another HIS, with another list of fields. The locum card in the rota should have a checkbox: duration of treatment and structured dosing explained, date, who showed it. Without the checkbox a Friday-evening locum is a lottery.
A Saturday on-call, if you run one, has the same P1 and a shorter vendor helpline. The person on duty gets a one-page crib: what to do when the document comes back with 20540 (fill in duration, do not flip co-payment), what to do when there is no connection after 3 September (do not issue 100% as a workaround, call the number on the duty card). The crib sits by the station, not in an email nobody opens on call. Clinic software can show that crib after an error — three sentences, a code, a link to the CeZ notice. It does not need to be clever. It needs to be at hand.
Fields on the prescription card before sending to P1
A working prescription card does not have to look pretty. It must refuse to send when something CeZ will block is missing. The fields below repeat in practice regardless of vendor. Names in your HIS will differ. The meaning does not.
- Type: ordinary reimbursed / reimbursed 365 / 100% 30-day / magistral / named-patient import.
- Duration of treatment — mandatory on ordinary reimbursement and on a reimbursed medical device.
- Structured dosing: dose, unit, frequency, times of day if needed. A separate note for the patient if required.
- GTIN and pack size from the RPL, date of the last register sync.
- Co-payment and additional entitlement (IB, ZK, AZ and others you actually use — do not invent a list).
- P1 error code, wording, timestamp, user, working document — when the send fails.
The note for the patient field stays. The patient should get, in Polish, how to take the medicine. Validation does not read it. Do not put structured dosing only in the note because “it is more convenient”. P1 counts from fields. The note is for a person in the pharmacy and at home.
Additional entitlements are a separate shelf. The 13 September notice does not mention them. We do not therefore claim that validation will change them. They stay on the card because they are on a reimbursed prescription anyway. If your system mixes entitlement with prescription type, 13 September makes it easy to slip: someone removes IB to “unlock save”, and the patient leaves without a reduction they are due.
The regular-medicines card should suggest the last duration and the last dosing, but not paste them blindly onto a new prescription. The doctor confirms. A suggestion shortens the visit. Automatic copy from last quarter will also copy an error that went through then. After 13 September that error will no longer go through — only the queue will be longer.
In a panel GESOFT builds beside the HIS, those fields can hang as a checklist and a log even when e-prescriptions are still issued by the current system. We do not duplicate P1. We show reception and the doctor what is missing, and we keep a history of rejections. If the HIS already does that — stay with the HIS. Writing a second e-prescription issuer “because Laravel” makes no sense. Clinic software in that role is a layer, not a new bus.
P1 bus certificate change on 3 September at 16:00
Beside validation on 13 September, CeZ announced a second date. On 3 September 2026 at 16:00 the certificate with which the P1 Service Bus identifies itself in production will be replaced. The new certificate will be issued by a new authority: RootCA 2025 and SubCA TLS 2025. The notice: 3 września zmiana urzędu certyfikacji P1.
The bus presents itself to software with this certificate. You are not renewing your practice certificate here. If the HIS does not trust the new authority, after 16:00 the production connection may fall even though your TLS.P12 is still valid. CeZ asks you to adapt the software and publishes a bundle of production certificates: https://ezdrowie.gov.pl/pobierz/systemp1_certyfikaty_produkcyjne.
In a small practice nobody reads notices “for suppliers”. The firm that installed your HIS three years ago reads them, or nobody does. The question to the vendor is one sentence and is worth sending in writing: will the version on our stations trust RootCA 2025 before 3 September 16:00? The date of the reply and the ticket number go in the P1 folder. A phone remark “we should be OK” is not a record.
16:00 on a Thursday is the end of clinics in some practices and mid-afternoon in others. If the update needs a service restart, plan it outside the queue. A test-environment trial — if the vendor has one — should land before the weekend of 29–30 August, not at 15:50 on the Thursday. CeZ technical helpline: 19 239. That number is for the bus and certificates, not for an argument with a drug wholesaler.
Two dates in one September are easy to mash in the head into “some P1 problem”. Split them on the IT duty card. 3 September, 16:00 — the bus certification authority. 13 September — reimbursed-prescription validation. A different notice, a different person at the vendor, a different symptom on the screen. First symptom: no connection. Second: the connection is up, the document is rejected.
The RPWDL 2.0 application and TLS.P12 / WSS.P12 files
A separate matter CeZ described on 14 August is renewal of your P1 certificate. The guide: Jak zaktualizować certyfikat P1? Praktyczna instrukcja dla podmiotów leczniczych. A P1 certificate is two certificates: TLS and WSS. It has an expiry date. Once a new one is issued, the old one becomes invalid.
The procedure runs through RPWDL 2.0. Log in at https://rpwdl2.ezdrowie.gov.pl — Trusted Profile, mObywatel, e-ID or another method on the form. Choose the entity’s register book. Application: Wnioski → Wnioski o uzyskanie dostępu do systemu P1 → Dodaj nowy wniosek. Fields from the guide: book number, email, administrator details on the entity side (given name, surname, PESEL, email).
You download the CSR Generator from CeZ. Versions: Windows 10, Windows 11, macOS. The program makes TLS.CSR and WSS.CSR, plus JKS files and passwords you must keep. The CSRs go on the application. After sending you download TLS.pem and WSS.pem — CeZ notes that the files are available for a limited time. Then the Generator again: load the pem files, enter the passwords, receive TLS.P12 and WSS.P12. Those two you import into the clinic software.
The last step depends on the HIS vendor. CeZ says so: the import method differs, use the producer’s documentation. On the entity card in your panel you should keep: TLS expiry, WSS expiry, who imported, onto which stations, whether after import the old certificate already fails. Because it does. The guide says: after a new certificate is issued, the old one is invalid. Importing on Friday afternoon onto one PC and “the rest on Monday” leaves the weekend on-call on an invalid certificate.
Passwords for JKS and P12 should not sit in a notebook at reception or in a messenger group. The person on the register book, the administrator on the application, the HIS engineer — three roles, one set of files. If the practice owner is also the doctor and the administrator, still separate the P12 medium from the password. CeZ lists a security incident as a reason to update a certificate, beside ordinary expiry. We do not add incident details, because the guide does not give them. A P12 stick in the reception drawer “because it is easier for locums” is also convenient for someone who should not prescribe from your book.
A panel that watches certificate expiry and reminds you 30 days ahead will not replace RPWDL. It can, however, stop you arriving at 13 September with a valid bus certificate and an invalid WSS. Those are two ends of the same pipe. Both have to hold for a prescription to leave at all, before validation even looks at duration.
In practice the RPWDL application often sits with the person who “did it once”. They go on leave in the last week of August, and the P12 expires on 10 September. The deputy does not know the Generator password, does not know which book number, and has no Trusted Profile tied to that book. The CeZ procedure is then correct and useless. On the entity card, next to the P12 date, put the deputy’s name with RPWDL access and whether they have mObywatel or a profile for that book. You check this in August, not at 19:00 on 9 September.
Importing a P12 onto a terminal nobody sits at does nothing. The list of e-prescription stations: room 1, room 2, treatment room, the “spare” laptop in a cupboard. Against each — import date, who clicked, whether a test prescription went out afterwards (even a full-pay one, so you do not touch reimbursement). The cupboard laptop goes out with a locum on a home visit and is suddenly the only station with the old certificate. An entry “imported everywhere” without station names is a well-meant lie.
Annual prescriptions, 120 days of therapy and the patient card
The notice returns to the figure of 120 days because that is the threshold an ordinary prescription must not exceed in quantity of medicine. One hundred and twenty days is reserved for annual prescriptions. A clinic that, “for the patient’s convenience”, packed a six-month supply onto an ordinary form will hit validation after 13 September. Either you shorten the quantity to a course that fits in 120 days, or you issue a prescription marked annual — if you meet its own rules, which already apply.
The patient card should show when the last 365 prescription went out, which medicine, which course, how much the pharmacy could dispense at once. CeZ does not restate that in this notice. We therefore do not quote the pharmacy 120-day dispensing rules as if they were part of the September news. The news is about issuing, and about quantity on an ordinary prescription not exceeding 120 days of therapy. The rest of pharmaceutical law stays where it was.
A patient on many medicines arrives with an IKP list and paper bags. The doctor will not prescribe from a bag a GTIN that is not in the RPL. A regular-medicines card with the last pack, the last course and the issue date shortens that review. The patient will still say “the pharmacy did not have it”. That sentence is not an error code. On the prescription log you can see whether the document left or came back with 20540.
In a clinic where some visits are only a repeat, the diary lies if the slot is five minutes and validation adds two minutes to fix dosing. In September it is worth lengthening those slots or inserting a buffer every fourth visit until the team is used to the new fields. The calendar in the appointment system is allowed to do that. Five minutes on paper were never five minutes in the room; now the gap will show at once.
Do not mix the prescription card with the NFZ billing card and the invoice for a private visit. Medicine reimbursement is P1. A visit under a Fund contract is a separate message. An invoice for a private consultation, for most VAT payers since April 2026, goes through KSeF — there is a separate article. Three pipes. Three logs. One reception desk that hears “the system is down” and cannot tell which pipe.
A cardiology example, without guessing statistics. A patient on three regular medicines, one on a 365 prescription, two on ordinary reimbursement. The doctor renews all three from a single “regulars” list. A form that does not distinguish type will try to squeeze the annual supply into an ordinary prescription or the reverse. Validation on 13 September will hit the ordinary ones. The patient leaves with one prescription instead of three and comes back in the afternoon. A regular-medicines card with a column last prescription type and duration of treatment costs one field. The missing field costs a slot.
The pharmacy will not repair your issuing. The pharmacist sees what P1 accepted. If there is no document, the patient stands with a number that is not in the system. Reception that, after issue, tells the patient the prescription went in (an identifier, not “we sent it”) removes half the evening phone calls. Status sent / accepted / rejected is three states. A fourth, local “issued” confuses everyone.
Questions for the clinic-system vendor
Before anyone talks about a new panel, write to the firm that holds your e-prescriptions. The questions have a date and a ticket number. A reply “we will look into it” with no deadline is empty. The list below is for pasting into an email.
- Will you, before 13 September 2026, require duration of treatment and structured dosing on an ordinary reimbursed prescription and on a medical device (REG.WER.20540, REG.WER.20584)?
- Do you take the pack from the current RPL, and when was the last sync on our stations?
- Do you handle the exceptions in the CeZ notice, including the list of about 2.5 thousand complex-structure GTINs?
- What code and wording will the doctor see when P1 rejects the document? Does the log keep the user and a timestamp?
- Will the version on our PCs trust RootCA 2025 / SubCA TLS 2025 before 3 September 2026 at 16:00?
- How do we import TLS.P12 and WSS.P12 after an RPWDL 2.0 application — instructions for our version, not a general PDF from two years ago.
- Is there a test environment where we can try a reimbursed prescription with empty duration and see the block before 13 September?
If the vendor answers with a version number and an install date, you stay. An update from someone already talking to P1 is cheaper and safer than writing a second issuer. GESOFT does not hide that. Off-the-shelf or bespoke software — the same dilemma, other trades, the same honesty: we do not burn what works.
When no answer comes, or the version “will be ready in the autumn” with no day, the conversation about a layer beside the HIS starts. Diary, patient card, field checklist, error log, certificate reminder, invoices and KSeF. E-prescription stays in the HIS as long as the HIS lives. If the HIS dies on 13 September and the vendor is silent, you look for a clinic system that already has these rules — or a panel that at least shows what is missing before you click issue.
The test question is worth asking even in a large clinic group. P1 test and production are not the same, but a trial with empty duration on a copy of a card (without sending it to the patient) will show whether the form can even block a save locally. A local block before the bus is better than a rejection five seconds later in front of the patient. Not every HIS can do that. You need to hear it from the vendor, not guess from a leaflet.
At the end of the email ask for a named contact at 16:00 on 3 September and on the morning of 13 September. A phone number, not a generic “office@” box. On those two mornings a mailbox will not do. If the vendor will not name a person, write that down. That is an answer as well.
gabinet.gov.pl, packaged SaaS and a bespoke panel
The state provided gabinet.gov.pl. It is a tool for talking to P1, not a practice CRM and not a queue diary. We do not replace it. We do not replace IKP, NFZ, RPWDL or the CSR Generator. Anyone whose offer says they will “handle e-prescriptions without P1” has not read the statute, or is betting that you have not.
A packaged HIS (SaaS or a box) is enough when you issue a standard e-prescription, have one vendor, and that vendor will make validation and RootCA 2025 on time. Stay. You pay the subscription, you install the version, you run the checklist from the previous chapter. Bespoke code is not a prize for patience.
Clinic software written to order makes sense when the model does not fit a box: several sites with different register books, physiotherapy and dentistry under one roof, a tablet app for the doctor, private billing beside an NFZ contract, a different diary for each chair. Or when the HIS issues the prescription but cannot show reception why P1 sent an error, and does not watch the P12 date. Then GESOFT builds a layer in Laravel and Vue, with Android when someone has to work from the waiting room without sitting at a station.
In that layer we do not duplicate the RPL dictionary ourselves if the HIS already has it. We take status, show the missing field, keep a log, join the visit to the invoice. GDPR remains GDPR — a patient card is special-category data, as we wrote about applications built to the rules. A P1 error log is also health data if it shows a PESEL and a medicine. We do not dump it into a messenger group “so IT can see”.
The price of a bespoke panel depends on the number of stations, whether you want a mobile app, whether you join KSeF, whether you migrate visit history. The ranges from another article on Laravel pricing stay there. Here this is enough: first an email to the current vendor, then contact with the number of rooms and the HIS name. Within 24 hours you get a proposal or a sentence that their update will do. Both outcomes are fine.
A checklist through 13 September 2026
The points below are for ticking in a diary, not for hanging as a poster. The dates come from CeZ notices, not from wishes. Who ticks — a name against the point, not a tick without a date.
- By the end of August: an email to the HIS vendor with the questions from the previous chapter, ticket number in the P1 folder.
- Before 3 September: confirmation that stations trust RootCA 2025 / SubCA TLS 2025; the bundle from ezdrowie.gov.pl saved.
- After 16:00 on 3 September: a short P1 connection test on every station, a log line “works / does not work”.
- TLS.P12 and WSS.P12 expiry: the date on the entity card; if it falls in September, an RPWDL 2.0 application before it dies.
- Before 13 September: on a copy of a card (or on a test) an attempt to save a reimbursed prescription without duration — it must fail.
- Morning of 13 September: one person on the vendor’s phone, another at reception with the field list from the prescription card.
- In the first week after the change: a review of the rejection log — code, medicine, doctor — without guessing “it must be P1”.
In a clinic group you split the checklist by site. A ground-floor room with the update and a first-floor room without it are two different 13 Septembers. An entry “done at the clinic” with no station name says nothing. Ground-floor reception will not import a certificate upstairs.
After 13 September the checklist does not go in a drawer. Once a week through October someone looks at the rejection log. If 20540 disappears, the team has entered the field routine. If it comes back with one doctor, the problem is a habit, not the bus. Five minutes of training at that station will do more than another email to the vendor.
Finally, a thing the notice will not do for you. Someone in the practice has to like reading ezdrowie.gov.pl. Not the doctor in every break. A systems person, with a P1 folder, with two September dates. The panel helps them because it holds the link and the P12 expiry. It does not read the notice for them. If that person is missing, 13 September still arrives — only in queue mode, with complaints and a 100% prescription so that “it somehow dispenses”.
If after this text one Monday task remains: open the last reimbursed prescription in your HIS and check whether duration of treatment and structured dosing are fields or a note. You can add the rest of the list during the week. That one click will split practices that will see patients normally on 13 September from those that at 8:40 will hear that the document cannot be saved.
A second thing for the same Monday, if the first went too fast: open the CeZ notice on a shared screen with reception, not in an email “for information”. Read aloud the sentence on blocking mode and the list of exceptions. Five minutes. Then someone from reception repeats in their own words what they will do when the doctor says the system did not accept it. If the answer is “I’ll call Mrs Krysia who does the computers”, put Mrs Krysia’s number and 19 239 and the HIS vendor’s number on the crib. Three numbers, one sheet, 13 September at the top. A sheet nobody hid in a drawer “for later” will outlive another newsletter from ezdrowie.gov.pl that nobody opened. The date at the top of the sheet should be 13 September, not “September”, so nobody confuses it with the bus certificate change at 16:00 on 3 September.
What can stay in a spreadsheet and what needs a panel
A one-person practice with twenty reimbursed prescriptions a week and a HIS that will make validation does not need a second system. The on-call rota spreadsheet can stay a spreadsheet. The patient card stays in the HIS. The certificate — in the paperwork, with a date on a wall calendar. That is enough if the wall calendar actually rings 30 days before P12 ends.
Three chairs, two doctors on a rota, half-time reception and a dentist in the same premises — here the spreadsheet starts to lie. Who imported the certificate, onto which station, which HIS version, which RPWDL book, who issued the prescription that came back with 20584 at 18:11. Those are not columns that survive the holiday of the person “who does the computers”. The panel does not have to be large. It has to have those few fields and not vanish when someone tidies a desktop.
An owner who also sees patients will not sit down in the evening with the P1 log. That is why the log should enter the morning reception report: how many prescriptions left, how many came back, which codes. Three lines, not a dashboard with a chart. If the same code returns for three days with the same doctor, reception leaves a note on the desk. Training happens between patients, not on a Saturday webinar.
The practice bookkeeper sees another side of September: invoices for private visits, KSeF, and possibly e-Delivery from October 2026 for firms in CEIDG before 2025. Prescription validation is a separate shelf, the PC at reception is the same, and so is the person meant to “sort the systems”. Do not dump RootCA and REG.WER on them. Split the P1 folder from the accounts folder. Otherwise at 16:00 on 3 September someone will be posting invoices while the bus changes its certificate with no witness.
GESOFT can join those folders in one panel with permissions: the doctor sees the card and the working prescription, reception sees the diary and missing-field flags, the bookkeeper sees invoices, IT sees P12 dates and versions. That is a reason to write bespoke software when the HIS SaaS either lets the bookkeeper into nothing or into everything. Permissions are dull until a trainee exports the patient list onto a stick.
An owner of two practices in two towns has two RPWDL books and often one “just in case” laptop. A certificate from book A imported onto a station in town B is an error that will surface at the worst moment. A panel with a list book — station — certificate — date is not a CRM. It is a table a spreadsheet will not hold when someone copies a row and forgets to change the town. Two practices are two P1 folders, even when the accounts are shared.
A dietitian in the same premises, a speech therapist, a treatment room — each has their own diary. Most of them do not issue reimbursed prescriptions. Mixing them in one “clinic system” without distinguishing roles ends with the dietitian seeing an e-prescription button, or the doctor seeing a weight from a dietetic visit in the field where they look for regular medicines. Dietitian software and an internist’s e-prescription may share a patient (with a basis and consent), not a form. After 13 September that mess costs a queue and nerves.
What a week of deploying a layer beside the HIS looks like
If after the vendor email it is clear that e-prescription stays in the HIS and you are missing a diary, flags and a log, deploying a layer does not take a quarter. A typical run in a small practice looks like this — without promising a magic weekend and without pretending every clinic is the same.
Day one: a list of stations, HIS versions, RPWDL books, people with access to the CSR Generator, P12 expiry dates. A photograph of what is there, not of what you would like. Day two: the field list from the prescription card and a decision which of them the HIS already enforces. We do not duplicate enforced fields. We duplicate those that are missing, or those the HIS does not show to reception.
Days three and four: the appointment diary, if the current one is a paper sheet or a free account that cuts off after two users. Import of a patient dictionary — PESEL, allergies, regular medicines — only in the scope you have a basis for. Day five: an error log, manual at first (paste from the HIS), then, if the vendor gives a status API, a hook-up. A status API is not an issuing API. We do not ask the HIS to hand us the keys to P1.
At the end of the week: a trial with staff, not with the owner. Reception books, the doctor opens the card, sees a missing-duration flag, completes it in the HIS, comes back. If that loop needs six clicks and two logins, we shorten it. If it needs issuing the prescription in the new panel while the HIS remains the legal issuer — we drop that idea. A layer beside the HIS does not become a second HIS.
Android comes in when the doctor walks between rooms or consults at two sites and does not sit at the station that holds the P12. The app shows the diary and the card; it does not hold the bus key in a phone. The P1 certificate stays on the station that is allowed to present itself. A phone that “issues a prescription in a taxi” is a risk, not an innovation.
After go-live there is a support contract, or there is not. GESOFT does not pretend that a 49 zł subscription covers duty at 08:00 on 13 September. If you want someone on the phone those two mornings, that is in the proposal as cover, not as “support included in the pack”. A HIS that already has that cover wins. Stay with it.
Migrating visit history from a spreadsheet or an old online calendar is a separate decision. Do not do it in the same week as RootCA. September 2026 already has two P1 dates. Adding an import of five thousand old visits with broken PESEL numbers just so the panel “looks full” ends in GDPR and a row at reception. You import what the doctor uses at the prescription: regular medicines, allergies, last courses. The rest can wait until October.
If the practice bills NFZ and privately, a layer beside the HIS should not pretend that a reimbursed visit and a private visit are the same record with a different label. A different document, a different till, a different KSeF or none. On the slot the doctor sees which mode before opening the prescription card — because a reimbursed prescription on a private visit and a 100% prescription on a contracted visit are two different ledgers that someone will mix for you sooner or later. The panel does not settle with the Fund. It can stop you ignoring visit mode.
At the end of the deployment week sit for a quarter of an hour with the person who actually clicks issue, not with the person who signed the contract. The question is simple: what is missing on the screen when P1 returns 20540? If the answer is “I’ll go into the HIS anyway and guess”, the layer gave you nothing. If the answer is “I can see there is no duration, I add it in the HIS, I come back” — you managed. That conversation is recorded as a note, not a slide. The note goes in the P1 folder beside the HIS vendor’s email and the RootCA install date. In a month nobody will remember who promised what over coffee.
Frequently asked questions
- From when will P1 block a reimbursed prescription without duration of treatment?
- From 13 September 2026, according to the CeZ notice. Rules REG.WER.20540 and REG.WER.20584 enter in blocking mode. A prescription that fails the requirements will not be accepted.
- What exactly does the notice require on a reimbursed prescription?
- Duration of treatment, structured dosing and a pack size that matches the RPL. CeZ writes that this is a basic requirement, as for annual prescriptions.
- Which prescriptions does the change not cover?
- Non-reimbursed 100% without the “365” mark, magistral, named-patient import, pharmacist prescriptions, and named packs of complex structure (about 2.5 thousand GTINs). The list is in the CeZ notice.
- Are 3 September and 13 September the same change?
- No. On 3 September 2026 at 16:00 the P1 bus changes its authority certificate (RootCA 2025). On 13 September reimbursed-prescription validation starts. A different notice, a different symptom on the screen.
- Will GESOFT replace gabinet.gov.pl or e-prescription issuing in P1?
- No. We do not replace P1, gabinet.gov.pl, RPWDL, NFZ or IKP. A panel can watch fields, the log and the diary. The prescription goes through a system attached to the bus.
- What if the HIS does not require duration of treatment?
- First a ticket to the vendor with a deadline before 13 September. If they stay silent — you look for an update, another HIS, or a layer that will block sending an empty card. Do not flip co-payment to 100% so that “it goes through”.
- How do we renew a P1 certificate?
- An application in RPWDL 2.0, the CSR Generator (TLS.CSR and WSS.CSR), download of the pem files, generation of P12, import into the HIS. CeZ guide of 14 August 2026. After a new certificate is issued, the old one is invalid.
- Are dentists and physiotherapists in the same topic?
- A dentist who issues reimbursement, yes — the same P1 rules. A physiotherapist usually does not prescribe; they share the diary and the patient card. Do not mix those roles in one “issue” button.
- When is the current HIS enough, and when do you need bespoke software?
- The HIS is enough when it will make validation and RootCA 2025. Bespoke (Laravel, Vue, Android) — when you need a layer: several sites, flags for reception, KSeF, an app, permissions. A proposal from contact in 24 hours.
- Where do these dates come from?
- Validation: https://ezdrowie.gov.pl/portal/artykul/13-wrzesnia-2026-zmienia-sie-zasady-walidacji-recept-refundowanych. Bus certificate: https://ezdrowie.gov.pl/portal/artykul/3-wrzesnia-zmiana-urzedu-certyfikacji-p1. P12 guide: https://ezdrowie.gov.pl/portal/artykul/jak-zaktualizowac-certyfikat-p1-praktyczna-instrukcja-dla-podmiotow-leczniczych.
Describe your project