Differences

This shows you the differences between two versions of the page.

--- fmk:generel:fejlhandtering [2019-12-03 13:34] – 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 |
 | 4000 - 9999 | Valideringsfejl, rolle-rettighedsfejl m.v. | 4003: "SOSI xml fejl: ID card is not valid in time. The card has to be less than 9 hours old 4200: Ingen roller passer på brugeren |
-| 10000 - 10999 | Udvidet valideringsfejl, dvs. fejl som kan ignoreres | 10001: Ej muligt at seponere lægemiddelordination 31237621536712 da der findes en åben recept |
+| 10000 - 10999 | [[fmk:generel:udvidet_validering | Udvidet valideringsfejl]], dvs. fejl som kan ignoreres | 10001: Ej muligt at seponere lægemiddelordination 31237621536712 da der findes en åben recept |
 En liste af fejl FMK returnerer findes i afsnittet [[Fejlkoder og -tekster]].
@@ Line 70: / Line 70: @@
 ====== Udvidet validering ======
-Udvidet validering er et nyt koncept i FMK, der understøtter validering, som muligvis ikke er relevant for alle klienter. Nogle klienter kan vælge helt at fravælge en udvidet validering, mens andre klienter kan vælge først at vise fejlen for en bruger og derefter, hvis brugeren ønsker det, prøve igen hvor valideringen er fravalgt. Udvidet validering returnerer fejl der ligger i intervallet 10000-10999. Et eksempel på en udvidet validering der kan fravælges, er validering der sikrer at man ikke kan seponere lægemiddelordinationer med åbne recepter.
+den sidste type af validering er de såkaldte udvidet valideringer, som i modsætning til de 3 andre typer af valideringsfejl kan disse valideringer skippes gennem brugen af de specifikke felt ''ModificationMetadata'' som findes i de fleste opdaterende requests som sendes til FMK.
-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.
-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>
-<WithdrawDrugMedicationRequest>
-	<PersonIdentifier>1111111118</PersonIdentifier>
-	<MedicineCardVersion>1341404077657004001</MedicineCardVersion>
-	<WithdrawnBy>
-		<AuthorisedHealthcareProfessional>
-			<AuthorisationIdentifier>2Q5TK</AuthorisationIdentifier>
-			<Name>Tess Christoffersen</Name>
-		</AuthorisedHealthcareProfessional>
-		<Organisation>
-			<Name>Lægerne Vestergade</Name>
-			<TelephoneNumber>86521348</TelephoneNumber>
-			<Type>Yder</Type>
-			<Identifier source="Yder">66974</Identifier>
-		</Organisation>
-	</WithdrawnBy>
-	<DrugMedication>
-		<Identifier>1971221231</Identifier>
-		<ModificationMetadata>Extended validation supported</ModificationMetadata>
-	</DrugMedication>
-	<DrugMedication>
-		<Identifier>1971221232</Identifier>
-                <ModificationMetadata>Extended validation supported</ModificationMetadata>
-	</DrugMedication>
-	<DrugMedication>
-		<Identifier>1971221233</Identifier>
-                <ModificationMetadata>Extended validation supported</ModificationMetadata>
-	</DrugMedication>
-</WithdrawDrugMedicationRequest>
-</code>
-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, hvor der er angivet at det er understøttet.
-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  “Skip validation for (fejl_1, fejl_2, … fejl_n)” i ModificationMetadata-element. Bemærk at tilstedeværelsen af en valideringskode der skal ignoreres også implicit betyder at udvidet validering er understøttet og man skal derfor ikke samtidigt angive "Extended validation supported".
-Eksempel på et et request i 1.4.4 der seponerer 3 lægemiddelordinationer, og samtidig angiver at der for en enkelt seponering ikke skal udføres validering med koden 10001:
-<code xml>
-<WithdrawDrugMedicationRequest>
-	<PersonIdentifier>1111111118</PersonIdentifier>
-	<MedicineCardVersion>1341404077657004001</MedicineCardVersion>
-	<WithdrawnBy>
-		<AuthorisedHealthcareProfessional>
-			<AuthorisationIdentifier>2Q5TK</AuthorisationIdentifier>
-			<Name>Tess Christoffersen</Name>
-		</AuthorisedHealthcareProfessional>
-		<Organisation>
-			<Name>Lægerne Vestergade</Name>
-			<TelephoneNumber>86521348</TelephoneNumber>
-			<Type>Yder</Type>
-			<Identifier source="Yder">66974</Identifier>
-		</Organisation>
-	</WithdrawnBy>
-	<DrugMedication>
-		<Identifier>1971221231</Identifier>
-                <ModificationMetadata>Extended validation supported</ModificationMetadata>
-	</DrugMedication>
-	<DrugMedication>
-		<Identifier>1971221232</Identifier>
-		<ModificationMetadata>Skip validation for (10001)</ModificationMetadata>
-	</DrugMedication>
-	<DrugMedication>
-		<Identifier>1971221233</Identifier>
-                <ModificationMetadata>Extended validation supported</ModificationMetadata>
-	</DrugMedication>
-</WithdrawDrugMedicationRequest>
-</code>
-===== 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, er validering af, at et CPR-nummer der potentielt kunne repræsentere en nyfødt, er kendt af FMK når der oprettes f.eks. lægemiddelordinationer. For fødeafdelinger er denne validering ikke ønskelig, da nyfødte ofte ikke er kendt i FMK før efter et stykke tid og dermed kan være en hindring i det daglige arbejde, mens den for andre aktører er ønskelig, da den sikrer mod fejlregistreringer.
-For snitflader ældre end 1.4.4.E2 udføres valideringer på request-niveau, hvis der blot et vilkårligt sted i requestet er angivet "Extended validation supported". Fra og med 1.4.4.E2 udføres de altid.
-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>
-…
-<CreateDrugMedication>
-        <BeginEndDate>
-            <TreatmentStartedPreviously />
-            <TreatmentEndingUndetermined />
-        </BeginEndDate>
-        <CreatePrescriptionMedication>
-            <ModificationMetadata>Extended validation supported but skip validation for (10000)</ModificationMetadata>
-	</<CreatePrescriptionMedication>
-   …
-</CreateDrugMedication>
-…
-</code>
-For eksemplets skyld bliver valideringkoden sat på et underelement til CreateDrugMedication, men som beskrevet i følgende afsnit, kan man sætte den på det element, som bliver udpeget af fejlen.
-===== 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, returnes følgende fejl:
-<code xml>
-  …
-		<soapenv:Fault>
-			<faultcode>Server</faultcode>
-			<detail>
-				<medcom:FaultCode>10001</medcom:FaultCode>
-				<medicinecard20120601:FaultText>Ej muligt at seponere lægemiddelordination 31237621536712 da der findes en åben recept</medicinecard20120601:FaultText>
-				<medicinecard20120601:FaultDetails>
-					<medicinecard20120601:KeyValueSet>
-						<medicinecard20120601:Key>DrugMedicationIdentifier</medicinecard20120601:Key>
-						<medicinecard20120601:Value>31237621536712</medicinecard20120601:Value>
-					</medicinecard20120601:KeyValueSet>
-					<medicinecard20120601:KeyValueSet>
-						<medicinecard20120601:Key>ElementPath</medicinecard20120601:Key>
-						<medicinecard20120601:Value>WithdrawDrugMedicationRequest .DrugMedication[1]</medicinecard20120601:Value>
-					</medicinecard20120601:KeyValueSet>
-				</medicinecard20120601:FaultDetails>
-			</detail>
-			<faultstring>Ej muligt at seponere lægemiddelordination 31237621536712 da der findes en åben recept</faultstring>
-		</soapenv:Fault>
-  …
-</code>
-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 "RegisterPatientOrganisationRelationRequest".
-===== 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 "CreateDrugMedicationRequest.DrugMedication[0]" eller "UpdateMedicineCardRequest.CreateDrugMedication[0]" for fejl opstået i henholdsvis CreateDrugMedicationRequest og UpdateMedicineCardRequest.
+Se mere her: [[Udvidet validering]]