Clinical Process – Health Condition: Description (Documentation IG) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
clinicalprocess_healthcond_ description
Tjänstekontraktsbeskrivning Version 3.0.5 2024-11-22
Innehållsförteckning
Revisionshistorik3
Referenser18
Förkortningar19
1Inledning20
1.1Svenskt namn20
1.2Beskrivning20
2Versionsinformation21
2.1Version 3.0.521
2.1.1Oförändrade tjänstekontrakt21
2.1.2Nya tjänstekontrakt21
2.1.3Förändrade tjänstekontrakt21
2.1.4Utgångna tjänstekontrakt22
2.2Version tidigare22
3Tjänstedomänens arkitektur22
3.1Flöden22
3.1.1Arbetsflöde23
3.1.2Sekvensdiagram24
3.1.3Obligatoriska kontrakt25
3.2Adressering25
3.2.1Sammanfattning av adresseringsmodell26
3.3Aggregering och engagemangsindex26
4Tjänstedomänens krav och regler26
4.1Uppdatering av engagemangsindex26
4.2Informationssäkerhet och juridik30
4.2.1Medarbetarens direktåtkomst30
4.2.2Patientens direktåtkomst30
4.2.3Generellt30
4.3Icke funktionella krav31
4.3.1SLA krav31
4.3.2Övriga krav och regler32
4.4Felhantering33
4.4.1Krav på en tjänsteproducent33
4.4.2Krav på en tjänstekonsument33
5Gemensamma informationskomponenter33
6Tjänstedomänens meddelandemodeller34
6.1MIM Journalanteckning35
6.2MIM Diagnos40
6.3MIM Uppmärksamhetsinformation43
6.4MIM Funktionsstatus48
7Tjänstekontrakt51
7.1GetCareDocumentation51
7.1.1Version51
7.1.2Gemensamma informationskomponenter51
7.1.3DocBook-format för clinicalDocuemtNoteText-fältet56
7.1.4Fältregler57
7.1.5Partiell datahämtning68
7.1.6Övriga regler68
7.1.7Logiska fel71
7.2GetDiagnosis72
7.2.1Version72
7.2.2Gemensamma informationskompontenter72
7.2.3Fältregler72
7.2.4Övriga regler78
7.2.5Logiska fel78
7.3GetAlertInformation79
7.3.1Version79
7.3.2Gemensamma informationskomponenter79
7.3.3Fältregler79
7.3.4Övriga regler94
7.3.5Logiska fel95
7.4GetFunctionalStatus96
7.4.1Version96
7.4.2Gemensamma informationskomponenter96
7.4.3Fältregler96
7.4.4Övriga regler103
7.4.5Logiska fel104
Revisionshistorik
Version
Datum
Författare
Kommentar
PA1
2012-12-03
FS, MA
Arbetsdokument: Vårddokumentation tillagd
PA2
2012-12-11
Maria Andersson
Uppdaterade tabeller efter diskussioner med Johan Eltes
PA3
2012-12-18
Maria Andersson
Lagt till kap 5. GetReferralAnswer
PA4
2012-12-20
Maria Andersson
Uppdaterat tabeller
PA5
2012-12-21
Maria Andersson
Uppdaterat tabeller efter ny struktur
PA6
2012-12-21
Maria Andersson
Uppdaterat namnen i tabellen
PA7
2012-12-21
Johan Eltes
Lagt till avsnittet Tjänstedomänens arkitektur samt redigerat avsnittet Generella regler
PA8
2013-01-07
Johan Eltes
Förbättrad kvalitén på texterna från PA7
PA9
2013-01-08
Maria Andersson
Uppdaterat tabellerna under kap 4, 5 och 6
PA10
2013-01-09
Johan Eltes
Lagt till avsnitt om engagemangsindex. Kompletterat/förtydligat avsnitten nationell användning, nationell användning och adresseringsmodell.
PA11
2013-01-14
Maria Andersson
Uppdaterat kap 5 och 6 med ny struktur.
PA12
2013-01-14
Maria Andersson
Lagt till kap 7.
PA13
2013-01-20
Johan Eltes
Uppdaterat efter beslut att hålla indexpostern på PDLenhetsnivå och använda SourceSystem för adressering.
PA14
2013-01-21
Fredrik Ström
Uppdaterat gemensamma informationskomponenter och tjänstebeskrivning
PA15
2013-01-21
Maria Andersson
Uppdaterat typerna med inledande versal. Ändrat från careRequest till Referral och från Answer till Outcome i kap 6.
PA16
2013-01-21
Maria Andersson
Ändrat kardinaliteten på referral i kap 6.
PA17
2013-01-24
Maria Andersson
Ändrat i tabellerna i kap 4, 5 och 6.
PA18
2013-01-25
Maria Andersson
Ändrat i tabellerna i kap 4, 5 och 6.
PA19
2013-01-29
Maria Andersson
Ändrat beskrivningar i kap 4, 5 och 6 samt ny struktur i kap 4.
PA20
2013-01-30
Fredrik Ström
Magnus Ekstrand
Ändrat beskrivningar kap 4, 5.4 och 6.4.
Nya och uppdaterade typer kap 4, 5.4 och 6.4.
PA21
2013-01-31
Maria Andersson
Ändringar i beskrivningar kap 4, 5, 6 och 7.
PA22
2013-01-31
Maria Andersson
Ändringar i kap 7, GetCareContact
PA23
2013-02-07
Magnus Ekstrand
Justeringar av elementnamn och kardinalitet i kap 5, 6 och 7.
Tog bort ej använd gemensam komponent.
PA24
2013-02-11
Maria Andersson de Vicente
Lagt till kap 8, GetDiagnosis
PA25
2013-02-19
Johan Eltes
Definierat krav på uppdatering av fältet mostRecentContent i EI-posten.
PA26
2013-03-01
Maria Andersson de Vicente
Lagt in beskrivning av personidentifierare under kap 3.
PA27
2013-03-04
Maria Andersson de Vicente
Uppdaterat till careContactUnitid, careContactUnitName, careContactUnitAddress under 7.4. Uppdaterat beskrivningen av Author under 5.4, 6.4, 7.4 och 8.4. Ändrat Adress till Postadress i hela dokumentet.
PA28
2013-03-04
Maria Andersson de Vicente
Ändrat kardinalitet på CareContactUnit till 1..1 under 7.4. Lagt till authorOrgUnitHSAid och authorOrgUnitName. Ändrat kardinalitet på legalAuthenticatorHSAid till 0..1. Tagit bort information om signatur under 7.4. Lagt till sourceSystem.
PA29
2013-03-05
Johan Eltes
Lagt till nya sökparametrar för source system och care contact id. Lagt till authorOrgUnitAddress och tagit bort careUnitName.
Förtydligat skrivning om aggregerande tjänster samt lagt till scenariobeskrivning för sökning på careContactId
Överfört i ny tjänstedomän enligt anvisning från CeHis.
PA30
2013-03-11
Johan Eltes
Specificerat kodverk för EI-postens Categorization-fält.
SLA-krav uppdaterade
PA31
2013-03-14
Maria Andersson de Vicente
Ändrat beskrivningen av DocumentTime
PA32
2013-03-14
Johan Eltes
Preciserat lexikaliskt format för personnummer.
Lagt till stöd för gamla dokumenttyper för att under en övergångsperiod underlätta för bef. NPÖ-anslutningar.
PA33
2013-03-25
Fredrik Ström
Johan Eltes
Khaled Daham
Uppdaterat beskrivning i GetCareDocumentation av tidsattribut.
Ändrat format på MultiMediaEntry
authorOtherRole tillagt.
Tagit bort koppling mellan categorization-koden för EI och NPÖ:s kodverk. Koden ägs nu av denna tjänstedomän (ingen ändring av själva värdet).
Ändrat elementnamnet sourceSystem till sourceSystemHSAid
Förbättrat och utökat beskrivningen av adressering för att även täcka anrop utan aggregering.
Uppdaterat semantik för ”Most Recent Content” (EI)
PA34
2013-04-30
Johan Eltes
Uppdaterat regelverk för EI-poster avseende fältet LogicalAddress (som nu är samma som för source system)
Lagt till regel enligt NPÖ RIV-spec för formattering av clinicalDocumentNoteText
Lagt till krav på uppdatering av EI-fältet DataController
Uppdaterat bilder och text i arkitekturavsnittet för att spegla ändring i EI-postens innehåll
Formatteringsproblem i dokumentet åtgärdade.
PA35
2013-09-21
Björn Genfors
Uppdaterat sektionen om gemensamma typer.
Följduppdaterat tjänstekontraktsbeskrivningar
Lagt till information om avvikande åsikt till journalnotatet
Lagt till beskrivning av formattering av clinicalDocumentNoteText
PA36
2013-09-26
Björn Genfors
Redaktionella ändringar (HSAId ska skrivas just så)
PA37
2013-09-30
Johan Eltes
Åtgärdat ett par copy-paste-fel i skrivningen om docbook-formatet.
Förtydligat beskrivningen av opinionId
PB1
2013-10-09
Björn Genfors
Tagit bort nullified från GetCareDocumentation
Satt kardinaliteten på healthcareProfessionalHSAId till 0..1.
Justerat läsbarheten i kontraktstabellen.
PB2
2013-10-15
Björn Genfors
Förtydligat patientId i PatientSummaryHeader.
PB3
2013-10-17
Björn Genfors
Korrigerat beskrivning av documentId i PatientSummaryHeader
Justerat beskrivning av adress i OrgUnitType.
Lagt till SourceSystem i Engagemangsindex.
PB4
2013-10-21
Johan Eltes
Förtydligat kravet på filtrering av svar enligt logicalAddress (lagt till avsnitt 3.4).
Markerat i flödesmodeller att anslutningskatalog inte är del av dagens arkitektur.
PB5
2013-11-04
Johan Eltes
Ersatt termen PDL-enhet med vårdenhet (i löpande text)
Uppdaterat avsnittet om informationssäkerhet efter CeHis-granskning
PB6
2013-11-25
Johan Eltes
Lagt till text för tjänstekontrakten som deklarerar kompatibilitet med NPÖ RIV Spec och HL7 CDA.
PB7
2013-11-26
Björn Genfors
Lagt till tjänstekontrakt för Diagnos
Lagt till tjänstekontrakt för Uppmärksamhetsinformation
PB8
2013-11-28
Khaled Daham
Rättat namn på typer och djup på element för GetAlertInformation
PB9
2013-11-29
Björn Genfors
Rättat versalisering på två element i diagnoskontraktet
PB10
2013-12-05
Björn Genfors
Infört nytt element: chronicDiagnosis i GetDiagnosis
Ändrat elementnamn på relaterad diagnos-id i GetDiagnosis
Korrigerat format och kardinalitet på ingående element i validityTimePeriod i GetAlertInformation
Ändrat namn på ett fåtal element i GetAlertInformation (treatmentDescription, communicableDiseaseCode och restrictionOfCareComment är nya namnen)
Beskrivningar av ett fåtal fält har åtgärdats.
PB11
2013-12-10
Björn Genfors
Bytt namn på elementet diagnosisType till typeOfDiagnosis
PB12
2013-12-11
Björn Genfors
Förtydligat beskrivning av tidsparametern i begäran för GetAlertInformation
PB13
2013-12-11
Johan Eltes
Lagt till kategorikoder för infomängder diagnos och uppmärksamhetsinformation
Ersatt beskrivningen av generella klasser med en referens till bilaga
Lagt till skrivning på orgunit-fält i alla typer och kontrakt om att lokalt id kan anges om HSA-id saknas i källsystemet.
PB14
2014-01-21
Björn Genfors
Lagt till det nya kontraktet för reumatismdata.
PB15
2014-01-22
Björn Genfors
Kontraktet för reumatismdata är flyttat till en egen domän: clinicalprocess.healthcond.rheuma
PB16
2014-01-23
Khaled Daham
Ändrade serviceDomain ifrån logistics.logistics till healthcond.description
2.1.RC2
2014-03-13
Björn Genfors
Bytt dokumentationen till ny mall
Lagt till MIM-ar
Lagt till V-TIM-mappning
Uppdaterat arbetsflödesdiagram
Uppdaterat några av fältregelbeskrivningarna i GetDiagnosis och GetAlertInformation för att harmoniera med GetCareDocumentation
Förtydligat beskrivningen av vad diagnoskontraktet är tänkt att returnera (definitionen av ”diagnos”).
Ändrat ISO-referens för angivande av tid- och datumformat.
2.1.RC3
2014-03-17
Khaled Daham
Lagt till resultType för alla kontrakt i tabellen för fältregler
Lagt till en beskrivning för logiska fel i kap 4.4
Förtydligat text kring adressering i kap 3.3
Uppdaterat versionsnummer samt kompabilitetstabellen
2.1 RC4
2014-09-15
Björn Genfors
Bytt dokumentationsmall
Korrigerat GCD att vara bakåtkompatibel med v 2.0 (elementnamnet sourceSystemHSAid behöver ett gement i).
Förtydligat dokumentation om begäran i GetDiagnosis och GetAlertInformation.
Lagt till kontraktet GetFunctionalStatus
2.1 RC4
2014-09-16
Khaled Daham
Uppdaterat MIM för GetFunctionalStatus, samt referredInformation.type till string från URN
2.1 RC5
2014-09-18
Khaled Daham
Rättat småfel i fältregellistan, bl.a kardinalitet för referredInformation från 0..* till 1..*
2.1 RC6
2014-10-02
Khaled Daham
Åtgärdat kommentarer efter VIS-granskning.
2.1 RC7
2014-11-18
Khaled Daham
Fixat stavfel
Lagt till Ineras HSAid för aggregerande tjänster.
sourceSystemHSAId krävs vid begäran på reservnummer
2.1 RC7
2014-11-25
Khaled Daham
Tagit bort alternativet att använda GetUpdates(index-pull) för EI då den inte är implementerad och det pågår diskussioner om att den skall tas bort ifrån TKB för EI.
Uppdaterat sekvensdiagram.
Ändrat skrivelse kring medarbetarens åtkomst till att peka på SOSFS 2008:14 istället för PDL-i-praktiken.
Förtydligat sambandet mellan categorization och assessmentCategory för GetFunctionalStatus
2.1
2015-03-16
Björn Genfors
Uppdaterat V-TIM-mappningskapitlet med korrigerade V-TIM-mappningar, och mappning mot NPÖ.
Korrigerat beskrivninge n av fältet padl/assessment i GFS.
2.1.1
2015-03-31
Khaled Daham
Tagit bort relation ifrån GetFunctionalStatus efter beslut av Inera
2.1.2
2015-05-13
Khaled Daham
Korrigerat HSA-id som skall användas vid addressering till Inera.
2.1.3
2015-07-02
Khaled Daham
Uppdaterat beskrivning av authorTime i headern.
2.1.4
2015-09-16
Björn Genfors
Korrigerat NPÖ-mappningar för två fält i GD och GAI
2.1.4
2015-09-21
Khaled Daham
Förtydligat att användning av clinicalDocumentTypeCode endast skall användas av 13606-adapters.
2.1.4
2015-10-13
Khaled Daham
Ändrad/rättat kardinalitet på pharmaceuticalTreatment från 0..1 till 0..* i fältregellistan samt i schemat.
Svarstider för SLA ändrat ifrån 15 sekunder till 30 sekunder.
2.1.4
2015-10-20
Khaled Daham
Uppdaterat text kring KV Befattning för GetFunctionalStatus
Uppdaterat regelverk för inbäddade binära bilagor
2.1.5
2015-11-27
Björn Genfors
Uppdaterat fältet allvarlighetsgrad i GAI med information om att det föreslagna kodverket allvarlighetsgrad finns i två versioner.
2.1.6
2016-02-23
Ranjdar Fallyih
Uppdaterat beskrivningen för legalAuthenticator (när informationen har låsts utan signering)
2.1.7
2017-04-18
Khaled Daham
Förtydligat i kap 7.1.4 att nullified och nullifiedReason inte används https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/358/gcd-21-tkb-saknar-f-lten-om-makulering-i-f
2.1.7
2017-04-19
Björn Pettersson
Testsviter uppdaterade
2.1.8
2017-06-21
Magnus Söderlind
Testsviter och självdeklaration uppdaterade
2.1.9
2017-08-07
Khaled Daham
Uppdaterat beskrivning av fält clinicalDocumentNoteText samt multimediaEntry https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/374/getcaredocumentation-tvetydig-semi
2.1.9
2017-08-11
Khaled Daham
Förtydligat actSubstance och lagt till element som ej skall användas, https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/369/getalertinformation-20-felaktig-cvtype
Förtydligat att låsning skall signaleras på samma sätt som det görs i getCareDocumentation för getDiagnosis, getFunctionalStatus, getAlertInformation
https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/377
Förtydligat användning av relatedDiagnosis https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/373/fr-gor-ang-ende-tolkning-av
2.1.9
2017-08-11
Magnus Söderlind
Testsviter/självdeklarationer utökade och uppdaterade.
2.1.10
2018-01-19
Emmy Damberg
Rättat beskrivning av timePeriod i GetDiagnosis och datePeriod i GetFunctionalStatus https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/380/felaktig-beskrivning-av-dateperiod-i-tkb
2.1.10
2018-10-05
Magnus Söderlind
Uppdateringar i SJD och testförbättringar i testsviter, framförallt tidsfiltrering. Testsvit 7,8 tillkommer.
2.1.10
2019-03-25
Jan Söderman
Lagt till SjD för konsument och uppdaterat mock
2.1.10
2019-04-03
Malin Lindberg
Rättat kardinalitet för ../start och ../end i GetFunctionalStatus
https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/384/kardinalitet
2.1.11
2019-05-02
Jan Söderman
Ny testsvit och självdeklaration
2.1.12
2020-03-30
Maja Hedengren
Regelförtydligande av HSA-id för
vårdgivare och vårdenhet.
Rättning av kardinalitet till 0..1 för elementen healthcareProfessionalCareUnitHSAId samt healthcareProfessionalCareGiverHSAId i GCD som felaktigt var satt till 1..1 i TKB.
Flyttat ut regler i fältreglerna till Övriga regler.
Uppdaterar gamla länkar i referenslistan.
Tagit bort mappningar mot NPÖ och V-TIM från mappningstabellerna för respektive tjänstekontrakt samt övriga referenser till mappningen, efter A&R beslut om att mappningar ska tas bort.
Förtydligat regel i GFS för elemten ../../../disabilityAssessment och ../../../comment
Ändrat användning av vård- och omsorg (tex vård och omsorgspersonal) till hälso- och sjukvård (tex hälso- och sjukvårdspersonal).
2.1.13
2020-11-25
Claudia Ehrentraut
Uppdaterat versionsnummer
2.1.14
2020-11-25
2020-12-02
Claudia Ehrentraut
Förtydligat information om DocBook-formatet under avsnitt 7.1.3 och i beskrivningstexten för attributet clinicalDocumentNoteText samt uppdaterat referenser för DocBookformatet.
Byt ut alla förekomster av skall till ska och förekomster av oid till OID.
Bytt ut SOAP-Exception till Soap Fault, enligt https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/381/byt-till-soap-fault
Förtydligat skrivning under avsnitt 4.3 Icke funktionella krav om hur dubbletter i olika verksamhetssystem ska hanteras samt lagt till referens till ARK_0040.
Bytt namn av kodverket KV Befattning till Befattning, resp. KV Sambandstyp till KV Samband för att stämma överens med benämningarna på https://inera.atlassian.net/wiki/spaces/KINT/pages/3615655/Kodverk+i+nationella+tj+nstekontrakt OBS! Det är samma kodverk som avses i båda fall.
Uppdaterat länk för referens R13 till https://inera.atlassian.net/wiki/spaces/KINT/pages/3615655/Kodverk+i+nationella+tj+nstekontrakt
Lagt till referens till kodverkslistan [R13] för Snomed, ICD10, och ATC, KV Samband
Tagit bort referens R14 Internationell klassifikation av funktionstillstånd, funktionshinder och hälsa (ICF) eftersom ICF listas på kodverkslistan som refereras till i R13.
Lagt till ny R14 som är en referens till Listan över identifierare.
Lagt till referens till Listan över identifierare [R14] för personnummer, samordningsnummer och SLL-reservnummer.
Uppdaterat beskrivning av documentId i PatientSummaryHeader
Ändrat multiplicitet för orgUnitHSAId och orgUnitName från 0..1 till 1..1 för att stämma överens med schemat/testsviter i GetDiagnosis, GetAlertInformation och GetFunctionalStatus (GetCareDocumentation var redan korrekt satt till 1..1), utifrån https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.description/issues/387/uppt-ckt-fel-i-wsdl-och-soapui-testsvit-f
Rättat rubriknivåer under 3.1 Flöden
2.1.15
2021-02-01
Tobias BlombergClaudia Ehrentraut
Förtydligat regel 2 för GetFunctionalStatus.
Uppdaterat attributbeskrivningen för headerId (dvs documentId i PatientSummaryHeaderType) i samtliga tjänstekontrakt för domänen.
Uppdaterat versionsinformation
2.1.16
2021-05-24
Tobias Blomberg
Uppdaterat beskrivningarna för domänen respektive varje tjänstekontrakt.
Uppdaterat beskrivningen för attributet MostRecentContent unde avsnitt 4.1
Uppdaterat beskrivningen av tidsfiltrering i samtliga tjänstekontrakt.
2.1.17
2022-01-11
2022-03-18
Tobias Blomberg
Ändrat multiplicitet för careDocumentation/careDocumentationHeader/documentTime i GCD till valfritt för att stämma överens med schemat.
Uppdaterat beskrivningen för elementet sourceSystemHSAId i begäran för samtliga kontrakt i domänen.
2.1.17
2022-03-22
Tobias Blomberg
Version godkänd
2.1.18
2022-11-29
2023-01-10
Tobias Blomberg
Uppdaterat beskrivningen för attributet alertInformation i getAlertInformation enligt TJN-291
Lagt till regel 2 under övriga regler i getAlertInformation
Tagit bort denna text från attributet legalAuthenticator ur samtliga tjänstekontrakt:
”I de fall där informationen har låsts utan signering, representeras detta genom att signatureTime sätts till tidpunkten för låsning, och resterande fält i LegalAuthenticatorType lämnas tomma.”.
Detta då det enligt SOSFS 2016:40 ska det ej längre finnas möjlighet att låsa osignerade journalanteckningar
Uppdaterat samtliga beskrivningar av CVType för att tydliggöra regler gällande hur de olika elementen i typen relaterar till varandra. Reglerna finns redan beskrivna i schematron.
3.0
2023-10-03
Thomas Siltberg
2021-07-09
Kontraktet GetCareDocumentation uppdaterat till version 3.0.
Uppdaterat JoL-header till version 1.5 i GetCareDocumentation.
Uppdaterat gemensamma datatyper för GetCareDocumentation.
Lagt till pageneringshantering i GetCareDocumentation och med det lagt till avsnitt 4.3.2.5, 4.3.2.5 och 7.1.5 samt uppdaterat avsnitt 4.4.1.1 och 3.2.
Ändring av datatypen för personId i DissentingOpinionType.
Ändrat namn på sourceSystemHSAId till sourceSystemId i GetCareDocumentation.
Ändrat datatyp på sourceSystemId i GetCareDocumentation.
Flyttat regeln för sourceSystemId i GetCareDocumentation till avsnittet för övriga regler.
Justerat regel 1 för GetCareDocumentation då vårdgivaren nu är obligatorisk att ange i headern.
Lagt till hantering av logiska fel för GetCareDocumentation.
Lagt till regel 4 i övriga regler för GetCareDocumentation.
2021-08-04
Tagit bort clinicalDocumentTypeCode från GetCareDocumentation då den inte används längre.
Ändrat beskrivningen av clinicalDocumentNoteCode i GetCareDocumentation.
2021-08-12
Uppdatering av regler vid användning av Partiell datahämtning.
2021-09-01
Uppdaterat namn och beskrivning för tidsfiltrering i GetCareDocumentation.
2021-10-12
Ändrat benämningen på avvikande åsikt till avvikande mening.
Ändrat benämningen på hälso- och vårddokument till journalanteckning.
2021-11-02
Lagt till mappningstabell mellan MIM och informationsmodell för GetCareDocumentation.
2022-01-25
Lagt till regel för hur länge referensen ska vara giltig för HasMoreType i GetCareDociumentation under avsnitt 7.1.6.
Tagit bort attributet readyAt från HasMoreType för partiell datahämtning.
Förtydligat beskrivningen av record.id i GetCareDocumentation.
2022-05-05
Uppdaterat headern till version 2.0.
2022-10-21
Uppdaterat headern till version 2.1 (se TJN-304)
Tagit bort careContactId från begäran i GetCareDocumentation (se TJN-304)
Uppdaterat regel 3 för GetCareDocumentation vid borttag av careContactId
accountableHealthcareProvider i GetCareDocumentation är ändrad till ej obligatorisk (se TJN-304).
2022-11-17
Uppdaterat beskrivningen av patientId i begäran i GetCareDocumentation.
Förtydligat hantering av Partiell datahämtning under avsnitt 7.1.5.
Uppdaterat headern till version 2.2 och med det ändrat namnet på originalPatientId till patientId och kardinaliteten till 1..1 i schema och TKB.
Uppdaterat gemensamma typer till version 17.
Uppdaterat ClinicalDocumentNoteCode i GetCareDocumentation till att vara obligatorisk att ange i schema och TKB.
2022-12-14
Förtydligat användning av hasMore
2022-12-16
Justerat MIM samt mappningstabell för GetCareDocumentation.
Uppdatering av element för regel 1 för GetCareDocumentation.
Kompletterat fältregeltabellen med beskrivningarna av attributen i JoL-headern.
Lagt till skrivelse om att kodverket för clinicalDocumentNoteCode kan komma att ändras över tid och att konsumenter ska ta höjd för det.
2022-12-30
Ändrat clinicalDocumentNoteCode till CVType och uppdaterat beskrivningen.
Ändrat beskrivning av MultimediaEntry samt ändrat mediaType till string.
2023-01-18
Justerat beskrivningen av clinicalDocumentNoteCode samt MultimediaEntry
Har lyft in gemensamma typer i TKB i stället för att peka på en bilaga. Gäller GetCareDocumentation.
Har lyft in beskrivning om headern i TKB i stället för att peka på en bilaga. Gäller GetCareDocumentation.
Har lagt till regler för getCareDocumentation och kopplat dessa till schematron.
Uppdaterat beskrivningen av patientId i begäran för GetCareDocumentation.
2023-02-09
Tagit bort regel om begränsning på 100kb för binära bilagor. Storlegsbegränsning anges i interaktionsöverenskommelse i stället.
2023-03-02
Uppdaterat beskrivning av record.id i GetCareDocumentation.
2023-09-21
Ny dokumentmall
2023-10-03
Uppdaterat beskrivningen för sourceSystemHSAId i samtliga tjänstekontrakt för att tydliggöra vad fältet avser filtrera på.
3.0.1
2024-03-05
Thomas Siltberg
Stegrad domänversion. Inga ändringar i detta dokument.
3.0.2
2024-04-23
Thomas Siltberg
Uppdaterat beskrivningen om hantering av DocBook-standarden.
Justerat beskrivning om funktionen hasMore så att det framgår att den även är aktuell att använda baserat på gällande storleksbegränsningar på svarsmeddelandet.
3.0.3
2024-05-06
Tobias Blomberg
Stegrad domänversion. Inga ändringar i detta dokument.
3.0.4
2024-05-28
Tobias Blomberg
Stegrad domänversion. Inga ändringar i detta dokument.
3.0.5
2024-11-22
Thomas Siltberg
Förtydligande av beskrivning för atcSubstance, nonATCSubstance samt nonATCSubstanceComment i GetAlertInformation.
Referenser
Namn
Dokument
Kommentar
Länk
R1
AB_clinicalprocess_healthcond_description
Obligatoriskt
Bilaga
R2
RIVTA flera dokument
Finns på Webben
Länk
R3
Bilaga Mappningar_GetCareDocumentation.xslx
Bilaga
R4
Bilaga Mappningar_GetDiagnosis.xslx
Bilaga
R5
Bilaga Mappningar_GetAlertInformation.xslx
Bilaga
R6
ISO8601-standarden för tidsformat
Finns på Webben
Länk
R7
RIV Tekniska Anvisningar
Översikt. Version 2.0.4
Finns på Webben
Länk
R8
Tabell över godkända tjänstedomäner
Finns på Webben
Länk
R9
Senaste version av SOSFS 2016:40 Socialstyrelsens föreskrifter och allmänna råd om journalföring och behandling av personuppgifter i hälso- och sjukvården
Finns på Webben
Länk
R10
Journalföring och behandling av personuppgifter i hälso- och sjukvården - Handbok vid tillämpningen av Socialstyrelsens föreskrifter och allmänna råd (HSLF-FS 2016:40) om journalföring och behandling av personuppgifter i hälso- och sjukvården.
Finns på Webben
Länk
R11
DocBook
Finns på Webben
Länk DocBook
Länk schemas
Länk tools
R12
Apache Commons Text StringEscapeUtils
Finns på Webben
Länk
R13
Kodverkslistan
Finns på Webben
Länk
R14
Lista över identifierare
Finns på Webben
Länk
R15
Bilaga Gemensamma_typer_7.pdf
Bilaga
R16
RIV Tekniska Anvisningar - Binära bilagor
Finns på Webben
Länk
R17
RIV Tekniska Anvisningar - Parallella huvudversioner av ett tjänstekontrakt
Finns på Webben
Länk
R18
ADL-Taxonomin® – en bedömning av aktivitetsförmåga
Länk
R19
Regel #11, Logiska fel
RIV Tekniska Anvisningar - Tjänsteschema 2.1
Länk
Förkortningar
Förkortning
Betydelse
Kommentar
K
Tjänstekonsument
Se referens R7
P
Tjänsteproducent
Se referens R7
Inledning
Detta är beskrivningen av tjänstekontrakten i tjänstedomänen
clinicalprocess: healthcond: description
Tjänstekontrakten är baserade på RIVTA 2.1 [R2] och reglerade genom arkitekturella beslut [R1].
Tjänstekontraktsbeskrivningen är en kravspecifikation. Den skall fungera som ett teknikneutralt, formellt regelverk som reglerar integrationskrav för parter (tjänstekonsumenter och tjänsteproducenter) som avser ansluta system för samverkan enligt dessa tjänstekontrakt. Tjänstekontraktsbeskrivningen är också ett viktigt underlag för skapande av de tekniska kontrakten (scheman och WSDL-filer).
Detta dokument kompletterar reglerna i de tekniska kontrakten. Tjänsteproducenter och tjänstekonsumenter ska m.a.o. följa såväl de maskintolkbara reglerna i de tekniska kontrakten, så väl som de regler som uttrycks verbalt i detta dokument.
Svenskt namn
Vård- och omsorg kärnprocess:hantera hälsorelaterade tillstånd:tillståndsbeskrivning
Tillståndsbeskrivning
Beskrivning
Denna domän hantera information som beskriver patientens hälsotillstånd, till exempel vårdanteckningar, diagnoser, uppmärksamhetsinformation och funktionsstatus. Domänen syftar till att tillmötesgå vårdprofessionens behov av direktåtkomst till patientens vårdinformation (så kallad sammanhållen journalföring) såväl som patientens egen åtkomst till sin vårdinformation.
Tjänstekontrakten i denna domän hanterar specifikt patientens journalanteckningar, och klinisk information som beskriver patientens hälsotillstånd, exempelvis vårdanteckningar, diagnoser, uppmärksamhetsinformation (som innefattar bland annat allvarliga allergier och allvarliga sjukdomar) samt funktionsstatus. Domänens kontrakt stödjer tjänsteinteraktioner där konsumenten är i behov av att läsa informationen från ett eller flera källsystem.
Versionsinformation
Denna revision av tjänstekontraktsbeskrivningen handlar om domänen clinicalprocess: healthcond: description. Observera att version för detta dokument och domänen måste vara lika. Detta för att spårbarheten inte skall brytas.
Version 3.0.5
Oförändrade tjänstekontrakt
GetDiagnosis, version 2.0
GetAlertInformation, version 2.0
GetFunctionalStatus, version 2.0
Nya tjänstekontrakt
Följande nya tjänstekontrakt finns från och med denna version:Inga nya kontrakt har tillkommit i denna version
Förändrade tjänstekontrakt
GetCareDocumentation, version 3.0
Nedan redovisas kompatibilitet mellan konsument och producent för tjänstekontrakten som finns i flera versioner. Kompatibilitet avser här såväl format som semantik. För definition av kompatibilitet mellan format, se RIV Tekniska Anvisningar, Översikt.
Tjänstekontrakt
Konsument
Producent
Kompatibilitet
GetCareDocumentation
2.1
2.0
OK
2.0
2.1
Ej kompatibel
2.x
3.0
EJ kompatibel
3.0
2.x
EJ kompatibel
Utgångna tjänstekontrakt
Inga tjänstekontrakt har utgått.
Version tidigare
3.0.2
Tjänstedomänens arkitektur
I detta avsnitt beskrivs hur T-boken tillämpats i tjänstedomänen. Avsnittet syftar till att ge läsaren överblick och förståelse. Avsnittet innehåller inga regler, men ger ett sammanhang för de regler som beskrivs i övriga delar av dokumentet.
Tjänsterna för beskrivning av hälsorelaterade tillstånd erbjuder sökning av information i hälso- och sjukvårdsgivarnas system för patientadministration och vårddokumentation. Utgångspunkten för tjänsterna i denna tjänstedomän är i första hand patientens och professionens behov av direktåtkomst till en patients hälso- och sjukvårdshistorik sett ur ett nationellt eller ett regionalt perspektiv. I båda fallen är syftet att historisk information sammanställs från det eller de källsystem där det finns historik via s.k. aggregerande tjänster, snarare än att begära information från ett specifikt system eller en specifik verksamhet.
Tjänstekontrakten erbjuder även möjlighet att nå information från ett specifikt system eller en specifik verksamhet. Behovet av att rikta en fråga till ett specifikt system uppstår främst när tjänstekonsumenten också är prenumerant på notifieringar från engagemangsindex och på det sättet (via ProcessNotification) får information om en händelse i ett specifikt system. Det är då ändamålsenligt att adressera det specifika systemet, istället för den aggregerande tjänsten.
Följande flödesmodeller beskriver översiktligt hur tjänstekontrakten är tänkta att användas. Tjänstekonsument (K) och tjänsteproducenter (P) är markerade i figurerna.
Flöden
Nedanstående diagram visar hur flödet principiellt ser ut när information ur kontrakt i tjänstedomänen efterfrågas och hanteras.
Arbetsflöde
Figur 1 Exempel: Adressering vid anrop till aggregerande tjänst från patienttjänst (t.ex. från Mina Vårdkontakters tjänst för journalåtkomst).
Figur 2 Exempel: Adressering vid anrop till aggregerande vårdgivartjänst (t.ex. från NPÖ-tillämpningen).
Roller
Namn/beteckning
Beskrivning alt. referens
Patienten
Den patient som vill få tillgång till information som tjänsterna tillhandahåller.
Professionen
Den hälso- och sjukvårdsperson som vill få tillgång till patientens data.
Sekvensdiagram
Figur 3 Sekvensdiagram över sökning efter information där GetAlertInformation används som exempel men samma princip gäller för alla kontrakt i tjänstedomänen, diagrammet visar på två alternativa sekvenser där det första alternativet gäller när aggregerande tjänster adresseras och det andra alternativet gäller när källsystemet adresseras.
Roller
Namn/beteckning
Beskrivning alt. referens
Tjänstekonsument
Det system som används för att konsumera information. Dvs det system som använder tjänster enligt ett tjänstekontrakt.
Tjänsteplattform
Tjänsteplattformen är det lager som hanterar virtuella tjänster, aggregerande tjänster samt anpassningstjänster.
Aggregerande tjänst
En aggregerande tjänst är en integrationstjänst som för en tjänstekonsument sammanställer en nationell vy av informationen av den typ som är aktuell för tjänsten i fråga. Är beroende av engagemangsindex för att begränsa sökningen till relevanta informationsägare.
Engagemangsindex
En tjänst där det finns uppdaterade nationella index över vilka informationsägare som har information kring en viss invånare/patient.
Vårdinformationssystem
Det system som i detta fall utgör källsystemet som vårdpersonal direkt registrerar/uppdaterar/raderar information i.
Obligatoriska kontrakt
Domänen definierar inga flöden och har därmed inga obligatoriska kontrakt att uppfylla.
Adressering
Tjänstedomänen tillämpar källsystem-adressering. Observera att tjänstekonsumenter främst anropar aggregerande tjänster. Tjänstekonsumenten adresserar därför den aggregerande tjänsten med antingen nationellt HSA-id (Ineras HSA-id) eller HSA-id för aktuell huvudman om det är en regional/huvudmanna-specifik (t.ex. ”regional”) aggregerande tjänst som ska adresseras.
Det finns också fall då en tjänstekonsument adresserar ett källsystem. Det förutsätter att tjänstekonsumenten känner till källsystemets HSA-id. Det sker genom att ett sådant anrop föregås av ett anrop till en aggregerande tjänst (källsystemets HSA-id finns då i svarsmeddelandet) eller genom att tjänstekonsumenten är producent för Engagemangsindex notifieringskontrakt (ProcessNotification). Notifieringen innehåller information om en händelse rörande en patients information i ett specifikt källsystem. Genom att använda informationen om källsystemets HSA-id kan tjänstekonsumenten direktadressera källsystemet i syfte att hämta information om den händelse som just notifierats för patienten.
Adressering sker i enlighet med RIV Tekniska Anvisningar Översikt, Rev E, avsnitt 8.3, där mer information kan hittas.
Vid partiell datahämtning ska anropen efter det första anropet direktadresseras till tjänsteproducenten.
Sammanfattning av adresseringsmodell
Åtkomstbehov för patientens journalhistorik
Logisk adress
Nationellt
Ineras HSA-id: 5565594230
För en huvudman/region
Huvudmannens/regionens HSA-id
För ett källsystem
Källsystemets HSA-id
Aggregering och engagemangsindex
Det behövs en aggregerande tjänst för varje tjänstekontrakt som läser data i denna domän. Aggregerande tjänster har samma tjänstekontrakt och anropsadress som en traditionell virtuell tjänst, men nås via olika logiska adresser.
Om ett källsystemets HSA-id anges som logisk adress, kommer frågemeddelandet att dirigeras vidare direkt till källsystemet utav tjänsteplattformen utan att passera en aggregerande tjänst.
Om logisk adress HSA-id för Inera eller en huvudman kommer anropet att dirigeras till aggregerande tjänsten som i sin tur – efter att ha konsulterat engagemangsindex – vidarebefordrar frågan till de källsystem som har information om patienten.
Tjänstedomänens krav och regler
Dessa gäller alla tjänstekontrakt i hela tjänstedomänen om inte undantag görs för specifika tjänstekontrakt senare i dokumentet.
Uppdatering av engagemangsindex
Alla källsystem ska uppdatera engagemangsindex. Engagemangsindex ska uppdateras så snart en händelse inträffar som påverkar indexposterna enligt beskrivningen nedan.All uppdatering av engagemangsindex sker genom att källsystemet anropar engagemangsindex genom tjänstekontraktet
urn:riv:itintegration:engagementindex:UpdateResponder:1 (”index-push”).
Ladda hem engagemangsindex WSDL (se referens [R8]), scheman och tjänstekontraktsbeskrivning för detaljer.
Följande regler gäller för innehållet i begäran till engagemangsindex för uppdateringar som rör denna tjänstedomän:
Attribut
Beskrivning
Format
Kardinalitet
Kodverk/värde-mängd /ev begränsningar
Beslutsregler och kommentar
Registered ResidentIdent Identification
Invånarens person-nummer
Person- eller samordningsnummer enligt skatteverkets definition (12 tecken).
1..1
Del av instansens unikhet
Service domain*
Den tjänstedomän som förekomsten avser.
URN på formen
1..1
”riv:clinicalprocess:healthcond:description”
Del av instansens unikhet
Categori-zation*
Kategori-sering enligt kodverk som är specifikt för tjänste-domänen
Text bestående av bokstäver i ASCII.
1..1
Informationsmängd enligt tabell nedan.
Del av instansens unikhet
Logical address*
Referens till informationskällan enligt tjänste-domänens definition
Logisk adress enligt adresseringsmodell för den tjänstedomän som anges av fältet Service Domain.
1..1
Samma värde som fältet Source System.
Del av instansens unikhet
Business object Instance Identifier*
Unik identifierare för händelse-bärande objekt
Text
1..1
”NA” – d.v.s. ej tillämpat för tjänstedomänen.
Del av instansens unikhet
Clinical process interest Id
Hälsoärende-id
GUID
1..1
”NA” (ännu ej tillämpat i tjänstedomänen)
Del av instansens unikhet
Most Recent Content*
Tidpunkt för senaste uppdatering av den informationstyp och patient i den källa som denna indexpost avser.
DT
1..1
Tidpunkt för senaste händelse som matchar indexposten. Kan även avse borttag. Ex: En indexpost representerar 2 bef. dokument. Ett av dem tas bort. Det markeras genom att bef. post uppdateras med tidpunkt för borttagshändelsen.
CreationTime
Tidpunkten då index-posten registrerades
DT
1..1
Sätts automatiskt av EI-instansen.
Genereras automatiskt av kontraktets tjänste-producent
Update Time
Tidpunkten då index-posten senast upp-daterades
DT
0..1
Sätts automatiskt av EI-instansen.
Upp-datering innebär ny post som matchar samtliga attribut som är del av en instans unikitet.
Source system
Källsystemet som genererade engagemangs-posten via Update-tjänsten
Källsystemets HSA-id. För system-adresserade tjänstedomäner motsvarar detta LogicalAddress vid anrop till tjänster i tjänstedomänen i fråga. Detta är inte anslutningspunktens HSA-id utan systemet som operativt hanterar originalinformationen i verksamheten.
1..1
Systemadressering tillämpas. Detta värde används som LogicalAddress vid tjänsteanrop.
Del av instansens unikhet
Data Controller
Personuppgiftsansvarig organisation
Vårdgivarens organisationsnummer eller HSA-id
eller inom källsystemet unik identifierare för vårdgivaren.
1..1
”SE”
systemspecifik identitet.
Del av instansens unikhet
Regler för tilldelning av värde i fältet Categorization i engagemangsposten för tjänstekontrakt i denna domän.
En tjänsteproducent av GetFunctionalStatus måste använda samma värde för categorization i en Update som för elementet assessmentCategory i svaret.
Informationsmängd enligt Tjänstekontrakt
Värde på Categorization
GetCareDocumentation
voo
GetDiagnosis
dia
GetAlertInformation
upp
GetFunctionalStatus – funktionsnedsättning
fun-fun
GetFunctionalStatus – PADL
pad-pad
Informationssäkerhet och juridik
Medarbetarens direktåtkomst
Vid sammanhållen journalföring ansvarar verksamheten som erbjuder sina medarbetare direktåtkomst till sammanhållen journal för att patientdatalagen efterlevs. Det innebär bl.a. att spärrkontroll kan behöva genomföras innan information kan visas. Det innebär också att regelverket för samtycke, vårdrelation och åtkomstloggning måste följas. Dessutom finns krav från Integritetsskyddsmyndigheten om ytterligare teknisk åtkomstkontroll.
HSLF-FS 2016:40 [R9] ställer också krav (via handboken “Journalföring och behandling av personuppgifter i hälso- och sjukvården” [R10]) på att medarbetaren är starkt autentiserad om medarbetarens inloggning sker i nät som delas med flera vårdgivare och att uppdragsval görs i samband med autentisering (vårdenhet).
Det kompletta regelverket finns i handboken samt i anvisningar för tillgänglig patient.
Observera att tjänstekontrakten i sig inte påtvingar sammanhållen journalföring. Krav rörande sammanhållen journalföring och eller krav på spärrhantering uppstår först om tjänstekonsumenten (e-tjänsten) för medarbetaren tillgängliggör information som härrör från andra vårdgivare (sammanhållen journalföring) eller andra vårdenheter inom egna vårdgivaren (spärrkrav).
Patientens direktåtkomst
Alla tjänstekontrakten i denna tjänstedomän har en svarsflagga som anger om verksamheten (informationsägaren) godkänt att informationen får visas för patient. Det kan t.ex. ha skett genom menprövning eller rådrum. För vissa tjänstekontrakt, såsom hälso- och sjukvårdskontakter, kanske informationsägaren policymässigt har menprövat all information. Det är varje vårdgivares ansvar att tjänsteproducenten sätter ”kan visas för patient”-flaggan i enlighet med vårdgivarens verksamhetsregler.
Generellt
Tjänsteproducenten ansvarar för att information endast lämnas ut till de tjänstekonsumenter som informationsägaren godkänt. Det är inte ett juridiskt krav, men tydliggörs här eftersom det avviker från T-boken i det att tjänsteplattformen då inte ansvarar för den tekniska åtkomstkontrollen (ej möjligt när systembaserad adressering tillämpas). Om informationsägaren har behov av att reglera åtkomst per tjänstekonsument, ska tjänsteproducenten filtrera svaret enligt informationsägarens önskemål. Observera att det är regionala policyer snarare än lagar och förordningar som styr i vilken grad tjänsteproducenten ska begränsa åtkomst för en viss tjänstekonsument. Kunskapen om tjänstekonsumentens (tjänstens) identitet (d.v.s. ursprunglig tjänstekonsument i anropskedjan) får bara användas för teknisk åtkomstbegränsning på så sätt att svaret blir som om de vårdenheter vars verksamhetschef inte godkänner aktuell tjänstekonsument varit exkluderade i frågan.
Icke funktionella krav
Det är den informationsproducerande vårdgivarens ansvar att endast ett källsystem tillhandahåller informationen via lästjänst och engagemangsindex där patientdata lagras i flera källsystem. Konsumenter som är anslutna till flera majorversioner av samma kontrakt måste hantera dubblettborttagning mellan dessa. Detta sker genom att jämföra identiteter på postnivå och endast behålla en av de poster som returnerats, se referens [R17].
SLA krav
Följande generella SLA-krav gäller för alla tjänsteproducenter som tillhandahåller tjänster. Dessa krav gäller där inget annat anges för ett specifikt tjänstekontrakt.
Kategori
Värde
Beskrivning
Svarstid
Svarstiden för ett anrop får inte överstiga 30 sekunder.
Tillgänglighet
24x7, 99,5%
Last
Tjänsteproducenten ska kunna hantera minst dubbla mängden frågor per dygn i förhållande till antalet journaluppdatering per dygn.
Aktualitet
Kraven på aktualitet varierar för olika tjänstekonsumenter. Det behöver inte vara absolut aktualitet i förhållande till källsystemet, men ju mindre fördröjning desto bättre. Ett riktmärke är att försöka undvika längre fördröjning än 60 minuter. Fördröjningen avser både journaldata och uppdatering av engagemangsindex.
Uppdatering av engagemangspost måste ske så att engagemangsposten refererar data som är omedelbart tillgängligt via tjänstekontraktet.
Robusthet
Om tidsintervall inte angivits i frågan kan tjänsteproducenten välja att lämna ett delsvar i syfte att uppfylla svarstidskravet. Delsvaret måste då vara avgränsat i tiden genom att det finns äldre men inte nyare data än det äldsta som returnerats.
Samtidighet
Tjänsteproducenten ska hantera minst 10 samtidiga frågor.
Övriga krav och regler
Gemensamma konsumentregler
R1: Filtrera enligt flagga ”approvedForPatient”R2: Tillämpa regelverk enl. PDL
Gemensamma producentregler
R3: Filtrera enligt RIVTA-headern LogicalAddress. Svarsmeddelandet får endast innehålla information som skapats i det källsystem som anges av frågemeddelandets LogicalAddress.
Format för datum och tidpunkter
Datum anges alltid på formatet ”ÅÅÅÅMMDD”, vilket motsvarar ISO 8601-kompatibla formatbeskrivningen ”YYYYMMDD”.
Tidpunkter anges alltid på formatet ”ÅÅÅÅMMDDttmmss”, vilket motsvarar den ISO 8601-kompatibla formatbeskrivningen ”YYYYMMDDhhmmss”.
Tidszon för tidpunkter
Tidszon anges inte i meddelandeformaten. All information om datum och tidpunkter som utbyts via tjänsterna ska ange datum och tidpunkter i den tidszon som gäller/gällde i Sverige vid den tidpunkt som respektive datum- eller tidpunktsfält bär information om. Såväl tjänstekonsumenter som tjänsteproducenter ska med andra ord förutsätta att datum och tidpunkter som utbyts är i tidszonerna CET (svensk normaltid) respektive CEST (svensk normaltid med justering för sommartid).
Partiell datahämtning direktadresseras (Övriga krav och regler)
Om en tjänstekonsument väljer att hämta ytterligare information från en tjänsteproducent som signalerat att detta finns med hasMore, så måste detta göras med direktadressering. hasMoreReference får alltså inte användas vid anrop till aggregerande tjänst.
Dubblettkontroll vid partiell datahämtning görs av tjänstekonsument (övriga krav och regler)
Vid partiell leverans av information är det tjänstekonsumentens ansvar att hantera eventuella dubbletter om sådana skulle skickas i efterföljande anrop. Det kan exempelvis ske om information som redan levererats i tidigare anrop förändrats. Med dubblett avses information med samma unika identifierare (record.id i JoL-headern).
Felhantering
Krav på en tjänsteproducent
Logiska fel
Respektive kontrakt beskriver närmare hur logiska fel ska hanteras.
Tekniska fel
Vid ett tekniskt fel levereras ett generellt undantag (Soap Fault). Exempel på detta kan vara deadlock i databasen eller följdeffekter av programmeringsfel. Tekniska fel får inte förmedla personuppgifter. Istället rekommenderas att ett log-id förmedlas, som ger möjlighet för tjänsteproducentens förvaltning att bistå tjänstekonsumentens förvaltning med felsökning. Ett log-id bör vara en UUID. Ett log-id får under inga omständigheter förmedla information som är spårbar till patienten.
Krav på en tjänstekonsument
Logiska fel
Inga krav på konsument
Tekniska fel
Inga krav på konsument
Gemensamma informationskomponenter
I tjänstekontraktsbeskrivningarna används ett antal komponenter som är gemensamma för vissa meddelanden i flera domäner eller inom denna domän. Observera att med anledning av att tjänstekontrakten även kan stödjas av producentsystem som saknar (fullständig) HSA-id-information så är HSA-id-attribut i beskrivningarna nedan valfria. Se även avsnittet ”Informationssäkerhet och juridik” ovan.
De gemensamma typerna beskrivs i bilaga/bilagor med namn ”Bilaga Gemensamma_typer_
Tjänstedomänens meddelandemodeller
Här beskrivs de modeller som beskriver informationsinnehållet i tjänstekontrakten inom tjänstedomänen. Varje tjänstekontrakt ska ha en (1..1) egen meddelandemodell som uttömmande beskriver informationen som tjänstekontraktet bär. För varje meddelandemodell beskrivs hur mappning ser ut mot tjänstekontraktets schema (XSD).
MIM Journalanteckning
Modellen är en UML-representation av XSD-schemat. Någon mappning mellan XSD och MIM är därmed inte inkluderad.
Nedan beskrivs mappning mellan MIM/ XSD och informationsmodellen i informationsspecifikationen.
MIM/ XSD
Mappning mot informationsmodell
GetCareDocumentationRequest
logicalAddress
Saknas
parameters
Saknas
GetCareDocumentationType
careUnit
Vårdenhet.id
healthcareProvider
Vårdgivare.id
patientId
Patient.id
timePeriod
Saknas
sourceSystemId
Saknas
hasMoreReference
Saknas
GetCareDocumentationResponse
parameters
Saknas
GetCareDocumentationResponseType
careDocumentation
Saknas
hasMore
Saknas
result
Saknas
CareDocumentationType
header
Saknas
body
Saknas
HeaderType
accessControlHeader
Saknas
sourceSystemId
Saknas
record
Journalanteckning
author
Hälso- och sjukvårdspersonal
signature
Hälso- och sjukvårdspersonal
AccessControlHeaderType
accountableHealthcareProvider
Vårdgivare.id
accountableCareUnit
Vårdenhet.id
patientId
Patient.id
careProcessId
Saknas
blockComparisonTime
Saknas
approvedForPatient
Saknas
RecordType
id
Journalanteckning.id
timestamp
Journalanteckning.dokumentationstidpunkt
AuthorType
id
Hälso- och sjukvårdspersonal.id
name
Saknas
timestamp
Deltagande.tid
byRole
Hälso- och sjukvårdspersonal.befattning
orgUnit
Vårdenhet
OrgUnitType
orgUnitHSAId
Vårdenhet.id
orgUnitName
Saknas
orgUnitTelecom
Saknas
orgUnitEmail
Saknas
orgUnitAddress
Saknas
orgUnitLocation
Saknas
SignatureType
id
Hälso- och sjukvårdspersonal.id
name
Saknas
timestamp
Deltagande.tid
byRole
Hälso- och sjukvårdspersonal.befattning
CareDocumentationBodyType
clinicalDocumentNoteCode
Journalanteckning.typ
clinicalDocumentNoteTitle
Journalanteckning.titel
clinicalDocumentNoteText
Journalanteckning.text
multimediaEntry
Multimedia
dissentingOpinion
Avvikande mening
MultimediaType
mediaType
Multimedia.typ
value
Multimedia.binärdata
reference
Multimedia.referens
DissentingOpinionType
opinionId
Avvikande mening.id
authorTime
Avvikande mening.tidpunkt
opinion
Avvilande mening.text
personId
Person.person-id
personName
Person.namn
HasMoreType
logicalAddress
Saknas
reference
Saknas
ResultType
resultCode
Saknas
resultText
Saknas
IIType
root
Saknas
extension
Saknas
CVType
code
Saknas
codeSystem
Saknas
codeSystemName
Saknas
codeSystemVersion
Saknas
displayName
Saknas
originalText
Saknas
DatePeriodType
start
Saknas
end
Saknas
MIM Diagnos
Klass.attribut
Mappning mot XSD schema
diagnosis
DiagnosisHeaderType.documentId
diagnosis/diagnosisHeader/documentId
DiagnosisHeaderType.sourceSystemHSAId
diagnosis/diagnosisHeader/sourceSystemHSAId
DiagnosisHeaderType.patientId
diagnosis/diagnosisHeader/patientId
DiagnosisHeaderType.accountableHealthcareProfessional
diagnosis/diagnosisHeader/accountableHealthcareProfessional
AccountableHealthcareProfessionalType.authorTime
diagnosis/diagnosisHeader/ accountableHealthcareProfessional /authorTime
AccountableHealthcareProfessionalType.healthcareProfessionalHSAId
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalHSAId
AccountableHealthcareProfessionalType.healthcareProfessionalName
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalName
AccountableHealthcareProfessionalType.healthcareProfessionalRoleCode
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalRoleCode
HealthcareProfessionalOrgUnitType.orgUnitHSAId
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitHSAId
HealthcareProfessionalOrgUnitType.orgUnitname
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitname
HealthcareProfessionalOrgUnitType.orgUnitTelecom
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitTelecom
HealthcareProfessionalOrgUnitType.orgUnitEmail
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitEmail
HealthcareProfessionalOrgUnitType.orgUnitAddress
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitAddress
HealthcareProfessionalOrgUnitType.orgUnitLocation
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitLocation
AccountableHealthcareProfessionalType.healthcareProfessionalCareUnitHSAId
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalCareUnitHSAId
AccountableHealthcareProfessionalType.healthcareProfessionalCareGiverHSAId
diagnosis/diagnosisHeader/accountableHealthcareProfessional/healthcareProfessionalCareGiverHSAId
LegalAuthenticatorType.legalAuthenticatorTime
diagnosis/diagnosisHeader/legalAuthenticator/legalAuthenticatorTime
LegalAuthenticatorType.legalAuthenticatorHSAId
diagnosis/diagnosisHeader/legalAuthenticator/legalAuthenticatorHSAId
LegalAuthenticatorType.legalAuthenticatorName
diagnosis/diagnosisHeader/legalAuthenticator/legalAuthenticatorName
DiagnosisHeaderType.approvedForPatient
diagnosis/diagnosisHeader/approvedForPatient
DiagnosisHeaderType.careContactId
diagnosis/diagnosisHeader/careContactId
DiagnosisBodyType
DiagnosisBodyType.typeOfDiagnosis
diagnosis/diagnosisBody/typeOfDiagnosis
DiagnosisBodyType.chronicDiagnosis
diagnosis/diagnosisBody/chronicDiagnosis
DiagnosisBodyType.diagnosisTime
diagnosis/diagnosisBody/diagnosisTime
DiagnosisBodyType.diagnosisCode
diagnosis/diagnosisBody/diagnosisCode
RelatedDiagnosisType.documentId
diagnosis/diagnosisBody/relatedDiagnosis/documentId
MIM Uppmärksamhetsinformation
Klass.attribut
Mappning mot XSD schema
AlertInformationType
AlertInformationHeaderType.documentId
alertInformation/alertInformationHeader/documentId
AlertInformationHeaderType.sourceSystemHSAId
alertInformation/alertInformationHeader/sourceSystemHSAId
AlertInformationHeaderType.patientId
alertInformation/alertInformationHeader/patientId
AlertInformationHeaderType.accountableHealthcareProfessional
alertInformation/alertInformationHeader/accountableHealthcareProfessional
AccountableHealthcareProfessionalType.authorTime
alertInformation/alertInformationHeader/ accountableHealthcareProfessional /authorTime
AccountableHealthcareProfessionalType.healthcareProfessionalHSAId
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalHSAId
AccountableHealthcareProfessionalType.healthcareProfessionalName
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalName
AccountableHealthcareProfessionalType.healthcareProfessionalRoleCode
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalRoleCode
HealthcareProfessionalOrgUnitType.orgUnitHSAId
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitHSAId
HealthcareProfessionalOrgUnitType.orgUnitname
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitname
HealthcareProfessionalOrgUnitType.orgUnitTelecom
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitTelecom
HealthcareProfessionalOrgUnitType.orgUnitEmail
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitEmail
HealthcareProfessionalOrgUnitType.orgUnitAddress
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitAddress
HealthcareProfessionalOrgUnitType.orgUnitLocation
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitLocation
AccountableHealthcareProfessionalType.healthcareProfessionalCareUnitHSAId
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalCareUnitHSAId
AccountableHealthcareProfessionalType.healthcareProfessionalCareGiverHSAId
alertInformation/alertInformationHeader/accountableHealthcareProfessional/healthcareProfessionalCareGiverHSAId
LegalAuthenticatorType.legalAuthenticatorTime
alertInformation/alertInformationHeader/legalAuthenticator/legalAuthenticatorTime
LegalAuthenticatorType.legalAuthenticatorHSAId
alertInformation/alertInformationHeader/legalAuthenticator/legalAuthenticatorHSAId
LegalAuthenticatorType.legalAuthenticatorName
alertInformation/alertInformationHeader/legalAuthenticator/legalAuthenticatorName
AlertInformationHeaderType.approvedForPatient
alertInformation/alertInformationHeader/approvedForPatient
AlertInformationHeaderType.careContactId
alertInformation/alertInformationHeader/careContactId
AlertInformationBodyType
AlertInformationBodyType.typeOfAlertInformation
alertInformation/alertInformationBody/typeOfAlertInformation
AlertInformationBodyType.ascertainedDate
alertInformation/alertInformationBody/ascertainedDate
AlertInformationBodyType.verifiedTime
alertInformation/alertInformationBody/verifiedTime
AlertInformationBodyType.validityTimePeriod
alertInformation/alertInformationBody/validityTimePeriod
AlertInformationBodyType.alertInformationComment
alertInformation/alertInformationBody/alertInformationComment
AlertInformationBodyType.obsoleteTime
alertInformation/alertInformationBody/obsoleteTime
AlertInformationBodyType.obsoleteComment
alertInformation/alertInformationBody/obsoleteComment
HypersensitivityType.typeOfSensitivity
alertInformation/alertInformationBody/hyperSensitivity/typeOfSensitvity
HypersensitivityType.degreeOfSeverity
alertInformation/alertInformationBody/hyperSensitivity/degreeOfSeverity
HypersensitivityType.degreeOfCertainty
alertInformation/alertInformationBody/hyperSensitivity/degreeOfCertainty
PharmaceuticalHypersensitivityType.atcSubstance
alertInformation/alertInformationBody/hyperSensitivity/pharmaceuticalHypersensitivity/atcSubstance
PharmaceuticalHypersensitivityType.nonATCSubstance
alertInformation/alertInformationBody/hyperSensitivity/pharmaceuticalHypersensitivity/nonATCSubstance
PharmaceuticalHypersensitivityType.nonATCSubstanceComment
alertInformation/alertInformationBody/hyperSensitivity/pharmaceuticalHypersensitivity/nonATCSubstanceComment
PharmaceuticalHypersensitivityType.pharmaceuticalProductId
alertInformation/alertInformationBody/hyperSensitivity/pharmaceuticalHypersensitivity/pharmaceuticalProductId
OtherHypersensitivityType.hypersensitivityAgent
alertInformation/alertInformationBody/hyperSensitivity/otherHypersensitivity/hypersensitivityAgent
OtherHypersensitivityType.hypersensitivityAgentCode
alertInformation/alertInformationBody/hyperSensitivity/otherHypersensitivity/hypersensitivityAgentCode
SeriousDiseaseType.disease
alertInformation/alertInformationBody/seriousDisease/disease
TreatmentType.treatmentDescription
alertInformation/alertInformationBody/treatment/treatmentDescription
TreatmentType.treatmentCode
alertInformation/alertInformationBody/treatment/treatmentCode
TreatmentType.pharmaceuticalTreatment
alertInformation/alertInformationBody/treatment/pharmaceuticalTreatment
RestrictionOfCareType.restrictionOfCareComment
alertInformation/alertInformationBody/restrictionOfCare/restrictionOfCareComment
CommunicableDiseaseType.communicableDiseaseCode
alertInformation/alertInformationBody/communicableDisease/communicableDiseaseCode
CommunicableDiseaseType.routeOfTransmission
alertInformation/alertInformationBody/communicableDisease/routeOfTransmission
UnstructuredAlertInformationType.unstructuredAlertInformationHeading
alertInformation/alertInformationBody/unstructuredAlertInformation/unstructuredAlertInformationHeading
UnstructuredAlertInformationType.unstructuredAlertInformationContent
alertInformation/alertInformationBody/unstructuredAlertInformation/unstructuredAlertInformationContent
AlertInformationRelationshipType.typeOfAlertInformationRelationship
alertInformation/alertInformationBody/alertInformationRelationship/typeOfAlertInfomationRelationship
AlertInformationRelationshipType.relationComment
alertInformation/alertInformationBody/alertInformationRelationship/relationComment
RelatedAlertInformationType.documentId
alertInformation/alertInformationBody/alertInformationRelationship/relatedAlertInformation/documentId
MIM Funktionsstatus
Klass.attribut
Mappning mot XSD schema
FunctionalStatusAssessmentType
PatientSummaryHeaderType.documentId
functionalStatusAssessment/functionalStatusAssessmentHeader/documentId
PatientSummaryHeaderType.sourceSystemHSAId
functionalStatusAssessment/functionalStatusAssessmentHeader/sourceSystemHSAId
PatientSummaryHeaderType.documentTime
functionalStatusAssessment/functionalStatusAssessmentHeader/documentTime
PatientSummaryHeaderType.patientId
functionalStatusAssessment/functionalStatusAssessmentHeader/patientId
PatientSummaryHeaderType.accountableHealthcareProfessional
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional
HealthcareProfessionalType.authorTime
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional /authorTime
HealthcareProfessionalType.healthcareProfessionalHSAId
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalHSAId
HealthcareProfessionalType.healthcareProfessionalName
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalName
HealthcareProfessionalType.healthcareProfessionalRoleCode
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalRoleCode
HealthcareProfessionalOrgUnitType.orgUnitHSAId
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitHSAId
HealthcareProfessionalOrgUnitType.orgUnitname
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitname
HealthcareProfessionalOrgUnitType.orgUnitTelecom
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitTelecom
HealthcareProfessionalOrgUnitType.orgUnitEmail
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitEmail
HealthcareProfessionalOrgUnitType.orgUnitAddress
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitAddress
HealthcareProfessionalOrgUnitType.orgUnitLocation
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalOrgUnit/orgUnitLocation
HealthcareProfessionalType.healthcareProfessionalCareUnitHSAId
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalCareUnitHSAId
HealthcareProfessionalType.healthcareProfessionalCareGiverHSAId
functionalStatusAssessment/functionalStatusAssessmentHeader/accountableHealthcareProfessional/healthcareProfessionalCareGiverHSAId
LegalAuthenticatorType.legalAuthenticatorTime
functionalStatusAssessment/functionalStatusAssessmentHeader/legalAuthenticator/legalAuthenticatorTime
LegalAuthenticatorType.legalAuthenticatorHSAId
functionalStatusAssessment/functionalStatusAssessmentHeader/legalAuthenticator/legalAuthenticatorHSAId
LegalAuthenticatorType.legalAuthenticatorName
functionalStatusAssessment/functionalStatusAssessmentHeader/legalAuthenticator/legalAuthenticatorName
LegalAuthenticatorType.legalAuthenticatorRoleCode
functionalStatusAssessment/functionalStatusAssessmentHeader/legalAuthenticator/legalAuthenticator RoleCode
PatientSummaryHeaderType.approvedForPatient
functionalStatusAssessment/functionalStatusAssessmentHeader/approvedForPatient
PatientSummaryHeaderType.careContactId
functionalStatusAssessment/functionalStatusAssessmentHeader/careContactId
FunctionalStatusAssessmentBodyType
FunctionalStatusAssessmentBodyType.assessmentCategory
functionalStatusAssessment/functionalStatusAssessmentBody/assessmentCategory
FunctionalStatusAssessmentBodyType.comment
functionalStatusAssessment/functionalStatusAssessmentBody/comment
PADLType.typeOfAssessment
functionalStatusAssessment/functionalStatusAssessmentBody/padl/typeOfAssessment
PADLType.assessment
functionalStatusAssessment/functionalStatusAssessmentBody/padl/assessment
DisabilityType.disabilityAssessment
functionalStatusAssessment/functionalStatusAssessmentBody/disability/disabilityAssessment
DisabilityType.comment
functionalStatusAssessment/functionalStatusAssessmentBody/disability/comment
ResultType
result
ResultType.resultCode
result/resultCode
ResultType.errorCode
result/errorCode
ResultType.subcode
result/subcode
ResultType.logId
result/logId
ResultType.message
result/message
Tjänstekontrakt
GetCareDocumentation
GetCareDocumentation returnerar journalanteckningar för en patient. Sådana anteckningar är av typerna utredning, åtgärd/behandling, sammanfattning, samordning, inskrivning, slutanteckning som även inkluderar epikris, anteckning utan fysiskt möte, slutenvårdsanteckning samt besöksanteckning.
Meddelandeformatet baseras på NPÖ RIV 2.2.0 och är kompatibelt med HL7 v. 3 CDA v. 2. Mappning mot dessa hittas i bilaga [R3].
Version
3.0
Gemensamma informationskomponenter
Gemensamma informationskomponenter är typer gemensamma för användning i tjänstekontrakt i flera domäner. Nedan listas de gemensamma typer som används i kontraktet GetCareDocumentation.
Användning av datatyperna sker i enlighet med hur de är definierade, dvs. regler som anges för respektive datatyp och kardinalitet för de olika attributen ska följas. I de fall det finns restriktioner på en eller flera datatyper anges det i fältregeltabellerna.
Version 19 av gemensamma datatyper har använts för det här kontraktet.
CVType
En CVType är en referens till ett begrepp som definieras i ett externt kodverk (kodsystem, terminologi eller ontologi). Se vanligt förekommande kodverk. En CVType kan innehålla en enkel kod, det vill säga en hänvisning till ett begrepp som definieras direkt av det refererade kodverket, eller den kan innehålla ett uttryck i någon syntax definierad av det refererade kodverket som kan utvärderas, exempelvis begreppet “vänster fot” som är ett postkoordinerat uttryck byggt från den primära koden “FOT” och bestämningen “VÄNSTER”.
Namn
Datatyp
Beskrivning
Kardinalitet
code
string
Kod eller uttryck definierad enligt kodverket.
0..1
codeSystem
string
Kodverket som definierar koden.
0..1
codeSystemName
string
Kodverkets namn i klartext.
0..1
codeSystemVersion
string
Versionsangivelse som har definierats specifikt för det givna kodverket.
0..1
displayName
string
Den läsbara representationen (klartext) av koden eller uttrycket som definierat av kodverket.
0..1
originalText
string
Texten så som sedd och/eller vald av användaren som har matat in den, och som representerar användarens avsedda betydelse.
0..1
Regler
codecode ska vara en exakt match till en kod eller ett uttryck definierat av kodverket, som refereras till i codeSystem. Om kodverket definierar en kod eller ett uttryck som inkluderar mellanslag, ska koden inkludera mellanslaget. Ett uttryck kan endast användas där kodverket antingen definierar en uttryckssyntax, eller där det finns en allmänt accepterad syntax för kodverket.
Det åligger det mottagande systemet att bedöma om man kontrollerar huruvida det är ett uttryck som har skickats istället för en enkel kod, och utvärdera uttrycket istället för att behandla uttrycket som en kod. I vissa fall kan det vara oklart eller tvetydigt om koden representerar en enda symbol eller ett uttryck. Detta uppstår vanligtvis där kodverket definierar ett uttrycksspråk och sedan definierar prekoordinerade begrepp med symboler som matchar deras uttryck, t.ex. UCUM. I andra fall är det säkert att behandla uttrycket som en symbol. Det finns ingen garanti för att detta alltid är säkert: definitionerna i kodverket bör alltid konsulteras för att avgöra hur man ska hantera potentiella uttryck.
codeSystemKodverk ska refereras till genom en globalt unik identifierare, som möjliggör entydig hänvisning till standardkodverk eller andra lokala kodverk. Identifieraren ska vara en Universally Unique Identifier (UUID), Object Identifier (OID), eller Uniform Resource Identifier (URI). En CVType som har ett kodattribut ska ha ett kodverk som specificerar begreppsystemet som definierar koden.
codeSystemNameSyftet med ett kodverksnamn är att hjälpa en mänsklig tolkare av en kod att tolka codeSystem. Tjänstekonsumenter och tjänsteproducenter som använder codeSystemName ska INTE funktionellt förlita sig på kodverkets namn. Dessutom KAN de välja att inte implementera kodverkets namn men ska INTE avvisa instanser då namnet finns.
codeSystemVersionOlika versioner av ett kodverk måste vara kompatibla. Per definition ska en kod ha samma betydelse i alla versioner av ett kodverk. Mellan versioner kan koder inaktiveras men inte tas bort eller återanvändas. Om klartexten av en kod ändras måste den fortfarande vara kompatibel (lika) mellan olika kodverksversioner.
displayNameOm ifylld, ska klartexten vara den läsbara representationen av koden eller uttrycket som definierat av kodverket vid tiden av datainmatningen. Om kodverket inte definierar en klartext för koden eller uttrycket, kan ingen tillhandahållas. Tjänstekonsumenter och tjänsteproducenter som hävdar direkt eller indirekt överensstämmelse KAN välja att inte implementera klartext men ska INTE avvisa instanser då klartext finns.
Huvudsyfte med klartexten är att stödja implementationsfelsökning, men kan även användas till andra tillämpningsspecifika ändamål som till exempel visning för användaren i gränssnittet.
originalTextDet finns två godkända tillämpningar av elementet originalText:
OriginalText kan användas för att beskriva det en användare angav och som representeras av koden. I en situation där användaren dikterar eller skriver text är originalText den text som matats in eller yttrats av användaren.
OriginalText kan användas i de fall producenten avser ange ett värde som saknar kod. I dessa fall motsvarar originalText benämningen för värdet som saknar kod. Behov att tillföra nya koder till kodverket förmedlas till den som ansvarar för kodverkets innehåll.
OriginalText ska vara den exakta text så som den presenteras i originalkällan utan att på något sätt bearbetas eller omvandlas. Således ska originalText representeras i vanlig textform.
DatePeriodType
Ett datumintervall anges normalt sett med ett start- och ett slutdatum, men öppna intervall är tillåtna. Huruvida ändpunkterna inkluderas i intervallet eller ej bör tydligt beskrivas vid varje enskild tillämpning.
Namn
Typ
Beskrivning
Kardinalitet
start
DateType
Periodens startdatum. Minst ett av start och end skall anges.
0..1
end
DateType
Periodens slutdatum. Minst ett av start och end skall anges.
0..1
DateType
Datum anges som en sträng med formatet ”ÅÅÅÅMMDD”. Detta motsvarar den ISO 8601 och ISO 8824-kompatibla formatbeskrivningen ”YYYYMMDD”. Tidszon anges inte. Datum ska anges i tidszonerna CET (svensk normaltid) respektive CEST (svensk normaltid med justering för sommartid).
HSAIdType
HSA-id anges som en sträng enligt definition från Inera AB. I de fall då HSA-id inte finns tillgängligt ska ett för källsystemet lokalt id användas. Lokala id:n får enbart användas i OrgUnitType, och då endast i undantagsfall.
IIType
En IIType är en numerisk eller alfanumerisk sträng som kan härledas till ett enskilt objekt eller entitet i ett känt system. Exempel är ett personnummer eller ett vårdkontakts-id.
Namn
Datatyp
Beskrivning
Kardinalitet
root
string
En identifierare som i sig själv eller tillsammans med värdet för extension är universellt unik. Om extension anges är root en unik identifierare av namnrymden för värdet som anges i extension.
1..1
extension
string
En identifierare som tillsammans med värdet för root är universellt unik. Används om värdet på root inte är universellt unikt.
0..1
MultimediaType
Namn
Datatyp
Beskrivning
Kardinalitet
id
string
Identitet på multimediaobjekt som används vid referenser inom multimediadokument.
0..1
mediaType
MediaTypeEnum
Mediatyper enligt HL7
1..1
value
base64Binary
Value är binärdata som representerar objektet. Ett och endast ett av value och reference ska anges.
0..1
reference
anyURI
Referens till extern bild i form av en URL. Ett och endast ett av value och reference ska anges.
0..1
OrgUnitType
Namn
Datatyp
Beskrivning
Kardinalitet
orgUnitHSAId
HSAIdType
HSA-id för organisationsenhet. Om tillgängligt skall detta anges. I de fall HSA-id saknas kan ett för källsystemet unikt id användas.
0..1
orgUnitName
string
Namn på organisationsenhet. Om tillgängligt skall detta anges.
0..1
orgUnitTelecom
string
Telefon till organisationsenhet.
0..1
orgUnitEmail
string
Epost till organisationsenhet.
0..1
orgUnitAddress
string
Postadress till organisationsenhet. Skrivs på ett så naturligt sätt som möjligt, exempelvis:”Storgatan 12468 91 Lilleby”
0..1
orgUnitLocation
string
Text som anger namnet på plats eller ort för enhetens eller funktionens fysiska placering
0..1
ResultType
Element för att returnera logiska fel i uppdaterande tjänster. Ska inte definieras som egen typ utan inkluderas i svarstypen.
Namn
Datatyp
Beskrivning
Kardinalitet
resultCode
ResultCodeEnum
Kan endast vara OK, INFO eller ERROR.
1..1
resultText
string
En beskrivande text som kan visas för användaren.
0..1
TimeStampType
Tidpunkt anges som en sträng med formatet ”ÅÅÅÅMMDDttmmss”. Detta motsvarar den ISO 8601 och ISO 8824-kompatibla formatbeskrivningen ”YYYYMMDDhhmmss”. Tidszon anges inte. Tidpunkt ska anges i tidszonerna CET (svensk normaltid) respektive CEST (svensk normaltid med justering för sommartid).
JoL-header
Detta kontrakt använder en gemensam header som används vid läsning av journalinformation. Headern är uppdelad i två huvudsakliga delar. Den första innehåller information för att ett konsumerande system ska kunna avgöra om en användare har rätt att ta del av den returnerade informationen. För detta beslut krävs bland annat information om vilken vårdgivare och vårdenhet som är informationsägare samt vilken tidpunkt som skall användas som jämförelsetid vid spärrkontroll. Den andra delen av headern innehåller metainformation som är gemensam för patientjournalinformation, exempelvis uppgift om vilken hälso- och sjukvårdspersonal som är angiven som författare av informationen och information om signering.
Version 2.2 av JoL-headern har använts för det här kontraktet.
DocBook-format för clinicalDocuemtNoteText-fältet
Fältet ”clinicalDocumentNoteText” innehåller anteckningens textuella innehåll. Producenten har möjlighet att formatera denna text i sina system i det standardiserade layout-formatet DocBook version 5.0 [R11], som är en Oasis standard.
En tjänstekonsument eller tjänsteproducent behöver inte stödja samtliga element i DocBook-standarden. Följande element är centrala och ska hanteras av samtliga tjänstekonsumenter.
version
article
title
info
para
section
bibliography
En tjänstekonsument kan utöver dessa element specificera regler kring användningen av ytterligare element i en interaktionsöverenskommelse.
En tjänsteproducent kan välja att hantera elementen ovan men kan även välja att följa reglerna i en eventuell interaktionsöverenskommelsen vid formatering av text med DocBook anpassad för en specifik tjänstekonsument. Tjänsteproducenten ska då baserat på information i http-headern ”x-rivta-original-serviceconsumer-hsaid” [R2] identifiera tjänstekonsumenten och anpassa svaret baserat på interaktionsöverenskommelsens regler.
En tjänsteproducent får inte använda andra element i DocBook-standarden som inte ingår i listan ovan eller i tjänstekonsumentens interaktionsöverenskommelse.
En text som är formaterad enligt DocBook ska vara s.k. ”entity encoded” för att kunna skickas via fältet “clinicalDocumentNoteText”. Detta behövs för att XML-taggarna, som är en del av DocBook-formatet som används för att formatera texten som utgör fältets innehåll, inte ska uppfattas som en del av svarsmeddelandets XML-struktur. Vid den s.k. entity encoding översätts exempelvis de nedanstående symbolerna på angivit sätt:
översätts till >
< översätts till <
“ översätts till "
Kolumnen “DocBook-element” i tabellen nedan visar en exempelstruktur med de DocBook-element som kan användas. Kolumnen “DocBook-element med entity encoding” visar samma DocBook-element med entity encoding, och därmed det formatet som kan skickas via fältet “clinicalDocumentNoteText”.
Konsumenten behöver sedan återskapa den ursprungliga DocBook XML-syntaxen från innehållet i fältet, dvs översätta t.ex. > till >. Det finns många exempel på open-source-bibliotek som kan användas av producenten för att göra ”entity encoding” och av konsumenten för att återställa till XML-syntaxen. Ett exempel är Apache Commons Text StringEscapeUtils (se metoderna escapeXml respektive unescapeXml) [R12].
Efter att konsumenten har återställt texten till den ursprungliga XML-syntaxen, behöver konsumenten även transformera texten till ett presentationsformat såsom XHTML eller PDF. Det kan t.ex. ske med hjälp av de XSLT-baserade transformeringsskript som tillhandahålls på DocBooks hemsida [R11].
DocBook-element
DocBook-element med entity encoding
Fältregler
Nedanstående tabell beskriver varje element i begäran och svar. Finns ytterligare regler för ett element är det noterat med referens till regeln i beskrivningen och beskrivs mer i detalj i stycket Övriga regler.
Namn
Typ
Beskrivning
Kardinalitet
Begäran
careUnit
IIType
Filtrering på vårdenhet vilket motsvarar accountableCareUnit i svaret.
root sätts till OID(1.2.752.129.2.1.4.1) för HSA
extension sätts till HSA-id på vårdenhet.
0..*
healthcareProvider
IIType
Filtrering på vårdgivare vilket motsvarar accountableHealthcareProvider i svaret.
root sätts till OID (1.2.752.129.2.1.4.1) för HSA
extension sätts till HSA-id på vårdgivare.
0..*
patientId
IIType
Id för patienten där fältet extension sätts till patientens identitetsbeteckning. Anges med 12 tecken utan avskiljare.
Tjänsteproducenten ska i svaret leverera all information om patienten på en begäran riktad mot någon av patientens identitetsbeteckningar, dvs. även information som har registrerats på andra till patienten kopplade identitetsbeteckningar (personnummer, samordningsnummer eller lokala reservnummer).
Fältet root sätts till OID för typ av identifierare. 1) För personnummer ska Skatteverkets OID för personnummer (1.2.752.129.2.1.3.1) användas.
2) För samordningsnummer ska Skatteverkets OID för samordningsnummer (1.2.752.129.2.1.3.3) användas.
3) Tjänsteproducenter ska även stödja sökning på lokal reservidentitet med hjälp av att ange lokalt definierade OID:ar för lokal reservidentitet, exempelvis SLL:s lokal reservidentitet (1.2.752.97.3.1.3).
OBS lokal reservidentitet kan ej användas tillsammans med EI och aggregerande tjänster då dessa komponenter idag inte är anpassade för att stödja typ av id, inga uppdateringar till EI ska göras av en tjänsteproducent för lokal reservidentitet.
En tjänstekonsument som vill begära mha. lokal reservidentitet måste därmed använda sig av systemadressering och ha vetskap om vilken OID för den specifika lokala reservidentitet som gäller vid anrop mot en specifik tjänsteproducent.
1..1
datePeriod
DatePeriodType
Begränsar sökningen till det angivna intervallet. Begränsningen innebär att endast poster returneras där någon av tidpunkterna record.timestamp, author.timestamp, signature.timestamp i headern eller dissentingOpinion.authorTime i svaret ligger inom sökintervallets start- och slutdatum.
Notera att sökintervallet beskrivs som ett datumintervall. Vid jämförelse konverteras datapostens tidpunkter till datum.
0..1
../start
string
Startdatum. Format ÅÅÅÅMMDD.
1..1
../end
string
Slutdatum. Format ÅÅÅÅMMDD.
1..1
sourceSystemId
IIType
Begränsar sökningen till anteckningar som är skapade i det angivna källsystemet. Tjänsteproducenten förväntas enbart returnera poster som tillhör efterfrågat källsystem.
Fältet root sätts till OID för HSA-katalogen (1.2.752.129.2.1.4.1) och fältet extension sätts till källsystemets HSA-id.
Se även regel sourceSystemId.
0..1
hasMoreReference
string
Kan anges av tjänstekonsument när man tidigare fått ett hasMore-svar från tjänsteproducent att det finns ytterligare information att hämta.
Se även regel hasMoreReference.
0..1
Svar
careDocumentation
CareDocumentationType
De anteckningar som matchar begäran.
0..*
../header
HeaderType
JoL-header.
Innehåller metainformation som är gemensam för patientjournalinformation, exempelvis uppgift om vilken hälso- och sjukvårdspersonal
som är angiven som författare av informationen och information om signering.
1..1
../../accessControlHeader
AccessControlHeaderType
Information för kontroll av åtkomst.
Syftet med denna del av headern är att den ska innehålla den information som behövs för konsumentens filtrering av informationen innan den visas upp för slutanvändaren eller på annat vis behandlas vidare, exempelvis för kontroll av spärrar (avseende vårdpersonals åtkomst till information; PDL) eller om informationen får visas för patienten eller inte (verksamhetens rätt till rådrum och menprövning).
En konsument (en konsumerande tjänst/applikation) har inte rätt att ta del av något annat än innehållet i accessControlHeader innan de för ändamålet nödvändiga säkerhetskontrollerna har utförts.
1..1
../../../accountableHealthcareProvider
IIType
Id för informationsägande vårdgivare.
I första hand HSAid alternativt i andra hand organisationsnummer.
Om HSA-id används sätts fältet root till oid för HSA-katalogen (1.2.752.129.2.1.4.1) och fältet extension sätts till HSA-id.
Om organisationsnummer används skall fältet root sättas till OID för organisationsnummer (1.2.752.29.4.3) och fältet extension sättas till organisationsnumret.
Enskild näringsidkare har i rollen som juridisk person sitt personnummer som organisationsnummer.
Se även regel Spärrhantering.
0..1
../../../accountableCareUnit
IIType
Id för informationsägande vårdenhet angivet med HSA-id.
Fältet root sätts OID för HSA-katalogen (1.2.752.129.2.1.4.1) och fältet extension sätts till HSA-id.
Fältet används för spärrkontroll och är obligatorisk om uppgiften i patientjournal ska kunna ses via sammanhållen journalföring.
Se även regel Spärrhantering.
0..1
../../../patientId
IIType
Patientens identitetsbeteckning. Den identitetsbeteckning som denna uppgift lagrades under när uppgiften skapades ska om möjligt anges. Exempel på en situation då detta förekommer är exempelvis då patienten tidigare erhållit vård dokumenterat under ett samordningsnummer för att sedan bli folkbokförd i Sverige och få ett personnummer.
Fältet root sätts till OID för kodverket för identifieraren:
1) För personnummer skall Skatteverkets OID för personnummer (1.2.752.129.2.1.3.1) användas.
2) För samordningsnummer skall Skatteverkets OID för samordningsnummer (1.2.752.129.2.1.3.3) användas.
Fältet extension sätts till patientens identifierare. Anges med 12 tecken utan avskiljare.
1..1
../../../careProcessId
IIType
Id för den individanpassad vårdprocess som informationen journalförts inom ramen för. Består av ett lokalt genererat UUID.
UUID anges i root och extension lämnas tomt.
0..1
../../../blockComparisonTime
TimeStampType
Den tidpunkt mot vilken spärrkontroll sker vid åtkomst med syftet sammanhållen journalföring för kontroll av patientens (ev.) spärrade information, såväl yttre (mellan vårdgivare) som inre (mellan vårdenheter) spärr.
Tidpunkten ska i så hög grad som möjligt överensstämma med den tidpunkt som ur patientens synvinkel är den mest naturliga. Detta är vanligtvis tidpunkten för patientens vårdkontakt som låg till grund för dokumentationen.
1..1
../../../approvedForPatient
boolean
Ansvarig vårdpersonals beslut, alternativt baserat på verksamhetens policy och regler (men-/sekretessprövning), huruvida informationen får delas till patient för ändamålet Patients åtkomst (Individens direktåtkomst).
Om information beslutas delas sätts värdet i sådant fall till true, i annat fall till false. False innebär att informationen inte får delas till patient.
Notera att flaggans värde kan, för samma information, förändras med tiden på grund av att rådrumstid har passerats, eller att verksamheten ändrat policy för vad som lämnas ut till patient.
I sådana fall skall källsystemet uppdatera engagemangsindex för att konsumenter skall kunna bli notifierade därom.
1..1
../../sourceSystemId
IIType
Det källsystem som informationen lagras i.
Fältet root sätts till OID för HSA-katalogen (1.2.752.129.2.1.4.1) och fältet extension sätts till källsystemets HSA-id.
1..1
../../record
RecordType
Uppgift i patientjournal
Metainformation avseende den dokumenterade informationen.
1..1
../../../id
IIType
Unik och beständig identifierare för uppgift i patientjournal.
För att vara konsistent och beständig med tidigare majorversioner ska tjänsteproducenter av tidigare majorversioner av GetCareDocumentation endast ange root på samma sätt som documentId i tidigare majorversioner.Extension utelämnas. Denna hantering krävs för att tjänstekonsumenten ska kunna filtrera bort dubbletter.
Identifieraren ska vara konsistent och beständigt mellan olika kontrakt. Ett exempel på detta är att samma remiss-identitet ska användas i ett tjänstekontrakt för att läsa remisser, samt tjänstekontraktet som läser remissvar som refererar till den ursprungliga remissen.
Se även regel Verify unique recordId.
1..1
../../../timestamp
TimeStampType
Första tidpunkten då denna journalinformation skapades hos tjänsteproducenten.
1..1
../../author
AuthorType
Hälso- och sjukvårdspersonal som ansvarar för information i patientjournal. Notera att den som registrerar informationen från annan källa, exempelvis en medicinsk sekreterare som transkriberar ett diktat, inte är författare.
0..1
../../../id
IIType
HSA-id för hälso- och sjukvårdspersonal.
Fältet root sätts till oid för HSA-id (1.2.752.129.2.1.4.1) och fältet extension sätts till HSA-id.
0..1
../../../name
string
Namn på hälso- och sjukvårdspersonal.
0..1
../../../timestamp
TimeStampType
Tidpunkt vid vilken journalinformationen skapades eller senast uppdaterades hos tjänsteproducenten. I de fall då journalinformationen skapats i ett annat informationssystem (t.ex. laboratoriesystem eller annan remittents journalsystem) är det tidpunkten då journalinformationen ursprungligen skapades som ska anges.
1..1
../../../byRole
CVType
Information om hälso- och sjukvårdspersonalens befattning vid författandet av informationen. Om möjligt skall kod från kodverket KV Befattning användas för att ange personens befattning så som den var angiven i HSA-katalogen vid tidpunkten. Om kod inte är tillgänglig anges befattning i klartext i CV-typens attribut originalText.
0..1
../../../orgUnit
OrgUnitType
Den organisation som författaren är uppdragstagare på.
0..1
../../signature
SignatureType
Signeringsinformation
0..1
../../../id
IIType
HSA-id för hälso- och sjukvårdspersonal som signerat uppgift i patientjournal.
Fältet root sätts till oid för HSA-id (1.2.752.129.2.1.4.1) och fältet extension sätts till HSA-id.
0..1
../../../name
String
Namn på hälso- och sjukvårdspersonal som signerat uppgift i patientjournal.
0..1
../../../timestamp
TimeStampType
Anger tidpunkten för signering av uppgift i patientjournal.
0..1
../../../byRole
CVType
Information om hälso- och sjukvårdspersonalens befattning vid författandet av informationen. Om möjligt skall KV Befattning användas för att ange personens befattning så som den var angiven i HSA-katalogen vid tidpunkten. Om kod inte är tillgänglig anges befattning i klartext i CV-typens attribut originalText.
0..1
../body
CareDocumentationBodyType
Journalanteckning
1..1
../../clinicalDocumentNoteCode
CVType
Typ av anteckning. Kod tas från KV Anteckningstyp (1.2.752.129.2.2.2.11).
Kodverket kan komma att kompletteras över tid vilket medför att konsumenter av kontraktet behöver vara förberedda på att nya koder kan tillkomma utan att versionen på tjänstekontraktet uppdateras.
1..1
../../clinicalDocumentNoteTitle
string
Titel på anteckningen.
0..1
../../clinicalDocumentNoteText
string
Journalanteckningens innehåll i text.
Texten kan antingen skickas som vanlig text eller formaterat enligt DocBook-standarden, se 7.1.3.
Se även regel careDocumentationBody.
0..1
../../multimediaEntry
MultimediaType
Journalanteckningens innehåll i form av en multimediaobjekt, i form av antingen ett inbäddat objekt eller en länk till objektet.
Vid användning av multimediaEntry kompletteras reglerna i tjänstekontraktsbeskrivningen med en Interaktionsöverenskommelse som ytterligare beskriver integrationen.
Se även regel careDocumentationBody samt regel Binära bilagor.
0..1
../../../mediaType
string
Typ av multimedia.
Se interaktionsöverenskommelse för beskrivning av typer som hanteras.
1..1
../../../value
base64Binary
Value är binärdata som representerar objektet. Ett och endast ett av attributen value och reference ska anges.
Se även regel multimediaEntry.
0..1
../../../reference
anyURI
Referens till extern binär fil i form av en URL om interaktionsöverenskommelsen tillåter detta. Ett och endast ett av attributen value och reference ska anges.
Se interaktionsöverenskommelse för ytterligare beskrivning.
Se även regel multimediaEntry.
0..1
../../dissentingOpinion
DissentingOpinionType
Om patienten eller någon för denna ansvarig person (exempelvis vårdnadshavare) har lämnat en avvikande mening till journalanteckningen.
0..*
../../../opinionId
IIType
En universellt unik identifierare för den avvikande meningen. Identifieraren ska vara beständig, i betydelsen att upprepade frågemeddelanden ger samma värde i svarsmeddelanden som rör samma journalnotat.
0..1
../../../../root
string
En universellt unik identifierare för den avvikande meningen eller en identifierare som tillsammans med värdet för ”extension” ger en universellt unik identifierare.
1..1
../../../../extension
string
Om värdet på root inte universellt unikt ska detta fält innehålla ett kompletterande värde som tillsammans med värdet för root ger en universellt unik identifierare.
0..1
../../../authorTime
TimeStampType
Tidpunkten då den avvikande meningen författades.
1..1
../../../opinion
string
Text som innehåller den avvikande meningen.
1..1
../../../personId
IIType
Id för författaren av den avvikande meningen.
1..1
../../../../root
string
Sätts till OID för typ av identifierare. För personnummer ska Skatteverkets personnummer (1.2.752.129.2.1.3.1) ), [R14].För samordningsnummer ska Skatteverkets samordningsnummer (1.2.752.129.2.1.3.3) ), [R14].För reservnummer används lokalt definierade reservnummet, exempelvis SLL reservnummer (1.2.752.97.3.1.3) ), [R14].
1..1
../../../../extension
string
Sätts till personens identifierare. Anges med 12 tecken utan avskiljare.
1..1
../../../personName
string
Namnet på författaren av den avvikande meningen.
1..1
hasMore
HasMoreType
Anges av tjänsteproducent när det finns ytterligare information att hämta.
Not: Vid svar från tjänsteproducent är kardinaliteten 0..1.
Se även regel Partiell datahämtning.
0..*
../logicalAddress
string
Den logiska adressen till tjänsteproducenten som genererar svaret och har mer information.
1..1
../reference
string
En unik identifierare som tjänstekonsumenten anger i nästa anrop för att hämta mer data. Om det då finns ytterligare mer information hos tjänsteproducenten ska en ny, unik identifierare levereras.
Tjänsteproducenten avgör hur referensen byggs upp.
Exempel: Base64({ ”queryHash” : ”7114efbb6a761fb1a2d6dae55b5612e1”, ”lastReturnedId” : 7685824}) = eyDigJ1xdWVyeUhhc2jigJ0gOiDigJ03MTE0ZWZiYjZhNzYxZmIxYTJkNmRhZTU1YjU2MTJlMSIsIOKAnWxhc3RSZXR1cm5lZElk4oCdIDogNzY4NTgyNH0=
Re även regel Referensens giltighetstid.
1..1
result
ResultType
Innehåller information om det gick bra eller ej att besvara förfrågan.
Se avsnitt 7.1.7 för beskrivning av hantering vid logiska fel.
1..1
../resultCode
ResultCodeEnum
Anger resultatet av besvarad förfrågan.
Kan endast vara OK, INFO eller ERROR.
1..1
../resultText
string
Optionellt felmeddelande som innehåller information om felet som uppstod.
0..1
Partiell datahämtning
GetCareDocumentation möjliggör partiell leverans och hämtning av vårdanteckningar. Detta bör endast användas av de tjänsteproducenter som har uttömt möjligheterna att möta svarstidskraven eller krav på meddelandestorlek för tjänstekontraktet. Att stödja partiell datahämtning är frivilligt för både tjänstekonsument och tjänsteproducent.
Partiell datahämtning initieras av tjänsteproducenten genom att leverera den senaste journalinformationen, plus elementet hasMore med en unik referens.
Vid flera partiella leveranser ska tjänsteproducenten alltid leverera den senaste informationen som inte tidigare levererats i omvänd kronologisk ordning. I det fall information som redan levererats har uppdaterats kan producenten välja att på nytt skicka den uppdaterade informationen i kommande anrop. I det fall ny information tillkommer under den tid då referensen är giltig kan producenten välja att inkludera den nya informationen.
Ambitionen bör vara att skicka så många poster som möjligt under svarstidskravet eller krav på meddelandestorlek för tjänstekontraktet vid varje partiell leverans. Detta då det är frivilligt för tjänstekonsumenter att stödja funktionen samt för att möjliggöra en så bra upplevelse som möjligt för slutanvändaren då en tjänstekonsument kan ha valt att endast hämta nästkommande partiella leverans på slutanvändarens kommando.
Tjänstekonsumenter väljer själva hur och om de vill hämta resterande information, eller om de vill nöja sig med den information som levererats. Om mer information ska hämtas, så ska anropet direktadresseras till aktuell tjänsteproducent, begäran ska innehålla attributet hasMoreReference och övriga anropsparametrar ska vara identiska med anropet som föranledde hasMore-svar.
Övriga regler
Till detta tjänstekontrakt finns regler som ej uttrycks i schemafilerna och tabellen ovan. Dessa återfinns nedan. Regler markerade med [sch] återfinns i schematron (constraints).
ID
Element
Beskrivning
Begäran
hasMoreReference