1. Formål

Dette dokument beskriver designet af Graviditetskort-servicen.

Det forudsættes at læseren er bekendt med grundfunktionaliteten i servicen, beskrevet i dokumentet Graviditetskort (GSR).

1.1. Terminologi



HL7 CDA

CDA står for Clinical Document Architecture, og er en international standard til udveksling af oplysninger indenfor sundhedsvæsenet.

HL7 FHIRFHIR udtales som det engelske "fire", og er en international standard til udveksling af oplysninger indenfor sundhedsvæsenet.

1.2. Forkortelser

Forkortelse

Betydning

GMGraviditetsmappen

GSR

Graviditetskortregistret

GCPGraviditetsplanregistret
GRPGraviditetsmappe Repository Proxy
GTKGraviditetsmappen testklient
DDSDokumentdelingsservicen
DCCAfkoblingskomponenten

2. Arkitektur

Graviditetsmappen består af de to register-services GSR og GCP, samt en proxy-komponent GRP. Dette dokument beskriver arkitekturen for GSR.

Registerservicen håndterer funktionalitet og databaseadgang. En separat NSP-komponent håndterer de sikkerhedsmæssige aspekter ved kald til systemet. Der understøttes adgang gennem DGWS eller IDWS.

Som illustreret på figuren herunder tilgår brugerne servicen direkte gennem en testklient (som kun findes i NSP's testmiljøer), eller indirekte via egne patientjournalsystemer, lægepraksissystemer og omsorgsjournaler, som har implementeret opdatering via dyb integration. Data hentes igennem Dokumentdelingsservicen (DDS).

GSR arkitektur

3. Standarder

Hent af data via DDS er basereret på HL7 Clinical Document Architecture (CDA).

Data fra registret udstilles i CDA-dokumentets body (structuredBody), mens metadata udstilles i CDA-dokumentets header. Metadata er hovedsageligt information om, hvilken borger de pågældende oplysninger vedrører.

Ved forespørgsler til oprettelse (Create) og opdatering (Update) medsendes en komplet datastruktur og ikke kun de opdaterede elementer i tilfælde af en opdatering. Ved de øvrige forespørgsler (Delete) medsendes kun borgerens cpr nummer og ansvarlig organisations identifier, som anvendes til opslag.

Forretningslogikken i servicen er afkoblet fra udvekslingsformatet, dvs. Fra HL7 CDA.

Se Guide til Anvendere for flere detaljer.

4. Sikkerhed

Kald til servicen kan foretages som enten DGWS- (Den Gode Webservice) eller IDWS- (Identity Based Web Services) kald. Som beskrevet ovenfor foretages kald til servicen igennem NSP komponenten AccessHandler, der har det primære formål at validere at der er foretaget et korrekt DGWS- eller IDWS-kald.

Sundhedsprofessionelle, der vil tilgå servicen fra deres EPJ-, LPS- eller EOJ-system, kan foretage DGWS-kald igennem den centrale NSP afkoblingskomponent (DCC), som viderestiller kaldet til servicen. Der kræves anvendelse af OCES sikkerhedsniveau 4, hvor der skal medsendes et ID-kort, som er signeret med medarbejdercertifikat (MOCES). AccessHandler verificerer at kaldet er korrekt signeret, og at signeringen ikke er udløbet.

Borgere, der ønsker at tilgå servicen, skal foretage IDWS-kald til servicen. AccessHandler vil verificere at der er tale om et korrekt IDWS-kald.

Såfremt det verificeres at der er tale om et korrekt DGWS- eller IDWS-kald, vil kaldet blive viderestillet til servicen. Servicen vil tillade kaldet hvis:

  • Der er tale om et level 4 DGWS-kald (MOCES).

  • Der er tale om et IDWS-kald foretaget af samme person, som der slås data op for.

Der henvises til hhv. Den Gode Webservice og OIO Identity-based Web Services v1.0.1a for yderligere information.

5. Integrationer

5.1. MinLog

Der foretages logning til Minlog2 af kald til GSR servicen, som modificerer graviditetskortet. Logning foretages i praksis ved anvendelse af minlog-producer library, som lægger data til minlogning på en Kafka-kø. En Kafka consumer, som indgår i NSP's minlog2-service, læser data fra denne kø og lagrer disse data i Minlog2-registret.

Data i graviditetskortet læses igennem dokumentdelingsservicen DDS. DDS logger selv læsninger i Minlog2, og GSR logger derfor ikke selv disse,  

5.2. NAS - National Advis Service

I det en graviditet når uge 20, hvis AssessmentLevel ændres efter uge 20 og hvis graviditeskortet slettes mellem uge 20 og uge 35 sendes en advis via NAS2 notificationbroker, indeholdende cprnr, same information om, hvilken handling der var tale om.

5.3. SCES - CPR Enkeltopslag

Der foretages CPR opslag i SCES ved oprettelse og opdatering af graviditetskort.

Det valideres at den gravide patient findes, og data suppleres med navn og adresse. Såfremt der i data er angivet cprnr. på barnefar/partner/medmor, foretages der også opslag af dette cprnr, og der valideres at dette findes.

5.4. SORES - SOR Enkeltopslag

Ved oprettelse og opdatering af graviditetskort angiver kalderen sin organisationsid. Denne ID valideres med opslag i SORES, og data suppleres med navn på organisationen.

6. Design

Følgende diagram viser en oversigt over komponenter, der indgår i GSR

GSR design

7. Persistenslag

Persistenslag overholder HAPI FHIR Dokument Design Requirement. Kig på https://www.hl7.org/fhir/documents.html for mere information.


Eksempel på HAPI FHIR data model vist herunder:

Bundle (Type = document, FHIR)

Entry 0 (Composition, FHIR)

Meta (FHIR)

VersionId (Integer)

LastUpdated (DateTime)

Subject (Patient reference, FHIR)

Author (Organization reference, FHIR)

Section

Section 0 (Patient Section)

Code

Coding "sds:patient"

Entry (Patient reference, FHIR)

Section (Patient Provenance)

Entry (Provenance reference)

Agent (Provenance, FHIR)

Recorded (DateTime)

Who (Organization reference, FHIR)

Section 1 ("GraviditetsforløbsID", Pregnancy Course Section)

Code

Coding "sds:pregnancycourse"

Entry (Observation reference, FHIR)

Code

Coding "sds:pregnancycourse"

EffectiveDateTime (DateTime)

Value (UUID)

Section (Pregnancy Course Provenance, samme format som tidligere provenance, se på "Patient Provenance" or "MaternityCard Status Provenance")

Section 2 ("Sprog", Language Section)

Code

Coding "sds:language"

Entry (Composition reference, FHIR)

Section

Section 0 (Observation reference, FHIR)

Code

Coding "sds:language"

Value (String)

Section 1 (Observation reference, FHIR)

Code

Coding "sds:nationality"

Value (String)

Section 2 (Observation reference, FHIR)

Code

Coding "sds:needsTranslator"

Value (String)

Section (Language Provence, samme format som tidligere provenance, se på "Patient Provenance" or "MaternityCard Status Provenance")

Section ...

Samme format som Sprog composition sectionen, en section for hver snitflade gruppe defineret i dokumentet, GSR - Guide til anvendere.

8. Specifikke designbeslutninger

Vedr. denne løsning henledes opmærksomheden der specielt på følgende.

8.1. Owner, Responsible og Author

Data fra GSR hentes af anvendere igennem Dokumentdelingsservicen (DDS). DDS anvender servicen Min Spærring til at undersøge, om den der henter et dokument igennem DDS har tilladelse til dette. Borger har forskellige muligheder for at spærre for data i Min Spærring. Eksempelvis kan der spærres for at hente for data fra en bestemt organisation.

Da et Graviditetskort som udgangspunkt kan indeholde data fra forskellige organisationer har Sundhedsdatastyrelsen, for at tillade Min Spærring at spærre for data fra en givet organisation, besluttet, at hver organisation har sit eget graviditetskort. Dvs. hvis en praktiserende læge opretter data i Graviditetskortet, og en jordemoder på en fødeafdeling på et sygehus ligeledes opretter data, så opstår der 2 forskellige graviditetskort for den samme gravide borger, som begge er aktive. Anvendere, der henter data ud, kan så hente begge graviditetskort - med mulighed for at der er spærret for det ene eller for begge - og må så flette data for at få et samlet billede af data i kortet. 


GSR arbejder med 2 forskellige enheder for at understøtte dette:

Begreb

Beskrivelse

Eksempel

Responsible

SOR-id for den enhed der svarer til ejeren, altså eksempelvis for lægepraksis eller region. Skal være på IE-niveau. Denne værdi tages som parameter til alle kald og skrives som Author i DDS' Registry ved oprettelse af data. Der valideres ved opslag i SORES at SOR-id'en er valid.

SOR, 598321000016006
AuthorSOR-id for den enhed, der modificerer data, altså eksempelvis for lægepraksis eller specifik fødeafdeling på et regionshospital. Denne værdi tages som parameter til både Create-, Update- og Delete-kald. Der valideres ved opslag i SORES at SOR-id'en er valid.SOR, 598321000016006
  • No labels