====== Hent receptanmodninger med detaljer om organisation ====== Denne service er lavet med udgangspunkt i [[fmk:1.4.4:hent_organisations_receptanmodninger | Hent organisations receptanmodninger]]. Dog med input fra EPJ-systemer omkring nødvendigheden i at kende den enkelte modtager af receptanmodninger, men henblik på at kunne internt viderestille eller afvis anmodninger. Servicen er derfor bygget til at kunne eksplicit hente både for den angivne organisation, og eventuelle underafdelinger (Kun hospitalerne er supporteret i denne), og at der så i svaret kommer ud hvilke organisationer den enkelte anmodninger er sendt til. Der laver paginering af svaret således at kun et fast antal receptanmodninger returneres, anmodninger til samme patient sættes sammen. **Bemærk:** I modsætning til tidligere services vil det ikke være lovligt for EPJ af søge på underafdelinger ved at angive en '*' som en del af den identifier man søger på, i stedet er dette erstattet af et krævet element i forespørgslen. Kaldet supporterer alle former for organisations-typer, men som beskrevet er søgning i underafdelinger ikke supporteret for andre en sygehuse. Hvis der anvendes en ikke supporteret type sammen med søgning i underafdelinger, vil anmodningen om underafdelinger blive ignoreret af FMK. Søgning på under-afdeligner supporteres både for SKS og for SOR, FMK har også en mapning frem og tilbage mellem disse intern. Så anvendes SKS, vil FMK også fremsøger for SOR, og omvendt. Dette gøres for at understøtte overgangen til SOR. **Dette kræver dog at SKS-koden er angives i SOR for at mapningen kan ske. Søges der på en SOR-kode hvor SKS ikke er angives i SOR, kan FMK ikke søge igennem med både SOR og SKS** **Bemærk** Da SOR er et meget stort register, supporteres hierarkisk søgning kun på hospitaler under de danske regioner. Samtidig har FMK teamet identificeret potentielle farer for performance pga størrelsen af de forskellige hospitaler, og antallet af afdelinger som ville kunne modtage receptanmodninger, og derfor skal inkluderes i en søgning. FMK har implementeret at de kan afvise hierarkiske søgninger hvis antallet af enheder som ville skulle gennemsøges virker for højt. Denne vil i første omgang ikke være tændt, men kan blive nødvendigt at aktivere. ====== Forespørgsel / Request ====== I forspørgslen angives en ''PrescribingOrganisation'' som er den organisation som anmodningen skulle være sendt til. Herefter angives ''IncludeSubOrganisations'', som sættes til enten ''true'' eller ''false''. Alt efter om man ønsker FMK skal forsøge at søge ikke kun på den angivne ''PrescribingOrganisation'', men også eventuelle underafdelinger til denne. Herefter kan der optionelt angives en ''RequestNotOlderThan'' Som FMK bruger til at filterede således kun oplysninger om anmodninger lavet på eller efter dette tidspunkt skal findes og returneres. Til den daglige overvågning af indsendte receptanmodninger kan denne værdi anvendes, men det anbefales også at systemet understøtter at hente alle receptanmodninger uanset alder. Dette kan gøres med en nattelig gennemgang, men blot for at sikre at der ikke er anmodninger som bliver glemt. Det sidste "optionelle" element er ''LastReceived'' som er en paginerings-variable, i ens første request til servicen skal dette element ikke indgå. Hvis FMK findes en stor nok mængde af receptanmodninger til at paginering er nødvendigt, vil svaret fra forespørgslen også indeholde en ''LastReceived'' (Kombineret med ''MoreAvailable'') som så skal videreføres til næste request. **Bemærk: ** Hvis en ''LastReceived'' angives, men denne ikke kan findes af FMK (fx hvis anmodninger er blevet behandlet i mellemtiden), vil FMK blot starte med første receptanmodning igen. __Det er altså ikke set som en fejl, at ''LastReceieved'' ikke matcher med en ubehandlet receptanmodning til den organisation man søger på. FMK ignorerer blot ''LastReceived'' i disse tilfælde__ **source="SOR"**. I forhold til andre steder i FMK hvor SOR anvendes, så er der ikke lige så mange restriktioner på anvendelsen af SOR i denne service, da den angivne organisation i denne service ikke benyttes til at registrere data i FMK, men blot benyttes til en søgning på denne og eventuelle under-organisationer. Man kan derfor opleve ikke at få fejl, selvom man fx anvender SOR-typer som ikke ellers er tilladte andre steder i FMK. Bemærk dog at man ikke skal forvente at finde recept-anmodninger sendte til organisationer hvis SOR-type ikke tillades i FMK, da FMK ville have afvist at oprette en anmodning til denne organisation. Sygehus 1443 false 2023-01-01T00:00:00Z Sygehus 1721 true 2023-01-01T00:00:00Z 111111111111111111 ====== Svar / Response ====== Svaret fra servicen indeholder en liste af ''PersonWithPrescriptionRequest'' elementer, disse elementer indeholder: * Patientens id ''PersonIdentifier'', fx CPR eller eCPR. * En liste af ''PrescriptionRequest'' elementer Hvert ''PrescriptionRequest'' element indeholder følgende: * ''PrescriptionRequestIdentifier'', id på receptanmodningen * En liste af ''OrganisationIdentifier'', Id på organisationerne som anmodningen er sendt til. Oftest vil der kun være 1 element i denne liste. * ''CreatedDateTime'' Oprettelsestidpunktet for denne receptanmodning. Denne vil altid ligge på eller efter ''RequestNotOlderThan'' hvis denne blev angivet i forespørgslen. Herefter kan elementerne ''LastReceived'' og ''MoreAvailable'' forekomme. ''LastReceived'' er Id'et på en af de receptanmodninger som forekommer i svaret, **bemærk: ** da flere receptanmodninger på samme person bundles, er ''LastReceived'' ikke nødvendigvis bundet til den sidste person i svaret. ''MoreAvailable'' forekommer og er et tegn på der er yderligere anmodninger som endnu ikke er sendt, og man bør foretage en ny forespørgsel, hvor ''LastReceived'' tages fra dette svar, og sættes på den nye request. **Bemærk: ** hverken ''LastReceived'' og ''MoreAvailable'' forekommer ikke med mindre FMK har lavet paginering af anmodningerne i svaret. 2806807019 1683718029167001188 1301 2016-01-01T08:00:00Z ... 1683718034204001188 1301 2016-01-01T08:00:00Z 2608856731 1683718029312001188 1301 2016-02-01T08:00:00Z ... 1683718033630001188 1301 2016-02-01T08:00:00Z 2007433755 1683718029450001188 1301 2016-03-01T08:00:00Z ... 1683718034102001188 1301 2016-10-01T08:00:00Z 1405035896 1683718029691001188 1301 2016-06-01T08:00:00Z ... 1683718034003001188 1301 2016-07-01T08:00:00Z 1683718034204001188