Hvis der opstår en fejl ved behandling af en forespørgsel vil der blive returneret et fejldokument i stedet for det forventede svar, og den forretningsmæssige del af transaktionen vil blive rullet tilbage. Dvs. at der f.eks. ikke oprettes, opdateres eller seponeres på nogen af de medsendte medicinkort eller lægemiddelordinationer, heller ikke selv om der f.eks. forsøges at oprette tre lægemiddelordinationer i samme kald og den tredje fejler. Kaldet vil dog blive logget.

Fejl returneres i XML ifølge ”Den Gode Webservice”. Der medsendes en fejlkode. De mulige fejlkoder er opdelt i følgende intervaller:

En liste af fejl FMK returnerer findes i afsnittet Fejlkoder og -tekster.

I forhold til eventelt transiente fejl og retransmission se: Retransmission

Udover en fejlkode returneres en fejl-tekst og en liste af key-value par der uddyber specifikke værdier for fejlen (values) samt hvilken del af datamodellen denne værdi tilhører (keys). En key vil typisk stemme overens med navnet på et af de xml elementer i response-dokumentet som fejlen knytter sig til.

Nedenfor er der et eksempel på hvordan body-delen af et fejldokument kan se ud (de er indsat nogle få linieskift i teksten herunder).

<soapenv:Envelope 
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
	xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
	xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" 
	xmlns:medicinecard20120601="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01"
	id="Envelope">
	<soapenv:Header>
		<wsse:Security>
			<wsu:Timestamp>
				<wsu:Created>2012-09-25T19:06:51Z</wsu:Created>
			</wsu:Timestamp>
		</wsse:Security>
		<medcom:Header>
			<medcom:SecurityLevel>1</medcom:SecurityLevel>
			<medcom:Linking>
				<medcom:FlowID>flowId</medcom:FlowID>
				<medcom:MessageID>AAABOf7THJIabqVHn2+kY1NPU0k=</medcom:MessageID>
				<medcom:InResponseToMessageID>AAABOf7TGLxiFKiBQ3eIEVNPU0k=
																			</medcom:InResponseToMessageID>
			</medcom:Linking>
		</medcom:Header>
	</soapenv:Header>
	<soapenv:Body>
		<soapenv:Fault>
			<faultcode>Server</faultcode>
			<detail>
				<medcom:FaultCode>3</medcom:FaultCode>
				<medicinecard20120601:FaultText>Medicinkortet 2603558084 findes ikke i version 999</medicinecard20120601:FaultText>
				<medicinecard20120601:FaultDetails>
					<medicinecard20120601:KeyValueSet>
						<medicinecard20120601:Key>MedicineCardVersion</medicinecard20120601:Key>
						<medicinecard20120601:Value>999</medicinecard20120601:Value>
					</medicinecard20120601:KeyValueSet>
					<medicinecard20120601:KeyValueSet>
						<medicinecard20120601:Key>PersonIdentifier</medicinecard20120601:Key>
						<medicinecard20120601:Value>2603558084</medicinecard20120601:Value>
					</medicinecard20120601:KeyValueSet>
				</medicinecard20120601:FaultDetails>
			</detail>
			<faultstring>Medicinkortet 2603558084 findes ikke i version 999</faultstring>
		</soapenv:Fault>
	</soapenv:Body>
</soapenv:Envelope>

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.

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

<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>

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:

<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>

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.

…
<CreateDrugMedication>
        <BeginEndDate>
            <TreatmentStartedPreviously />
            <TreatmentEndingUndetermined />
        </BeginEndDate>
        <CreatePrescriptionMedication>
            <ModificationMetadata>Extended validation supported but skip validation for (10000)</ModificationMetadata>
	</<CreatePrescriptionMedication>
   …
</CreateDrugMedication>
…

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.

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:

Example of extended validation (namespaces removed)

  …
<Fault>
	<faultcode>Server</faultcode>
	<detail>
		<FaultCode>10001</FaultCode>
		<FaultText>Ej muligt at seponere lægemiddelordination 31237621536712 da der findes en åben recept</FaultText>
		<FaultDetails>
			<KeyValueSet>
				<Key>DrugMedicationIdentifier</Key>
				<Value>31237621536712</Value>
			</KeyValueSet>
			<KeyValueSet>
				<Key>WarningQuestion</Key>
				<Value>Lægemiddelordinationen på Morfin har åbne recepter. Disse skal annulleres før du seponerer ordinationen.
					Hvis du fortsætter vil seponeringen finde sted og efterlade åbne recepter på den behandling, du er ved at seponere.</Value>
			</KeyValueSet>
			<KeyValueSet>
				<Key>ElementPath</Key>
				<Value>WithdrawDrugMedicationRequest.DrugMedication[1]</Value>
			</KeyValueSet>
		</FaultDetails>
	</detail>
	<faultstring>Ej muligt at seponere lægemiddelordination 31237621536712 da der findes en åben recept</faultstring>
</Fault>
  …

WarningQuestion er en unik Key som kun benyttes til udvidet valideringer, denne indeholder en sekundær besked som alternativt kan vises for brugeren, og signalerer at man kan få sin opdatering igennem, men at man skal være opmærksom på eventuelle konsekvenser ved at gøre dette.

Vi anbefaler kun at man viser WarningQuestion for brugeren HVIS systemet har en generisk håndtering at udvidet valideringer, eller kan det skabe massiv forvirring hvis WarningQuestion vises, men at systemet ikke undersøtter at overrule den specifikke kode.

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 “RegisterPatientOrganisationRelationRequest”.

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.

Du kan finde nogle korte beskrivelse af de ting som de individuelle udvidede valideringer tjekker når der laves en forespørgsel.

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, og den heller ikke allerede er registeret som nyfødt, så tjekkes der på om de første 6 cifre i stemmer overens med en person som kunne være født indenfor de seneste 20 dage.

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 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, så henter FMK alle recepter for denne ordination, og tjekker om nogle af disse stadig er åbne.

Hvis der stadig er åbne recepter, vil FMK sende en udvidet validering med kode 10001.

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, dette kan både være hvis der er recepter der håndteres dosisdispenseret, og der kan også være hvis apoteket har oprettet et dosisdispenseringskort til patienten, hvor denne ordination ingår. Såfremt ordinationen ikke er dosisdispenseret fortsætter denne validering ikke

Såfremt ordinationen er håndteret dosisdispenseret, tjekker FMK om patienten har aktiv dosisdispensering som varetages gennem FMK, dvs at apoteket både har oprettet et dosisdispenseringskort på patienten i FMK, men også at der skal være aktive/kommende perioder på kortet, hvis ikke dette er tilfældet valideres der ikke yderligere.

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, antal, iterationer, dag-nummer, supplerende tekst mm. ses dette som en akut ændring i det pakkede dosisdispensering.

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 her: Akutte ændringer i dosisdispensering

Hvis der anses for at være akutte ændringer i det pakkede dosisdispensering vil FMK sende en udvidet validering med kode 10004

Kode 10005 skal forsøge at forhindre UTH med forskel i dosering på FMK og fysisk dosisdispensering.

Når der laves et kald enten til servicen pauser laegemiddelordination eller opdater laegemiddelordination med en helt ny eller ændret pausering, tjekkes der på om denne håndteres dosisdispenseret, dette kan både være hvis der er recepter der håndteres dosisdispenseret, og der kan også være hvis apoteket har oprettet et dosisdispenseringskort til patienten, hvor denne ordination ingår. Såfremt ordinationen ikke er dosisdispenseret fortsætter denne validering ikke

Såfremt ordinationen er håndteret dosisdispenseret, tjekker FMK om patienten har aktiv dosisdispensering som varetages gennem FMK, dvs at apoteket både har oprettet et dosisdispenseringskort på patienten i FMK, men også at der skal være aktive/kommende perioder på kortet, hvis ikke dette er tilfældet valideres der ikke yderligere.

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, og omvendt.

Der valideres ikke på at man laver/ændre på pauseringer som ligger i fortiden. Dette er for at tillade man kan registerer efterfølgende hvis lægemidlet ikke har været taget.

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 10005