Avvikelser - hela listan (Nordic Medtest JIRA) | |||||||
Displaying 91 issues at 2021-08-10 09:16. |
Issue Type | Key | Summary | Description | Påverkat TK | TK-bedömning | Acceptabel för | Ej acceptabel för |
---|---|---|---|---|---|---|---|
Avvikelse | INAV-1093 | SLA på svarstid / delsvar följas ej |
För tjänstekontrakten inom området sammanhållen journalföring finns ett SLA-krav för svarstid.
|*Kategori*|*Värde*|*Beskrivning*| |Svarstid|Svarstiden för ett anrop får inte överstiga 30 sekunder.|Svarstid| Avvikelsen uppstår när en tjänsteproducent inte uppfyller detta krav, inte returnerar delsvar, utan returnerar tomt svar. |
Godkänd - Förbehåll |
-
|
-
|
|
Avvikelse | INAV-1087 | SOAP-header: Hänsyn tas inte till Logical Adress vid filtrering |
Tjänsteproducenten får enbart returnera data som härstammar ur det källsystem som logiskt adresseras.
*Från TKB:* Filtrera enligt RIVTA-headern LogicalAddress. Svarsmeddelandet får endast innehålla information som skapats i det källsystem som anges av frågemeddelandets LogicalAddress. Filtrering på källsystem via Logical Address ska tillämpas. Avvikelsen uppstår när källsystemet returnerar data även om logisk adress ändras till en icke godkänd konsument. Källsystemet returnerar alltså alltid data oberoende av logisk adress. |
<p> <n>GetActivities - 1.0</n> <br /> <n>GetObservations - 1.0</n> <br /> </p> |
Underkänd |
-
|
-
|
Avvikelse | INAV-1061 | Svarstidskrav på 30 sekunder uppfylls inte |
För tjänstekontrakten inom området sammanhållen journalföring finns ett SLA-krav för svarstid.
|*Kategori*|*Värde*|*Beskrivning*| |Svarstid|Svarstiden för ett anrop får inte överstiga 30 sekunder.|Svarstid| Avvikelsen uppstår när en tjänsteproducent inte uppfyller detta krav. Om Tjänsteproducenten kan garantera att detta inträffar i mindre än 1% av fallen accepteras detta. Not: I realiteten är det den aggregerande tjänstens timeout som är på 27 sekunder som styr. |
<p> <n>GetActivities - 1.0</n> <br /> <n>GetMedicationHistory - 2.1</n> <br /> <n>GetObservations - 1.0</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-1025 | Urval på relation stöds ej mellan observationer och aktiviteter |
Tjänstekontraktet för strukturerade observationer medger att en konsument kan söka ut alla observationer som har en relation till en viss aktivitet.
Tjänstekontraktet för strukturerade aktiviteter medger att en konsument kan söka ut alla aktiviteter som har en relation till en viss observation. Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetActivities - 1.0</n> <br /> <n>GetObservations - 1.0</n> <br /> </p> |
Godkänd |
NKRR
|
-
|
Avvikelse | INAV-1015 | Sätter inte information om källsystem fullt ut på ett korrekt sätt för vaccinationer |
Avvikelsen uppstår när tjänsteproducenten sätter ett inte helt korrekt värde i ett eller flera av elementen för patientens ordinerade och/eller administrerade vaccinationer.
Nedan är några exempel på avvikelser: * PrescriberOrg.orgUnitName sätts till samma som PerformerOrg.orgUnitName * Hårdkodar sourceSystemContact.personName * Hårdkodar sourceSystemName |
<p> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
-, Journalen, NPÖ
|
-
|
Avvikelse | INAV-986 | Villkorstext inkluderas ej i villkorsdosering i läkemedelshistorik |
Avvikelsen uppstår i de fall villkorstext till villkorsdosering utelämnas i läkemedelshistorik.
Utifrån aktuell TKB är detta inte ett brott, däremot hanterar schemat fältet som ett obligatoriskt fält. Det verksamhetsmässiga behovet är speglat i schemat, men inte i TKB. Därav så behöver TKB uppdateras och med det också de producenter som följer TKB, men inte det verksamhetsmässiga behovet (schemat). TKB säger följande: |../../../../../../conditionDescription|string|Villkorstext. Text som anger villkor kopplat till en villkorsdosering, t.ex. "vid behov".|0..1| Medans WSDL säger följande: <xs:complexType name="ConditionalDosageType"> <xs:annotation> <xs:documentation> </xs:documentation> </xs:annotation> <xs:sequence> <xs:element minOccurs="1" name="conditionDescription" type="xs:string"/> |
<p> <n>GetMedicationHistory - 2.1</n> <br /> </p> |
Godkänd - Tidsbegränsad |
-
|
-
|
Avvikelse | INAV-980 | Saknar stöd för att ange korrekt vårdbegäran i labsvar |
Avvikelsen uppstår när tjänsteproducenten bryter lexikaliskt mot filtreringsregeln för orderId genom att t.ex. låta fältet ha ett tomt innehåll (ej unik identifierare).
Från TKB: |../../order|OrderType|Information om en vårdbegäran som ligger till grund för svaret|1..1| |../../../orderId|string|Unik identifierare för vårdbegäran.|1..1| |
<p> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
-
|
-
|
Avvikelse | INAV-863 | Tidsfiltrering på uppmärksamhetssignal tar ej hänsyn till sluttid för valideringsperiod |
Avvikelsen uppstår när tjänsteproducenten bryter på nedanstående filtreringsregler i TKB:
|timePeriod|DatePeriodType|Begränsning av sökningen i tid, vilket innebär att endast svar där giltighetsintervallet ligger helt eller delvis inom efterfrågat tidsintervall returneras. Giltighetsintervallet startar vid validityTimePeriod.start och slutar vid tidigaste datum av obsoleteTime och validityTimePeriod.end om någon av dessa är satta, annars tills vidare.|0..1| |
<p> <n>GetAlertInformation - 2.0</n> <br /> </p> |
Godkänd - Tidsbegränsad |
-
|
-
|
Avvikelse | INAV-849 | Urval på observationsidentitet stöds ej |
Tjänstekontraktet för strukturerade observationer medger att en konsument i sin begäran gör urval baserat på unikt id för själva observationen (observationId).
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetObservations - 1.0</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-842 | INFO returneras felaktigt istället för OK i åtkomstloggar |
Avvikelsen uppstår om tjänsten returnerar resultkod INFO trots att en lista med patientinformation returneras korrekt i åtkomstloggen (även om listan är tom).
|
<p> <n>GetAccessLogsForPatient - 2.0</n> <br /> </p> |
Godkänd - Förbehåll |
-, Journalen, NPÖ
|
-
|
Avvikelse | INAV-819 | Tekniska fel paketeras ej som ett SOAP Fault |
Tjänstekontraktsbeskrivningen stipulerar hur en tjänsteproducent ska bete sig när ett tekniskt fel inträffar. Definitionen av ett tekniskt fel är här någon form av fel som uppstår i den interna arkitekturen som påverkar tjänsteproducentens förmåga att ge korrekta svar på anrop till exponerade tjänstekontrakt.
Kravet är att en tjänsteproducent i sådana fall ska returnera SOAP Fault med ett log-id som ger möjlighet för tjänsteproducentens förvaltning att bistå tjänstekonsumentens förvaltning med felsökning. Ett log-id bör vara en UUID. Avvikelsen uppstår när tjänsteproducenten när det tekniska felet paketeras på HTTP-nivå istället för att paketeras på SOAP-nivå (SOAP Fault). |
Godkänd - Förbehåll |
-
|
-
|
|
Avvikelse | INAV-808 | Poster tas ej bort ur EI när en bokning eller kallelse avbokats |
Avvikelsen uppstår när poster i nationella Engagemangsindex inte tas bort av tjänsteproducenten när en bokning eller kallelse avbokats, dess starttidpunkt passerats eller när kallelsens giltighetstid löpt ut.
Från kap. 5.7 i TKB - Då anses en bokning eller kallelse vara inaktuell: En bokning eller kallelse anses vara inaktuell när den avbokats, dess starttidpunkt passerats (besöket påbörjats) eller när kallelsens giltighetstid löpt ut. När en bokning eller kallelse blivit inaktuell ska dess post i nationella Engagemangsindex tas bort av tjänsteproducenten. |
<p> <n>CancelBooking - 1.1</n> <br /> <n>GetSubjectOfCareSchedule - 1.1</n> <br /> <n>UpdateBooking - 1.1</n> <br /> </p> |
Godkänd - Förbehåll |
-
|
-
|
Avvikelse | INAV-806 | Nutritionsprodukter (handelsvaror) hanteras som läkemedel |
Avvikelsen uppstår då producenten producerar nutritionsprodukter (handelsvaror) som läkemedel.
Nutritionsprodukter kan t.ex. vara näringsdrycker. |
<p> <n>GetMedicationHistory - 2.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-804 | Kan ej leverera fysiologiremiss som används av verksamheten |
Avvikelsen uppstår när en tjänsteproducent saknar stöd för att hantera fysiologiremiss som används av verksamheten och som stöds av tjänstekontraktet. |
<p> <n>GetRequestActivities - 1.0</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-793 | Saknas stöd för att påvisa makulering av vaccinationer |
Från TKB
|../../nullified|boolean|Anger om dokumentet makulerats i källsystemet. Sätts i så fall till true annars false. Används bl.a. i statistik-/rapportuttag med hjälp av tjänstekontrakten.|1..1| |../../nullifiedReason|string|Anger orsak till makulering. Får endast anges i kombination med att nullified = true|0..1| Avvikelsen uppstår om producenten saknar stöd för att påvisa när dokument makulerats i källsystemet. Det finns dock ingen konsument idag som har behov av att föra statistik och uppföljning. Ett förslag har lyfts att justera kontraktet så att det är samklang med övriga JoL kontrakt där makulering och makuleringsorsak inte används. |
<p> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-791 | Engagemangsindex uppdateras trots att det inte finns information att hämta |
*R13*: EI ska uppdateras när ett anrop till motsvarande tjänstekontrakt ger annan data än ett tidigare anrop skulle gjort.
Avvikelsen kan uppstå på grund av att producenten uppdaterar EI trots att ett nytt anrop inte kommer resultera i att annan data hämtas jämfört med tidigare anrop. |
Godkänd - Förbehåll |
Journalen, NPÖ
|
-
|
|
Avvikelse | INAV-770 | Remissaktivitet skickas felaktigt flera gånger för samma status |
Avvikelsen uppstår om tjänsteproducenten felaktigt genererar flera remissaktiviteter vid förändring av status (t.e.x 'skickad', 'mottagen'). |
<p> <n>GetRequestActivities - 1.0</n> <br /> </p> |
Underkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-768 | Registrering av annan överkänslighet mappas till engelska istället för svenska |
Avvikelsen uppstår när registrering av annan överkänslighet för annat födoämne/insektsbett/kemikalie mappas till engelsk text (istället för svensk) hos producenten. |
<p> <n>GetAlertInformation - 2.0</n> <br /> </p> |
Godkänd |
-
|
-
|
Avvikelse | INAV-764 | SLA för upptid uppfylls ej på så sätt att tjänsten är tillfälligt otillgänglig utanför kontorstid varje dygn |
Tjänstekontraktsbeskrivningen för en given domän stipulerar SLA-krav som gäller för de tjänstekontrakt i aktuell domämn som en tjänsteproducent exponerar.
Ett av dessa krav gäller upptid, dvs tjänstens tillgänglighet för en konsument. Denna uttrycks vanligtvis som en procentsats. Avvikelsen uppstår när en tjänsteproducent är otillgänglig upp till 1-2 timmar utanför kontorstid varje dygn. |
<p> <n>GetActivities - 1.0</n> <br /> <n>GetObservations - 1.0</n> <br /> </p> |
Underkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-763 | Kan ej leverera labbremiss som används av verksamheten |
Avvikelsen uppstår när en tjänsteproducent saknar stöd för att hantera labbremiss som används av verksamheten och som stöds av tjänstekontraktet. |
<p> <n>GetRequestActivities - 1.0</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-738 | Tekniskt fel returneras felaktigt vid urval på samordningsnummer |
En producent som saknar stöd för urval på samordningsnummer förväntas returnera ett tomt svar (det finns ingen information att hämta för patienten). | Godkänd - Förbehåll |
Journalen, NPÖ
|
-
|
|
Avvikelse | INAV-692 | Saknar stöd för att ange allvarlighetsgrad för överkänslighet |
Avvikelsen uppstår när allvarlighetsgrad inte kan inkluderas i en uppmärksamhetssignal för överkänslighet.
Från TKB: |../../../degreeOfSeverity|CVType|Kod som anger bedömning av överkänslighetens allvarlighet. För kompatibilitet med NPÖ RIV 2.2.0 ska KV Allvarlighetsgrad (1.2.752.129.2.2.3.3) följas. Bör anges. Notera: Det finns två varianter av detta kodverk, en som har distribuerats med V-TIM och en som har distribuerats med NPÖ. V-TIM - [Livshotande, *Skadlig*, Besvärande] NPÖ - [Livshotande, *Skadande*, Besvärande] En informationskonsument bör säkerställa att den klarar av att hantera båda varianterna.|0..1| |
<p> <n>GetAlertInformation - 2.0</n> <br /> </p> |
Godkänd |
Journalen
|
NPÖ
|
Avvikelse | INAV-680 | Producenten saknar stöd för att ange namn på tidstyp vid ombokning |
Avvikelsen uppstår när producenten saknar stöd för att hantera elementet tidstyp för tjänstekontrakt under domänen tidbokning.
|timeTypeName|string|Tidstyp för det bokade besöket.| |
<p> <n>UpdateBooking - 1.1</n> <br /> </p> |
Godkänd |
1177 Webbtidbok
|
-
|
Avvikelse | INAV-678 | Producenten saknar stöd för att ange resurs vid nybokning och ombokning |
Avvikelsen uppstår när producenten saknar stöd för att hantera elementen resourceName och/eller resourceID.
|resourceName|string|Namn på resurs| |resourceID|ResourceIDType|Identitet för resurs| |
<p> <n>MakeBooking - 1.1</n> <br /> <n>UpdateBooking - 1.1</n> <br /> </p> |
Godkänd |
1177 Webbtidbok
|
-
|
Avvikelse | INAV-677 | Producenten åsidosätter namn på HoSP vid nybokning och ombokning |
Avvikelsen uppstår när producenten saknar stöd för att hantera performerName i inkommande requester för tjänstekontrakt under domänen för tidbokning.
|performerName|string|Namn på HoS-person som besöket är bokat hos. Ska innehålla en blank-tecken-separerad sammanslagning av yrkestitel, förnamn, mellannamn, efternamn.| |
<p> <n>MakeBooking - 1.1</n> <br /> <n>UpdateBooking - 1.1</n> <br /> </p> |
Godkänd |
1177 Webbtidbok
|
-
|
Avvikelse | INAV-675 | Ombudsbokning stöds ej vid tidbokning |
Avvikelsen uppstår för de producenter som saknar stöd för ombudsbokning.
Från TKB (crm_scheduling): _Fr.o.m. 1.1 Alla tjänsteinteraktioner i tidbokningsdomänen har en obligatorisk "header" för att ange aktör (Actor). En aktör kan vara patienten (subject_of_care) eller en mellanman (subject_of_care_agent). Med mellanman avses en medarbetare i professionen som handräcker patienten med genomförandet av bokningen. Det kan t.ex. vara en sköterska på 1177 Sjukvårdsrådgivningen som på patientens begäran genomför en bokning via Mina Vårdkontakter eller via Rådgivningsstödet._ |
<p> <n>CancelBooking - 1.1</n> <br /> <n>GetAllTimeTypes - 1.1</n> <br /> <n>GetAvailableDates - 1.1</n> <br /> <n>GetAvailableTimeslots - 1.1</n> <br /> <n>GetBookingDetails - 1.1</n> <br /> <n>GetSubjectOfCareSchedule - 1.1</n> <br /> <n>MakeBooking - 1.1</n> <br /> <n>UpdateBooking - 1.1</n> <br /> </p> |
Godkänd |
1177 Webbtidbok
|
-
|
Avvikelse | INAV-658 | Tjänsteproducenten använder felaktigt dubbel encoding |
Från TKB:
_För ovanstående DocBook-exempel ska alltså fältet "clinicalDocumentNoteText" innehålla en version som är "entity encoded" enligt följande:_ _<?xml version="1.0"?>_ _<article>_ _..._ Det finns inget i TKB som nämner att CDATA är OK att använda (svårt att täcka alla situationer som kan uppstå textuellt). Att använda CDATA istället för "entity encoding" enligt TKB är något som dock accepteras, då det i praktiken är samma sak. Avvikelsen berör fall där"entity encoding" används inuti ett CDATA-block, vilket skulle kunna liknas med "entity encoded entity encoding". |
Godkänd - Förbehåll |
Journalen, NPÖ
|
-
|
|
Avvikelse | INAV-637 | Tjänsteproducenten uppfyller ej riktlinjer på aktualitetskrav |
Kraven på aktualitet varierar för olika tjänstekonsumenter. Det behöver inte vara absolut aktualitet i förhållande till källsystemet, men ju mindre fördröjning desto bättre. Ett riktmärke är att försöka undvika längre fördröjning än 60 minuter. Fördröjningen avser både journaldata och uppdatering av engagemangsindex.
Uppdatering av engagemangspost måste ske så att engagemangsposten refererar data som är omedelbart tillgängligt via tjänstekontraktet. Avvikelsen uppstår när uppdateringar av engagemangsindex dröjer mer än 60 minuter. |
<p> <n>GetCareContacts - 3.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NPÖ
|
-, NKRR
|
Avvikelse | INAV-628 | Glycosuria i mödravårdsinformation används av verksamheten men mappas ej |
Glycosuria används av verksamheten men mappning saknas till motsvarande element i tjänstekontraktet GetMaternityMedicalHistory.
|../../../glycosuria|PQType|Glucosuri - Glucos i urinet [antal / volym] Förväntad enhet är mmol/l. Använd INTE mätstickans kodning (0, 1+, 2+…) OBS! U på svenska men y på engelska (ICD10).|0..1| |
<p> <n>GetMaternityMedicalHistory - 2.0</n> <br /> </p> |
Godkänd |
-
|
-
|
Avvikelse | INAV-627 | Proteinuria i mödravårdsinformation används av verksamheten men mappas ej |
Proteinuria används av verksamheten men mappning saknas till motsvarande element i tjänstekontraktet GetMaternityMedicalHistory.
|../../../proteinuria|PQType|Proteinuri - Protein i urinet [massa / volym] Mängden protein skall alltså anges i g/l eller motsvarande. Använd INTE mätstickans kodning (0, 1+, 2+…)|0..1| |
<p> <n>GetMaternityMedicalHistory - 2.0</n> <br /> </p> |
Godkänd |
-
|
-
|
Avvikelse | INAV-616 | Inaktuella uppmärksamhetssignaler visas ej |
Uppmärksamhetssignaler kan registreras som "inaktuell" i det lokala systemet.
En avvikelse är det t.ex. om systemet inte kan producera poster som är "inaktuella". |
<p> <n>GetAlertInformation - 2.0</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-569 | Verksamheten använder sig av fler anteckningstyper än vad som mappas |
Verksamheten använder sig av fler anteckningstyper för anteckning än vad som är implementerat/mappat i vårdsystemet (producenten).
Det kan få som följd att en anteckning angiven med en viss anteckningstyp, i själva verket innehåller en annan typ av anteckningar. Ett vårdsystem kan t.ex. hårdkoda clinicalDocumentNoteCode. Tillåtna värden enligt TKB är: utr = Utredning, atb = åtgärd/Behandling, sam = Sammanfattning, sao = Samordning, ins = Inskrivning, slu = Slutanteckning, auf = Anteckning utan fysiskt möte, sva = Slutenvårdsanteckning, bes = Besöksanteckning. |
<p> <n>GetCareDocumentation - 2.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-546 | Uppdateringsregel R11 för engagemangsindex följs ej |
Det finns flera uppdateringsregler för de aktörer som avser att som konsument uppdatera EI med hjälp av tjänstekontraktet "Update", den här avvikelsen syftar specifikt på regel 11 i TKB.
- *R11*: Tjänstekonsumenten ska kunna konfigureras med avseende på hur många engagemangsposter som paketeras i varje Update-anrop, utan krav på release eller ominstallation. De engagemangsposter som är färdiga att skickas under det intervall som är angivet I *R8* skall skickas enligt max antal tillåtna poster som är angivet I SLA-krav under "Last". Exempel: Finns 500 nya poster så anropas Update 1 gång med 500 poster i en och samma transaktion. Finns 1003 nya poster så anropas Update 2 ggr, ett anrop på 1000 poster och ett på 3 poster. Finns 2000 nya poster så anropas Update 2 ggr, vardera anrop med 1000 poster. |
<p> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetCarePlans - 2.0</n> <br /> <n>GetFunctionalStatus - 2.0</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd - Tidsbegränsad |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-513 | Information om begäran gick bra eller ej inkluderas ej i svar |
I vissa tjänstekontraktsbeskrivningar förekommer det att ResultType ska skickas med.
Elementet "ResultType" kommer successivt att tas bort för Get-kontrakt. |
<p> <n>GetCareDocumentation - 2.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-510 | Ej möjligt att leverera utsatta läkemedel |
Anslutande part levererar inte poster med utsatta läkemedel (ordination som beskriver avslut av läkemedelsbehandling). |
<p> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd |
Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-506 | Samtliga läkemedel hanteras som läkemedelsprodukter |
Handelsvaror (merchandise), läkemedelsartiklar (pharmaceuticalItem), fritextbeskrivningar (unstructuredDrug) och generiska läkemedelsval (generics) presenteras som läkemedelsprodukter (drug).
|../../../drug|DrugChoiceType|Läkemedelsval. OBS: Ett och endast ett av följande alternativ: - unstructuredDrugInformation (fritextval/extemporeberedning) - merchandise (handelsvara) - drugArticle (läkemedelsartikel) - drug (läkemedelsprodukt) - generics (generika/utbytesgrupp) Utelämnas om ordinationstyp är Utsättning.|0..1| |
<p> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd |
Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-504 | "Utvärderat av" inkluderas ej i läkemedelsposter trots att det används i verksamheten |
"Utvärderat av" är ett optionellt fält. När verksamheten har personer som utvärderat utfall av ordinationer/förskrivningar, så bör dessa också inkluderas i läkemedelsposten.
|../../../evaluator|HealthcareProfessionalType|”Utvärderat av”. Den hälso- och sjukvårdsperson/-enhet som utvärderat utfallet av ordinationen/förskrivningen.|0..1| |
<p> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-501 | Information om makulering inkluderas felaktigt i journalanteckning |
Tidiga versioner av tjänstekontraktet för journalanteckning medgav att tjänsteproducenten kunde leverera information om huruvida ett dokument hade makulerats i källsystemet och av vilken orsak. Elementent för detta hette "nullified" och "nullifiedReaseon". Dessa element är numera otillåtna.
Avvikelsen uppstår då en tjänsteproducent inkluderar minst ett av dessa element i en respons. Tilläggs-information: Dokumentet (TKB) för GetCareDocumentation 2.0 är lite vilseledande: I TKB's fältregler nämns inte nullified och nullifiedReason och man kan tolka det som att elementet inte ska inkluderas. Däremot så behandlas elementen i kapitlet som beskriver PatientSummaryHeaderType och där är elementen optionella: |nullified|boolean|Anger om dokumentet makulerats i källsystemet. Sätts i så fall till true annars false. Används bl.a. i statistik-/rapportuttag med hjälp av tjänstekontrakten.|0..1| |nullifiedReason|string|Anger orsak till makulering.|0..1| I dokumentet för GetCareDocumentation 2.1 är det tydliggjort att nullified och nullifiedReason inte ska inkluderas. |../../nullified| |N/A|0..0| |../../nullifiedReason| |N/A|0..0| |
<p> <n>GetCareDocumentation - 2.0</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-500 | Uppfyller inte schemaregler |
Elementet accountableHealthcareProfessional (AHCP) betecknar en HoS-person och återfinns i header-elementet för de flesta tjänstekontrakt inom sammanhållen journalföring.
Syftet med elementet varierar beroende på tjänstekontrakt. Det vanligaste är att det pekar ut den person som är "ansvarig för informationen", dvs den som har skapat informationen i källsystemet. Till undantagen hör t.ex. GetLaboratoryOrderOutcome, där AHCP pekar ut den person som har framställt den vårdbegäran som ligger till grund för labbsvaret. Avvikelsen uppstår när en tjänsteproducent inkluderar elementet "accountableHealthcareProfessional", men på ett felaktigt sätt som gör att konsumenten kan få svårt att tyda informationen. |
Godkänd |
Journalen
|
NKRR, NPÖ
|
|
Avvikelse | INAV-492 | Felaktig hantering av ATC-kod för läkemedelsprodukt |
I tjänstekontraktet för läkemedelshistorik så kan en läkemedelsprodukts ATC-kod beskrivas m.h.a. ett kodverk. För detta kodverk finns ett antal regler för de ingående elementen rörande kardinalitet och inbördes beroenden.
Avvikelsen uppstår när en tjänsteproducent inte uppfyller dessa regler. |
Godkänd - Förbehåll |
Biverkningsrapportering, Förnya recept, Journalen
|
MPÖ (Tieto), NKRR, NPÖ, XView (Cambio)
|
|
Avvikelse | INAV-475 | Uppdateringstidpunkt innehåller fel värde vid uppdatering av EI |
Tjänstekontraktsbeskrivningen för Update stipulerar att fältet "mostRecentContent" i ett anrop ska sättas till tidpunkt för när uppdatering i informationsobjektet har skett.
Avvikelsen uppstår när det sker en uppdatering av informationsobjektet i källsystemet med påföljande Update-anrop, men "mostRecentContent" avspeglar inte tidpunkt för uppdatering utan baseras på något annat. |
<p> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> </p> |
Godkänd |
Bokade tider, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-447 | Insättningstidpunkt saknas vid ordination av typen "Insättning" |
Tjänstekontraktet för läkemedel stipulerar att en tjänsteproducent för en post som beskriver en ordination av typen "Insättning" även ska ange insättningstidpunkt.
Avvikelsen uppstår då en tjänsteproducent inte levererar insättningstidpunkt för en eller flera poster som beskriver ordination av typen "Insättning" |
<p> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Förnya recept, Journalen, NPÖ
|
-, NKRR
|
Avvikelse | INAV-443 | Saknar stöd att leverera obligatoriskt element logId |
Flera JoL-kontrakt stipulerar att en tjänsteproducent i slutet av en respons ska inkludera ett element "result" och att detta bl.a. ska innehålla ett obligatoriskt log-id för att underlätta eventuell felsökning.
Avvikelsen uppstår när en tjänsteproducent saknar stöd att leverera detta log-id. Tilläggs-information: "ResultType i kontrakten skall enligt regelverket endast finnas i uppdaterande kontrakt och inte i rena läs-kontrakt. Att ResultType kom med i vissa av JoL-kontraktens fastställda versioner var att under en period 2014, så ställdes krav på ATT den skulle ingå i syfte att kunna ge information om logiska fel av olika slag. Men därefter kom krav från A&R centralt att den skulle bort ur alla Get-kontrakt när vi gör nya majors av dessa. Så de rensas undan över tid. Vidare så saknar aggregerande Get-tjänster idag stöd för hantering av logiska-fel/ResultType." |
<p> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd - Förbehåll |
-
|
|
Avvikelse | INAV-441 | Vårdenhet och vårdgivare för remissförfattare inkluderas felaktigt för konsultationsremiss |
I tjänstekontraktet för konsultationsremiss finns information om den person som skapat remissen som ligger till grund för remissvaret.
Det finns två element för att ange HSA-id för vårdenhet och vårdgivare för det medarbetaruppdrag som denne person arbetade inom. Elementen heter healthcareProfessionalCareUnitHSAId och healthcareProfessionalCareGiverHSAId och de är numera otillåtna (kardinalitet 0..0) Avvikelsen uppstår när en tjänsteproducent skickar med ett eller båda av dessa element. |
<p> <n>GetReferralOutcome - 3.1</n> <br /> </p> |
Godkänd - Tidsbegränsad |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-431 | Uppdatering av EI sker ej när en källsystemspost uppdateras |
Enligt regel R13 ska EI uppdateras när ett anrop till aktuellt tjänstekontrakt ger annan data än ett tidigare anrop skulle gjort.
Avvikelsen uppstår när en tjänsteproducent inte uppdaterar EI enligt ovan scenario. |
<p> <n>GetAlertInformation - 2.0</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-428 | Kan inte leverera information om signering |
Via det optionella elementet "legalAuthenticator" kan en tjänsteproducent för en post tala om huruvida posten är signerad, osignerad eller låst.
Avvikelsen uppstår när en tjänsteproducent inte stödjer att skicka med detta element. Låsta svar (manuellt, i samband med en signering, eller genom en automatisk åtgärd efter en viss tidpunkt) åstadkoms genom att inkludera legalAuthenticor, enbart med subelementet signatureTime (dvs. HSAId och Name utelämnas). ../../legalAuthenticator LegalAuthenticatorType Information om vem som signerat informationen i dokumentet. Signering är inte samma sak som vidimering. Information om vidimering anges i attributet attested i bodyn. 0..1 ../../../signatureTime TimeStampType Tidpunkt för signering. 1..1 ../../../legalAuthenticatorHSAId HSAIdType HSA-id för person som signerat dokumentet. HSA-id för vård- och omsorgspersonal. Skall anges om tillgänglig. 0..1 ../../../legalAuthenticatorName String Namnen i klartext för signerande person. 0..1 |
<p> <n>GetActivities - 1.0</n> <br /> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetCarePlans - 2.0</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMaternityMedicalHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetObservations - 1.0</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Journalen, NKRR, NPÖ
|
-, Förnya recept
|
Avvikelse | INAV-427 | Saknar stöd för att leverera vårdkontaktsstatus |
Tjänstekontraktet för vårdkontakt medger att leverera information om vårdkontaktens status enligt kodverk.
Avvikelsen uppstår när en tjänsteproducent saknar stöd för att leverera denna information. |
<p> <n>GetCareContacts - 3.0</n> <br /> </p> |
Godkänd |
Bokade tider, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-413 | Log-id saknas i SOAP-Fault vid tekniskt fel |
Tjänstekontraktsbeskrivningen stipulerar hur en tjänsteproducent ska bete sig när ett tekniskt fel inträffar. Definitionen av ett tekniskt fel är här någon form av fel som uppstår i den interna arkitekturen som påverkar tjänsteproducentens förmåga att ge korrekta svar på anrop till exponerade tjänstekontrakt.
Kravet är att en tjänsteproducent i sådana fall ska returnera SOAP Fault med ett log-id som ger möjlighet för tjänsteproducentens förvaltning att bistå tjänstekonsumentens förvaltning med felsökning. Ett log-id bör vara en UUID. Avvikelsen uppstår när tjänsteproducenten inte stödjer att leverera log-id i ett sådant SOAP Fault. |
<p> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetCarePlans - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetMedicationHistory - 2.1</n> <br /> </p> |
Godkänd |
Bokade tider, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-400 | Kodverk för vårdkontaktsstatus stöds ej fullt ut |
Det finns för vårdkontakt ett kodverk för att beskriva vilken status en vårdkontakt har. Exempel är "makulerad", "tidbokad" osv.
Avvikelsen uppstår när en tjänsteproducent saknar stöd för att representera en eller flera av dessa statuskoder. |
<p> <n>GetCareContacts - 3.0</n> <br /> </p> |
Godkänd |
Bokade tider, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-396 | Inkorrekt mappning av statuskoder för vårdkontakt |
Det finns för vårdkontakter ett antal statusar som kan anges. Exempel är "makulerad", "inställd" osv.
Avvikelsen uppstår när en tjänsteproducent skickar felaktiga koder för en eller flera typer av vårdkontakter. |
<p> <n>GetCareContacts - 3.0</n> <br /> </p> |
Underkänd |
NKRR
|
Bokade tider, Journalen, NPÖ
|
Avvikelse | INAV-383 | Saknar stöd för att leverera information om vidimering |
Många tjänstekontrakt medger att skicka med information som rör vidimering av en post. Elementet heter ofta "attested".
Avvikelsen uppstår när en tjänsteproducent inte stödjer att skicka denna information. |
<p> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-382 | Saknar stöd för att ange resurstyp för åtkomstloggposter |
För tjänstekontraktet som returnerar åtkomstloggposter är det obligatoriskt att i elementet "resourceType" ange vilken resurstyp som loggposten avser. Exempel kan vara remiss, journaltext, samtycke osv.
Avvikelsen uppstår när tjänsteproducenten inte stödjer detta (genom att sätta irrelevanta värden i elementet). |
<p> <n>GetAccessLogsForPatient - 1.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-381 | Saknar stöd för att ange referens till relaterad vårdkontakt |
För en informationspost kan tjänsteproducenten skicka med id på den vårdkontakt som föranlett den information som omfattas av dokumentet. Elementet är frivilligt och heter oftast "careContactId".
Avvikelsen uppstår när tjänsteproducenten inte skickar med denna information. |
<p> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetCarePlans - 2.0</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetFunctionalStatus - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-379 | Kan inte leverera preliminärsvar från bilddiagnostik |
Tjänstekontraktet för bilddiagnostiska resultat medger att man talar om postens svarstyp. De olika typerna är definitivsvar, tilläggssvar och preliminärsvar. Preliminärsvar är en ny svarstyp och finns ej med i NPÖ:s riv-specifikation.
Avvikelsen uppstår när en tjänsteproducent inte stödjer att sätta preliminärsvar på poster. |
<p> <n>GetImagingOutcome - 1.0</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-373 | Kan inte leverera information om signering |
Via det optionella elementet "legalAuthenticator" kan en tjänsteproducent för en post tala om huruvida posten är signerad, osignerad eller låst.
Avvikelsen uppstår när en tjänsteproducent inte stödjer att skicka med detta element. |
<p> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetECGOutcome - 1.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Journalen, NPÖ
|
Förnya recept, NKRR
|
Avvikelse | INAV-369 | SLA-krav för upptid uppfylls ej |
Tjänstekontraktsbeskrivningen för en given domän stipulerar SLA-krav som gäller för de tjänstekontrakt i aktuell domämn som en tjänsteproducent exponerar.
Ett av dessa krav gäller upptid, dvs tjänstens tillgänglighet för en konsument. Denna uttrycks vanligtvis som en procentsats. Avvikelsen uppstår när en tjänsteproducent av en eller flera orsaker inte uppfyller detta krav under normal drift. |
<p> <n>GetCareContacts - 3.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> </p> |
Godkänd |
Bokade tider, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-367 | Stödjer inte rekommenderat kodverk för åtgärdsstatus fullt ut |
Tjänstekontraktsbeskrivningen för laboratoriesvar stipulerar att man för åtgärdsstatus (element analysisStatus) bör använda KV "Åtgärdsstatus".
Avvikelsen uppstår när tjänsteproducenten inte fullt ut följer detta kodverk. Enligt tillgänglig information så är dock detta kodverk på väg ut. Oklart om det i detta sammanhang kommer att ersättas med annat kodverk. |
<p> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-360 | Filtrering på ordinationskedja stöds ej |
Tjänstekontraktet för läkemedel medger att en konsument i sin begäran gör urval baserat på ordinationskedja.
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.1</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-358 | Regler för tidsintervall och vårdkontaktsstatus uppfylls ej |
Tjänstekontraktsbeskrivningen för vårdkontakt stipulerar regler för hur tidsintervall ska anges för en vårdkontakt beroende på vilken status kontakten har.
Avvikelsen uppstår när en tjänsteproducent bryter mot dessa regler. |
<p> <n>GetCareContacts - 3.0</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-355 | Avvikelse mot förväntat beteende vid urval på tid |
Tjänstekontraktsbeskrivningarna för olika tjänstekontrakt inom domänen JoL medger för de flesta tjänstekontrakt att en tjänstekonsument kan göra urval på tid.
Detta betyder att en konsument skickar med parametrar för datum och/eller tidpunkt i begäran så att tjänsteproducenten kan göra en filtrering av responsen utifrån dessa parametrar. Avvikelsen uppstår när en tjänsteproducent på olika sätt avviker från förväntat beteende. |
<p> <n>GetCareContacts - 3.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Journalen, NPÖ
|
NKRR
|
Avvikelse | INAV-345 | Inget av alternativen fastdosering eller villkorsdosering anges vid dosering |
Enligt TKB så måste man vid dosering ange om det är fastdosering eller villkorsdosering. Båda elementen är valfria så det är en logisk regel.
Avvikelsen uppstår när en tjänsteproducent inte anger något av dessa två alternativ. |
<p> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-341 | Saknar stöd för filtrering på tidsintervall |
De flesta tjänstekontrakt har stöd för att konsumenten gör urval baserat på tidsintervall. Filtreringen hos tjänsteproducenten görs på olika sätt beroende på vilket tjänstekontrakt det rör.
Avvikelsen uppstår när en tjänsteproducent trots tidsintervall i anropet ej gör denna filtrering och returnerar samma poster som om detta urval inte hade gjorts. |
<p> <n>GetDiagnosis - 2.0</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Journalen, NPÖ
|
NKRR
|
Avvikelse | INAV-340 | Låst post saknar tidpunkt för låsning |
När en osignerad post automatiskt låses i källsystemet ska detta markeras i en respons genom att elementet "legalAuthenticator" skickas med och det ska endast innehålla elementet "signatureTime" där tidpunkt för låsning ska framgå.
Avvikelsen uppstår när en tjänsteproducent returnerar en låst post där elementet "legalAuthenticator.signatureTime" saknas. |
<p> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetMedicationHistory - 2.1</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-336 | Värden för OID och namn på kodverk har bytt plats |
För de element som anges i form av kodverk så ska codeSystem innehålla OID för kodverket och codeSystemName innehålla namn på kodverket.
Avvikelsen uppstår då dessa värden har bytt plats. |
<p> <n>GetCareContacts - 3.0</n> <br /> </p> |
Godkänd - Tidsbegränsad |
NPÖ
|
Bokade tider, NKRR
|
Avvikelse | INAV-334 | Tjänsteproducent filtrerar svar utifrån ursprunglig konsument |
Enligt regelverket i RIV så ska en tjänsteproducent avlämna all information som finns tillgänglig som svar på en begäran, oavsett vilken applikation som är den ursprungliga tjänstekonsumenten. Det åligger tjänstekonsumenten att utföra lämplig filtrering i de fall det är tillämpligt.
Avvikelsen uppstår då tjänsteproducenten utför filtrering baserat på vilken applikation som är ursprunglig tjänstekonsument. |
<p> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-332 | Konsumentregler för engagemangsindex följs ej |
Det finns en del regler för de aktörer som avser att som konsument uppdatera EI med hjälp av tjänstekontraktet "Update".
Exempel: - Alla tillgängliga poster ska förpackas i samma EI Update anrop, upp till max 1000 st. Detta för att inte i onödan orsaka stor belastning på EI-plattformen. - R8: Poster med samma unika nyckel skall inte skickas oftare än var 5:e minut även om det skett fler än en matchande händelse i källsystemet under den tidsrymden. Detta intervall bör vara konfigurerbart. Under en grundladdning får inga dubbletter (med avseende på fälten som utgör del i postens unikhet) förekomma under hela körningen (d.v.s. inte bara inom ett Update-anrop, utan sammantaget för alla Update-anrop som sker under grundladdningen). - R11: Tjänstekonsumenten ska kunna konfigureras med avseende på hur många engagemangsposter som paketeras i varje Update-anrop, utan krav på release eller ominstallation. De engagemangsposter som är färdiga att skickas under det intervall som är angivet I R8 skall skickas enligt max antal tillåtna poster som är angivet I SLA-krav under “Last”. Exempel: Finns 500 nya poster så anropas Update 1 gång med 500 poster i en och samma transaktion. Finns 1003 nya poster så anropas Update 2 ggr, ett anrop på 1000 poster och ett på 3 poster. Finns 2000 nya poster så anropas Update 2 ggr, vardera anrop med 1000 poster. Avvikelse uppstår när aktör i rollen som konsument av Update brister i följsamhet mot en eller flera av dessa regler |
<p> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd - Tidsbegränsad |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-329 | Filtrering på reservnummer stöds ej |
Flera tjänstekontrakt medger att en tjänstekonsument i sin begäran anger reservnummer istället för personnummer.
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetAccessLogsForPatient - 1.1</n> <br /> <n>GetAccessLogsForPatient - 2.0</n> <br /> <n>GetActivities - 1.0</n> <br /> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetCarePlans - 2.0</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetFunctionalStatus - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetLaboratoryOrderOutcome - null</n> <br /> <n>GetMaternityMedicalHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.1</n> <br /> <n>GetObservations - 1.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-327 | Poster i engagemangsindex tas ej bort |
Referensarkitekturen för tjänstesamverkan som definieras av T-Boken pekar tydligt på engagemangsindexets syfte och funktion och att avsaknaden av ett uppdaterat engagemangsindex kan leda till att ett orimligt antal producenter anropas på spekulation.
En rad i databasen för engagemangsindex ska betyda att det finns data att hämta för aktuell patient och informationsmängd, hos aktuell logisk adressat. Avvikelsen uppstår när en tjänsteproducent på olika sätt makulerar data i källsystemet så att denna data inte längre blir tillgänglig att hämta via tjänstekontrakt, men tjänsteproducenten undlåter att uppdatera engagemangsindex för att reflektera denna ändring. (Tjänsteproducenten borde skicka ett Update-anrop med "deleteFlag=true") Det är informationsägaren som ansvarar för att kunna ta bort information ur EI och därmed leva upp till GDPR, vilket bör noteras i självdeklarationen. SjD kompletteras med följande mening: _"När det gäller INAV-327, så är det informationsägaren som ansvarar för att kunna ta bort information ur EI och därmed leva upp till GDPR."_ |
<p> <n>GetActivities - 1.0</n> <br /> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMaternityMedicalHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetObservations - 1.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd - Tidsbegränsad |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-312 | Ej uppfyllnad kring regelverk för legalAuthenticator |
I elementet "legalAuthenticator" kan en tjänsteproducent skicka med information om vem som har signerat en post och när det gjordes.
Avvikelse uppstår när tjänsteproducenten beter sig på ett sätt som inte motsvarar det förväntade utifrån regelverket. Avsteg från regelverket kan se ut på olika sätt. |
<p> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-311 | OID för patient-id valideras ej |
I ett anrop så skickar konsumenten med patientens identifikation i fältet "patientId", samt ett OID i ett fält som ofta heter "patientIdType".
Detta OID talar om för tjänsteproducenten hur den ska tolka innehållet i "patientId", t.ex. om det är ett personnummer. Avvikelsen uppstår när tjänsteproducenten inte validerar innehållet i detta OID-fält. |
<p> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-310 | Filtrering på samordningsnummer stöds ej |
Flera tjänstekontrakt medger att en tjänstekonsument i sin begäran anger samordningsnummer istället för personnummer.
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetAccessLogsForPatient - 1.1</n> <br /> <n>GetAccessLogsForPatient - 2.0</n> <br /> <n>GetActivities - 1.0</n> <br /> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetLaboratoryOrderOutcome - null</n> <br /> <n>GetMaternityMedicalHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.1</n> <br /> <n>GetObservations - 1.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> <n>GetRequestActivities - 1.0</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-309 | Tidsfiltrering inkluderar poster utanför givet intervall |
Vissa tjänstekontrakt medger filtrering på tidsintervall på så sätt att de poster som returneras ska ha relevanta tidpunkter som ligger inom det intervall som anges i begäran.
Avvikelsen uppstår när tjänsteproducenten under dessa förutsättningar returnerar poster som ligger utanför det intervall som anges i begäran. |
<p> <n>GetCareContacts - 3.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Bokade tider, Journalen, NPÖ
|
-, NKRR
|
Avvikelse | INAV-305 | PingForConfiguration ej implementerat |
Tjänstekontraktet "PingForConfiguration" kan installeras i ett landstings miljö, exempelvis i en regional tjänsteplattform. Kontraktet finns till för övervakning av övriga installerade tjänstekontrakt och rekommendationen från Ineras sida är att ha det installerat för att möjliggöra centraliserad övervakning.
Avvikelsen uppstår när en tjänsteproducent har valt att inte implementera tjänstekontraktet. |
<p> <n>GetAccessLogsForPatient - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-289 | Kan ej producera signeringstidpunkt |
Flera tjänstekontrakt medger att i elementet "legalAuthenticator" skicka med information vem som har signerat informationen i posten och när detta skedde, s.k. signeringstidpunkt.
Avvikelsen uppstår då tjänsteproducenten ej producerar denna information. |
<p> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-, NKRR
|
Avvikelse | INAV-256 | XML-standard för radbrytningar följs ej |
I XML så finns en standard för att representera radbrytning i ett element av typen String.
Man kan ange tecknen ("carriage return" resp "line feed") direkt i strängen, eller genom "character reference": Carriage return: {code}
{code} Line feed: {code}
{code} Källa: https://www.w3.org/TR/REC-xml/#sec-references Avvikelsen uppstår när en tjänsteproducent ej följer denna standard vid representation av radbrytningar i element av typen String. |
<p> <n>GetCareContacts - 3.0</n> <br /> </p> |
Godkänd |
Bokade tider, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-253 | Filtrering på signeringstidpunkt stöds ej |
Vissa tjänstekontrakt medger att en tjänstekonsument i sin begäran gör urval baserat på signeringstidpunkt.
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetCareDocumentation - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetMaternityMedicalHistory - 2.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-238 | Svarstidskrav på 15 sekunder uppfylls ej |
För tjänstekontraktet GetAccessLogsForPatient finns ett SLA-krav för svarstid; att tjänsten alltid returnerar inom 15 sekunder.
Avvikelsen uppstår när en tjänsteproducent inte uppfyller detta krav. |
<p> <n>GetAccessLogsForPatient - 1.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-236 | Loggsvar uppfyller ej regler för beskrivning av syfte |
För tjänstekontraktet GetAccessLogsForPatient så finns, för det element som beskriver en enstaka åtkomst, ett element som heter "purposeDescription".
Detta element ska innehålla syftet med åtkomsten och ska matcha något av de syften (kopplade till medarbetaruppdrag) som förekommer i HSA-katalogen. Exempel kan vara "Vård och behandling". Avvikelsen uppstår när en tjänsteproducent inte följer dessa regler, t.ex. genom att skicka ett otillåtet värde eller att skicka samma värde för alla poster oavsett faktiskt syfte. |
<p> <n>GetAccessLogsForPatient - 1.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-230 | Regler för tidsperiod med avseende på vårdkontakt följs ej |
Tjänstekontraktsbeskrivningen för GetCareContacts 3.0 stipulerar för elementet careContactTimePeriod hur en tjänsteproducent med hjälp av elementen "start" och "end" ska representera olika typer av vårdkontakter.
Avvikelsen uppstår när en tjänsteproducent inte följer dessa regler. |
<p> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> </p> |
Godkänd |
Bokade tider, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-215 | Kö-funktionalitet stöds ej |
Tjänstekontraktsbeskrivningen för GetAccessLogsForPatient stipulerar att om det tar (för) lång tid att generera en loggrapport så ska tjänsten returnera ett svar som innehåller:
- ett kö-id (queuedReportId) - någon av resultatkoderna REPORTONQUEUE eller REPORTINPROCESS. - en indikation på hur länge det förväntas ta innan rapporten är genererad (queueTime). Med hjälp av queuedReportId kan en konsument efter den av queueTime stipulerade kötiden göra ett nytt anrop för att hämta den skapade rapporten. Avvikelsen uppstår när denna funktionalitet saknas hos en tjänsteproducent. Orsaken till att den saknas kan variera. Inera förebehåller sig rätten att återkomma med krav på att funktionen skall införas i det fall anslutningen inte klarar stipulerad SLA avseende svarstid eller att den gemensamma infrastrukturen utvecklas på ett sätt så att funktionen blir ett krav. |
<p> <n>GetAccessLogsForPatient - 1.1</n> <br /> <n>GetAccessLogsForPatient - 2.0</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-206 | Kommentarstext för labbsvar inkluderas inte i svar |
För ett labbsvar kan text som innehåller en kommentar som avser den utförda analysen läggas till i analysisComment t.ex. information om varför ett prov inte har genomförts.
Om detta används i verksamheten, men inte har mappats mot tjänstekontraktet uppstår denna avvikelse. |
<p> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-158 | All information som ska vara tillgänglig enligt en begäran tillgängliggörs inte |
Den information som en tjänstekonsument har rätt att begära ska vara tillgänglig och den information en tjänstekonsument inte har rätt att begära ska inte vara tillgänglig.
Avvikelsen uppstår när en tjänsteproducent inte tillgängliggör all information som enligt avtal ska vara tillgänglig. |
<p> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-151 | Tjänsteproducent stödjer inte UTF-8 fullt ut |
Detta innebär att vissa tecken inte levereras på ett semantiskt interoperabelt sätt, dvs så som de är dokumenterade i källsystemen.
Det kan finnas många orsaker till denna avvikelse. De enskilda fallen får bedömas individuellt för att undersöka om avvikelsen kan accepteras av tjänstekonsument och om det påverkar samverkansetablering med aktuell tjänsteproducent. |
<p> <n>GetDiagnosis - 2.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-150 | Information om ansvarig person inkluderas inte i svar |
Elementet accountableHealthcareProfessional (AHCP) betecknar en HoS-person och återfinns i header-elementet för de flesta tjänstekontrakt inom sammanhållen journalföring.
Syftet med elementet varierar beroende på tjänstekontrakt. Det vanligaste är att det pekar ut den person som är "ansvarig för informationen", dvs den som har skapat informationen i källsystemet. Till undantagen hör t.ex. GetLaboratoryOrderOutcome, där AHCP pekar ut den person som har framställt den vårdbegäran som ligger till grund för labbsvaret. |
<p> <n>GetCareContacts - 2.0</n> <br /> </p> |
Godkänd |
Bokade tider, Journalen, NPÖ
|
-, NKRR
|
Avvikelse | INAV-135 | Filtrering på källsystem stöds ej |
Vissa tjänstekontrakt medger att en tjänstekonsument i sin begäran gör urval baserat på källsystem.
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-51 | Tomma element inkluderas i svar |
Tomma element innebär dessa två varianter:
<element></element> <element/> 1). Tolkning enligt XML Detta betyder "Tomt innehåll" enligt XML och ska rendera identiska resultat vid tolkning, men det är inte lika med NULL. (ref: https://www.w3.org/TR/REC-xml/#NT-content (och http://www.w3schools.com/xml/xml_elements.asp)) 2). Tolkning enligt XML + Schema Tomma element har en innebörd, ska kunna tolkas och schemat är regelsamling för tolkningen. Ett element (enligt xml + schema) har en Type som specar vad innehållet ska tolkas som. Type = String ==> Tomt element ska tolkas som en tom sträng, dvs 0 tecken. (ref: https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html#string ) Detta innebär att det i ett fåtal fall skulle kunna vara OK att dessa element levereras (se punkt 3 nedan). Type ≠ String ==> Tomt element har ett felaktigt innehåll enligt Type (såvida inte det i specialfall har specats som ett giltigt värde enligt dess Type). Exempel på Type enligt det senare är Boolean, Date, TimeStamp, ENUM, OID. 3). Tolkning enligt XML + Schema + TKB Rent lexikaliskt behöver beskrivningen av ett element i TKB tas i beaktande för att utröna om tomt element är tillåtet. Type = String ==> Tomt element ska tolkas i kontexten av beskrivningen i TKB. T.ex. elementet "Förnamn" är inte OK sätta till 0 tecken, då ett förnamn inte kan bestå av 0 tecken. |
<p> <n>GetCareContacts - 2.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> </p> |
Godkänd - Tidsbegränsad |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NPÖ
|
-
|
Avvikelse | INAV-48 | Obsoleta och otillåtna element inkluderas i svar |
Denna avvikelse rör tjänstekontraktselement som i tidigare major-versioner av tjänstekontraktet har varit giltiga, men som i en senare version klassats som obsoleta och där kardinaliteten för elementet numera är satt till "0..0". Detta innebär att elementet inte får inkluderas i ett svar.
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent returnerar ett svar som innehåller detta element. Konsekvensen kan bli en oförutsägbart beteende hos en tjänstekonsument när den får ta hand om ett svars-element som den inte hade räknat med. |
<p> <n>GetReferralOutcome - 3.1</n> <br /> </p> |
Godkänd |
Journalen, NPÖ
|
-
|
Avvikelse | INAV-45 | Filtrering på registreringstidpunkt stöds ej |
Vissa tjänstekontrakt medger att en tjänstekonsument i sin begäran gör urval baserat på registreringstidpunkt (authorTime).
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMaternityMedicalHistory - 2.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-25 | Inkorrekt hantering av ogiltig begäran |
Denna avvikelse gäller för de domäner där tjänstekontraktsbeskrivningen stipulerar regler för hur tjänsteproducenten ska hantera en begäran som ej är korrekt utifrån de regler som gäller för aktuellt tjänstekontrakt.
En sådan begäran kallas även "logiskt fel" och tjänsteproducenten ska då returnera ett svar där result.resultCode är satt till "ERROR" och result.errorCode är satt till "INVALID_REQUEST". Avvikelsen gentemot tjänstekontraktsbeskrivningen uppstår då tjänsteproducenten inte stödjer denna typ av hantering. Konsekvensen blir ett oförutsägbart beteende hos tjänstekonsumenten. |
<p> <n>GetAccessLogsForPatient - 2.0</n> <br /> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMaternityMedicalHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Journalen, NPÖ
|
Förnya recept
|
Avvikelse | INAV-7 | Filtrering på vårdkontakts-id stöds ej |
Vissa tjänstekontrakt medger att en tjänstekonsument i sin begäran gör urval baserat på vårdkontakts-id.
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. |
<p> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetCareDocumentation - 2.1</n> <br /> <n>GetCarePlans - 2.0</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetFunctionalStatus - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> <n>GetMaternityMedicalHistory - 2.0</n> <br /> <n>GetMedicationHistory - 2.0</n> <br /> <n>GetReferralOutcome - 3.1</n> <br /> <n>GetVaccinationHistory - 2.0</n> <br /> </p> |
Godkänd |
Biverkningsrapportering, Bokade tider, Förnya recept, Journalen, NKRR, NPÖ
|
-
|
Avvikelse | INAV-3 | Filtrering på vårdenhet stöds ej |
Vissa tjänstekontrakt medger att en tjänstekonsument i sin begäran gör urval baserat på vårdenhet.
Avvikelsen gentemot tjänstekontraktet uppstår när en tjänsteproducent inte stödjer denna typ av filtrering. (där samtliga poster felaktigt returneras eller ett felmeddelande returneras) Konsekvensen kan bli eventuellt sämre prestanda när en tjänstekonsument måste efterfråga och hantera samtliga poster för en patient (en konsument kan ju välja att endast visa poster från en vårdenhet även om den har tvingats ta emot samtliga poster). |
<p> <n>GetAlertInformation - 2.0</n> <br /> <n>GetCareContacts - 2.0</n> <br /> <n>GetCareContacts - 3.0</n> <br /> <n>GetDiagnosis - 2.0</n> <br /> <n>GetImagingOutcome - 1.0</n> <br /> <n>GetLaboratoryOrderOutcome - 3.1</n> <br /> </p> |
Godkänd - Tidsbegränsad |
Biverkningsrapportering, Bokade tider, Journalen, NPÖ
|
NKRR
|
Generated at Tue Aug 10 09:16:40 CEST 2021 by Henrik Emilsson using Jira 8.13.0#813000-sha1:8c68d8036d917652ef7564456d59d80184b5a77e. |