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