Nu har vi prövat den svenska PDL-implementationsguiden ett tag. Jag har börjat klura på alternativa metoder för att representera PDL/SVOD-styrande attribut i openEHR-conpositions utan att belasta mallarna med extre arketyper/embedded templates i other_context (det krånglar till template-hantering).
Spår A: health_care_facility gör dessutom filtermekanismer mer effektiva att implementera (filtrering körs vid varje anrop, alltså väldigt ofta och vi har sett att det påverkar prestanda). Det faktum att pahen kan vara olika (olika at-koder) i other_context för olika templates gär algoritmer större och långsammare.
För att minska komplexiteten i openEHR-mallar och undvika extra arketyper för Vårdgivare och Vårdenhet, föreslås nedan två alternativa spår som båda utnyttjar delar av openEHR:s Referensmodell (RM) som inte behöver extra arketyper. Båda spåren uppfyller kraven i svensk PDL.
Byggstenar användbara i båda spåren
1. openEHR-klasser
2. Formatering och tvätt av kliniknamn
För att kunna presentera hela hierarkin snyggt i ett UI tillämpar vi en strukturerad namnsträng där den mest fingranulära nivån står först: [Underenhet] – [Vårdenhet] | [Vårdgivare]. Detta kommer runt begränsningen att openEHRs PARTY_IDENTIFIED som används i health_care_facility bara kan ha ett enda namn (men flera identifierare)
- Avgränsare: Vi använder
–(mellanslag, tankstreck, mellanslag) och|(mellanslag, pipe, mellanslag). - Tvättregel: Existerande
|i ursprungsnamn ersätts med/och existerande–ersätts med-innan strängen slås ihop. - Dubblettregel: Om Underenhet och Vårdenhet är desamma skrivs namnet bara en gång.
3. Maskinella identifierare via URI (Sambi/FHIR-mönster)
Vi använde i några av exemplen för RM-datatypen DV_IDENTIFIERen URI i fältet issuer. Fältet type kan då användas för en mänskligt läsbar sträng (t.ex. “HSA-ID”). Man skulle förstås kunna använda type för URIn istället för issuer
Ett förslag (som ni gärna får hitta potentiellt bättre alterantiv till) är att haka på ett URI-fragment på ehälsomyndighetens mänskligt läsbara hsa-id-URI, t.ex. så här:
- Underenhet:
http://electronichealth.se/identifier/hsa-id#sub-unit(finns ofta om vårdenheterna är stora, t.ex. massor på Karolinskas Cancercentrum) - Vårdenhet (HSA):
http://electronichealth.se/identifier/hsa-id#careunit(den lägsta nivå PDL byr sig om) - Vårdgivare (HSA):
http://electronichealth.se/identifier/hsa-id#careprovider - Vårdgivare (Org.nr):
http://electronichealth.se/identifier/org-nr
Någon från eHM får gärna uttala sig om sådana påhitt eller om ni kanske planerar andra URIer för att peka ut sådant. (Ping @Daniel_Karlsson med kollegor.) Vore bra att synka lite med svenskt FHIR-arbete också. (Ping @claudiaehr m.fl.)
Spår A: Attribut i health_care_facility
I detta spår lagras all organisatorisk kontext i ett och samma RM-attribut: COMPOSITION.context.health_care_facility (av typen PARTY_IDENTIFIED). Eftersom denna klass endast har ett fält för namn, lägger vi hela den hierarkiska namnsträngen där, och samlar alla identifierare som separata poster i listan.
A1: JSON-instans (utdrag) med type som skiljemetod
Med denna metod kan man om man vill som i exemlet nedan ta med både organisationsnummer och HSA-id för vårdgivaren. I denna nmetod kan vi skippa #-fragment. Vi måste dock ha noggrann spec av strängarna vi stoppar i type
För att förkorta mer skulle man kunna skrota issuer helt nedan, men då kanske kombinationen av fält blir globalt unik. För att uppnå effektivitet/komnpression kanske vi kan tycka att det är tillräckligt unikt när det befinner sig i den kontext det gör, d.v.s. inuti en COMPOSITION från en svensk vårdgivare där det är osannolikt att någon annan i världen vill börja sina IDn med SE följt av organisationsnummer?
...
{
"context": {
"health_care_facility": {
"_type": "PARTY_IDENTIFIED",
"name": "Distriktssköterskemottagning – Brandbergens vårdcentral | Region Stockholm",
"identifiers": [
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-14LF",
"type": "sub unit HSA-ID",
"issuer": "http://electronichealth.se/identifier/hsa-id"
},
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-1003",
"type": "care unit HSA-ID",
"issuer": "http://electronichealth.se/identifier/hsa-id"
},
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-2GJS",
"type": "care provider HSA-ID",
"issuer": "http://electronichealth.se/identifier/hsa-id"
},
{
"_type": "DV_IDENTIFIER",
"id": "232100-0016",
"type": "care provider organisation number",
"issuer": "http://electronichealth.se/identifier/org-nr"
}
]
}
}
}
...
A2: JSON-instans (utdrag) med issuer som skiljemetod
Man skulle ju även i nedanstående kunan tänka sig att flytta de betydlesebärnade URI erna från “issuer” till “type” men de är inte lika tydligt mänskligt läsbara
...
{
"context": {
"health_care_facility": {
"_type": "PARTY_IDENTIFIED",
"name": "Distriktssköterskemottagning – Brandbergens vårdcentral | Region Stockholm",
"identifiers": [
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-14LF",
"type": "HSA-ID",
"issuer": "http://electronichealth.se/identifier/hsa-id#sub-unit"
},
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-1003",
"type": "HSA-ID",
"issuer": "http://electronichealth.se/identifier/hsa-id#careunit"
},
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-2GJS",
"type": "care provider HSA-ID",
"issuer": "http://electronichealth.se/identifier/hsa-id#careprovider"
},
{
"_type": "DV_IDENTIFIER",
"id": "232100-0016",
"type": "Organisationsnummer",
"issuer": "http://electronichealth.se/identifier/org-nr"
}
]
}
}
}
...
Syftet med health_care_facility passar bra till PDL/SVOD-styrande attributen:
The identification of the HCF can be used to ensure medico-legal accountability. Often, the HCF is also where the encounter physically took place, but not in the case of patient home visits, internet contacts or emergency care; the HCF should not be thought of as a physical place, but as a care delivery management unit. Länk till specifikation som citerats.
Spår B: Attribut i FEEDER_AUDIT
I detta spår utnyttjas RM-attributet COMPOSITION.feeder_audit. Detta möjliggör en semantisk separation mellan den fysiska/logiska platsen (location) och den juridiska parten (provider). Den hierarkiska namnsträngen delas logiskt upp mellan dessa fält.
I detta exempel har vi som tidgare föreslaget skrotat “type” inuti PARTY_IDENTIFIED för att effektivisera/komprimera - men skulle ju istället kunna ha med “type” och skrota “issuer”
JSON-instans (Utdrag)
...
{
"feeder_audit": {
"_type": "FEEDER_AUDIT",
"originating_system_audit": {
"_type": "FEEDER_AUDIT_DETAILS",
"system_id": "KällsystemX",
"location": {
... add physical location here if needed/wanted...
},
"provider": {
"_type": "PARTY_IDENTIFIED",
"name": "Distriktssköterskemottagning – Brandbergens vårdcentral | Region Stockholm",
"identifiers": [
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-14LF",
"issuer": "http://electronichealth.se/identifier/hsa-id#sub-unit"
},
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-1003",
"issuer": "http://electronichealth.se/identifier/hsa-id#careunit"
},
{
"_type": "DV_IDENTIFIER",
"id": "232100-0000",
"issuer": "http://electronichealth.se/identifier/org-nr"
},
{
"_type": "DV_IDENTIFIER",
"id": "SE2321000016-2GJS",
"issuer": "http://electronichealth.se/identifier/hsa-id#careprovider"
}
]
}
}
}
}
...
Båda spåren ger oss en mall-oberoende spårbarhet. Valet mellan spåren handlar primärt om var man vill lägga infoRmrationen. Feeder_audit är kanske inte helt självklar plats inuti ett original/käll-system.
Tabell med exempel från tidigare version av openEHR Sveriges PDL i openEHR som använts ovan. Kursiverade uppgifter i tabellen är påhittade.
Förhoppningsvis kan man i existerande system göra en mjuk övergång eftersom nuvarande PDL-utvärdering inte använder health_care_facility. Man kan då under en (förhoppningsvis kort) övergång ha PDL-attribut både under other_context och health_care_facility.
Tankar? Förslag?