admstar / rivta

Automatically exported from code.google.com/p/rivta
0 stars 0 forks source link

Vidimerat av och vidimeringsdatum saknas #193

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
När rådrum för konsultationsremisser hanteras i Sustains så kontrollerar vi 
om svaret är vidimerat eller inte av behandlande läkare. Om svaret inte är 
vidimerat så innefattas det av rådrummet då det anses som obekräftad 
information. (vidimerat i detta fall betyder om behandlande läkare tagit del 
av remissen) 

Vid en snabb första kontroll så hittar jag inte detta fält någonstans och 
vi önskar givetvis att kontraktet kompletteras med denna information.

Mvh
Martin

Original issue reported on code.google.com by Evry.Mar...@gmail.com on 22 Oct 2013 at 12:19

GoogleCodeExporter commented 9 years ago
Frågan som Fredrik bör svara på: betyder legalAuthenticator i det här 
fallet vidimering?

Original comment by bjorn.ge...@gmail.com on 5 Nov 2013 at 9:14

GoogleCodeExporter commented 9 years ago
Se issue 182.
Informationen om huruvida ett svar är vidimerat eller inte finns i dagsläget 
inte med i kontraktet.
I kontraktet finns approvedForPatient vilket används för att ange om 
patienten kan ta del av informationen. I källsystem kan det finnas en regel 
som sätter värde på det attributet utifrån exempelvis huruvida infomationen 
är vidimerad.

För att kunna besluta om huruvida vidimering ska läggas till i kontraktet 
behöver en tydlig specifikation av behovet tas fram.

Original comment by fredrik....@mawell.com on 8 Nov 2013 at 9:36

GoogleCodeExporter commented 9 years ago
Rådrum kommer ju att vara med i vissa verksamheters regelverk för att sätta 
"approvedForPatient" till "true". Att det dessutom finns i Sustains-e-tjänsten 
(nationella versionen/eJournalen) glr ju att det i vissa fall kan bli dubbelt 
rådrum (det som professionen beslutar om + det som e-tjänsten i 
Sustains-fallet dessutom adderar om patienten så beslutar).

Original comment by jo...@eltesconsulting.se on 17 Nov 2013 at 8:05

GoogleCodeExporter commented 9 years ago
Kan återöppnas när kravbild blir tydlig ur ett producentperspektiv.

Original comment by jo...@eltesconsulting.se on 17 Nov 2013 at 8:07

GoogleCodeExporter commented 9 years ago
Jag håller inte med dig Johan. Rådrum hanteras av användaren i vår 
e-tjänst, baserat på ett politiskt beslut taget av produktionsstyrelsen i 
Uppsala. Rådrum bestäms alltså inte av producenten av informationen. Detta 
står i regelverket. 

Angående behovet så tycker jag att det är beskrivet i den översta punkten. 
Hör av er om ni tycker att det fortfarande är otydligt. Angående vad som ska 
sparas så är det:
* Vidimerat av: (förnamn, efternamn och roll.)
* Vidimerat datum

Kardinalitet: Varje svarstyp ska gå att vidimera

Original comment by Evry.Mar...@gmail.com on 22 Nov 2013 at 10:35

GoogleCodeExporter commented 9 years ago
Tjänstekontrakten möjliggör att rådrum bestäms av producenterna. Det 
ligger i varje vårdgivares handlingsutrymme att införa det som vårdgivarens 
policy för en viss enhet eller utgående från godtyckligt fingranulära 
regler. Vi har ett strukturellt problem här. Men om alla vårdgivare som 
ansluter till tjänstekontraktet väljer att gå på den policy som kommer att 
rekommenderas av CeHis (eller kanske redan rekommenderas) så blir ju effekten 
att patienten kontrollerar rådrummet. Men varje landsting beslutar ju själva 
vilken policy de inför. Policyn för att sätta "approvedForPatient" kan inte 
sättas per per e-tjänst, utan är den gäller oavsett på vilket sätt 
patienten ges tillgång till informationen.

Låt oss ta upp stödet för vidimering i kontraktet utgående från ett 
informatiskt/verksamhetsperspektiv på kommande integratörsmöte. Det är där 
vi måste lands frågan för att kunna införa den. Hittar vi bara ett sätt 
att definiera vad visitering avser på ett systemneutralt så borde vi vara i 
hamn.

Original comment by jo...@eltesconsulting.se on 22 Nov 2013 at 11:34

GoogleCodeExporter commented 9 years ago
Issue 223 has been merged into this issue.

Original comment by jo...@eltesconsulting.se on 22 Nov 2013 at 11:36

GoogleCodeExporter commented 9 years ago
Issue 182 has been merged into this issue.

Original comment by jo...@eltesconsulting.se on 22 Nov 2013 at 11:40

GoogleCodeExporter commented 9 years ago

Original comment by jo...@eltesconsulting.se on 22 Nov 2013 at 11:41

GoogleCodeExporter commented 9 years ago
Det är skillnad på vad rådrum på/av visar/inte visar och vad som är 
approvedForPatient = true/false. 

Vårdinformation från vårdgivaren kan vara menprövad alltså 
approvedForPatient= true , men användaren vill fortfarande vänta med att 
läsa informationen tills man blivit kontaktad av vårdgivaren alltså rådrum 
= på.

Rådrum är alltså inget som producenten styr över utan användaren av 
e-tjänsten. Jag väljer alltså själv om jag vill be konfronterad av ny eller 
obekräftad information innan vårdgivaren i sin tur har kontaktat mig. 

Original comment by Evry.Mar...@gmail.com on 22 Nov 2013 at 12:30

GoogleCodeExporter commented 9 years ago
Det är inte säkert att det är skillnad. Vårdgivaren (informationsägaren) 
kan bestämma sig för att forsera rådrum genom att addera t.ex. 14 dagar som 
del av policy för att sätta approvedForPatient till true för att man 
bedömer att det är så man vill hantera delgivningen.

Original comment by jo...@eltesconsulting.se on 23 Nov 2013 at 10:38

GoogleCodeExporter commented 9 years ago
Om det är skillnad eller inte beror på hur man ser att funktionen rådrum ska 
fungera. Vi har våra krav på hur rådrum ska fungera (från LUL) baserat på 
ovanstående. Men du förespråkar ett alternativt sätt? Borde inte detta 
diskuteras med LUL och CEHIS hur det egentligen ska hanteras?

Original comment by Evry.Mar...@gmail.com on 3 Dec 2013 at 11:49

GoogleCodeExporter commented 9 years ago
Det tycks inte finnas något robust  system/verksamhetsoberoende sätt att 
definiera vidimarkering. Men om behovet egentligen handlat om att styra rådrum 
skulle en lösning ev kunna vara att fokusera på just det genom att införa 
ett fält för rådrumsdatum. Då kan varje tjänsteproducent tillämpa 
system/verksamhetsspecifika regler (t.ex vidimarkeringsdatum för labbsvar i 
fallet cosmic) för att stämpla det det datum dom ska vara bas när en 
invånartjänst ska beräkna rådrum. Fråga till Uppsala/Martin: skulle det 
lösa ut frågeställningen? Kan i så fall ett sådant datumfält ligga i 
summaryheader?

Original comment by jo...@eltesconsulting.se on 6 Feb 2014 at 6:14

GoogleCodeExporter commented 9 years ago
Det tycks inte finnas något robust  system/verksamhetsoberoende sätt att 
definiera vidimarkering. Men om behovet egentligen handlat om att styra rådrum 
skulle en lösning ev kunna vara att fokusera på just det genom att införa 
ett fält för rådrumsdatum. Då kan varje tjänsteproducent tillämpa 
system/verksamhetsspecifika regler (t.ex vidimarkeringsdatum för labbsvar i 
fallet cosmic) för att stämpla det det datum dom ska vara bas när en 
invånartjänst ska beräkna rådrum. Fråga till Uppsala/Martin: skulle det 
lösa ut frågeställningen? Kan i så fall ett sådant datumfält ligga i 
summaryheader?

Original comment by jo...@eltesconsulting.se on 6 Feb 2014 at 6:14

GoogleCodeExporter commented 9 years ago

Original comment by jo...@eltesconsulting.se on 6 Feb 2014 at 6:22

GoogleCodeExporter commented 9 years ago
Utifrån diskussioner med Martin L föreslås en lösning se ut som följer:

För kemisvar är behovet att kunna ange per analys i ett svar om den är 
vidimerad och av vem. Det finns inte behov av att kunna vidimera ett helt svar 
för kemisvar. Notering: i kommande mikrobiologisvar finns eventuellt behov att 
kunna vidimera ett svar i sin helhet.

I laboratoryOrderOutcome/laboratoryOrderOutcomeBody/analysis läggs följande 
till

attested                LegalAuthenticatorType      0..1    Information om vidimering av enskild 
analys med tillhörande resultat. Finns attester är analysen vidimerad. Med 
vidimerat menas att information om analysen har lästs och den som läst har 
tagit ansvar.

    signatureTime           TimeStampType       1..1    Tidpunkten för vidimering
    legalAuthenticatorHSAId         HSAIdType       0..1    HSA-id för person som vidimerat
    legalAuthenticatorName              string  0..1    Namn på person som vidimerat

Original comment by fredrik....@mawell.com on 7 Feb 2014 at 8:41

GoogleCodeExporter commented 9 years ago
Lösning infört i kontrakt

Original comment by fredrik....@gmail.com on 14 Nov 2014 at 11:58

GoogleCodeExporter commented 9 years ago

Original comment by fredrik....@mawell.com on 14 Nov 2014 at 12:05

GoogleCodeExporter commented 9 years ago
Med i nästa RC(clinicalprocess_healthcond_actoutcome_3.0_RC3) av 3.0

Original comment by khaled.d...@carity.se on 24 Nov 2014 at 9:12