�ݺ�ߣ

Editor's Notes

1. Största hotet mot min profession, fantastiskt!
2. Tackla behovet av rätt informaton vid rätt tillfälle genom Intraoperabilitet handlar om att få ordning på det man har i den egna organisationen och ett antal avtalspartner, visionen är certifierad interoperabilitet från leverantörer, appifiering Interoperablitet informatioen skall följa patienten. En medelstor journalsystemsinstallation kan ha upp mot 50 anslutningar mot externa system Läsa, skirva i databaser, FTP, mail till att konsumera och producera diverse SOAP-tjänster Journalsystem är ”sviter” från en levernatör där ny funktionalitet måste beställas eller upphandlas 1980-2000 sker en datorisering av vården 2001 använder hälften av alla läkare ett elektroniskt journalsystem och idag är siffran ca 99% Sedan 2004 pågår arbete med nationell infrastruktur för att få informationen att följa patienten mellan vårdgivare och över systemgränser
3. 7:an syftar på den sjunde nivån i OSI-modellen, dvs applikationsnivån, man utvecklar altså standarder för att utbyta information på applikationsnivå V2 är storsäljaren och de facto standard för utbyte mellan avdelningar på sjukhus runt om i världen. V3 var HL7:s försök att ta sig an SOA genom att lite måttfullt ta sig an att en gång för alla definiera alla tjänster och deras möjliga innehåll som behövs för att överföra information inom sjukvården.
4. Två delar, meddelandeformat, transport och infrastruktur Meddelandeformat har även ett europeiskt initiativ, OpenEHR, För transport är valet i praktiken ebXML eller eget, HL7 v3 i XML gjordes innan XML-schema fanns
5. Intraoperabilitet, intraorganisatoriskt utbyte Inte så mycket utbyte som push-flöden från system till system för en mängd användningsfall.
6. Modell/terminologi: informationskvalitén är dålig för användning av information utanför ursprungliga användningsfallet. Ej delmängder av ett kanoniskt meddelandeformat
7. endast kunnat uppnå en minsta gemensamma nämnare mellan de inblandade systemen I praktiken tog många institutioner ett exempelmeddelande och strösslade med de värden de hade i sina system och hoppades att det skulle validera mot schemat. Problemet är att man måste sätta någon i mitten som hanterar drift, avtal Vill journalsystem X tllgängliggöra en ny parameter så måste en ny version av tjänsten tas fram och alla som skall konsumera
8. Text för mänsklig läsbarhet Titel och rubrik
9. I tid och korrekt men sakna djup Korrekt och uttömmande vilket år som helst Uttömmande och i tid men på bekostnad av kvaliteén Hur kan vi göra saker snabbare?
10. Tagit det bästa från tidigare HL7-standarder, datatyper, domänmodeller,
11. REST: Små resurser, patient, vårdenhet, åtgärd, diagnos etc. Med unika identiteter för varje resurts, i en RESTful designfilosofi. Dessa resurser utgör den minsta enheten för en transaktion. Document, Flera resurser kan paketeras som ett ”dokument”, men en header som säger något om innehållet. Bakåtkompabilitet mot CDA, den dokumentbaserade standarden som är den dominerande lösningen idag, även för hantering av t ex remisser och myndighetsrapportering där mottagaren förväntar sig att få ett dokument. Message, länge ingick ATOM-formatet som en metod att prenumerera på uppgifter, men nu har man övergått till ett eget format som både stödjer puch och pull genom en notifieringsfunktion. Service, vill man så går det så klart att packetera resurser eller kluster av resurser som web services för att göra RPC:er mot dem. REST och SOAP är inte två rivaliserande metoder utan REST är en arkitektoriell stil och SOAP är ett protokoll.
12. Enkelt då många domäner redan är dokumenterade Extensions löser standardiseringens dilemma Kan vara obligatoriska för en konsument att förstå eller frivilliga Tillgängliggörs som en resurs-profil, även de som en resurs
13. Här har vi ett exempel på en icke tvingande extension (det framgår av resursens profil) Exemplet här är hur ett norskt mellannamn skulle se ut för en utvecklare som interagerar med t ex en patient-resurs. Alla konsumenter måste förstå vad name är och att det innehåller family och given, men sen kommer ett till given, Prästkulla med en extension som hänvisar till definitionen av ett MID, ett mellannamn. Förstår inte konsumenten denna extension hanteras Prästkulla som ytteliggare ett förnamn, förstår konsumenten betydelsen så kan namnet hanteras separat. En annan intressant sak att notera är hur utvecklarvänligt det är med en URL till specen av denna extension,
14. Framtiden, SMART on FHIR
15. Sätter man ihop alla dessa delar får man en öppen plattformsarkitektur Som möjliggör ett ekosystem med tunga affärssystem, journalsystem i botten och ovanpå det kan man utveckla innovativa web och mobil appar. Journalsystemen väljer att tillgängliggöra hela eller delar av sin data via ett FHIR-API Ovanpå det kan man bygga appar för kliniska specialiteter, eller tillhandahålla funktionalitet i patientportaler Med hjälp av det standardiserade API:et vet dessa appar var de hittar rätt information. Vill man veta om data finns tillgängligt tittar man i profile-resursen.
16. Den som har utvecklat en app behöver bara känna till URL-förledet till en FHIR-server. Alla resurser heter likadant och beter sig likadant. Trots att standarden inte kommer att bli oficiell förän till slutet på året så finns redan hela app-bibliotek att tilgå. Här kan jag till exempel plocka in en tillväxtkurva till min medarbetarportal, eller för mina patienter i deras patientportal
17. Slutligen kan man säga att framtiden ser ljus ut för sen semantiska interoperabiliteten men arbetet har precis bara börjat. För sveriges del gället det att hänga med för tåget går och vi har inte råd att missa att vara med.