FMK Teknik

Datasættet "doseringsenheder og doseringsforslag" er opdateret med doseringsforslag (doseringsenhederne er uændrede). Vedhæftede fil indeholder ændringer i forhold til versionen der aktuelt findes på test og produktion.

Desuden er doseringen for Vermox rettet, hvilket også fremgår af listen.

Det har været nødvendigt at ændre oprindelige tidsplan en smule, idet der har været en del afklaringer og ændringsønsker undervejs. Den nye plan er:

Test1 og test2 opdateres mandag den 31. marts med data gældende fra samme dag.
Prod og prodtest opdateres tirsdag den 8. april med data gældende fra den 9. (dvs. med ValidFrom = 2014-04-09).
Uddannelsmiljøet opdateres ikke.

Mvh Tom

Jeg vil gøre opmærksom på at den endelige snitfladespecifikationen findes på http://wiki.fmk.netic.dk

Endelige specifikationer har tidligere kunnet findes på digitaliser.dk. Gamle versioner findes stadig der, men fremover vil snitfladedokumentation være at finde på http://wiki.fmk.netic.dk

Mvh Tom

I forbindelse med at muligheden for at oprette receptordinationer via EDIFACT lukkes fra og med 30.  juni i år, er der to væsentlige punkter at bemærke:

For det første, at det naturligvis også vil betyde, at det ikke længere vil være muligt at oprette receptordinationer ud fra hjemmesygeplejens receptfornyesesanmodninger. Disse skal oprettes via FMKs "opret receptordination ud fra lægemiddelordination"-service, på samme måde som alle andre receptordinationer. Det gælder i øvrigt allerede i dag, jvf. de aktuelle certificeringskrav.

For det andet, at de af hjemmesygeplejens EOJ-systemer, der på dette tidspunkt endnu ikke er kommet på FMK, stadig vil sende receptfornyelsesanmodninger via EDIFACT. Disse skal stadig kunne modtages, også efter 30. juni.

Mvh Tom

Vedhæftet er doseringsenheder og doseringsforslag svarende til hvad der aktuelt udstilles på TEST1 og TEST2. Bemærk at formatet er ikke det samme som fås ved opslag på stamdatamodulet på NSP'en.

Mvh Tom

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.

Der har vist sig et behov for at kunne fjerne data i FMK. Eksempelvis ved fejlagtige registreringer på et forkert CPR-nummer eller registreringer der er opstået ved misbrug af CPR-numre.

I den forbindelse er det ikke tilstrækkeligt at fjerne data i FMK, systemer der på et tidspunkt har hentet medicinkort fra FMK skal også informeres om at data er fjernet fra FMK.

I den eksisterende 1.2 og 1.4 snitflade er det muligt at markere et medicinkort som ”ugyldigt”:

Medicinkort slettes ikke, men kan som før stadig markeres som ”ugyldig”, hvilket indikerer at medicinkortet i et eller andet omfang indeholder misvisende data. Medicinkort markeret som ”ugyldig” kan stadig returneres og opdateres, idet det skal være muligt at bringe medicinkortet tilbage til en korrekt tilstand.

Tilsvarende vil der blive indført mulighed for at markere øvrige dele af medicinkortet som ”ugyldige”:

Lægemiddelordinationer kan blive markeret som ”ugyldige” af en administrator. Derved returneres kun lægemiddelordinationens ID i et InvalidDrugMedication-element ved opslag på medicinkort eller ved opslag direkte på lægemiddelordinationen.

Receptordinationer kan kan blive markeret som ”ugyldige” af en administrator. Derved returneres kun receptordinationens ID i et InvalidPrescriptionMedication-element ved opslag på medicinkort, lægemiddelordination eller ved opslag direkte på receptordinationen.

Effektueringer kan kan blive markeret som ”ugyldige” af en administrator. Derved returneres kun effektueringens ID i et InvalidEffectuation-element ved opslag på medicinkort, lægemiddelordination, receptordination eller ved opslag direkte på effektuering.

Systemer der modtager en ugyldig-markeret lægemiddelordination, receptordination eller effektuering skal sikre at denne ikke præsenteres  for brugeren, hverken ud fra data netop returneret fra FMK eller ud fra importerede lokale data.

I responses vil der i stedet for DrugMedication-, PrescriptionMedication- og Effectuation-elementerne kunne blive returneret InvalidDrugMedication-, InvalidPrescriptionMedication- og InvalidEffectuation-elementer. Disse indeholder udelukkende et Identifer-element, dvs. det oprindelige lægemiddelordinations-ID, receptordinations-ID eller effektuerings-ID. 

FMK vil returnere ugyldig-markerede lægemiddelordinationer, receptordinationer og effektueringer i to år efter de er markeret som ugyldige. Herefter vil de blive endeligt slettede på FMK.

Vi har lavet en liste der sammenfatter hvilke "source" typer der kan anvendes i FMK som kilde til kodeværdier, og som der kan forventes at FMK aktuelt vil returnere. Source "Medicinpriser" angiver at stamdata stammer fra taksten (officielt Medicinpriser), og er altid suppleret med en sourceDate indeholdende takstversion. Evt. kan takstversionen i stedet angives som år og uge i sourceYearAndWeek i kald til FMK, i svar vil dette være erstattet af den eksakte takstdato.

Bemærk at alle 1.4.0 og 1.4.2 systemer skal kunne forvente at der i fremtiden tilføjes nye source-typer.


Administrationsvej
I skemaer RouteOfAdministrationCode, RouteOfAdministrationText
1.4.0, 1.4.2: Medicinpriser

Aktiv substans
I skemaer ActiveSubstanceCode, ActiveSubstanceText, ActiveSubstance
1.4.0: Medicinpriser, Local, Chemical Abstract (CAS)
1.4.2: Medicinpriser, Local
Local kan anvendes til at angive en aktiv substans der ikke er defineret i Medicicinpriser, i så fald er der behov for at dette er i generelt forståelige termer.
CAS er aldrig taget i brug og bør ikke anvendes.

ATC
I skema ATCCode
1.4.0, 1.4.2: Medicinpriser

Doseringsenhed
I skema DosageCode, kun anvendt i receptordinationer
1.4.0, 1.4.2: Medicinpriser

Doseringsenhed
I skemaer DosageQuantityUnitTexts, DosageQuantityUnitText
1.4.0, 1.4.2: Medicinpriser, Doseringsforslag, Local
Local svarer reelt til situationen i FMK 1.2, hvor der ikke findes fælles stamdata for doseringsenheder.

Drugid
I skema DrugIdentifier
1.4.0: Medicinpriser, Local
1.4.2: Medicinpriser, Local, desuden forventes suppleret med specifikke sorces for stærke vitaminer og mineraler og tilknyttede behandlinger
Med Local kan der i 1.4 indsendes lægemidler der i 1.2 skulle være oprettet uden drugid. Drugid med source Local må dog ikke anvendes til en uovervåget import.

Indikation
I skema IndicationCode
1.4.0, 1.4.2: Medicinpriser

Lægemiddelform
I skema DrugFormCode
1.4.0, 1.4.2: Medicinpriser

Organisations-ID
I skema OrganisationIdentifier
1.4.0, 1.4.2: SKS, Yder, EAN-Lokationsnummer, CVR, CVR-P, Kommunekode
EAN-Lokationsnummer CVR og CVR-P anvendes i forbindelse med apotekernes recepthåndtering.

Pakningsstørrelsesenhed
PackageSizeUnitCode
1.4.0, 1.4.2: Medicinpriser

Specialekode (læge)
I skema SpecialityCode
1.4.0, 1.4.2: Medicinpriser

Styrkeenhed
I skemaer DrugStrengthText, DrugStrengthUnitCode
1.4.0, 1.4.2: Medicinpriser

Varenummer (pakning)
I skema PackageNumber
1.4.0, 1.4.2: Medicinpriser, Frihandelsvare
Ved Frihandelsvare vil varenummer ikke blive valideret.