Ny validering omkring anvendelse af SOR i FMK

Started by Steven A. Sørensen, 2023-09-19 15:40:25

Previous topic - Next topic

Steven A. Sørensen

Goddag,

Med release 1.4.6.59.c, som blev released til produktion den 6/9/2023 blev der indført en validering omkring benyttelsen af SOR i FMK. FMK har altid valideret at det anvendte SOR-nummer er gyldigt, og at den SOR-type man angav kunne få adgang.

Problematikken ligger i at FMK ikke validerede sammenhængen mellem SOR-nummer og SOR-type.

Det har derfor været muligt at anvende et SOR-nummer i kombination med en SOR-type som ikke matchede. Det gav anledning til problematisk opførsel i nogen af FMK's services, og anses også som en fejl at dette har været muligt, da FMK er pålagt fra SDS's side kun at godkendte SOR-typer bør have adgang til FMK.

Efter release vil de klienter som ikke angiver en gyldig kombination af nummer+type, opleve en fejl med teksten: "SOR Organisation med id [anvendte SOR-nummer] angivet med den forkerte type: [anvendt SOR-type], opslag i SOR viser følgende type: [verificerede SOR-type]". Vi har sidenhen oplevet en del forvirring og behov for support omkring denne ny validering, og skriver derfor denne generelle udmelding.

Klient-systemer, hvis kunder oplever dette problem, bør guide deres kunder til at i stedet anvende en gyldig SOR-nummer+type kombination. Efter vores oplevelse er der typisk tale om at SOR-nummeret som er anvendt er af typen "Supplerende oplysninger" eller "Privat". Oftest vil det korrekte Nummer+Type faktisk ligge enten niveauet over eller under i SOR.

  • For typen "Privat" ligger organisationen i niveauet under.
  • For typen "Supplerende  oplysninger" ligger organisationen i niveauet over.

Der er udstillet en kopi af SOR her: https://sorbrowser.sundhedsdatastyrelsen.dk/

SOR vil i det fleste tilfælde være udformet i følgende niveauer.

  • Organisations ejer (Privat, Stat, Region, Kommune)
  • Organisation(er) (Bosted, Plejehjem, Almen lægepraksis mm.)
  • Andre Organisationsoplysninger (Supplerende oplysninger)

Det vil altså oftest være tilfældet at SOR-nummer+Type skal tages fra 2.niveau. Bemærk dog at FMK indtil videre kun accepterer typerne som de kommer fra vores KRS replikering, hvori typen altid er angivet med små bogstaver ("bosted" frem for "Bosted").

Der kan være andre udformninger såfremt organisationen er inddelt med hovedafdeling of underafdelinger.

I skrivende stund accepterer FMK følgende organisations-typer:


  • bosted
  • center for misbrugsbehandling
  • genoptræningsenhed
  • handicap- og psykiatrienhed
  • handicapenhed
  • hjemmeplejeenhed
  • hjemmesygeplejeenhed
  • plejehjem
  • psykiatrienhed
  • sundhedscenter
  • sundhedsplejen
  • sygeplejeklinik
  • tandlægepraksis
  • tandplejeklinik
  • behandlingscenter for stofmisbrugere
  • behandlingsenhed i fængsel eller arresthus
  • vaccinationsklinik
  • hospice
  • almen lægepraksis
  • speciallægepraksis
  • asylcenter
  • fertilitetsklinik
  • rehabiliteringsenhed
  • internetbaseret sundhedsydelse

[EDIT]
Når der slåes op i SOR-browseren: https://sorbrowser.sundhedsdatastyrelsen.dk/ er det vigtigt at det korrekt niveau vælges, således at de korrekt oplysninger ses i informationsvinduet.



[EDIT2]
Findes organisations type ikke i listen over godkendte typer, skal der overvejes 1 af 2 løsninger.


  • Organisationstypen er ikke beskrivende nok fx "Anden  sundhedsinstitution" er ikke beskrivende, og er derfor ikke tilladt. Hvis der findes en beskrivende type blandt de godkendte enheder, skal SOR kontaktes med henblik på at få ændret typen.
  • Organisationstypen er beskrivende, og bør kunne få adgang. I dette tilfælde skal SDS kontaktes, med henblik på af FMK skal lukke op for den pågældende enhedstype.

Mvh FMK Teamet

Paul D. Samsig

Man kunne argumenterer for, at det er totalt overflødig at skulle angive SOR-type, da det er implicit ud fra SOR-kode, og man kunne også argumentere for, at når SOR-typen (implicit eller eksplicit) er 'Supplerende  oplysninger', så tjekkede FMK selv på om niveauet over, var en valid SOR-type. Det ville have været en meget mindre disruptiv måde, at opnå den samme sikkerhed for 'korrekte' SOR-koder og SOR-typer.

Paul D. Samsig, EG Healthcare en del af EG Danmark A/S

Steven A. Sørensen

Quote from: Paul D. Samsig on 2023-09-19 16:42:35
Man kunne argumenterer for, at det er totalt overflødig at skulle angive SOR-type, da det er implicit ud fra SOR-kode, og man kunne også argumentere for, at når SOR-typen (implicit eller eksplicit) er 'Supplerende  oplysninger', så tjekkede FMK selv på om niveauet over, var en valid SOR-type. Det ville have været en meget mindre disruptiv måde, at opnå den samme sikkerhed for 'korrekte' SOR-koder og SOR-typer.

Hej Paul,

Det har aldrig været FMKs første tilgang til problemer, at ændre på hvad klienten indberetter. Gør vi dette, så er chancen stor for det også skaber forvirring når data så kommer ud igen og ikke er ens med hvad der blev indberettet. Det kan sagtens være det i realiteten ikke har den store indflydelse, og de fleste vil nok ikke opdage det, men det skaber noget utryghed at FMK "bare ændre" på hvad folk indberetter, selv hvis det vi ændre det til faktisk vil være det korrekte.

Da OrganisationIdentifierType i skemaet ( https://wiki.fmk-teknik.dk/doku.php?id=fmk:medicinecard-inline_2015_01_01_e4:feltbeskrivelser#OrganisationIdentifierType ) kun har en source og ikke source+date. Har klienten ikke adgang til at informere FMK om hvordan den forventer verden ser ud. Vi har set at Organisationer skifter type, uden at skifte SOR-nummer, fx ved fejlregisteringer.

Så hvis vi implementerede det som du foreslår:
Systemet indberetter Kode X, som har typen "Supplerende oplysninger".
FMK "beriger" på vej ind, finder Kode Y, har typen "Administrativ Enhed". (Blot til eksempel om type som ikke godtages)

Hvad skal FMK returnerer? Vi kan ikke acceptere kode X, vi kan ikke acceptere kode Y. Skulle vi have lavet en anden valideringfejl om at FMK kan ikke finde en gyldig SOR-nummer+Type kombination?

Det samme gør sig gældende hvis vi er ude i en situation hvor organisationen har ændret type. Uden af klientsystemet eller brugeren har kendskab til ændringen. Da i ikke kan angive en SourceDate, vil FMK finde noget andet en hvad klienten havde forventet.

Systemer indberetter Kode X, indtil dagen før havde den typen "Bosted".
FMK "beriger" på vej ind, finde X, men beriger nu typen til den nye værdi "Administrativ Enhed".

FMK smider nu fejlkode 306, "Det er ikke tilladt at anvende en SOR organisations id for typen [Beriget type], kun flg. er tilladte: [Accepterede typer]".

Hvis vi berige på vej ind med en helt anden SOR-nummer end det som blev indberettet, gør også FMKs arbejde med flere typer support mere besværligt. Derudover vil en berigelse på vej ud, ud fra det ændrede sor-nummer, med stor sandsynlighed give nogle helt andre oplysninger end hvad der måske kunne forventes. I supplerende oplysninger angives type nogle helt andre navne på noden, end det som angives på organisations-noden, så hvis FMK fra den ene dag til den anden returnere nogle helt andre oplysninger, uden nogen prompt, kunne vi nok forvente lige så mange supportsager på "Oplysningerne er forkerte, indtil i går var det altid...".

Den simple forklaring må nok være, at valideringen følger FMKs normer for at når der opdages fejl, skal de rettes. i dette tilfælde gøres det efter vores overbevisning bedst, ved at validerer sammenhængende mellem nummer og type på vej ind. Dette giver nogen gener for slutbrugerne, og noget forvirring omkring hvad de nu skal gøre. Vi hjælper forsat gerne med at udrede det support som måtte komme ind, men håber også på at denne post ville hjælpe med at forklarer hvad der er ændret, og hvorfor vi har valgt at gøre det. Når den korrekt kombination af Nummer+Type er fundet og anvendes, er alle parter enige om hvad der forventes på vej ind, og hvad der kan forventes kommer tilbage hos alle systemer når data hentes op igen.

Håber denne forklaring giver mening.

Mvh FMK Teamet