Pasientens prøvesvar - i teknisk utprøving uten helsehjelp.
Pasientens prøvesvar skal muliggjøre deling av prøvesvar på tvers av behandlingsnivåer, uavhengig av hvem som har bestilt undersøkelsen og hvor i landet den er utført. Dette skal kunne bidra til at:
- Helsepersonell får trygg og sikker tilgang til informasjon som kan bidra til raskere diagnostisering, riktigere behandlingsnivå og bedre kvalitet i helsetjenestene
- Innbyggerne får enklere tilgang til sine prøvesvar i Helsenorge
Pasientens prøvesvar er en del av Nasjonal Kjernejournal, og krever autentisering med pålogget Helse-ID bruker, jfr tillitsarbeidet forankret i helsesektoren.
For mere informasjon om Pasientens prøvesvar, også spesifisering av minimumskrav for leverandører som ønsker å være en del av første utprøving med formål helsehjelp, tidlig i 2025, se NHN hjemmesider her;
Utprøving og feilsøking for leverandører og IKT medarbeidere
Hvis du har utfordringer med integrasjoner eller validering av XML-meldinger, her finnes hjelp.
- Teknisk bistand fra utviklere i leveranseteamet på Slack-kanal
- EXT-UTV-Pasientensprøvesvar
- Virksomheter som allerede har Slack Workspace, kan ta denne lenken i bruk;
- For virksomheter som IKKE har Slack, må vi invitere dere inn, send oss da en mail med navn, virksomhet, formål og mailadresse, så inviterer vi dere inn. Det samme gjelder ved andre henvendelser, send en mail til provesvar@nhn.no - så hjelper vi deg så fort vi finner ledige ressurser.
- For andre henvendelser, ta kontakt med NHN Kundesenter
For avklaring om innhold i meldingsstandard, ta kontakt med ansvarlig direktorat, Helsedirektoratet
- Send mail til meldingshjelp@helsedir.no
I PPS test vises alle prøvesvar som er sendt inn til Pasientens prøvesvar, hvor svarrapporten er i henhold til standard, og Id for test-pasient finnes i Persontjenesten i test (syntetisk testpasient) eller fra "Testaktører".
Testmeldinger sendes til Pasientens prøvesvar, med oppføring av adresser og sertifikater i NHN Adresseregister i test;
- HER-ID 8139764 i AR-TEST og edi-adresse TEST-NILAR@testedi.nhn.no
- HER-ID 8139952 i AR-TEST og edi-adresse NILAR-INTERNETT@samsvar.nhn.no
For mer informasjon om testmeldinger, anonymisering etc, se NHN hjemmesider om testmeldinger til Pasientens prøvesvar
Den enkleste form for XML-validering, er å laste opp syntetisk test XML til XML-validering, som en første validering på generelt nivå.
Dette er ikke en innholdsvalidering for om et labsvar er korrekt implementert, se da neste punkt, PPS innholdsvalidering.
I XML-validering, finnes muligheter for å finne generelle avvik for en eller flere fagmeldinger, ved å laste opp eller dra/slipp syntetis test xml-melding. Det er ikke krav om innlogging og tjenesten er tilgjengelig fra internett.
"Innhold" viser overordnet status på validering,oversikt over hvilke feil som er avdekket, samt utlisting av egen XML
"Skjema" viser om det er feil i skjemavalidering, som vil returnere Negativ AppRec ved innsending til PPS.
"Visning" er en enkel xml-transformering (visningsfil), uavhengig av eventuelle feil i "Innhold", men er ikke en visning av hvordan hvordan/om KJ Portal viser prøvesvaret.
Visning av prøvesvar i KJ Portal.
Hvis du får tilgang til denne lenken, Prøvesvar i KJ Portal, vises en oversikt over hvordan godkjente prøvesvar blir vist i KJ Portal for helsepersonell, som er første konsumnet av Prøvesvar-API'et.
På sikt vil kode for hvordan KJ Portal har implementert visning, bli gjort tilgjengelig for leverandører som ønsker å gjenbruke/forstå løsningsmønster.
I og med at Pasientens prøvesvar skal håndere prøvesvar fra alle lab/rad i hele Norge, er det viktig at informasjon som sendes er i henhold til standard for svarrapportering.
I tillegg til XML-validering, er det viktig å sikre at innholdet i svarrapporten tilfredsstiller detaljer som kreves for et lab-svar (inkludert RTG), og vi har derfor lagt inn validering av innhold, for å sikre at f.eks relasjoner mellom prøvemateriale og analyseresultater er entydig identifisert, at Id'er det referes til, faktisk finnes (og kun et sted) etc.
Etter sommeren -24, vil slike avvik returnere en Negativ AppRec, men inntil det er på plass, kan man benytte midlertidig PPS validerings-endepunkt, for å avdekke eventuelle avvik i en svarrapport, som ikke nødvendigvis avdekkes i XML-validering.
- Installer f.eks. Postman https://www.postman.com/downloads/
- Opprett en ny samling – new collection – new request
- Endre default Request fra GET til POST
- Legg inn POST https://backdoor.test.pps.nhn.no/dryrun/validate i Postman (å trykke på lenken vil feile)
- Opprett/finn syntetisk testmelding, og åpne XML i Notisblokk eller Notepad++ (ikke web-browser eller andre viewere som endrer format)
- Kopier hele XML-meldingen fra notisblokk - Ctrl+A og Ctrl+C
- Gå til Postman Body og velg raw som format for tekstboksen
- Klikk i tekstboksen, merk alt og lim inn - Ctrl+A og Ctrl+V
- Trykk Send og du skal få opp et valideringsresultat
- Les resultat fra OperationalOutcome – diagnostics
Her er et eksempel på en OK validering, med respons "Report validated OK"
Tilsvaredne vil validering med feil eller mangler, vises som diverse feilmeldinger hentet fra PPS sin interne domenemodell.
For å forstå hva hvert enkelt avvik (diagnostics) betyr, må dette oversettes tilbake til beskrivelser gitt i XML, hentet fra standard for svarrapportering.
- I neste punkt på drop-down-listen er de mest vanligste avvik beskrevet med utfyllende forklaringer og henvisninger til hvor beskrivelse finnes i standard for svarrapportering
- I siste punkt er det satt opp en sammenstilling mellom hvor feilkilden finnes i PPS domenemodell, og tilhørende plassering i XML-dokumentet, for ServReq, ServReport, ResultItem og AnalysecSubject.
OperationalOutcome | Oversatt til XML | Kort forklaring | Feiltekst forklaring | Svarrapport v1.4 |
LifeCycleFieldRequired* |
*Report.AllResults. ServType |
Manglende påkrevd ServType i en eller flere ResultItem | Manglende påkrevd ServType i en eller flere ResultItem, minimum "mor" må ha ServType hvis flere underliggende ResultItems. Enten nøstet direkte under "mor", eller med referanse til "mor" resultat. | Kap 6.5.6 side 44 - ServType Påkrevd felt for alle undersøkelser og angir status til dette undersøkelsesresultatet. |
IssueDateFieldRequired* | *Report.IssueDate | Manglende dato for svarrapporten | Dato skal angis, helst også klokkeslett. Samme dato og klokkeslett skal benyttes ved endring eller kansellering. | Kap 6.3.2 side 25 - IssueDate Påkrevd felt for når svarrapport klargjøres for sending første gang. |
InvalidDecimalFormat* |
*ResultItem.NumResult. NumResultValue |
Verdi inneholder annet enn tallverdi. | Hvis det forekommer annet enn kun tall (med eller uten desimaler) i V= for NumResultvalue, vil denne feile. | Kap 6.5.7 side 46 NumResultValue Påkrevd felt for måleresultat som en numerisk verdi, inkludert enhet, beskrevet for hhv V="Verdi" og U="Enhet". |
SystemFieldRequired* |
*ResultItem. Investigation.Id.S |
Mangler tilhørende kodeverk i S= | Hvis Kodeverdi og/eller Norsk bruksnavn er registrert, skal alltid tilhørende kodeverk inkluderes i S". Her maangler beskrivelse av hvilket kodeverk som benyttes, om det er nasjonale eller lokale kodeverk | Kap 5.5 side 19 for nasjonale kodeverk Påkrevd bruk av alle 3 felter S="OID", V="KODE" og DN=Norsk bruksnavn i hht https://finnkode.helsedirektoratet.no/ Kap 5.5.1 side 19 for lokale kodeverk Påkrevd bruk av S og OT for lokale koder |
ExternalIdByServRequester FieldRequired* |
*ServReq.Id | Mangler eller feil bruk av RekvisisjonsID | RekvisisjonsID mangler eller ikke "NULL". F.eks ID\ er ikke tillatt, ei heller ServReq.<Id>""</Id> i forskjellige varianter. | Kap 6.3.3 side 26 - ServReq Påkrevd felt i Svarrapporten, og RekvisisjonsId skal være "NULL" hvis den ikke finnes i Rekvisisjonsmeldingen. |
ExternalIdByServProvider FieldRequired* |
*AnalysedSubject. IdByServProvider |
Tjenesteyters identifisering av hvert enkelt prøvemateriale mangler | Hver prøve skal identifiseres med tjenesteyters ID av prøvemateriale, slik at hvert undersøkelsesresultat kan knyttes til riktig prøvemateriale. Her mangler Id for ett eller flere prøvematerialer. | Kap 6.5.2 side 39 - AnalysedSubject Påkrevd felt i svarrapporten for alle prøvematerialer |
DuplicateIdResultItem* |
*ResultItem. IdResultItem |
Samme IdResultItem er benyttet flere ganger i en og samme svarrapport (oftest ved foreløpige svar, men forekommer også for endelige). | Hvert resultat i svarrapporten har egen oppføring i <ResultItem>. Hver enkelt ResultItem skal ha sin unike ID - slik at underliggende analyseresultateter kan peke på akkurat denne spesifikke ID'en. Og det er samme krav om det er en foreløpig rapport (hvor man kan benytte løpenumre for flere <ResultItem> )eller en endelig rappport. | Kap 6.5.6 side 44 - ResultItem Benyttes for å kunne referere til ett SPESIFIKT undersøkelsesresultat. |
StatusFieldRequired* | *ServReport.Status | Mangler status på svarrapportnivå | Hvis svarrapporten inneholkder flere tildligere svar, skal Status gjelder for det siste gjeldende svaret. Her mangler enten hele <Status> eller statusverdier for V="" og/eller DN="". | Kap 6.3.2 side 25 - ServReport Påkrevd felt for status for hele svarrapporten, fra kodeverk 7603 |
Ref non-existing sample* |
*ResultItem. RefAnalysedSubject |
Ett eller flere analyseresultater referere til en ID som ikke finnes for et prøvemateriale (AnalysedSubject). | Hvert analyseresultat <ResultItem> kan peke på (Ref..) tilhørende prøvemateriale <AnalysedSubject>, som er identifisert av LAB med <IdByServProvider>. Ved "non-existing" referanse, vil ID som det refereres til (RefAnalysedSubject), ikke finnes for noe prøvemateriale (AnalysedSubject). Og det er samme krav om det er en foreløpig rapport eller en endelig rappport. | Kap 6.5.6 side 43-45 - ResultItem - peker på Kap 6.5.2 side 39. Benyttes for å kunne referere resultatet til et SPESIFIKT prøvemateriale. |
SystemFieldRequired* |
*ServType. MsgDescr.DN |
Type laboratoriemelding mangler tilhørende beskrivelse av kodeverdi i DN. | Alle oppføringer av type laboratorimelding, skal ineholde både V="" og DN"", i henhold til kodeverk 8202. Her er V oppgitt, men DN som beskriver type melding, mangler. | Kap 6.3.2 side 25 - ServReport Påkrevd felt i svarrapporten for å angi type laboratoriemelding, fra Kodeverk 8202 |
DerivedFromStatus FieldRequired |
*ResultItem. StatusInvestigation |
Feltet er med men mangler innhold i "V" og/eller "DN" | Når feltet StatusInvestigation er med i svarrapporten, er det krav om å inkludere både V="" og DN="" fra kodeverk 8245. Her mangler en eller begge oppføringer. | Se Kap 6.5.2 side 43-45 - ResultItem - StatusInvestigation Anbefalt felt i svarrapporten, men påkrevd å være komplett ved bruk - fra kodeverk 8245. Se også HITS-1249 under Teknsikse beskrivelser for prøvesvar, på nhn.no |
Under finnes en sammenstilling av interne beskrivelse fra PPS innholdsvalidering, og tilhørende plassering i XML-dokumentet, for ServReq, ServReport, ResultItem og AnalysecSubject.
Ved feiltekster fra PPS Innholdsvalidering, er det viktig at HVA legges til grunn, eks requiret, invalid, duplicate, non-exising etc. I tillegg må standard for svarrapportering benyttes, for videre feilsøking.
Og ja, vi beklager elendig formattering av denne tabellen.. :)
PPS innholdsvalidering | Oversatt til XML |
ServiceRequest | ServReq |
IdByRequester | Id |
IdByServiceProvider | IdByServProvider |
LifeCycle | ServType |
IssueDate | IssueDate |
ReasonAsText | ReasonAsText |
RequesterComment | ReqComment |
Reservations | Reservation |
PaymentCategory | PaymentCat |
RequestedPriority | RequestedPrioReport |
ReceiptDate | ReceiptDate |
CompositeComments | Comment |
MessageDescription | MsgDescr |
Report | ServReport |
ExternalId | ServProvId |
ExternalVersionId | MsgId |
EffectiveDate | <effectiveDate> |
IssueDate | IssueDate |
VersionDate | GenDate |
ApprovalDate | ApprDate |
Status | Status |
LifeCycle | ServType |
ReportCategory | MsgDescr |
ClinicalInformation | InfItem |
Comment | Comment |
CommentCoded | CodedComment |
DocumentReferences | RefDoc |
RelatedServiceProvider | RelServProv |
ServiceProvider | ServProvider |
Requester | Requester |
ResponsibleHcp | ResponsibleHcp |
Result | ResultItem |
ExternalId | IdResultItem |
Status | Status |
LifeCycle | ServType |
ReferenceIntervals | RefInterval |
Investigations | Investigation |
EffectiveDate | <effectiveDate> |
InvestigationDate | InvDate |
StatusChangedDate | StatusChangedDate |
MedicalValidationDate | MedicalValidationDate |
DescriptionDate | DescrDate |
CounterSignDate | CounterSignDate |
Interpretation | DevResultInd |
Comment | Comment |
Accredited | Accredited |
TextValue | TextResult |
NumberValue | NumResult |
DateValue | DateResult |
IntervalValue | IntervalResult |
Sample | AnalysedSubject |
IdByServiceProvider | IdByServProvider |
IdByRequester | IdByRequester |
LifeCycle | ServType |
Type | Type |
TypeCoded | TypeCoded |
Comment | Comment |
CollectedDate+SampleDate | CollectedSample.CollectedDate |
CollectorComment | CollectorComment |
CollectorCommentsCoded | CollectorCommentCoded |
Logistics | Logistics |
Addedmaterial | PreservMaterial |
Bodysite | AnatomicalOrigin |
NumberOfTestTubes | Number |
Method | SampleCollProc |
HandleInformation | SampleHandling |
PatientPreparation | Pretreatment |
RelatedSample | CollectedStydyProduct |
RelatedProduct | CollectedStudyProduct.RefRelatedProduct |
RelatedProductType | CollectedStudyProduct.Type |
RelatedProductDate+Sampledate | CollectedStudyProduct.ProductDate |
Accredited | Accredited |