FMK Teknik

Hej

Vedhæftet er den første udgave af skemaer til FMK 1.3. Denne version danner basis for yderligere funktionalitet til EOJ-systemer m.v. Skemaerne svarer i stor omfang til funktionalitet (men ikke skemadefinitioner) for FMK 1.2.4 og 1.2.6, og indeholder kun i begrænset omfang ny funktionalitet.

Det vil derfor med stor sikkerhed komme yderligere udvidelser, specielt til hjemmesygeplejen.

Mvh Tom

Hej

Omkring FMKs krav om takstdatoen, så var vi også inde på det på teknikermødet. Men en væsentlig årsag er at takstdato + "kode fra taksten" er en sammensat nøgle, og koden er ofte ikke tilstrækkelig for at finde en eksakt tekst, et eksakt lægemiddel m.v.

Omkring muligheden for at anvende lægemidler fra gamle takster, så gælder det ikke nødvendigvis kun for lægemidler der midlertidigt er udgåede. Så vidt jeg husker har vi ikke mulighed for at adskille permanent udgåede lægemidler, og lægemidler med f.eks. et midlertidigt leveringssvigt ud fra data i taksten. Men en anden væsentlig årsag, er at der er et ønske om at kunne oprette lægemiddelordinationer ud fra gamle løse receptordinationer. Her er det ikke nødvendigvis ønskeligt at substituere det lægemiddel der faktisk er givet.

Mvh Tom

"Minihøring" omkring FMK 1.4 snitflade-oprydning

Vedhæftede dokument indeholder en beskrivelse af et muligt indhold af en kommende 1.4 snitflade.

Kommentarer, forslag til yderligere forbedringer m.v. modtages gerne i dette forum eller via mail. For at vi kan nå at få eventuelle ønsker og forslag med, vil vi gerne have tilbagemeldinger senest fredag den 23. marts.

Mvh Tom

"Minihøring" omkring en mulig ændring af snitfladen – Lægemidlers takstdato

Ved oprettelse og opdatering af lægemiddelordinationer er der et krav at der angives en takstdato. Takstdatoen angiver versionen af både lægemiddeldata (drug-id, varenummer m.v.) og kodesæt (f.eks. indikation, administrationsvej). Det er nødvendigt at angive en takstdato, idet både lægemiddeldata og kodesæt kan ændres mellem takstversioner, takstdatoen udgør derfor den ene halvdel af en sammensat nøgle.

Ved oprettelse af lægemiddeldata kan der være den udfordring, at takstdatoen for lægemidlet ikke er kendt. Samtidigt vil kodesættet i visse systemer altid være fra den aktuelle takst. Dvs. selv om takstdatoen kunne angives, ville der være en risiko for at den ikke både kan udpege den rigtige takst for lægemiddeldata og for det anvendte kodesæt.

I en kommende snitflade version 1.4 vil vi overveje, at takstversionen angives på de enkelte felter, således at versionen angives på selve drugid-elementet, på indikationskode-elementet osv. Herved opnås der mulighed for at adskille versionen for lægemiddeldata og for øvrige koder og tekster. FMK vil som hidtil validere og supplere med opslag i den korrekte takst. I de tilfælde hvor takstversion ikke er kendt, kan dette eksplicit angives, og FMK kan supplere med opslag på den senest kendte version af lægemidlet.

I den eksisterende 1.2.* snitflade har vi ikke mulighed for at ændre hvorledes takstversionen angives, takstversionen skal derfor stadig altid angives for hele lægemiddelordinationen. Den ideelle situation er at takstversionen udpeger versionen af kodesættet og lægemiddeldata, dvs. som FMK også vil forstå det i dag. Er dette ikke muligt skal takstversionen udpege versionen af kodesættet. Validering og opslag på lægemiddeldata vil foregå som følger:

• Ved oprettelse og opdatering af en lægemiddelordination vil FMK først forsøge at slå lægemiddeldata op via et opslag på drugid med den angivne takstversion.
• Findes lægemidlet ikke ud fra ovenstående opslag søges drugid i tidligere takstversioner, med nyeste version først.
• Er lægemidlet ikke fundet vil FMK returnere en fejlbesked.

I forhold til nu er trin 2 nyt. Ændringen medfører at FMK også vil returnere data i denne form. Dvs. at klientsystemer også skal kunne håndtere at drugid ikke altid kan findes ud fra den angivne takstversion.

Før vi eventuelt kan gennemføre ændringen skal vi sikre os, at dette ikke er et problem. Derfor vil vi gerne have en tilbagemelding herpå for samtlige systemer. Er denne umiddelbart positiv kan vi gennemføre ændringen på testserverne først. Vi vil gerne have en tilbagemelding herpå senest fredag den 23. marts.

Mvh Tom

Hej Tom

Dit ønske er hørt, men: Doseringsforslagene med det nuværende format er sendt til NSP driftsoperatøren, således at de kan begynde at indlæse dem og udstille dem på stamdatamodulet på NSPen. Jeg kender ikke tidsplanen derfor, men vil være ked af at forsinke det yderligere. Derfor vil ændringen ikke blive indført med 1.2.6 snitfladen.

I øvrigt er langt de fleste doseringsforslag på formen morgen+middag+aften+nat, og vil derfor være anvendelige i alle systemer.

Mvh Tom

Det er, som Tom også skriver, fordi patienten giver samtykke til at se medicinkortet som det ser ud på det aktuelle tidspunkt. Efterfølgende nye ordinationer skal der også gives samtykke til.

Snitfladebeskrivelsen er opdateret med bilag omkring FMK webservice-versionsmatrix og rolle-rettigheder. Se version 1.2.4.5 på http://digitaliser.dk/resource/1916901

Hej Christian

Vi har for nyligt lavet nogle faste "pakker" til test og undervisning, nok først og fremmest til regionernes undevisning på EPJ systemerne. Se http://www.fmk-teknik.dk/index.php?topic=21.0

På de fællest testservere har du mulighed for at slette data på de testpersoner i har tilknyttet via admin gui. Vi har ingen automatiseret vej at i kan oprette individuelle testdata på, men en mulighed kunne være at i selv lavede en "testklient" der lægger testdata på serveren.

Mvh Tom

Hej Christian

I dag burde det kunne gøres på to måder:

• Ved at hente den aktuelle version og herefter de tidligere versioner enkeltvis. Dvs. hvis "hent aktuelt medicinkort" returnerer version 10 hentes version 9, 8, 7, ... enkeltvis indtil der returneres en version systemet kender i forvejen, eller der spørges på en version ældre end to år.
  
  
• 
  Ved at hente aktuelle medicinkort, herefter at hente medicinkort som det så ud for to år siden (med angivelse af dato i requestet). Herved kender systemet det interval af medicinkort-versionsnumre der kan returneres.
  

Bemærk dog at de fortløbende versionsnumre med stor sandsynlighed kommer til at blive erstattet af "noget andet". Det skyldes at FKM for at sikre en meget høj oppetid engang i fremtiden vil blive et distriberet system. Herved er der ingen sikker måde at et cluster kan generere "næste nummer", uden at der er en lille risiko for at et andet cluster næsten samtidigt også genererer samme "næste nummer".

Dette "noget andet" vil sandsynligvis blive et ikke fortløbende versionsid, en relation til forrige version, og en "versionering med events". Hvis vi indfører "versionering med events" som beskrevet i dokumentet i linket i min tidligere post, så vil du kunne slå den ældste tilgængelige version op med et request i retningen af:


<EventRequest>
<CPR>1111111118</CPR>
<FromTimestamp>2009-10-17T11:00:00</FromTimestamp>
<ToTimestamp>2999-01-01T00:00:00</ToTimestamp>
<Limit>1</Limit>
</EventRequest>


Der mangler dog en "order by" angivelse, som sikrer at det er det ældste event der returneres, og ikke det seneste, dette element er ikke beskrevet i ideoplægget.

Mvh Tom

Vi har opdateret snitfladebeskrivelsen på to punkter.

Den komplette snitfladebeskrivelse 1.2.4.4 findes på digitaliser.dk:
http://digitaliser.dk/resource/1913000

Receptkomprimering
Beskrivelsen af receptkomprimeringen er rettet, så den beskriver forskellen på snitfladeversion 1.2.2 hvor løse recepter komprimeres og 1.2.4 hvor der ikke komprimeres.

Information til første udlevering
Når lægen udsteder en recept er det muligt for lægen sætte visse typer af information til første udlevering: 

• Leveringinformation og ordre instruktion (DeliveryInformationAndOrderInstruction)
• Leveringens prioritet (DeliveryStructure/DeliveryPriorityText)
• Adresse (DeliveryStructure/StreetName) eller
• PseudoAdresse (DeliveryStructure/SPseudoAddress)
• Postnummer (DeliveryStructure/SPostCodeIdentifier)
• Kontakt navn (DeliveryStructure/SContactName)

Ved en eventuel genbestilling, foretaget af patienten selv, kan denne leveringsinformationen ændres på hver efterfølgende udlevering. På receptserveren findes disse typer af information derfor ikke på selve recepten (egentligt receptordinationen), men på effektueringen (i receptserver-terminologi på første deludlevering). 

Dette har den følgevirkning, at de ovenfor nævnte informationer først kan vises når apoteket har ekspederet recepten, og effektueringen vises på FMK. Informationen hentes altid fra første udlevering, idet det er denne der er angivet af lægen, også selv om patienten efterfølgende vælger en anden leveringsadresse eller lignende.

Hej Christian

Vi overvejer at forbedre mulighederne for at hente information omkring oprettelser/ændringer på FMK, se http://www.fmk-teknik.dk/index.php?topic=36.0

Ud over de andre fordele "versionering med events" giver skulle det f.eks. også være muligt at hente det første "opret" eller "opdater" kald siden "i dag minus to år".

Ḿvh Tom

Hej Christian

Kan jeg få dig til at oprette en sag i JIRA på det du beskriver? Gerne med de relevante punkter beskrevet under punktet bug-rapportering. Derved få du feedback på sagens forløb, og vi får den ind den rigtige vej

Mvh Tom

Hej Christian

Ifølge snitfladebeskrivelsen hentes startdatoen fra doseringen, alternativt fra lægemiddelordinationens startdato hvis den ikke findes på doseringen. I praksis er det implementeret således at hvis den både findes på doseringen og på lægemiddelordinationen anvendes den tidligste dato. Dette kan ikke være korrekt, idet doseringens startdato aldrig bør kunne være før lægemiddelordinationens startdato, og ofte vil være den samme.

Jeg har oprettet https://developer.trifork.com/browse/FMK-368

Tom

Hej

Uanset formatet kan der ikke i de tidligere formater (FMK, Receptserver, Den Gode XML recept, EDI, ...) sendes mere end 3 linjer med enten DeliveryInformation eller OrderInstruction. I praksis bliver DeliveryInformation og OrderInstruction brugt tilfældigt, derfor har vi valgt fremover ikke at skelne mellem de to tekster.

Mvh Tom

Hej

Reglen er, at lægemiddelordinationer skal slettes to år efter at de enten er udløbet eller aktivt seponeret. Dvs. har de ingen udløbsdato (faste medicineringer) slettes de ikke.

I øvrigt er vi ved at se på slettereglerne igen, og i den forbindelse vil vi nok lave en valideringsregel, der går at det ikke bliver muligt at slå op på medicinkort-versioner (dvs. historiske data) ældre end to år: Her kan der være slettet en eller flere lægemiddelordinationer, og opslaget kan derfor returnere misvisende data. Lægemiddelordinationer ældre end to år, og der ikke er slettede, kan man fortsat slå op på.

Mvh Tom