FMK Teknik

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.

FMKs snitflade er opdateret som beskrevet herover:

FMK - Snitfladebeskrivelse - 1.4.2.3: http://digitaliser.dk/resource/2535844
WSDL og skemaer for FMK 1.4.2: http://digitaliser.dk/resource/2535863
Inline WSDL for FMK 1.4.2: http://digitaliser.dk/resource/2535884

Det er blevet besluttet, at hjemmesygeplejens bestillinger i form af receptfornyelsesanmodninger fremover ikke kan foretages på lægemiddelordinationer der er privatmarkerede. Der vil derfor snarest muligt blive indført en validering på FMK, der gør at FMK returnerer en fejlmelding såfremt dette forsøges.

Som det fungerer nu giver det ikke mening at foretage bestillinger på lægemiddelordinationer med privatmarkering. Den eller de lægepraksis/sygehusafdelinger der angives som modtager på bestillingen har ikke har mulighed for at få patientens/borgerens samtykke til at slå op på den privatmarkerede lægemiddelordination, og værdispring er ikke relevant. Idet bestillinger er synlige på mange måder (ved opslag på CPR-nummer, på ydernummer/SKS-kode eller på kommunekode) kan man ikke pr. automatik gå ud fra at patienten har givet samtykke til den aktør der læser bestillingen.

På den korte bane vil løsningen være at patienten eller hjemmesygeplejen kontakter lægen ad andre veje, eller evt. overvejer om det er relevant med en privatmarkering.

Såfremt der, f.eks. i hjemmesygeplejens pilotfase, viser sig mulighed for en bedre løsning, forventer vi en lettere revideret snitflade for bestillinger i en senere version. Her kan der evt. være mulighed for at lave tilpasninger, således at der fremover vil være muligt at oprette bestillinger på privatmarkerede lægemiddelordinationer.

Mvh Tom

Hermed en invitation til en FMK 1.4.2 workshop den 18. november 12-16 hos Trifork i Århus.

Formålet med denne workshop/infomøde et at udveksle information omkring funktionalitet i en kommende 1.4.2 version, og desuden at få afstemt forventninger omkring tidsplaner. Arrangementet er derfør først og fremmest relevant for systemer der overvejer at begynde en 1.4.2 implementation i den nærmere fremtid.

Omkring praktisk information forventer jeg bl.a:

• Strukturerede doseringer med flere perioder
• Opslutning af doseringer i PN og ikke-PN
• Ændring af suspendering
• Aktører (ReportedBy, ansvarlig for ...)
• Kildeangivelser (source) til kodefelter m.v.

Øvrige emner er velkomne!

På grund af frokost skal tilmelding ske senest den 11, men gerne så snart som muligt for at kunne vurdere størrelsen af arrangementet!

Mvh Tom

Vedhæftet er en opdateret specifikation på stamdata for doseringer og doseringsforslag.

Stamdata er ændret således at der returneres doseringsforslag i XML-format passende til FMK 1.2.6, 1.4.0 og en kommende 1.4.2 version. Stamdata på TEST1 og TEST2 er opdateret for releaseNumber 9, de tidligere versioner er i det gamle format.

For at kunne udstille data så hurtigt som muligt, og for at gøre fremtidige opdateringer så enkle som muligt, er de tre formater returneret i samme felt, omgivet af et XML-element der fortæller hvilken version det drejer sig om. Skemaer til dette er også vedhæftet her.

Mvh Tom

 

Vedhæftede dokument indeholder en opdateret beskrivelse af hvorledes adviseringer anvendes i forbindelse med FMK.

Husk at det er nødvendigt at være logget ind for at få adgang til vedhæftede dokumenter.

Mvh Tom

Hej

Fra og med 1.4.0 er det muligt at angive doseringsenheder i både ental og flertalsform. Dette er desværre ikke muligt i 1.2, og der må man vælge en af de to former.

Om det er en entals- eller flertalsform er først og fremmest relevant for at undgå at der bliver produceret doseringsoversættelser som f.eks. "1 tabletter morgen og 2 tabletter aften".

Nu er lige præcist tabletter, kapsler osv. kendt af FMK, så der vil FMK alligevel vælge rette entals eller flertalsform (så eksemplet er der taget højde for), men for enheder FMK ikke kender er det ikke muligt.

Mvh Tom

På grund af uklarhed omkring den kliniske betydning af en "relation til overordnet lægemiddelordination" er det besluttet, at funktionaliteten disables i FMK 1.4.0 og 1.4.2. Elementet vil fortsat findes i XML-skemaerne, men et kald med en "relation til overordnet lægemiddelordination" vil medføre at FMK returnerer en fejlbesked.

Mvh Tom