RS eArkiv
27/3 2014
1
• Tero Ahola
• Informationsarkitekt
• Enheten för eArkiv, Regionarkivet
2
Upplägg
•
•
•
•
•
•
•
•
•
Standardsystem
Egenutvecklat
Vad är RS eArkiv?
Mellanarkiv/Slutarkiv
Informationskategorier
Sökning/Importer
Webbklienter för sökning
Egenutvecklad produkt
Varför egenutvecklat
3
Standardsystem
Kännetecken:
•”Färdig” programvara som ett företag kan köpa in och efter ”viss” anpassning utnyttja i företagets
verksamhet.
•Anpassning krävs av både system som verksamhet för att få en fungerande IT-lösning.
•Utvecklat för att motsvara flera kunders verksamhetsbehov (mer generellt byggda)
Fördelar:
•Snabb utveckling
•Kostnadsbesparande
•Kunskapsstöd
•Omfattande
•Ständig utveckling
Nackdelar:
•Leverantörsberoende
•Generella, svårt få alla behov täckta
•Ej öppen källkod
4
Egenutvecklat
Kännetecken:
•Skräddarsytt system
•System som byggs upp från grunden och anpassas efter verksamheten.
•Enklare system (färre funktioner)
Fördelar:
•Systemet kan skräddarsys efter det som verksamheten verkligen behöver
•Leverantörsoberoende
•Kontroll över teknik och källkod
•Anpassa systemet efter ny teknik
•Vidareutveckling av systemet
Nackdelar:
•Oftast dyrare alternativ än standardssystem
•Långsam utveckling
•Inget kunskapsstöd
•Resurskrävande/Kompetenskrävande
5
Vad är RS eArkiv?
Regionövergripande system för att säkerställa långsiktig tillgång till
verksamheternas digitala information
–
–
–
–
finns sedan oktober 2011
bygger på Stockholms Läns Landstings lösning men anpassad till Region Skånes behov
ca 3500 registrerade användare,
inom Region Skåne
olika sökgränssnitt för olika typer
av information:
•
•
•
•
•
Patientjournaler (bilden)
Personalakter
Ekonomi
Avtal
etc.
6
Samverkan
Samverkan
•R7 (nio landsting, landstingssamarbete): Dalarna, Sörmland, Gävleborg, Västmanland, Västernorrland,
Jönköping, Uppsala, Värmland, Örebro
•RS (Region Skåne)
•SLL (Stockholms Läns landsting).
•Gemensamt utbyte, utveckling och förvaltning av framtagen källkod.
•Leverantörsoberoende koncept för earkivering
•Exempel på aktiviteter
•Förädla inleveransspecifikation för journalhandlingar
•Finna arbetsformer för att utarbeta inleveransspecifikationer för fler handlingstyper
ENSAM (E-arkiv i nationell samverkan)
•Nätverk för samarbete och erfarenhetsutbyte kring elektroniskt bevarande
•Företrädare för stat, kommun och landsting
•Exempel på aktivitet
•Utvärdera metod för enklare utplock av data från verksamhetssystem till eArkiv
–
- POC AVK Journalia, Teleråd, Mapforce
7
Mellanarkiv
Slutarkiv
•
Kan innehålla information som ska gallras efter en
viss tid.
•
Innehåller enbart information som ska bevaras för
all framtid.
•
Verksamheten äger fortfarande informationen.
•
Verksamheten har lämnat över
informationsägarskapet till Regionarkivet. T ex
när vårdgivare upphör.
•
Verksamheten har direktåtkomst och söker
själv.
•
Endast Regionarkivets personal har
direktåtkomst som ansvarar för utlämning
•
Inga krav på PDL-loggning.
Verksamheten ansvarar för utlämning på begäran
av vårdpersonal, medborgare, myndigheter mm.
•
Regionarkivet ansvarar för utlämning på begäran av
vårdpersonal, medborgare, myndigheter mm.
Verksamheten ansvarar för menprövning vid
journalutlämning.
•
Regionarkivet ansvarar för menprövning vid
journalutlämning.
Höga krav på god prestanda eftersom systemet
används ofta och av många.
•
Lägre krav på prestanda då antalet användare är
färre, högre krav på avancerade sökmöjligheter för
olika forskningsändamål.
•
Högre krav gällande teknik- och formatoberoende
för att säkerställa långsiktig lagring och återsökning.
•
•
•
•
Användning måste loggas enligt Patientdatalagen.
Samma databas, flagga
8
Arkiverad information i RS eArkiv
RS eArkiv innehåller eArkiverad information från:
–Swedestar (Patientjournaler)
–Famlak (Patientjournaler)
–PLD (Personalakter)
–Prima (Personalakter)
–Effica (Folktandvårdsjournaler)
–Heroma (Personalakter)
–Telerad (Patientjournaler)
–Simrishamn (Patientjournaler)
–HUD E-Dok (Patientjournaler)
–ProCuris Paul32 (Folktandvårdsjournaler)
–ProCuris Edward32 (Folktandvårdsjournaler)
–ChamberSign (Avtalsinformation)
–Lokalt dokument (Avtalsinformation)
–Journalia (Patientjournaler)
–Viewscan (Patientjournaler)
–Skane.se (web)
–Inom en snar framtid även från :
–Ebill (Ekonomi)
–Raindance (Ekonomi)
–Obstetrix (Mödravårdsjournaler)
–KIKA (Mödravårdsjournaler)
–PMO (patientjournaler)
–Melior (patientjournaler)
9
Informationskategori
•
Ett mer generellt sätt att se på informationen.
•
Fokus på innehåll, ej hur ett system är konstruerat.
•
eArkivet arkiverar innehåll/information ur verksamhetssystem, ej själva systemet med databaser, programkod
etc.
•
System grupperas efter vilken typ av information de hanterar.
•
•
•
•
•
•
•
•
•
•
•
Ursprungssystem
Prima
Heroma
PLD
Chambersign
Csign
Swedestar
ViewScan
Hud e-Doc
eBill
Raindance
typ av system
Personaladministrativ
Personaladministrativ
Personaladministrativ
Avtassystem
Avtalssystem
Patientjournalsystem
Patientjournalsystem
Patientjournalsystem
ekonomisystem
ekonomisystem
Informationskategori
Personal
Personal
Personal
Avtal
Avtal
Hälso- och sjukvård
Hälso- och sjukvård
Hälso- och sjukvård
Ekonomi
Ekonomi
10
Informationskategori Personal
Person
- namn
- personnr
Frånvaro
- datum
- Frånvaroorsak
Anställning
- befattning
- datum
- Placering
Lön
- beslutad lön
- datum
Arbetsgivarintyg
informationsmodell
Informationsmodell beskriver
struktur, namnsättning,
förhållanden.
11
Informationskategori Personal
Prima
eArkiv Personal
tabell Person
personnamn
Bo, Ek
Elsa, Beskow
Heroma
tabell
Personuppgifter
eNamn
Varg
Testsson
fNamn
Kajsa
Test
Pld
table employee
surname
Ahola
Atterling
firstname
Tero
Christer
tabell
ArkivTypPersonal
efternamn
fornamn
Ek
Bo
Beskow
Elsa
Systemnamn
Prima
Varg
Kajsa
Testsson
Test
Systemnamn
Heroma
Ahola
Tero
Atterling
Christer
Systemnamn
Pld
12
Informationskategori
ex personaladministrativa
verksamhetssystem
prima
eArkiv databas
ekonomi
heroma
personal
Hälso- och sjukvård
Avtal
pld
FTV
Sökning efter arkiverad information från olika personaladministrativa
system sker från en och samma sökklient.
13
Informationskategori – mer i detalj
ex personaladministrativa
verksamhetssystem
prima
Exportskript
Exportskript
eArkiv databas
ekonomi
ekonomi
Leverans
Leverans ii xmlpaket
xmlpaket
Personal
Personal
ekonomi
heroma
personal
Hälso- och sjukvård
pld
Avtal
FTV
H&S
H&S
Avtal
Avtal
FTV
FTV
* Generell databas, samma tabeller oavsett informationskategori
* Samma stored procedures oavsett informationskategori
* Skräddarsydda adaptrar/klienter efter informationskategorier (ca 120h)
14
Sökning av information
eArkivering av information (importer)
15
Importer mer i detalj - HoS
verksamhetsdatabas
zippar
Leveransspecifikation
HoS
eArkiv databas
importprogram
Konvertering av binära filer till
arkivbeständigt format
(pdf/a, tiff, jpeg)
16
HoS – webbklient för sökning
17
Personal – webbklient för sökning
18
Avtal – webbklient för sökning
19
webb – webbklient för sökning
20
Egenutvecklad
•
•
•
•
RS eArkiv består av följande delar;
Klient (två webbservrar, Tomcat 7.0)
Adapter (två adapterservrar Jboss 5.1)
Databas (Sql server 2008 R2)
•
Grundidén är att RS eArkiv skall kunna hantera all typ av information. Databasen är därför generisk medan det finns
(kommer finnas) klienter för följande typer; Personal, Hälso- och sjukvård (journaler), Folktandvård, Avtal, Personal,
Obstetrik, Ekonomi samt ”web”.
•
•
•
•
•
•
•
•
•
Tekniker/språk som RS eArkiv använder sig av är utvecklat i Java 1.6, javascript, jsp, vaadin (Google web Toolkit) ,
SSIS, zircon ramverk och stored procedures.
Version 1.0 SLL stockholm (september 2011),
version 1.1
Version 1.2
Version 1.3
Version 1.4
Version 1.5
Version 1.6
21
Egenutvecklad
22
eArkivet - Varför egenutv?
•
•
•
•
•
•
•
•
Varför eget:
Standardsystemen var inte anpassade efter RS behov
Krav på en generisk lösning oavsett vad det är för digital information som ska lagras.
eArkivlösning fanns redan – SLL (samarbetsavtal, utbyte av kod)
Krav på öppen källkod.
Leverantörsoberoende
Långsiktighet – system för långtidslagring
Omöjligt från start veta alla verksamhetskrav (vad man behöver för lösning )
•
Konsekvenser:
•
Oberoende, vi kan köpa in konsulter.
- Om man har ett standardssystem, vad sker om leverantören försvinner ur marknaden?
Systemet kan skräddarsys efter det som verksamheten verkligen behöver (mellanarkiv/slutarkiv,
informationskategorier), alla krav kan uppfyllas!
Kontroll över teknik och källkod (återanvända kod till nya infokategorier),
Vi kan själva vidareutveckla systemet (nya informationskategorier), till en rimlig kostnad (snabb utveckling av nya
infokategorier).
Det är möjligt att anpassa systemet efter ny teknik
Anpassa lösning efter behov inte efter produktens begränsningar/funktionalitet.
Flexibelt system
Verksamheten mer involverad i lösning, vad de vill ha (engagemang)
Kunskapen stannar ”innanför” huset,
- De flesta utvecklare av standardsystem är fysiskt och organisatoriskt separerade från systemanvändarna
•
•
•
•
•
•
•
•
23
Sammanfattning
• Egenutvecklad
• Datat lagrat efter informationskategorier
• Klient för sökning efter
informationskategorier – ej system
• Mellanarkiv, slutarkiv
• Vi styr själva över systemets funktionalitet.
• Resurser/kompetens
• Alla krav kan uppfyllas
24
Frågor?
[email protected]
25