Arkitektur

Plain Text Användare trycker Skriv ut → Skrivare "Remiss" (fångstlager, t.ex. clawPDF) → PS→PDF, anropar ditt C#-exe med sökväg till PDF:en → [1] Dialog: välj mottagning → [2] Slå upp HSA-id → [3] Generera försättsblad → [4] Merge försättsblad + remiss → [5] Tyst utskrift till "andra digitala skrivaren" → [6] Logga + städa temp-fil Fångstlagret (clawPDF) gör bara det tråkiga: registrerar en skrivare som heter "Remiss", konverterar PostScript till PDF och kör ditt exe med PDF-sökvägen som argument. Klart. Resten är din kod. Teknikval (och licensfällorna, för de är viktiga här) .NET 8, Windows-only. UI: WPF för mottagningsdialogen — native, inga extra runtime-bekymmer. (Avalonia funkar och ligger i linje med det du redan pillar med, men för ett Windows-lokalt printverktyg tillför det inget här.) PDF-generering + merge: PdfSharp/MigraDoc 6.x — MIT-licens, gratis. Detta är default just för att slippa skit. Undvik QuestPDF trots att API:et är snyggare: Community-licensen är gratis bara under ~1 M USD omsättning, vilket VGR garanterat spränger — då krävs betald licens. Undvik iText (AGPL/kommersiell). PdfSharp täcker både försättsblad och sammanfogning utan en krona. Tyst utskrift till målskrivaren: SumatraPDF (-print-to "Skrivarnamn" -silent) buntad med appen. Mest pålitliga vägen att skjuta en PDF till en namngiven skrivare utan dialoger. Alternativ: gsprint (Ghostscript). Komponenter att bygga Entrypoint — tar emot PDF-sökväg som argument, felhanterar om filen saknas. Mottagningsregister — POC: mottagningar.json (namn → HSA-id). Prod: dra mot HSA-katalogen. Håll det bakom ett interface så du kan byta källa utan att röra resten. Mottagningsdialog (WPF) — sökbar lista, tydlig knapp, avbryt-hantering (vad händer om användaren stänger utan att välja? → avbryt jobbet, städa). Försättsbladsgenerator — "Remiss", mottagningens namn + HSA-id, stor text "Remiss bifogad som sida 2". Layouten här är inte spikad förrän Fas 0 nedan är löst. Merge — försättsblad som sida 1, remissen efter. Utskriftsmodul — skickar mergad PDF till målskrivaren, kollar returkod, retry-logik om det fallerar. Logg/audit — vem skickade vilken remiss till vilken mottagning, när, och lyckades det. Men logga aldrig patientdata eller innehåll — bara metadata. Det här är remisser, alltså känsliga personuppgifter. Säkerhet — måste in från början, inte klistras på sen Temp-PDF:erna innehåller patientdata. Det betyder: skriv dem till en skyddad temp-mapp (inte %TEMP% med slappa rättigheter), radera direkt efter lyckad utskrift, och håll dem ur alla loggar och crashdumps. Om sändningen fallerar — vad händer med filen? Den får inte bli liggande. Din GDPR/DPIA-erfarenhet lär göra det här till en av de första grejerna du vill nagla fast. Faser Fas 0 — Spika nedströms. Blockerande för Fas 4/försättsbladets format: hur läser den andra digitala skrivaren av vart remissen ska? Text, streckkod, eller separat metadatafil? Tills det är känt bygger vi mot en antagen layout men vet att den kan behöva göras om. Fas 1 — POC av C#-appen fristående. Kör den manuellt med en test-PDF som argument. Dialog → försättsblad → merge → skriv ut till valfri testskrivare. Ingen fångst inblandad än. Här får du 80% av värdet och kan validera flödet snabbt. Fas 2 — Koppla på fångst. Installera clawPDF, skapa skrivaren "Remiss", peka den mot ditt exe. Nu funkar hela kedjan från "Skriv ut". Fas 3 — Härda. HSA-källa, config, audit-logg, felhantering, temp-filsäkerhet, avbrottsflöden. Fas 4 — Paketera & rulla ut. Kodsignering, tyst installation av clahPDF + config + skrivarprovisionering, distribution via Intune/SCCM, pilot på en mottagning innan bredare. Föreslår att vi kör igång på Fas 1 direkt — den är oberoende av allt strul kring fångst och nedströms, och ger dig något att testa i handen. Ska jag scaffolda C#-projektet (solution-struktur, dialog, försättsblad, merge, utskrift) så du har en körbar grund? Säg bara till om du vill ha WPF eller WinForms för dialogen — WinForms om du vill ha det så lätt som möjligt, WPF om det ska leva vidare.