fmk:generel:fejlhandtering
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| fmk:generel:fejlhandtering [2020-02-19 09:49] – [Kode 10005: Akutte ændring af pausering på dosisdispenseret ordination] sas | fmk:generel:fejlhandtering [2026-03-06 08:53] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 9: | Line 9: | ||
| | 1000 - 3999 | Applikationsfejl | 3000: Intern server fejl | | | 1000 - 3999 | Applikationsfejl | 3000: Intern server fejl | | ||
| | 4000 - 9999 | Valideringsfejl, | | 4000 - 9999 | Valideringsfejl, | ||
| - | | 10000 - 10999 | Udvidet valideringsfejl, | + | | 10000 - 10999 | [[fmk: |
| En liste af fejl FMK returnerer findes i afsnittet [[Fejlkoder og -tekster]]. | En liste af fejl FMK returnerer findes i afsnittet [[Fejlkoder og -tekster]]. | ||
| Line 70: | Line 70: | ||
| ====== Udvidet validering ====== | ====== Udvidet validering ====== | ||
| - | Udvidet | + | den sidste type af validering er de såkaldte udvidet valideringer, som i modsætning til de 3 andre typer af valideringsfejl |
| - | Klienter som anvender snitflader ældre end 1.4.4.E2 skal som udgangspunkt angive om de understøtter udvidet validering, dvs. om hvorvidt de er i stand til at håndtere valideringsfejl fra udvidet validering. Fra og med 1.4.4.E2 //skal// klienter kunne håndtere fejl fra udvidet validering. | + | Se mere her: [[Udvidet |
| - | + | ||
| - | En klient angiver at den kan håndtere udvidet validering i xml elementet ModificationMetadata med strengen “Extended validation supported”. ModificationMetadata findes på xml-elementer der på en eller anden måde modificerer data. | + | |
| - | + | ||
| - | Eksempel på et request i 1.4.4 der seponerer 3 lægemiddelordinationer og samtidig angiver at udvidet validering er understøttet | + | |
| - | + | ||
| - | <code xml> | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | </ | + | |
| - | </ | + | |
| - | + | ||
| - | I eksemplet vil der bliver udført udvidet validering på alle seponeringer i requestet, men i princippet behøver man ikke at angive det på alle. Udvidet validering vil kun blive udført på de seponeringer, | + | |
| - | + | ||
| - | + | ||
| - | Bemærk at fra og med 1.4.4.E2, skal man ikke eksplicit angive at man understøtter udvidet validering, her vil der altid blive udført udvidet validering. | + | |
| - | + | ||
| - | En klient kan tilsvarende angive at en eller flere valideringer ikke ønskes ved at angive strengen | + | |
| - | + | ||
| - | Eksempel på et et request i 1.4.4 der seponerer 3 lægemiddelordinationer, | + | |
| - | + | ||
| - | <code xml> | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | </ | + | |
| - | </ | + | |
| - | + | ||
| - | ===== Udvidet validering på request niveau | + | |
| - | Ovenstående validering er et eksempel på en validering der omhandler et konkret underelement i et request. Der kan også forekomme valideringer der går på tværs af et helt request. Et eksempel på en sådan validering på request-niveau, | + | |
| - | + | ||
| - | For snitflader ældre end 1.4.4.E2 udføres valideringer på request-niveau, | + | |
| - | + | ||
| - | Når en validering på request-niveau ikke ønskes udført, skal valideringskoden angives på mindst ét ModificationMetada-element i requestet. | + | |
| - | + | ||
| - | Eksempel på et request i 1.4.4 der opretter lægemiddelordination med en tilhørende recept, og hvor validering med koden 10000 ikke skal udføres. | + | |
| - | + | ||
| - | <code xml> | + | |
| - | … | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | </< | + | |
| - | … | + | |
| - | </ | + | |
| - | … | + | |
| - | </ | + | |
| - | + | ||
| - | For eksemplets skyld bliver valideringkoden sat på et underelement til CreateDrugMedication, | + | |
| - | + | ||
| - | ===== Signalering af udvidede valideringsfejl | + | |
| - | Fejl der skyldes en udvidet validering ligner almindelige fejl bortset fra at fejlkoden ligger i intervallet 10000-10999 og at fejlen indeholder detaljer om hvor fejlen er opstået. Hvis fejlen f.eks. opstår i DrugMedication-element nr. 2 i et WithdrawDrugMedicationRequest, | + | |
| - | + | ||
| - | <code xml, Example of extended validation (namespaces removed)> | + | |
| - | … | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | Hvis du fortsætter vil seponeringen finde sted og efterlade åbne recepter på den behandling, du er ved at seponere.</ | + | |
| - | </ | + | |
| - | < | + | |
| - | < | + | |
| - | < | + | |
| - | </ | + | |
| - | </ | + | |
| - | </ | + | |
| - | < | + | |
| - | </ | + | |
| - | … | + | |
| - | </ | + | |
| - | + | ||
| - | '' | + | |
| - | + | ||
| - | Vi anbefaler kun at man viser WarningQuestion for brugeren **HVIS** systemet har en generisk håndtering at udvidet valideringer, | + | |
| - | + | ||
| - | En list af WarningQuestions og hvilken fejlkode de tilhører kan findes her: [[WarningQuestion]] | + | |
| - | + | ||
| - | ElementPath udpeger præcist hvor i requestet en fejl er opstået. Er det f.eks. 3. CreatePrescription i 2. DrugMedication i et CreateDrugMedicationRequest der fejler, indeholder ElementPath strengen “ CreateDrugMedicationRequest.DrugMedication[1].CreatePrescription[2]”. For samme fejl fra et UpdateMedicineCardRequest vil ElementPath være “UpdateMedicineCardRequest.CreateDrugMedication[1].CreatePrescription[2]”. | + | |
| - | + | ||
| - | I langt de fleste Request-typer kan man ikke angive ModificationMetadata på rodniveau. For de typer hvor det er muligt, f.eks. RegisterPatientOrganisationRelationRequest kan ElementPath i princippet bestå kun af " | + | |
| - | + | ||
| - | + | ||
| - | ===== Signalering af udvidede valideringsfejls på requestniveau | + | |
| - | Valideringsfejl på udvidet validering på requestniveau signaleres på samme måde som beskrevet i forrige afsnit. Da det ikke altid er muligt at angive et ModificationMetadata på request niveau udpeger ElementPath et vilkårlig (ofte det første) element i requestet, som indeholder ModificationMetadata. For fejl på opret lægemiddelordination kunne ElementPath være " | + | |
| - | + | ||
| - | ===== Tjeks for udvidede valideringer | + | |
| - | Du kan finde nogle korte beskrivelse af de ting som de individuelle udvidede valideringer tjekker når der laves en forespørgsel. | + | |
| - | + | ||
| - | ==== Kode 10000: Nyfødte ==== | + | |
| - | Kode 10000 henvender sig til registreringen af nyfødte. | + | |
| - | + | ||
| - | Når der laves et opdaterende kald på et CPR-nummer til FMK, hvis ikke FMK kan finde det pågældenden CPR-nummer i de stamdata den har tilgængelig, | + | |
| - | + | ||
| - | Hvis CPR nummeret stemmer overens med at være indenfor de seneste 20 dage, vil FMK sende en udvidet validering med kode 10000. | + | |
| - | + | ||
| - | ==== Kode 10001: Seponering af ordination med aktive recepter ==== | + | |
| - | Kode 10001 skal forsøge at minske problemet med åbne recepter på lukkede ordinationer | + | |
| - | + | ||
| - | Når der laves et kald til at seponerer en given lægemiddelordination, | + | |
| - | + | ||
| - | Hvis der stadig er åbne recepter, vil FMK sende en udvidet validering med kode 10001. | + | |
| - | + | ||
| - | ==== Kode 10004: Akutte ændring af struktureret dosering på dosisdispenseret ordination ==== | + | |
| - | Kode 10004 skal forsøge at forhindre UTH med forskel i dosering på FMK og fysisk dosisdispensering. | + | |
| - | + | ||
| - | Når der laves et kald til at opdaterer en lægemiddel ordination med en struktureret dosering, tjekkes der på om denne håndteres dosisdispenseret, | + | |
| - | + | ||
| - | Såfremt ordinationen er håndteret dosisdispenseret, | + | |
| - | + | ||
| - | Såfremt den er håndteret dosisdispenseret igennem FMK, henter FMK den seneste version af lægemiddelordinationen som apoteket har oprettet en planlagt dispensering på, og benytter denne version som udgangspunkt til at validerer om der er sket ændringer i den strukturerede dosering i en dosisdispenseringsperiode som af apoteket er fastlåst (Perioder hvor tidsfrist for ændring er overskredet). | + | |
| - | + | ||
| - | Er der ændret i en doserings-periode i den strukturerde dosering som ligger **inden i** den fastlåst periode, ænder inkludere her ting såsom: Doseringstidspunkter, | + | |
| - | + | ||
| - | **Bemærk** Laves der ændringer som først træder i kraft efter den fastlåste periode ses dette ikke som en akut ændring. | + | |
| - | + | ||
| - | Læs mere om de individuelle regler og forskellige scenarier | + | |
| - | + | ||
| - | Hvis der anses for at være akutte ændringer i det pakkede dosisdispensering vil FMK sende en udvidet | + | |
| - | + | ||
| - | ==== Kode 10005: Afvisning af automatisk genereret recept-anmodninger fra FMK ==== | + | |
| - | Kode 10005 skal forsøge at forhindre at dosisdispensering stopper på grund af manglende recepter. | + | |
| - | + | ||
| - | Når en læge vælger at afvise en recept anmodning der er genereret af FMK på baggrund af en udløbende recept til dosisdispensering, | + | |
| - | + | ||
| - | Såfremt at patient har en POR relation af typen " | + | |
| - | + | ||
| - | Har patienten ikke en relation af typen " | + | |
| - | + | ||
| - | ==== Kode 10006: Akutte ændring af pausering på dosisdispenseret ordination ==== | + | |
| - | Kode 10006 skal forsøge at forhindre UTH med forskel i dosering på FMK og fysisk dosisdispensering. | + | |
| - | + | ||
| - | Når der laves et kald enten til servicen [[fmk: | + | |
| - | + | ||
| - | Såfremt ordinationen er håndteret dosisdispenseret, | + | |
| - | + | ||
| - | Hvis ordination ingår i aktiv dosisdispensering gennem FMK, validerer FMK at der ikke er sket ændringer af pauseringen i en allerede fastlåst periode, dvs at dage som er pauserert i en fastlåst periode, også skal være pauseret i den nye pauseringer, | + | |
| - | + | ||
| - | Der valideres ikke på at man laver/ | + | |
| - | + | ||
| - | Læs mere om de individuelle regler og forskellige scenarier her: [[Akutte ændringer i dosisdispensering]] | + | |
| - | + | ||
| - | Såfremt der er lavet ændrigner i pauseringen i en fastlåst periode, vil FMK sende en udvidet validering med kode 10006 | + | |
| - | + | ||
| - | ==== Kode 10007: Akut fjernelse af pausering på dosisdispenseret ordination ==== | + | |
| - | Kode 10007 skal forsøge at forhindre UTH med forskel i dosering på FMK og fysisk dosisdispensering. | + | |
| - | + | ||
| - | Når der laves et kald enten til servicen [[fmk: | + | |
| - | + | ||
| - | Såfremt ordinationen er håndteret dosisdispenseret, | + | |
| - | + | ||
| - | Hvis ordination ingår i aktiv dosisdispensering gennem FMK, validerer FMK at den nuværende pausering ikke har dage/ | + | |
| - | + | ||
| - | Der valideres ikke på at man fjerner pauseringer som fuldt ud ligger i fortiden. Disse ordinationer bør heller ikke være markeret som pauseret længere. | + | |
| - | + | ||
| - | Læs mere om de individuelle regler og forskellige scenarier her: [[Akutte ændringer i dosisdispensering]] | + | |
| - | + | ||
| - | Såfremt der er fjernet en aktiv pauseringen som er aktiv i en fastlåst periode, vil FMK sende en udvidet validering med kode 10007 | + | |
fmk/generel/fejlhandtering.1582105772.txt.gz · Last modified: (external edit)
