1. Indledning

Denne vejledning beskriver de tekniske forretningsregler i forhold til at integrere til graviditetsmappen fra lokalt fagsystemer samt borgerrettede systemer under projekt  for Digital Løsning til Graviditetsforløb. Vejledningen er tiltænkt forretningsarkitekter, systemarkitekter samt systemleverandører.

På nationalt plan er der udarbejdes der en indholdsprofil ud fra HL7's Clinical Document Architecture  (CDA), som beskriver de graviditetsrelaterede data vedrørende den gravide. Indholdsprofilen er forankret hos MedCom.
CDA-dokumenter omfattet af graviditetsmappen skal, på nationalt plan, udstilles via den nationale delingsinfrastruktur, og der skal foretages en registrering af CDA-dokumenterne i det nationale “IHE XDS Registry”, således at graviditetsrelateret data i graviditetsmappen kan fremfindes på tværs af sundhedsvæsenets aktører.
For aktører i sundhedsvæsenet, der ikke ønsker at etablere et eget “IHE XDS repository” til opbevaring af CDA-dokumenter, stilles et statsligt repository til rådighed i forhold til opbevaring af graviditetsrelaterede CDA-dokumenter.

De aktører, som understøtter den gravide under graviditetsforløbet, kan via deres fagsystemer anvende de standardiserede IHE XDS snitflader til at dele information om oprettede, ændrede og annullerede graviditetsrelaterede dokumenter vedrørende den gravide.

Den nationale delingsinfrastruktur udstilles gennem dokumentdeling- og dokumentregistreringsservices via standardiserede IHE XDS snitflader tilpasset den nationale sikkerhedsinfrastruktur, som bl.a. omhandler autorisation, samtykkekontrol, auditlogning etc.

2. Anden dokumentation

De overordnede forretningsregler til Digital Løsning til Graviditetsforløb kan ses i dokumentet: Indhold og forretningsregler

Udveksling af data om den gravides gravidtetsmappe foregår via den nationale delingsinfrastruktur. Denne understøtter referencearkitekturen for deling af dokumenter og billeder.

For generel introduktion til den nationale delingsinfrastruktur, se vejledningen ’Kom godt i gang med dokumentdeling’ til deling af dokumenter via Dokumentdelingsservice på NSP lavet af MedCom.

For detaljeret teknisk dokumentation omkring dokumentdeling via NSP, se beskrivelsen på Dokumentdeling på NSP (DROS, DDS, NXRG/SDS Patientindex, OpenXDS)

3. Teknisk oversigt

3.1. Indhold i Graviditetsmappen

MedCom har sendt CDA standarderne til Graviditetsmappen i høring, der er derfor ikke tilgængelige under http://svn.medcom.dk/svn/drafts/Standarder/HL7/ endnu. Testprotokoller og eksempler er ligeledes ikke udarbejdede endnu.


Først og fremmest skal man kende til det indholdsformat der benyttes til CDA dokumenterne i Graviditetsmappen. Formatet er XML og indholdet er specificeret som en dansk profil af CDA. Der deles 3 dokumenttyper i Graviditetsmappen, som alle er forankrede hos MedCom der står for den danske profilering. Se under MedComs draft folder hvor både beskrivelse af standarderne samt forskellige eksempler opbevares (Bemærk info boksen, der nævner disse ikke er tilgængelige endnu...)

  1. Digital vandrejournal (Pregnancy Shared Care Record, forkortet PSCR)
  2. Digital svangerskabsjournal (Pregnancy Referral Form, forkortet PRF)
  3. Kliniske målinger (Care Measurement Report, forkortet CMR)

De 3 dokumenttyper er definerede i den logiske model udstillet under Indhold og forretningsregler, MedComs CDA standarder beskriver den fysiske model som anvendes til datadeling.

Et CDA dokument består af en header og en body, hvor headeren generelt beskriver en række metadata omkring dokumentets indhold, mens de dokumentspecifikke data placeres i body sektionen.

Indholdet i CDA headeren er fælles for alle danske CDA dokumenter, og er ligeledes forankret hos MedCom, se under MedCom CDA Header v. 1.4. I forbindelse med CDA dokumenterne i graviditetsmappen er der tilføjet et GraviditetsforløbsID til CDA headeren, som ikke er inkluderet i CDA Header v. 1,4 standarden - dette er beskrevet under: TODO: Indsæt når MedCom frigiver standarderne

Systemer der tilsluttes Graviditetsmappen, skal bl.a. godkendes af MedCom ud fra en certificering samt af Sundhedsdatastyrelsen i forhold til den tekniske implementering. Testprotokollerne for certificering til Graviditetsmappen, kan findes på MedCom's hjemmeside under: TODO: Indsæt når MedCom frigiver standarderne
Krav til test og godkenddelse kan ses under: Godkendelsestest for tilslutning til Graviditetsmappen

Yderligere information om hvordan CDA dokumenter er opbygget kan findes hos IHE, under: IHE - Hvad er HL7 CDA?

3.2. Tekniske forudsætninger

Se Administrative forudsætninger for at få adgang til NSP'en.

Graviditetsmappen udstilles via services på NSP'en, disse skal tilgås gennem en afkoblingskomponent "DCC'en". DCC'en viderestiller kald til underliggende services, så der er ikke en WSDL for DCC'en. Se DCC Dokumentation for adgang til services gennem DCC'en.

Det er et krav at dokumentdelingsservicen skal tilgås gennem afkoblingskomponenten

NSP services kan tilgås enten via Den Gode Webservice (DGWS) eller via OIO-IDWS (Udelukkende borger adgang). 
Den Gode WebService (DGWS) benytter XMLDSIG til at signere SAML assertions ud fra X.509 certifikater/nøgler - for adgang til graviditetsmappen skal sundhedspersoner have et STS-underskrevet SOSI-ID kort på niveau 4 (medarbejder), hvilket også er beskrevet under administrative forudsætninger, således at borgeren har mulighed for at lave en spærring så Graviditetsmappen ikke kan deles med specifikke sundhedspersoner, samt at patienten har mulighed for at se hvem der har haft adgang til patientens Graviditetsmappe via MinLog.
For mere information om den gode webservice, se: https://www.medcom.dk/standarder/webservice-standarder/den-gode-webservice

Sundhedsdatastyrelsen har beskrevet hvordan et SOSI-ID kort kan skabes og anvendes under STS Dokumentationen

De servicesnitflader der udstilles til Graviditetsmappen er alle baseret på SOAP kald der understøtter DGWS.
Indholdsdelen af den enkelte servicekald (SOAP body) er den del der er specificeret af IHE XDS snitfladerne, dvs. for eksempel ITI-18 og ITI-43, se nærmere beskrivelse under: Dokumentdeling på NSP (DROS, DDS, NXRG/SDS Patientindex, OpenXDS)

De detaljerede beskrivelser af snitfladerne findes i IHE IT Infrastructure Technical Framework dokumenterne volume 1, 2a, 2b, 2x og 3.

Beskrivelserne i de officielle dokumenter fra IHE er relativt komplicerede, og det kan være svært at opnå et godt overblik over hvordan specifikke kald sættes sammen. Der findes en række generelle og praktiske eksempler og programmer på IPF Open eHealth Integration Platform siderne. Se for eksempel:

3.3. Søgning på dokumenter i Graviditetsmappen

For at søge efter dokumenter i en borgers Graviditetsmappe, skal der laves en ITI-18 forespørgsel via NSP'ens dokumentdelingsservice.

WSDL til DDS Registry findes her: https://wsdl.nspop.dk/ddsregistry?wsdl

Når der søges, kan der søges på de værdier, der er angivet som XDS-metadata. Graviditetsmappe benytter metadata profil version 0.96, der kan hentes på https://svn.medcom.dk/svn/releases/Standarder/IHE/DK_profil_metadata/

Borgerens CPR-nummer (PatientId) samt dokumenternes statuskode (Status) er påkrævede felter, som skal inkluderes i alle søgninger.

For Graviditetsmappen, er der desuden følgende forretningsmæssige XDS-metdata, som skal anvendes i søgninger:

  • Typecode: TODO, er under høring via MedCom's CDA standarder

Desuden anbefales det at forespørge både efter specifikt format samt statiske og dynamiske (on-demand) dokumentkilder, angives denne værdi ikke, returneres kun data fra statiske dokumentkilder.

  • Type
    • urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 (for statiske dokumentkilder)
    • urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 (for dynamiske "on-demand" dokumentkilder)
  • FormatCode: TODO, er under høring via MedCom's CDA standarder

Værdierne (klassifikationerne) som anvendes i XDS-metadata er defineret i et regneark hos MedCom, se: DK-IHE_Metadata-Common_Code_systems-Value_sets.xlsx

XDS metadata, typecode og formatcode er endnu ikke beskrevet i MedCom's regneark: DK-IHE_Metadata-Common_Code_systems-Value_sets.xlsx 

For henholdsvis AND og OR søgninger gælder det at angives der flere søgeværdier i samme <slot> så tæller det som en OR søgning for disse værdier. Hvor der mellem de forskellige <slot> tæller som en AND søgning.

De detaljerede tekniske informationer om ITI-18 og angivelse af søgeparametre, kan ses i IHE ITI dokumentation volume 2

Eksempel på en ITI-18 forespørgsel efter digtal vandrejournal, digital svangerskabsjournal samt kliniske målinger:

ITI-18 AdhocQueryRequest 
<ns3:AdhocQueryRequest xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
			<ns3:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
			<AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
				<Slot name="$XDSDocumentEntryTypeCode">
					<ValueList>
						<Value>TODO - Typecode for Digital Vandrejournal</Value>
 						<Value>TODO - Typecode for Digital Svangerskabsjournal</Value>
  						<Value>TODO - Typecode for Kliniske målinger</Value>
                     </ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryFormatCode">
					<ValueList>
 						<Value>TODO - Formatcode for Digital Vandrejournal</Value>
 						<Value>TODO - Formatcode for Digital Svangerskabsjournal</Value>
  						<Value>TODO - Formatcode for Kliniske målinger</Value>
                     </ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryPatientId">
					<ValueList>
						<Value>'2512489996^^^&1.2.208.176.1.2&ISO'</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryType">
					<ValueList>
						<Value>('urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248')</Value>
						<Value>('urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1')</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryStatus">
					<ValueList>
						<Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value>
					</ValueList>
				</Slot>
			</AdhocQuery>
</ns3:AdhocQueryRequest>


Retur-svaret indeholder referencerne til dokumenterne i graviditetsmappen, der skal benyttes efterfølgende til at udtrække de konkrete dokumenter i Graviditetsmappen

ITI-18 AdhocQueryResponse 
		<ns3:AdhocQueryResponse xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns7="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns8="http://www.w3.org/2000/09/xmldsig#" xmlns:ns9="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns10="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" totalResultCount="3" status="urn:ihe:iti:2007:ResponseStatusType:Success">
			<RegistryObjectList>
TODO - Indsæt eksempel på svar når MedCom frigiver standarderne

			</RegistryObjectList>
		</ns3:AdhocQueryResponse>

3.4. Søgning ud fra GraviditetsforløbsID

MedCom er i spidsen for en arbejdsgruppe, som skal afklare hvordan det kan muliggøres at sammenkæde dokumenter i Graviditetsmappen under et specifiks GraviditetsforløbsID

TODO: Når arbejdsgruppen er kommet frem til en konklusion, vil der blive refereret til den herfra

3.5. Hentning af dokumenter i Graviditetsmappen

Bemærk for at hente en dokumenter i Graviditetsmappen på baggrund af en søgning, skal NSP's Service Deklaration: "Særlige begrænsninger ift. anvendelse af Dokumentdelingsservicen (DDS)" følges.

Se: Dokumentdelingsservice (DDS)

Opsummeret står der følgende: Der må højst være 10 minutter mellem disse kald (ITI-18 og ITI-43), begge kald skal udføres af samme bruger, og begge kald skal have samme (men unikke)  ‘flowID’

Der er tre værdier fra retursvaret på ITI-18 forespørgslen som skal benyttes for at hente indholdet af et konkret dokuement i Graviditetsmappen:

  1. HomeCommunityId - der beskriver det domæne dokumentet befinder sig i.

    Værdien hentes ud fra ...ExtrinsicObject/@home

  2. RepositoryUniqueId - der bekriver den kilde under domænet der opbevarer dokumentet
    Værdien hentes ud fra ...ExtrinsicObject/Slot[@name=’repositoryUniqueId’]/Value List/Value
  3. DocumentUniqueId - der identificerer selve dokumentet
    Værdien hentes ud fra ...ExtrinsicObject/ExternalIdentifier[@identificationScheme=’urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab]/@value

Ud fra disse værdier skal der laves en ITI-43 forespørgsel via NSP'ens dokumentdelingsservice.

Som beskrevet ovenfor benyttes de tre værdier: HomeCommunityId, RepositoryUniqueId og DocumentUniqueId til at hente dokumenterne.

WSDL til DDS Repository findes her: https://wsdl.nspop.dk/ddsrepository?wsdl

ITI-43 RetrieveDocumentSetRequest 
        <RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007">
            <DocumentRequest>
                <HomeCommunityId>urn:oid:1.2.208.176.43210.8.20.11</HomeCommunityId>
                <RepositoryUniqueId>1.2.208.176.43210.8.20.11</RepositoryUniqueId>
                <DocumentUniqueId>1.2.208.184^e23d1b0d-f4cc-4b3e-9973-b2a499aa15ba</DocumentUniqueId>
            </DocumentRequest>
        </RetrieveDocumentSetRequest>


Det svar der returneres er patientens dokument i Graviditetsmappen, indeholdende de dataelementer der er beskrevet i MedCom's CDA standarder til Graviditetsmappen

Bemærk at selve body delen af dokumentet skal hentes ud som en mime attachement

ITI-43 RetrieveDocumentSetResponse 
		<RetrieveDocumentSetResponse xmlns="urn:ihe:iti:xds-b:2007" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns7="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns8="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns9="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns10="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns11="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns12="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
			<ns9:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
			<DocumentResponse>
				<RepositoryUniqueId>1.2.208.176.43210.8.20.11</RepositoryUniqueId>
				<DocumentUniqueId>1.2.208.184^e23d1b0d-f4cc-4b3e-9973-b2a499aa15ba</DocumentUniqueId>
				<mimeType>text/xml</mimeType>
				<Document>
					<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:37b3a03a-70c8-45ea-9be5-bbaec58de49a-128338@urn%3Aihe%3Aiti%3Axds-b%3A2007"/>
				</Document>
			</DocumentResponse>
		</RetrieveDocumentSetResponse>

3.6. Oprettelse af dokumenter i Graviditetsmappen

Oprettelse af graviditetsdokumenter i Graviditetsmappen foregår via den dokumentregistreringsservic (DROS) som understøtter Graviditetsmappen, detaljeret dokumentation er beskrevet under: Dokumentregistreringsservice

Endpoint til Graviditetsmappe specifik DROS er: https://<NSP-SERVER_URL>:<NSP-SERVER_PORT>/dros_gm/iti41
NSP TEST1 endpoint er: http://test1-cnsp.ekstern-test.nspop.dk:8080/dros_gm/iti41
NSP TEST2 endpoint er: https://test2-cnsp.ekstern-test.nspop.dk:8080/dros_gm/iti41

Arbejdsgangene omkring skabelsen af dokumenter i den gravides Graviditetsmappe, og derved deling af dokumenterne foregår ofte som automatiske processer og system til system kommunikation, derfor kan der både benyttes et medarbejdercertifikat (MOCES) eller et Funktionscertifikat (FOCES) til deling af dokumenter til Graviditetsmappen via Dokumentregistreringsservicen.

WSDL til DROS'en findes under: Snitfladebeskrivelse og endpoints og på https://wsdl.nspop.dk/#dros

Igen som når et dokuemnt hentes, så skal selve ClinicalDocument oprettes som en MIME attachment, se eksemplet for detaljer.


ITI-41 ProvideAndRegisterDocumentSetRequest 
		<ProvideAndRegisterDocumentSetRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns="urn:ihe:iti:xds-b:2007">
			<lcm:SubmitObjectsRequest>

TODO - Indsæt eksempel på svar når MedCom frigiver standarderne

            </lcm:SubmitObjectsRequest>
			<Document id="10614913492668759151.7526722965054630547.1561027587628">
				<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:d028af6e-dc46-4049-b3bd-a4496767e42d@urn%3Aihe%3Aiti%3Axds-b%3A2007"/>
			</Document>
		</ProvideAndRegisterDocumentSetRequest>

3.7. Ændring af dokumenter i Graviditetsmappen

Ændring af dokuemter i graviditetsmappen foregår som oprettelser. Fagsystemet skal blot sikre sig at documententryid'en gemmes lokalt når dokumentet oprettes (husk atdocumententryid og dokument-id ikke er det samme - se beskrivelsen ovenfor).

Når ændringen af indholdet i CDA dokumentet har betydning for patienten og/eller sundhedsprofessionelle, fx rettelse af fejl eller tilføjelse af information, skal ændringerne i deles med Graviditetsmappen.

Når et dokument er ændret, skal der laves et ITI-41 provideAndRegister request, men man skal som dokument-provider selv angive associationstypen, source-objektet og target objektet
For en præcis teknisk vejledning, kan opskriften fra IHE’s wikiside følges (https://wiki.ihe.net/index.php/Annotated_ProvideAndRegister.b_Transaction#Document_Replacement)

Infrastrukturen vil derefter automatisk sørge for at tage den tidligere instans af dokumentet, og sætte den til status "deprecated" og så gemme den nye instans af dokumentet.
Den nye instans af dokumetnet bliver samtidigt kædet til den tidligere instans - således der er historik på dokumenterne.

3.8. Sletning af dokumenter i Graviditetsmappen

Der er ikke udstillet funktionalitet til at slette dokumenter for fagsystemerne.
Dokumenter i graviditetsmappen bliver automatisk slettet efter et givet tidsrum (TODO: Indsættes når lovbekendtgørelse offentliggøres), hvilket fastsættes lovgivningsmæssigt.

Fagsystemer kan, hvis dokumentet ikke længere bør deles i Graviditetsmappen, ændre dokumentet, og give det status "deprecated". Det kan gøres ved at benytte ITI-57 UpdateDocumentSet, hvorved AvailabilityStatus stættes til "deprecated" istedet for "approved". UpdateDocumentSet er ligeledes tilgængelig via ovenstående DROS endpoint

4. Sikkerhed, roller og rettigheder

For adgang til Graviditetsmappen skal der for sundhedspersoner eksistere et gyldigt SOSI-ID kort som er signeret af NSP'ens Secure Token Service, dokumentationen for SOSI-ID kort og STS ligger under: Anvenderguide til STS

Sundhedsfaglige uden sundhedsfaglig autorisation skal have tilknyttet en rettighed før disse kan få adgang. Lokale organisationer kan enten tilknytte disse rettigheder via Sundhedsstyrelsens Elektroniske Brugerstyring (SEB), eller give rettigheden via den lokale identifikations- og rettighedsstyring.

Følgende roller anvendes i forbindelse med Graviditetsmappen.

Rollenavn

Rettighed

Notation som indsættes i SOSI IdKort ved udstedelse

nspSundAssistR2

Giver ret til at læse til dokumenter i Graviditetsmappen

Giver også adgang til at læse andre dokumenter, der deles via dokumentdelingsinfrastrukturen jvf. Sundhedslovens §42a stk. 4

(Se overordnet dokumentation for nationale roller her: SEB - Sundhedsvæsenets Elektroniske Brugerstyring - Sundhedsdatastyrelsen Services (nsi.dk))

urn:dk:healthcare:national-federation-role:code:41002:value:SundAssistR2

 

En sundhedsfaglig uden sundhedsfaglig autorisation kan ikke have tilknyttet flere roller på samme tid - dette skal administreres via den lokale identifikations- og rettighedsstyring, eller via SEB

Ansvaret for at tildele rettigheder til sundhedsfaglige uden sundhedsfaglig autorisation ligger hos de enkelte parter. Parterne skal ligeledes via deres eget rolle/rettighedssystem kunne styre om en sundhedsfaglige uden sundhedsfaglig autorisation skal have adgang til Graviditetsmappen.

For yderligere information, se Administrative forudsætninger #Brugerstyring/trust

5. Håndtering af spærring og fuldmagt

Spærring

Borgeren kan have spærret for deling af at data, herunder dokumenter i Graviditetsmappen, med andre parter i sundhedssektoren, i det tilfælde vil fejlkoden "Consent Filter Applied” blive returneret (se nedenstående xml eksempel for ITI-18 spærrede dokumenter). Det betyder at borgeren enten har spærret for deling af data til den specifikke sundhedsperson, for data i et givet tidsrum, for data fra bestemte organisationer, eller i en kombination af disse. Klienten skal håndtere at der er angivet en spærring, og give sundhedspersonen mulighed for at få adgang til Graviditetsmappen under specielle vilkår, se forretningsregel #6 under: Indhold og forretningsregler 

For adgang til spærrede data kan klienten angive at der ønskes foretaget et værdispring og så sende forespørgslen igen med “ConsentOverride” flaget sat til “True”. Der laves logning i dokumentdelingsinfrastrukturen der angiver at en spærring er tilsidesat. Klienten skal samtidig angive årsagen (Eksempelvis: eksplicit samtykke fra patienten for at få adgang til data) til at spærringen er tilsidesat i eget journalsystem, da der kan forventes at være opfølgning på tilsidesatte spærringer.

Yderligere information omkring spærring og forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS

ITI-18 Spærrede dokumenter 
<rs:RegistryError codeContext="urn:dk:nsi:Consent Filter Applied" errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>

Fuldmagt

Borgerportaler kan give borgernes pårørende adgang via den Fælles Offentlige Fuldmagtsservice, hvortil der er tilknyttet en brugergrænseflade på Borger.dk.

Bevis for fuldmagter er understøttet i OIO-IDWS identitytokens signeret af STS'en, dog understøtter dokumentdelingsservicen ikke fuldmagter i OIO-IDWS - så fuldmagter er i stedet etableret via en trust-løsning hvor borgerportalen selv håndterer kontrol af fuldmagter.

Information angående angivelse af fuldmagter via dokumentdelingsservicen, kan ses i HSUID header dokumentation.

6. Graviditetsspecifik indhold i henvisninger

MedCom er i spidsen for en arbejdsgruppe, som skal afklare hvordan det kan muliggøres at effektivisere visitationen af den gravide.

TODO: Når arbejdsgruppen er kommet frem til en konklusion, vil der blive refereret til den herfra

7. Ændringslog

0.82023-04-22Udkast til Teknisk implementeringsguideSDS
1.02024-04-02Opdateret, således kun referencer til MedCom's CDA standarder manglerSDS
  • No labels