FMK Teknik

Der er lige deployet en v1.10.1 af Recept-modulet på TEST1, som understøtter den nye opførsel af apoteksnitfladen beskrevet i snitflade dokument v3.11.0.

Den nye opførsel kan enables med en property, og er blevet enabled på TEST1 miljøet. Det er planen er ændringerne i første omgang ikke enables i TEST2 eller øvrige testmiljøer (og produktion), selv når denne eller senere versioner deployes dér. Ændringerne vil dog blive enabled i TEST2 inden de bliver det i produktion, og på UDD og PRODTEST umiddelbart efter.

Bemærk at ny opførsel for lægerne ifm. annullering af recepter IKKE er aktivt endnu, da det kræver ny version af FMK koden også.

Vedhæftet er en beskrivelse af en række testcases, som Trifork har brugt internt, der beskriver hvordan visse scenarier skal fungere før og efter ændringen.

Apoteksleverandørerne opfordres til at test deres løsninger grundigt så der laves en version, der kan fungere både med gammel funktionalitet (fx som på TEST2 eller PRODTEST) og med ny funktionalitet på TEST1. Trifork deltager gerne i denne test! Vi ser frem til at høre fra jer.

Mvh
FMK-teamet

De schemaer som hidtil har ligget til grund for FMK snitfladerne har inkluderet nogle special-udgaver af bl.a. SAML og WSSE schemaer, som stammer fra dengang Den Gode WebService (DGWS) blev specificeret, vistnok i regi af IT & Telestyrelsen.  Dels har de taget udgangspunkt i en pre-release udgave af specifikationerne, og dels var de special-tilpassede. Det har vist sig at volde problemer nu, i forhold til at understøtte visse kald over Identitets-baserede WebServices (IDWS).

Derfor har vi måttet ændre i de versioner vi anvender af bl.a. SAML og WSSE så de er nærmere de officielle specifikationer. Der er tale om ændringer, som gør at schemaerne tillader det samme som før, plus nogle nye variationer. Det kan desværre betyde, at visse udviklingsværktøjer i mindre grad end hidtil bliver i stand til at hjælpe med at udfylde header-oplysninger korrekt.

Indtil videre er disse headers kun inkluderet i de foreløbige FMK v1.4.6 schemaer, men vil brede sig til de andre versioner såfremt der bliver behov for opdateringer til disse.

Vi har tidligere publiceret eksempelkode i C#.Net som illustrerer hvordan man kan skaffe et ID-kort og kalde en FMK service med DGWS. Den findes nu i en udgave som passer til de gamle schemaer (FMK 1.4.0 eksempel) og i en anden udgave som passer til de ny (FMK 1.4.6 eksempel).

Begge eksempler kan findes her: http://wiki.fmk.netic.dk/doku.php?id=fmk:generel:eksempel_kode

Med venlig hilsen
FMK-teamet

Vi har nu deployet en version (v1.4.4.10.a) af FMK på TEST1.

Den gamle version af FMK (v1.4.4.9.d) som var deployet på TEST1 før, kører nu på TEST2. Så hvis I af en eller anden grund vil udskyde overgangen til den nye version, så kan i teste imod TEST2 miljøet.

Den nye version understøtter følgende apoteks-rettede services i 1.4.6 snitfladen:

• Hent medicinkort for apoteker
• Påbegynd ekspedition
• Opret effektuering på recept
• Afbryd ekspedition
• Tilbagegefør effektuering på recept
• Afslut recept
• Ugyldiggør recept
• Genåbn recept
• Opret bestilling
• Opret og ekspeder recept

Samtidig er der indført en række mindre schema-ændringer til 1.4.6:

• Fjernet servicen Opdater Effektuering (og tilhørende schema-filer) - brugerne kan anvende tilbagefør og evt. ekspedere igen, hvis der skal rettes en fejl.
• CreateAndEffectuatePrescriptionType (som anvendes i servicen opret og ekspeder recept)
• Order skal være obligatorisk (fjern minOccurs=0)
• CreatedBy angives kun på request niveau, ikke pr. recept
   
• CreateOrderAndEffectuationType (som anvendes i servicen opret og ekspeder recept)
• Fjernet bestillingens status - status skal altid være Udført
   
• CreateOrderType (som anvendes ved recept-oprettelse)
• DoseDispensed skal bare være et flag, ikke en struktur. Dem der opretter en bestilling er ikke dem, der kender værdierne for DD-felterne. Flaget er indført i CreateOrder og CreatePrescription.
   
• CreateOrderRequest (som anvendes ved oprettelse af en bestilling på en eksisterende recept)
• Fjern ReportedBy - alle roller må oprette en bestilling, så det giver ikke mening at anvende på vegne af.
   
• CreateOrderPrescriptionType (som anvendes ved oprettelse af en bestilling på en eksisterende recept)
• Felter fra Order indlejres, dog uden CreatedBy og ReportedBy, som kun angives på request-niveau
• DoseDispensed skal bare være et flag, ikke en struktur. Dem der opretter en bestilling er ikke dem, der kender værdierne for DD-felterne.
   
• InvalidatePrescriptionType (som anvendes i servicen InvalidatePrescription)
• Feltet ReasonText er omdøbt til InvalidationReasonText og gjort obligatorisk.
   
• PrescriptionType (som bruges når man henter recepter, fx som en del af et medicinkort)
• Nyt felt InvalidationReasonText tilføjet på Prescription. Udfyldes på recepter hvor status er sat til Ugyldig (af et apotek).
   
• Flyttet DosageText fra Prescription.(PackageRestriction, DoseDispensedRestriction) til Prescription.
• Flyttet LabelText fra Prescription.Order.Effectuation.PackageDispensed til Prescription.Order.Effectuation.
• Ændringerne fra denne høring er implementeret: http://www.fmk-teknik.dk/index.php?topic=887.0
• Tilføjet schemaer til servicen Annuller Bestilling (CancelOrderRequest, CancelOrderResponse). Servicen er endnu ikke implementeret.

Ændrede schema- og wsdl-filer er publiceret på DokuWiki (her).

Med venlig hilsen
FMK teamet

Hej,

På sidste møde med apotekssystemleverandørerne (den 25. januar 2016) blev der lovet delvise leverancer af 1.4.6 snitfladen kørende på TEST 1 på nogle bestemte datoer, og herunder bl.a. en leverance til den 28. marts, hvoraf det meste funktionalitet allerede er leveret.

Da disse datoer blev fastsat var det i forhold til nogle sprint-perioder, som sidenhen er skubbet lidt af hensyn til vinterferie og påske. Derfor udskydes de sidste leverancer tilsvarende, så de ligger en uge senere end ellers. Indholdet af de sidste leverancer forventes at være følgende:

• 4. april: Opret og ekspeder recept, opret bestilling (samt måske også annuller bestilling - ellers er den med i næste leverance)
• 25. april: Hent nye bestillinger, kvitter for bestillinger, apotekssystem rolle
• 17. maj: Søg medicinkort, erstat recept, certificeringskriterier

Desuden forventes:

• en række mindre skema-ændringer, som annonceres separat
• muligvis ændringer af virkemåde på den eksisterende apoteksnitflade vedr. "påbegynd ekspedition", som har været i høring (konklusion er endnu ikke fastlagt)
• muligvis ny funktionalitet, så Lægemiddelstyrelsen kan registrere udenlandske apoteksudleveringer (oprettet via servicen Opret og ekspeder recept)

Med venlig hilsen
FMK-teamet

Der er lagt schemaer på DokuWiki som svarer til ovenstående rettelser.

I forbindelse med implementationen af FMK 1.4.6 er vi stødt på en række mindre fejl / uhensigtsmæssigheder i snitfladen, som vi har rettet. Herunder er en oversigt over ændringerne.

• Elementet OrganisationIdentifier er fjernet fra GetMedicineCardRequest og GetMedicineCardResponse, hvilket betyder at disse requests kun kan kaldes med en PersonIdentifier. Bemærk at der fortsat er flere muligheder i den apoteks-specifikke service GetMedicineCardOnlyEffectuatable.
• Tilføjet elementerne Gender og BirthDate til SimpleCPRPersonType, da man i den gamle apotekersnitflade kunne se denne information. Det betyder at elementer der indeholder en SimpleCPRPersonType, vil indeholde køn og fødselsdato.
• Ændret typen af elementet PackageNumber fra talværdier til strengværdier. Formålet er at være kompatibel med potentielle nye typer ID'er i fremtiden, hvilket vil kunne angives via Source-attributten.
• Elementet ModifiedBy i AbortEffectuationRequest, InvalidatePrescriptionRequest, ReopenPrescriptionRequest, TerminatePrescriptionRequest og UndoEffectuationRequest er ændret fra optional (minOccurs=0 i schema-filen) til at være påkrævet.
• Fjernet elementet ModifiedBy fra UndoEffectuation, da der allerede findes en ModifiedBy på UndoEffectuationRequest.
• Fjernet elementet ReportedBy fra UndoEffectuation, som bliver benyttet i UndoEffectuationRequest, da det ikke giver mening på apotekersnitfladen.
• Fjernet elementet ReportedBy fra InvalidatePrescriptionRequest, da det ikke giver mening på apotekersnitfladen.
• Elementet DeadlineDateTime er fjernet fra DoseDispensing. Det er ikke praktisk muligt for apotekerne at angive en deadline på forhånd, men deadline indtræffer de facto når servicen påbegynd ekspedition (StartEffectuation) kaldes.
• StartEffectuationRequest er udvidet med elementet DoseDispensing, der beskriver information omkring dosisdispensering. (se evt. eksempel  http://wiki.fmk.netic.dk/doku.php?id=fmk:1.4.6:pabegynd_ekspedition).
• Typerne CreatePrescriptionOrderEffectuationRequest og CreatePrescriptionOrderEffectuationResponse er omdøbt til henholdsvis CreateAndEffectuatePrescriptionRequest og CreateAndEffectuatePrescriptionResponse.
• Udvidet CreateAndEffectuatePrescriptionRequest således at det er muligt at oprette papirrecepter på personer uden et cpr-nummer. Bemærk, funktionaliteten er ikke implementeret endnu.

Vi lægger en ny version af schemaerne ud på denne side snarest muligt og lægger i opfølgende bemærkning i denne tråd, når det er gjort.

Vi har nu deployet en version af FMK på test1, der understøtter følgende apoteks-rettede services:

• Hent medicinkort for apoteker
• Påbegynd ekspedition
• Opret effektuering på recept
• Afbryd ekspedition
• Tilbagegefør effektuering på recept
• Afslut recept
• Ugyldiggør recept
• Genåbn recept

Desuden understøttes nye DD felter på den gamle apoteksnitflades GetMedicationByMedicationID, som forklaret her.

Jeg har fået en kommentar om, at det ville være godt at se, hvor det nye kald "påbegynd ekspedition" kunne se ud, så jeg vil lige uddybe en smule.

Konkret mener jeg at servicen nemmest implementeres i den eksisterende apoteksnitflade ved at udvide en eksisterende service GetMedicationsByMedicationID med nogle nye, optionelle input-felter. Den har nemlig allerede i dag mulighed for at ændre status til "under behandling" ved at sende elementerne MarkInProgress og MarkInProgressLocationNumber med.

<GetMedicationsByMedicationIDRequest>
    <MedicationID>123456789012345</MedicationID>
    <MarkInProgress>true</MarkInProgress>
    <MarkInProgressLocationNumber>5790000170609</MarkInProgressLocationNumber>
    <FirstDateOfDoseDispensingPeriod>2016-02-15</FirstDateOfDoseDispensingPeriod>
    <LastDateOfDoseDispensingPeriod>2016-02-28</LastDateOfDoseDispensingPeriod>
</GetMedicationsByMedicationIDRequest>

Konsekvensen af denne ændring er, at recepten først sættes under behandling når denne service kaldes med MarkInProgress=true og lokationsnummer i MarkInProgressLocationNumber. De nye felter, FirstDateOfDoseDispensingPeriod og LastDateOfDoseDispensingPeriod anvendes naturligvis kun når der er tale om ekspedition af dosisdispenseret medicin.

Dvs. følgende handling vil ikke sætte recepten under behandling, når denne ændring træder i kraft:

• Opret recept med adressering til et apotek
• Kvitter for modtagelse
• Opret anmodning om apoteksudlevering (opret bestilling) fra hjemmepleje eller patient

Sådanne ændringer vil naturligvis kræve apoteksleverandørernes accept og kræve at alle systemerne testes med den nye funktionalitet i testmiljøerne.
Derefter må vi sammen finde en dato hvor ny opførsel kan enables i produktion.