Kendte afvigelser mellem FMKs og PEMs apotekssnitflade

[Tom Kückelhahn Nilson]

Takstversion
PEM returnerer værdier som fx "12.0" som takstversion i elementet "DrugDatabaseVersion".
FMK vil returnere værdier som f.eks. "201352", dvs. årstal (4 cifre) og ugenummer (2 cifire).
Årsag hertil er at PEM ved en fejl ikke returnerer en takstversion, men et versionsnummer for formatet af taksten. Snitfladen specificerer årstal og ugenummer. Versionsnummer for formatet af taksten er ikke relevant her.

Servicen "Opret og ekspeder recept" validerer udsteder
PEM validerer ikke disse værdier, der sendes med i kaldet i elementerne Issuer/AuthorisationIdentifier eller Issuer/CivilRegistrationNumber.
FMK vil validere disse værdier. Der valideres op mod aktuelle værdier i autorisationsregisteret.
Årsag hertil er at FMK klart skal kunne identificere udsteder.

Søgning efter receptordinationer tillader ikke indledende wildcards
PEM tillader søgninger hvor navnefelterne (fornavn og efternavn) indeholder minimum to bogstaver, plus evt. wildcards eller implicit wildcard i slutningen af søgestrengen. Eksempelvis fornavn="*ders" og efternavn="*sen".
FMK vil kræve at navnefelterne begynder med to bogstaver, og wildcards kan således kun benyttes efter de to første bogstaver.
Årsag hertil er at sikre performance. Vi forventer i øvrigt at mulighederne for søgning senere kan forbedres væsentligt.

"Sæt status for frigiv ordination" kan returnere nye fejlkoder
FMK vil kunne returnere yderligere to fejlkoder og -tekster ved kald til servicen "Sæt status for frigiv ordination":

108242:
"Fejl under sæt status for frigiv ordination",
"Anmodning om at frigive ordination med ordinationsid {0} er sendt til et andet lokationsnummer"

108243:
"Fejl under sæt status for frigiv ordination"
"Ny status skal være enten 'accepteret' eller 'afvist'"

Årsag hertil er at sikre at data ikke kan bringes i en fejltilstand.

Tilbagefør udlevering <Terminated>true</Terminated> medfører at receptordinationen bliver afsluttet
PEM ignorerer tilsyneladende dette felt.
FMK vil sikre at receptordinationen afsluttes (forbliver afsluttet) når feltet er sat til true.
Årsag er at dette sandsynligvis er en fejl i PEM.

Fejl i IterationInterval
PEM returnerer 0 i IterationInterval. Dette er ikke skema-validt, og en validering af responset vil medføre fejlen "cvc-minInclusive-valid: Value '0' is not facet-valid with respect to minInclusive '1' for type 'IterationInterval_Type'"
FMK vil udelade elementet såfremt værdien er 0. Dette er den specificerede virkemåde, der returnerer valide svar.
Årsag hertil er at det er en fejl i PEM. FMK vil som udgangspunkt ikke kunne returnere XML responses der ikke er skema-valide. 

P-Nummer kan (i sjældne tilfælde) være længere end XML-skemaet tillader
PEM definerer XML-skemaet for PNummer som

<xs:simpleType name="PNumber_Type">
    <xs:annotation>
        <xs:documentation>P-nummer</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:int">
        <xs:pattern value="[0-9]{10}"/>
    </xs:restriction>
</xs:simpleType>

FMK vil ændre denne definition til

<xs:simpleType name="PNumber_Type">
    <xs:annotation>
        <xs:documentation>P-nummer</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:long">
        <xs:pattern value="[0-9]{10}"/>
    </xs:restriction>
</xs:simpleType>

Dvs. int ændres til long.

Årsag er at P-nummer kan være længere end hvad en int kan indeholde. Responset vil derved ikke være skema-validt.
Bemærk at ændringen medfører i sig selv ingen forskel i hvad der returneres fra PEM og FMK, men alene at der defineres et validt XML-skema. Apotekssystemerne vil derved ikke se en forskel i opførsel ved denne skemaændring!

XML-skema for response fra UndoAdministration er ikke korrekt
PEM definerer XML-skemaet for response som

<xs:complexType name="UndoAdministrationResponse_Type">
    <xs:choice>
            <xs:element name="PNumber" type="PNumber_Type"/>
            <xs:element name="PharmacyAdministrationNumber" type="PharmacyAdministrationNumber_Type"/>
            <xs:element name="PharmacyMedicationNumber" type="PharmacyMedicationNumber_Type"/>
            <xs:element name="AdministrationID" type="AdministrationID_Type"/>
            <xs:element name="Terminated" type="Terminated_Type"/>
    </xs:choice>
</xs:complexType>

FMK definerer skemaet som

<xs:complexType name="UndoAdministrationResponse_Type">
    <xs:choice>
        <xs:sequence>
            <xs:element name="PNumber" type="PNumber_Type"/>
            <xs:element name="PharmacyAdministrationNumber" type="PharmacyAdministrationNumber_Type"/>
            <xs:element name="PharmacyMedicationNumber" type="PharmacyMedicationNumber_Type"/>
        </xs:sequence>
        <xs:sequence>
            <xs:element name="AdministrationID" type="AdministrationID_Type"/>
            <xs:element name="Terminated" type="Terminated_Type"/>
        </xs:sequence>
    </xs:choice>
</xs:complexType>

Årsag hertil er at afhængigt om forespørgselsen er foretaget med "almindelige" parametre eller "bagudkompatible" parametre kan kun sæt af tre eller to returneres. PEM responses kan derved ikke være skema-valide.
Bemærk at ændringen medfører i sig selv ingen forskel i hvad der returneres fra PEM og FMK, men alene at der defineres et validt XML-skema. Apotekssystemerne vil derved ikke se en forskel i opførsel ved denne skemaændring!

IterationCount er længere end hvad XML-skemaet tillader
PEM definerer IterationCount som en værdi 0-99

<xs:simpleType name="IterationCount_Type">
    <xs:annotation>
        <xs:documentation>(Re-) Iterationsnummer, startende med 0</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:int">
        <xs:minInclusive value="0"/>
        <xs:maxInclusive value="99"/>
    </xs:restriction>
</xs:simpleType>

FMK definerer værdien uden øvre grænse, ud over hvad der kan være i en int-type.
<xs:simpleType name="IterationCount_Type">
    <xs:annotation>
        <xs:documentation>(Re-) Iterationsnummer, startende med 0</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:int">
        <xs:minInclusive value="0"/>
    </xs:restriction>
</xs:simpleType>

Årsagen hertil er at der ikke kan garanteres at der ikke kan garanteres at der ikke forekommer højere værdier end 99. Dette forekommer, om ikke andet så på testsystemerne.
Bemærk at ændringen medfører i sig selv ingen forskel i hvad der returneres fra PEM og FMK, men alene at der defineres et validt XML-skema. Apotekssystemerne vil derved ikke se en forskel i opførsel ved denne skemaændring!

PatientOrRelative indeholder altid patienten
FMK: Idet nyfødte har CPR-nummer vil det være krævet at PatientOrRelative altid indeholder CPR-nummer på patienten selv, og ikke på en pårørende (reelt barnets mor).

Effektueringer sker altid på samme CPR som receptordinationen (og medicinkortet)
FMK: Snitfladen tillader principielt at der effektueres på et andet CPR-nummer end hvad receptordinationen angiver. Dette valideres på FMK og tillades ikke.

Manglende doseringskode i FMK ordinationer
FMK: Receptordinationer oprettet via FMK indeholder ingen doseringskode, kun doseringstekst. Dette er allerede tilfældet, og vil derved ikke være en ændring der indføres ved at apotekssnitflade flyttes til FMK.

[Benny Kristensen]

Yderligere afvigleser:

Kviter uden MarkInProgress
PEM: hvis kviter (acknowledge) kaldes uden MarkInProgress, fjernes ordinationen fra getAddressed.
FMK: kviter uden MarkInProgress har ingen effekt.
Årsag: FMK's princip med at sætte ordinationen InProgress ved bestilling, betyder at det ikke vil give mening at kalde kviter uden MarkInProgress.

[Benny Kristensen]

Nye Generelle fejlkoder

WS_MISSING_ARG(900100, "Teknisk fejl ved kald af service", "Manglede obligatorisk parameter til servicekald: {0}")
returneres hvis en af følgende obligatoriske requestparametre udelades: "user", "localuser", "password" og "requestdata".

WS_XML_PARSE_ERROR(900101, "Fejl i XML request", "Fejl i XML request: {0}")
returneres i tilfælde af schemavalideringsfejl i request

UNKNOWN_LOCATION_NUMBER(900102, "Ukendt locationsnummer", "Kunne ikke finde: {0} i stamdata")
returneres hvis det medsendte lokationsnummer ikke kendes af FMK

[Benny Kristensen]

AdministrationsId fra ordren bevares ikke ved effektuering
PEM genbruger det administrationsId, der er oprettet i forbindelse med bestillngen og som returneres i AdministrationOrdered eller AdministrationInProgress i f.eks GetMedicationsById, således at det vil være det samme id der returneres ved Effektueringen.
FMK FMK genererer et ny AdministrationId i forbindelse med Effektueringen, således at det administrationId, der returneres fra administer altid vil være forskelligt fra det administrationId, der blev returneret i eks. AdministrationInProgress.
Årsag: for at kunne håndtere den fejl-situation hvor den samme ordre er blevet ekspederet af flere apoteker samtidigt.

[Benny Kristensen]

EnvelopeDateTime og LetterDateTime udfyldes ikke

MedicationSummary og MedicationDetails
PEM: udfylder EnvelopeDateTime og LetterDateTime med forsendelses tidsstempler for Edifact Ordinationer
FMK: udfylder aldrig disse felter
Årsag: Edifact ordinationer udgår og informationen er derfor ikke relevant på længere sigt

[Benny Kristensen]

DoseDispensing medsendes selv om start-/slutdato mangler

MedicationDetails
PEM: medsender kun DoseDispensing, hvis både startdato og slutdato er udfyldt
FMK: medsender DoseDispensing, hvis ordinationen er markeret som dosisdispenseret. Hvis Startdato mangler udfyldes den med ordinationens oprettelsesdato.
Årsag: Det betragtes som en fejl i PEM, da det er lovligt/muligt at lave en dosisdispenseret ordination uden at angive slutdato og via Edifact endda også uden startdato.

[Benny Kristensen]

Tidsbegrænsning i hvor længe bestillinger returneres i GetAddressed

GetAddressed
PEM: medsender alle addresserede bestillinger der ikke er kvitteret
FMK: medsender kun bestillinger oprettet inden for de sidste 10 dage.
Årsag: Dette sker dels af performancehensyn, dels fordi det er i tråd med den planlagte virkemåde i apotekssnitflade version2. Det vurderes ikke at have nogen praktisk betydning, da alle apoteker henter addresserede ordinationer ca. hver 5. minut

[Benny Kristensen]

Addresserede ordinationer returneres altid som AdministrationInProgress I MedicationDetails

MedicationDetails: AdministrationOrdered ~ AdministrationInProgress

PEM: returnerer addreserede (ikke kvitterede) ordinationer under enten AdministrationOrdered eller AdministrationInProgress afhægigt af om apoteket selv har markeret ordinationen under behandling
FMK: returnerer altid addreserede (ikke kvitterede) ordinationer under AdministrationInProgress
Årsag: FMK's princip med at sætte ordinationen InProgress ved bestilling, betyder at en ordination, der er addresseret også altid er under behandling.

[shp]

Hent addresserede kan returnere ny fejlkode:

108108:
"Fejl under hentning af adresserede recepter"
"adresseret til lokationsnummer" skal være lig "sæt under behandling af lokationsnummer"

[shp]

Søgning returnerer recepter oprettet til udlændinge selv hvis fødselsdato er udfyldt

Recepter for personer uden CPR vil blive returneret hvis kun for- og efternavn udfyldes. Men recepter for personer uden CPR vil ligeledes blive returneret, hvis fødselsdato medgives som søgekriterie.

[shp]

Tilbagefør udlevering kan returnere nye fejlkoder:

104226:
  "Fejl under tilbageføring af udlevering",
  "Kan ikke terminere receptordinationen, da receptordinationen er under behandling"

Returneres når terminate med værdien true er inkluderet i et tilbagefør kald af en receptordination, som er under behandling.

104228:
  "Fejl under tilbageføring af udlevering"
  "Kan ikke terminere receptordinationen når den allerede er i en terminal tilstand: {0}"

Returneres når terminate med værdien true er inkluderet i et tilbagefør kald af en receptordination, som har en terminal status (CANCELLED, INVALID, EXPIRED, INACTIVE, WEB_ADMINISTERED eller DELETED)     

104229:
  "Fejl under tilbageføring af udlevering"
  "Kan ikke genåbne receptordinationen når den i en terminal tilstand: {0}"),

Returneres når terminate med værdien false er inkluderet i et tilbagefør kald af en receptordination, som har en terminal status (CANCELLED, INVALID, EXPIRED, INACTIVE, WEB_ADMINISTERED eller DELETED)

[Pierre Jakobsen]

Generelt om systemangivelse i fejlbeskeder
Alle referencer til PEM/receptserveren i fejlbeskeder er enten fjernet eller ændret til "FMK ReceptModulet". Det er udelukkende fejlteksten, der er opdateret, fejlkoden etc er uændret.


Service "Foretag ekspedition" samt "Opret og foretag ekspedition" validerer P-Nummer
PEM validerer kun P-Nummer, når der ekspederes på en eksisterende deludlevering, men ikke ved ekspedition på en ny udlevering (= der findes ikke en bestilt deludlevering).
FMK validerer altid, at det angivne P-Nummer i forespørgslen kan findes i Stamdata på oprettelsestidspunktet. Fejler valideringen returneres i alle tilfælde den eksisterende fejlkode (104014) og -tekst.
Årsag til den mere restriktive validering i FMK er, at dette sandsynligvis er en mangel/fejl i PEM.

[shp]

Hent ordinationsdetaljer ud fra ordinations-ID returnerer ny fejlkode når man forsøger at sætte under behandling med recept-modulets lokationsnummer (5790000155811):

108010:
  "Fejl under hentning af ordinationsdetaljer ud fra ID",
  "Det er ikke lovligt at sætte ordinationen under behandling med recept-modulets lokationsnummer"


Kvitter for modtagelse returnerer ny fejlkode når man forsøger at sætte under behandling med recept-modulets lokationsnummer (5790000155811):

126213:
  "Fejl under kvittering for modtagelse af ordinationer"
  "Det er ikke lovligt at sætte ordinationen under behandling med recept-modulets lokationsnummer"

[Benny Kristensen]

Validering CPR nummer ved ekspedition

PEM: Validering af at CPR-nummer på ekspedition svarer til CPR nummer på ordination, blev kun foretaget ved DD ekspeditioner.
FMK: Valideringen foretages på alle ekspeditioner (såfremt CPR nummer er udfyldt begge steder). Det gælder også ved CreateAndAdminister.
Årsag: Valideringen er lige relevant på alle typer ekspeditioner.

Fejlteksten rettes derfor fra: "CPR nummer på ordinationen (nnnnnnnnnn) og indberetningen (nnnnnnnnnn) skal være ens for dosisdispenserede ekspeditioner" til: "CPR nummer på ordinationen (nnnnnnnnnn) og indberetningen (nnnnnnnnnn) skal være ens."