Stream: Sweden on FHIR
Topic: Patient
Elisabeth Adelgren (Nov 23 2018 at 11:59):
Hej,
Blev tipsad om att detta forum är uppe och snurrar igen efter gårdagens diskussioner om nationell profilering i Sverige så jag tänkte ta tillfället i akt att försöka med en virtuell diskussion kring Patient-profilen.
Vi har nyligen påbörjat diskussioner och PoC-ande på ehm och jag har därför gjort ett allra första utkast till Patient (se länk nedan)
https://simplifier.net/thefirstproject/swedish-patient
Det skulle vara intressant att höra era åsikter kring följande
- Öppen vs sluten profil (dvs tillåta en hög grad av element även om de ej används i Sverige alternativt begränsa element). I profilen ovan är den första strategin applicerad
- Mellannamn, verkar vara något som är på väg att fasas ut - vad jag förstår efter era diskussioner. Ska vi ändå göra en extension för mellannamn eller rekommendera att man lägger flera efternamn i family name?
- uri vs oid, vet vi om någon giltig uri är på gång från ex Skatteverket?
Viktor Jernelöv (Nov 23 2018 at 13:50):
Spännande! @Martin Grundberg sammanställde resultatet av våra diskussioner igår där åtminstone de två sista punkterna berördes. Den vore kul att se om Cambio kan jämföra det resultatet med eHMs utkast.
Angående den första frågan tänker åtminstone jag mig att det nog finns en poäng i att spegla modellen med "två nivåer" av profiler som använts i Holland, Tyskland, USA och Norge(?). Där är grundtanken att "basnivån" är så öppen som bara möjligt, men där man tar med specifika krav som man vet kommer vara aktuella för samtliga informationsutbyten inom landet. I vårt fall är det att ge möjlighet till personnummer, samordningsnummer, nationellt reservnummer samt lokala identitetstyper.
Drömmen vore om vi kunde enas kring vilka kriterierna för inkludering i en basprofil är så att vi får någon form av metamodell över våra profiler. Vi ser även att vi skulle behöva ta fram ett gäng nationella extensions och terminologiska resurser (CodeSystems och ValueSets) som är så pass centrala och gemensamma att man vill säkerställa att alla ska/kan göra på samma sätt.
Jag ser framför mig att vi kommer tvingas hantera många av de här frågorna allt eftersom vi jobbar vidare.
Viktor Jernelöv (Nov 23 2018 at 14:01):
@Elisabeth Adelgren Lite mer direkt återkoppling på ert Patient-utkast:
Jag antar att ni vill modellera patienten utifrån kraven inom kontexten NLL på API-nivån? Diskussionen vi hade igår handlade mer om en "allmän" basprofilsnivå, som du i det tänkta scenariot skulle agera basprofil för den profil ni tar fram för ert användningsfall.
Har ni baserat den på R4-builden eller STU3? Som jag tolkar profilen idag kan man ha flera personnummer och samordningsnummer samtidigt. Är det så ni vill ha det? Om vi arbetar utifrån tanken att profilen på något sätt blir en kravställan på informationsbehovet som en resurs ska kunna valideras mot skulle en stängd profil vara mer ändamålsenlig, även om det såklart får konsekvenser när man göra ändringar. @Emmeli Gross pratade igår om möjligheten att som konsument av resurserna helt enkelt kasta bort det man inte är intresserad av om man har en öppen profil. Jag är villig att erkänna att jag vet för lite om FHIRs tänkt kring detta och vilka verktyg man har för att indikera vilka element man inte kan hantera annat än genom att stryka dem i profileringssteget. Det känns som en fråga att gräva vidare i.
Snyggt också att ni lagt in regex på postnumret. Finns det motsvarande för patientidentiteterna man kan lägga in?
Elisabeth Adelgren (Nov 26 2018 at 07:31):
forge (profileringsverktyget) baseras på R3 till R4 är officiell, i och med det så bygger draftprofilen på R3. Dock är det få förändringar i R4 på Patient och inte på några av de delar som jag profilerat (ändrat)så det är ännu inget problem eftersom profilen visar differentialen.
Angående flera personnummer och samordningsnummer så är det möjligt för en person att ha flera historiska person/samordningsnummer. Exempelvis om personen först haft ett samordningsnummer, sedan får ett personnummer (de kommer då har olika validity/giltighetsperioder). Alternativt könsbyte el dyl då man också byter personnummer.
Gällande öppen/sluten profil tror jag vi behöver diskutera en del vidare.
Min personliga åsikt är att en öppen profil underlättar integrationer då färre anpassningar behöver göras. Eftersom en av grundtankarna med FHIR är enkla integrationer borde detta stämma väl överens med dessa principer. Med en öppen profil kommer klienten enbart skicka de element som krävs för givet fall (i och med att kardinaliteten är 0..* är det fullt möjligt att skippa fält) och servern kommer på sin sida bara konsumera de element som krävs för givet fall. Jag inser att det finns fler åsikter kring detta och ser fram emot en intressant debatt :-)
Viktor Jernelöv (Nov 26 2018 at 08:35):
Din poäng gällande öppen profil är tydlig och har helt klart sina meriter. Tänker ni er alltså att ni genererar upp APIet utifrån profilen då? Jag har begränsad erfarenhet av implementation av en FHIR-server (och ingen erfarenhet av implementation av FHIR-konsument), men det vi gjorde då var att använda HAPI-biblioteket för att agera fasad mot yttervärlden och sen plugga in våra interna strukturer mot HAPI-fronten. Profilerna användes mer för att vid anropet ange vilken specifik information konsumenten var intresserad av så att producenten kan säkerställa att den returnerar den information som efterfrågas. Det kan även användas av en konsument för att verifiera att ett meddelande faktiskt var korrekt, motsvarande vad en XSD-kontroll kan göra för en XML-payload. Med en valideringsserver på plats skulle den ansatsen erbjuda möjlighet till den typen av flexibilitet i APIet som jag uppfattar att du efterfrågar, även om det givetvis än så länge är en konceptuell whiteboardlösning som inte testats.
Ett syfte med profilering som man missar med öppen ansats är behovet av att kunna peka specifikt på vilken information som behövs för att stödja ett specifikt användningsfall. På Inera jobbar vi ju en hel del med våra informationsspecifikationer och tjänstekontraktsbeskrivningar, där just detta är en väldigt stor del av innehållet. Att kunna nyttja FHIR-profiler för att tydligt speca de krav som föreligger i en viss interaktion mellan systemen vore att föredra framför att behöva hantera den dokumentationen vid sidan om.
I ovan nämnda informationsspecifikationer (IS) och tjänstekontraktsbeskrivningar (TKBer) definieras dels hela domänens informationsmodell (DIM) upp för att sen smalnas av i specifika meddelandeinformationsmodeller (MIM). Tolkar jag dig rätt i att du tänker dig att de öppna profilerna ligger på DIM-nivån?
Björn Genfors (Nov 26 2018 at 08:40):
Angående flera personnummer och samordningsnummer så är det möjligt för en person att ha flera historiska person/samordningsnummer. [...] Alternativt könsbyte el dyl då man också byter personnummer.
Hej Elisabeth.
Utan att ha hunnit titta på det arbete du har gjort tänkte jag slänga mig huvudstupa in med ett par frågor kring de juridiska aspekterna kring personnummerbyte. Vis av erfarenhet: eftersom skriven text kan läsas på olika sätt vill jag betona att jag frågar av ren nyfikenhet.
1. Är tanken att man, efter personnummerbyte, fortsatt ska kunna hämta ut läkemedel på de fortfarande giltiga recept som är utskrivna till det gamla personnumret? Hur ska detta ske, rent praktiskt? Legitimationen borde ju rimligtvis också ha hunnit bytas ut. Är det just via Patient-resursen detta ska kunna skötas? Och hur ser det här ut på ett legalt plan? I någon mån är det förstås samma person som står framför apotekaren både före och efter köns- och identitetsbyte, men i någon mån är det en helt ny person.
2. Man skulle kunna argumentera för att frågan om könsbyte skulle kunna anses vara en extra känslig uppgift (även relativt mycket annan hälsorelaterad information). Är det juridiskt rimligt att information om historiskt könsbyte ska lagras hos EHM? Att det vore smidigt kan vi kanske vara överens om, men står den ökade smidigheten i proportion till det ökade integritetsintrånget?
Elisabeth Adelgren (Nov 26 2018 at 12:51):
@Björn Genfors
Hej Björn!
Jag vill börja med att förtydliga att jag inte är jurist och jag främst tittar på vilka informationsmängder som troligen behövs, inte bara av EHM då detta är en nationell profil, utan även av andra myndigheter eller aktörer. Jag vill också understryka att även om informationen potentiellt kan finnas tillgänglig innebär det inte att i praktiken alla användningsfall är tillåtna och jag håller med om att det kommer behövas en legal genomsyn på informationen efter ett utkast kommit på plats.
Precis som du nämner behöver patienten i de flesta fall (finns undantag) ha en giltig legitimation tillgänglig för att kunna hämta ut läkemedel. Men det finns andra användningsfall där t ex vi på EHM behöver tillgång till recept som potentiellt skrivits ut (och hämtats ut) på gammalt id-nummer. Ett exempel på det är vår EES-analys som behöver ta höjd för läkemedel som patienten kan ha hemma och hämtat ut sedan tidigare och detta behöver vägas in i analys för att upptäcka ex hög dos, dubbelmedicinering etc. I dessa fall behöver vi hitta recept på nuvarande samt ev tidigare id-nummer (efter samtycke av patient) eftersom den som konsumerar läkemedlen är densamma.
Jag vill också understryka att information om ev historiskt id-nummer endast är intressant för att göra den typ av tekniska länkningar som ovan, inte för att lagra någon anledning till varför byte gjorts. Vad som också bör förtydligas är att respektive aktör som håller patientinformation såklart måste följa gängse regler kring personuppgifter, gallring, samtycken etc.
Viktor Jernelöv (Nov 26 2018 at 12:56):
Ett inspel: HL7 själva jobbar på en Implementation Guide som beskriver hur informationen som specificerats i utkastet till CEN-standarden för en International Patient Summary representeras i FHIR: https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Patient-uv-ips.html
De har jobbat mycket med "mustSupport"-flaggan på sina element och inte nyttjat multiplicitetsinskränkningar.
Elisabeth Adelgren (Nov 26 2018 at 13:03):
Din poäng gällande öppen profil är tydlig och har helt klart sina meriter. Tänker ni er alltså att ni genererar upp APIet utifrån profilen då? Jag har begränsad erfarenhet av implementation av en FHIR-server (och ingen erfarenhet av implementation av FHIR-konsument), men det vi gjorde då var att använda HAPI-biblioteket för att agera fasad mot yttervärlden och sen plugga in våra interna strukturer mot HAPI-fronten. Profilerna användes mer för att vid anropet ange vilken specifik information konsumenten var intresserad av så att producenten kan säkerställa att den returnerar den information som efterfrågas. Det kan även användas av en konsument för att verifiera att ett meddelande faktiskt var korrekt, motsvarande vad en XSD-kontroll kan göra för en XML-payload. Med en valideringsserver på plats skulle den ansatsen erbjuda möjlighet till den typen av flexibilitet i APIet som jag uppfattar att du efterfrågar, även om det givetvis än så länge är en konceptuell whiteboardlösning som inte testats.
Ett syfte med profilering som man missar med öppen ansats är behovet av att kunna peka specifikt på vilken information som behövs för att stödja ett specifikt användningsfall. På Inera jobbar vi ju en hel del med våra informationsspecifikationer och tjänstekontraktsbeskrivningar, där just detta är en väldigt stor del av innehållet. Att kunna nyttja FHIR-profiler för att tydligt speca de krav som föreligger i en viss interaktion mellan systemen vore att föredra framför att behöva hantera den dokumentationen vid sidan om.
I ovan nämnda informationsspecifikationer (IS) och tjänstekontraktsbeskrivningar (TKBer) definieras dels hela domänens informationsmodell (DIM) upp för att sen smalnas av i specifika meddelandeinformationsmodeller (MIM). Tolkar jag dig rätt i att du tänker dig att de öppna profilerna ligger på DIM-nivån?
Precis som du säger är ansatsen en nationell profil som passar en mängd användningsfall. Med en stor grad begränsningar kommer vi missa användningsfall som vi idag inte ser existerar. Men generellt är det också något vi bör förhålla oss till, då det finns andra konsekvenser. Vid en hög grad av begränsningar måste vi troligen stega vår profil med varje release av FHIR, för att plocka bort tillägg av element som gjorts i den övergripande FHIR-profilen. Integrationen för ex systemleverantörer som finns på många marknader kan bli större om de redan har stöd för den resurs som FHIR publicerar men måste göra många anpassningar till vår begränsade profil. Men som sagt, detta är något vi bör diskutera i stort, inte enbart kring Patient-resursen.
Jag håller med om att profilen är en form av kontraktsbeskrivning men den saknar regler kring kombinationer, giltiga användningsfall etc vilket gör att den som publicerar en profil behöver komplettera med en IG el liknande (+ compatibility statement), så jag anser att kombinationen utgör tjänstekontrakt.
Viktor Jernelöv (Nov 27 2018 at 09:15):
Jag vill börja med att precis som Björn gjorde betona att jag ställer frågor och argumenterar ur rent intresse och inte för att vara bråkig, väl medveten om att text kan läsas på olika sätt. Med det sagt, så:
"Precis som du säger är ansatsen en nationell profil som passar en mängd användningsfall. Med en stor grad begränsningar kommer vi missa användningsfall som vi idag inte ser existerar."
- Jag köper det påståendet om profilen är synonymt med APIets förmåga att hantera information. För mig är det dock inte riktigt samma sak. En profil är snarare en beskrivning av vilken av all infromation som APIet kan hantera som är efterfrågat/kan hanteras i ett specifikt användningsfall. Det är alltså ingen motsättning mellan att ha en förmåga i APIet som beskrivs i ett CapabilityStatement och snäva profiler som är byggda ovanpå en öppen basprofil, vilka visar vilken information som efterfrågas för specifika användningsfall, som t.ex. när du ska hämta förskrivningar.
"Vid en hög grad av begränsningar måste vi troligen stega vår profil med varje release av FHIR, för att plocka bort tillägg av element som gjorts i den övergripande FHIR-profilen."
- Har ni några krav på er att alltid använda den senaste releasen? I och med att R4 släpps blir ju standarden normativ och anledningen att lyfta till en senare version skulle i såna fall enbart grundas i att ny funktionalitet tillkommit som man vill använda. Se gamla HL7 v2-standarden där det finns väldigt många olika välfungerande integrationer på plats i världen som inte är nyttjar den senaste versionen av standarden. Sen tror jag att profileringsdelen i ett versionslyft är en väldigt liten del av arbetet, men här killgissar jag bara.
"Integrationen för ex systemleverantörer som finns på många marknader kan bli större om de redan har stöd för den resurs som FHIR publicerar men måste göra många anpassningar till vår begränsade profil".
- Det här låter snarare som ett argument mot användandet av extensions? Profiler agerar i min värld snarare som en sorts filter som man använder för att sålla bort information man KAN producera till att bara innefatta det som faktiskt behövs. Extensions kommer man ju bara ha när det finns behov av att representera verksamhetsinformation i en kontext som inte grundresurserna hanterar. Se http://hl7.org/fhir/extensibility.html#2.5.0 för att se vad HL7 själva säger om användandet av extensions. Att "ha stöd för en resurs" betyder ju i sig väldigt lite eftersom resurserna utan profilering har väldigt få tvingande element alls.
"Jag håller med om att profilen är en form av kontraktsbeskrivning men den saknar regler för kombinationer, giltiga användningsfall etc vilket gör att den som publicerar en profil behöver komplettera med en IG el liknande (+ compatibility statement), så jag anser att kombinationen utgör tjänstekontrakt."
-Jag håller med dig. Enbart profiler täcker inte upp för behoven, långt därifrån. Att hitta en gemensam struktur på nationella IGs och "profileringspaket" i ordets bredare bemärkelse torde vara något att sträva efter för oss inom eHälsosfären i min mening.
Oskar Thunman (Nov 27 2018 at 21:21):
Hej alla!
Jag hde tyvärr inte möjligheten att vara med på profileringsdagen. Jag sitter och klurar på hur man kan skikta upp profilerandet så man inte blandar äpplen och päron.
Jag skulle säga att vi i Sverige kommer ha tre huvudtyper av profiler
1. Nationella anpassningar av FHIR (grundprofiler), huvuddelen av detta arbete går ut på att en gång för alla lösa t ex personnummer och peka ut rekommenderad terminologibindning där vi har nationella kodverk vi brukar använda.
2. Användningsfalls-specifika implementationsguider och profiler (informationsförsörjning i samverkan) för dessa "tjänster" kan man jobba i projektform, men man måste hitta varandra och harmonisera mellan projekten så att vi inte får en profil per projekt. Vill man lyfta NPÖ till FHIR är det här man gör det. Vill man utforska nya användningsfall pusslar man med befintliga resurser och utökar eller avgränsar dem vid behov.
3. Grunddata och nationell infrastruktur
Här har vi användningsfall runt ett nationellt register eller infrastrukturkomponent, dvs det är ingen kompromiss/samverkan mellan många producenter, utan det finns ett system som är facit. Här är masterdata-tänk viktigare, eftersom resurser härstammar från, och/eller ska återföras till ett specifikt system. Då ska samma resurs leva genom flera användningsfall.
Oskar Thunman (Nov 27 2018 at 21:48):
1 funkar då med löst hängande profiler
2 är då profiler som ramas in i en kontext av en implementationsguide som beskriver en eller ett par användningsfall.
3 är då profiler vars implementationsguide måste gå till botten med flöde/process, tillståndsdiagram mm
Oskar Thunman (Nov 27 2018 at 21:55):
När man gör en "3" kan jag tycka att man samtidigt borde bygga upp en "domänmodell" i form av en 2, där man samlar fler närliggande användningsfall och där 2 är fokuserat på harmonisering och att återföra till FHIR medan 3 bara uttrycker sin interna logik i form av FHIR.
Viktor Jernelöv (Nov 28 2018 at 08:16):
Vet du hur den modellen speglar andra länders ansatser @Oskar Thunman ?
Oskar Thunman (Nov 28 2018 at 09:25):
@Viktor Jernelöv Att ta fram 1:an är kanske inte så konstig ambition, där har du t ex https://www.hl7.no/index.php/standarder/hl7-fhir-norsk eller https://hl7.at/technische-komitees/tc-fhir/
För 2 handlar bygger det dels på hur amerikanska projekt jobbat mot fhir. Både arbetet i IHE och kopplat till Argonaut och nationella projekt handlar om att utforska nya användningsfall i projektform och ta fram en lagom generisk implementationsguide , t ex https://github.com/HL7/FHIR-ONC-Meds/wiki/Use-Cases
När jag varit på HL7-möten brukar det vara ett pilotprojekt bakom dessa initiativ, som ska implementera profilerna för ett specifikt system, eller för utbyte inom en specifik organisation.
För 3 har du t ex finska hälsokontot: https://simplifier.net/FinnishPHR och flertalet leverantörer som kör FHIR hos Infoway i Kanada, t ex https://simplifier.net/guide/OntarioLaboratoriesInformationSystemConsumerQuery/Home.
Att skilja mellan 2 och 3 är samma tanke som Inera har kring sina tjänster, vissa är tjänster för informationsförsörjning andra är infrastrukturkomponenter. Eller IHE som har dels profilen, dels implementationen inom en Affinity Domain. Om man gör ett nytag borde man se till att IG för informationsförsörjning har stöd för regionala utökningar och avgränsningar och att IG för informationsförsörjning tittar på informationens hela livscykel, tänk t ex HSA, om man hade profiler för olika kanalers behov av information vid vidareutnyttjande.
Martin Grundberg (Nov 28 2018 at 09:54):
Här kommer en liten sammanfattning av mina anteckningar från workshopen i torsdags kring profilering a Patient-resursen.
Vi gick ju igenom elementen, och här är några kommentarer. Element där det inte finns några kommenterar hann vi antingen inte gå igenom, eller så ansåg vi inte att det borde vara några skillnader mot basresursen.
Generella saker...
Basprofiler
Vi diskuterade att en sådan bör vara väldigt generell och tillåtande. Det är några grundläggande process/governance-frågor som behöver besvaras:
1. Vad avgör om en extension ska läggas till i en basprofil?
2. Vad får det för följdverkningar om en basprofil ändras?
3. Hur många nivåer av nationella basprofiler bör finnas? Räcker det med en?
Extensions
Det är väldigt viktigt att extensions definieras centralt och återanvänds. Det kanske tom är viktigare att prioritera governance kring Extensions framför profiler eftersom extensions är byggklossarna som används i olika profiler, och som kommer hjälpa/stjälpa interoperabilitet.
4. Vad är processen för att skapa en ”nationell extension”?
5. Vad händer om vi återanvänder någon annans extension? T.ex. en utländsk extension
Value sets
En generell kommentar vara att man inte bör stryka värden i value sets i en basprofil även om vi inte tror att de är applicerbara i Sverige.
6. Vi bör bekräfta ovanstående kommentar, och i så fall göra det till en generell profileringsprincip
Allt nedan gäller i en generell svensk basprofil
Identifier
Att utreda/besvara
7. Ska vi tillåta att samma patient kan ha flera instanser av samma identifierartyp? Patienter kan ju byta personnummer, så kanske behöver kunna vara 0..*. Betyder det att vi har samma krav på de andra typerna?
8. Prioritet eller nu gällande identifierare kanske är för konsumerande system att identifiera mha affärslogik, dvs man kommunicerar patientens identifierare, och då är det upp till konsumtenen att visa upp/använda t.ex. personnummer
Name
Att utreda/besvara
9. Det har nyligen gjorts ändringar i hur man hanterar mellannamn/efternamn. Här bör vi kolla med Skatteverket hur ett svenskt namn hanteras
10. Hur hanterar vi ordningen på namn? Vi kanske även behöver hantera ordning på efternamn/mellannamn.
11. Hur ska vi peka ut tilltalsnamn? Verkar finnas en extension som nyttjas i Holländska profilen, kanske kan återanvändas?
Gender
Här menar vi det vi ibland kallar juridiskt kön eller administrativt kön.
12. Ska man ha 0..1?
13. Hur hanterar man detta i relation till Personnummer? I Sverige så definierar Personnummer det administrativa könet. Vad har vi för beroenden mellan dessa element? T.ex. om vi säger att en patient kan ha 0..* personnummer, behöver vi då ha 0..* Gender (och med datum för Gender-perioder?)?
Gender identity
Att utreda/besvara
14. Ska vi använda standard extension genderIdentity? (http://hl7.org/fhir/StructureDefinition/patient-genderIdentity)?
Sekretessflagga – Behov av nationell Extension
Att utreda/besvara
15. Det låter som att vi behöver en nationell extension för sekretessflaggan som kan sättas av skatteverket, hur går vi vidare med det?
Address
Att utreda/besvara
16. Hur ser en svensk adress ut? Kolla med Skatteverket?
Deceased
Att utreda/besvara
17. Vi lägger inte in i profilen vilken datatyp som ska användas, utan basprofilen bör hantera båda. Är detta rätt approach? I så fall är det en generell princip, man profilerar aldrig vilken datatyp som ska användas?
Contact
Att utreda/besvara
18. Hur ska vi hantera uppdelning av relationstyp och roll? T.ex. kan man vara förälder och vårdnadshavare, respektive förälder och inte vårdnadshavare. Hur får vi in God man?
Det bör även diskuteras och överenskommas i grupp huruvida ordvitsar med FHIR ska förbjudas nationellt :)
Martin Grundberg (Nov 28 2018 at 09:57):
Sen har jag ett allmänt förslag här (utöver att förbjuda FHIR-ordvitsar), det här är en Patient-tråd, kan vi hålla diskussion kring konkreta frågeställningar för just Patient här? Vidare diskussioner kring generella profileringsprinciper, processfrågor kring extensions osv kanske vi kan hantera i separat tråd? Annars kommer det bli knepigt att hålla en konstruktiv dialog här om just Patient. Synpunkter?
Viktor Jernelöv (Nov 28 2018 at 11:43):
Bra idé att hålla trådarna rena Martin, jag får ta på mig skulden!
Elisabeth Adelgren (Nov 30 2018 at 08:16):
Har haft fullt upp och frånvarande här i forumet i några dagar, kul att se att diskussionen lever vidare!
Några kommentarer kring det som sagts här ovan.
Relaterat till flera nivåer av profiler som bl a @Oskar Thunman nämner är mycket intressant men jag tror det är viktigt att säkra de vanligaste grundprofilerna först och hitta en samsyn kring det. Det kan vara nog utmanande, inte minst ser vi i de här trådarna att vi har lite olika tankar och infallsvinklar :-D
Angående utkomsten från workshopen, @Martin Grundberg många intressanta frågor, kom ni överens om hur ni går vidare t ex vem som gör respektive utredning och har det beslutats om något uppföljningsmöte? Någonstans skulle vi ju vilka iterera fram en svensk patient utifrån dessa punkter och få en samsyn och konkret förslag kring respektive element, finns någon tanke kring hur det arbetet skulle kunna framskrida?
Oskar Thunman (Nov 30 2018 at 08:26):
Hej @Elisabeth Adelgren Min tanke med att börja skissa på kartan över olika tillämpningar av profilering var främst att skapa bättre förutsättningar för arbetet med grundprofiler. Jag håller med om att vi inte ska bita av för mycket här, men det vore bra med en "nyckel" för att förstå vilka utmaningar som ska lösas med respektive sorts profil.
Jag håller med om att grundprofilerna är en bra första ansats på nationell nivå.
Det jag tycker är viktigt i det arbetet är att den som sitter och tar fram en tillämpning för ett specifikt system förstår att vissa frågor kan tas tillbaka till grundprofilen , medan andra utmaningar är domänspecifka och/eller användsningsfalls-specifika och därför mer sällan borde påverka grundprofilen.
Martin Grundberg (Nov 30 2018 at 09:02):
@Elisabeth Adelgren , jag bollade lite löst med @Viktor Jernelöv igår om att ha en till workshop kring Patient.
Vi har inte assignat några formella actions utifrån punkterna i mitt tidigare inlägg, men alla kan ju fundera lite till nästa workshop. Jag håller helt med dig om approachen att iterera fram en patientprofil. Vi kan ju dela ut saker för utredning efter nästa tillfälle.
Hinner vi en workshop innan jul? Vi kan vara här hos oss, men trevligt att få besöka er andra också :)
Martin Grundberg (Aug 01 2019 at 07:56):
Jag har tittat lite mer på mellannamn, och tycker vi ska ha en extension för det. Norge har gjort likadant, men de har gjort en egen extension. Tills vidare får vi kanske göra det också, men jag lägger en CR för att det ska skapas en standard extension för mellannamn (för use case där mellannamn är ett efternamn som i Sverige, och som det verkar också som det är i andra nordiska länder).
Se diskussion här:
https://chat.fhir.org/#narrow/stream/194447-nordics/topic/Middle.20Name
Last updated: Apr 12 2022 at 19:14 UTC
