Introduktion

Formål

FSK Registry tilbyder en snitflade til fremsøgning af CDA Dokumenter af typen "Fælles Stamkort".

Formålet med dette dokument er at beskrive systemarkitekturen for FSK Registry. 

Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i anvendelsen af FSK Registry. Herunder hører naturligvis personer involveret i konkrete dokument-kildesystemers brug af FSK Registry (evt. indirekte gennem DDS).

Definitioner og referencer

Formålet med denne sektion er at give et overblik over definitioner og dokumenter, der benyttes i dette dokument.

Definition

Beskrivelse

NSP

Den Nationale Service Platform (inden for sundheds-IT)

DDS


Dokumentdelingsservice
XDS

Cross Domain Document Sharing 

Introduktion til FSK Registry

Overblik over løsningens arkitektur

FSKRegistryOverblik


Der etableres med løsningen en web service, som giver mulighed for at fremsøge on-demand CDA dokumenter af typen "Fælles Stamkort".

FSK Registry udstilles ikke direkte på NSP'en men kaldes via DDS som et bagvedliggende XDS Registry. FSK Registry komponenten overlader derfor flere sikkerhedsrelaterede opgaver til DDS.

Det drejer sig f.eks. om:

  • Sikkerhedsprotokol (DDS implementerer DGWS - FSK Registry har ingen sikkerhed)
  • Auditlogning
  • Kald af relaterede services:
    • Logning til MinLog
    • Tjek af samtykkeregler
    • Tjek af behandlingsrelation

FSK Registry er ikke et rigtigt XDS Registry og understøtter således kun en enkelt XDS registry operation: ITI-18 Registry Stored Query - mere specifik query typen  FindDocuments (urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d).

FSK Registry svarer på baggrund af en database med en tabel med mapning mellem patientens CPR nummer, formatcode, typecode og dokument id. Formatcode og typecode findes som en konfigurationstabel med par af formatcode og typecode angivet. Der returneres et dokument for hver af disse par ved en forspørgsel på et CPR nummer, med mindre dokumentforespørgslen indeholder søge parametre som udelukker disse (formatcode og typecode). Hvis FSK Registry modtager en query på et CPR nummer, som ligger i mapningstabllen med de konfigurede formatcode/typecoce returnerer den en eller flere DocumentEntry med det tilknyttede dokument id'er. Hvis tabellen ikke indeholder det forespurgte CPR nummer og de konfigurerede formatcode/typecode, så sørger FSK Registry for at generere et eller flere dokument id'er og gemme disse i mapningstabllen med det pågældende CPR nummer, formatcode og typecode.

Kalderen vil således altid få et eller flere Document Entry tilbage fra FSK Registry, hviss der spørges på et lovligt CPR nummer og man ikke vha. søgekriterier har udeholdt formatcode og typecode. FSK Registry implementerer en simpel verifikation på CPR nummeret. Denne verifikation validerer, at CPR nummeret består af netop 10 cifre.

Designmålsætninger og -beslutninger

Designmålsætninger

Designet af FSK Registry er holdt som en minimal løsning. FSK Registry er således udelukkende ansvarlig for at implementere fremsøgningsservice for CDA dokumenter. Al autentifikation og autorisation samt audit logning overlades til den foranliggende DRS.

Designbeslutninger

I dette afsnit fastholdes væsentlige design beslutninger samt deres rationale. Hvis relevant, fastholdes også designs, som er afvist samt rationalet herfor.

Indhold af Document Entries

Indholdet (antal, type og indhold af Classification elementer) er fastsat ud fra de metadata, der ved FSK Registry komponentens udviklingsperiodes start, var registreret i OpenText XDS Registry på TEST01 miljøet.

Et eksempel på dette ses i nedenstående svar (AdhocQueryResponse):

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing">urn:ihe:iti:2007:RegistryStoredQueryResponse</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:5602351a-99c4-4a01-bdeb-0759bdb01977</MessageID>
    <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
    <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:af25a586-dec3-4475-ba42-dae91a200902</RelatesTo>
  </soap:Header>
  <soap:Body>
    <ns4:AdhocQueryResponse xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
      <ns2:RegistryObjectList>
        <ns2:ExtrinsicObject mimeType="text/xml" lid="urn:uuid:43dab304-c2ac-44e7-a723-3361bfd90df3" objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:43dab304-c2ac-44e7-a723-3361bfd90df3" home="1.2.208.176.8.1.12">
          <ns2:Slot name="languageCode">
            <ns2:ValueList>
              <ns2:Value>da-DK</ns2:Value>
            </ns2:ValueList>
          </ns2:Slot>
          <ns2:Slot name="repositoryUniqueId">
            <ns2:ValueList>
              <ns2:Value>1.2.208.176.43210.8.10.12</ns2:Value>
            </ns2:ValueList>
          </ns2:Slot>
          <ns2:Slot name="sourcePatientId">
            <ns2:ValueList>
              <ns2:Value>2507650369^^^&amp;1.2.208.176.1.2&amp;ISO</ns2:Value>
            </ns2:ValueList>
          </ns2:Slot>
          <ns2:Name>
            <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Fælles stamkort"/>
          </ns2:Name>
          <ns2:VersionInfo versionName="1"/>
          <ns2:Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:43dab304-c2ac-44e7-a723-3361bfd90df3" nodeRepresentation="" id="urn:uuid:e785faa0-feea-472b-9ebf-02f775e53750">
            <ns2:Slot name="authorInstitution">
              <ns2:ValueList>
                <ns2:Value>Sundhedsdatastyrelsen^^^^^&amp;1.2.208.176.1.1&amp;ISO^^^^634491000016008</ns2:Value>
              </ns2:ValueList>
            </ns2:Slot>
          </ns2:Classification>
          <ns2:Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:43dab304-c2ac-44e7-a723-3361bfd90df3" nodeRepresentation="DK FSK Schema" id="urn:uuid:b6828d0a-f216-4c8b-94a7-168858654821">
            <ns2:Slot name="codingScheme">
              <ns2:ValueList>
                <ns2:Value>urn:ad:dk:medcom:fsk:full</ns2:Value>
              </ns2:ValueList>
            </ns2:Slot>
            <ns2:Name>
              <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="DK FSK Schema"/>
            </ns2:Name>
          </ns2:Classification>
          <ns2:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:43dab304-c2ac-44e7-a723-3361bfd90df3" nodeRepresentation="52460-3" id="urn:uuid:8f0c9bdb-eeec-4e8a-b7fe-8ce118305816">
            <ns2:Slot name="codingScheme">
              <ns2:ValueList>
                <ns2:Value>LOINC</ns2:Value>
              </ns2:ValueList>
            </ns2:Slot>
            <ns2:Name>
              <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Patient Information"/>
            </ns2:Name>
          </ns2:Classification>
          <ns2:ExternalIdentifier registryObject="urn:uuid:43dab304-c2ac-44e7-a723-3361bfd90df3" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2507650369^^^&amp;1.2.208.176.1.2&amp;ISO" id="urn:uuid:4f2c5f01-a866-483b-9bf5-f9b7416ca471">
            <ns2:Name>
              <ns2:LocalizedString value="XDSDocumentEntry.patientId"/>
            </ns2:Name>
          </ns2:ExternalIdentifier>
          <ns2:ExternalIdentifier registryObject="urn:uuid:43dab304-c2ac-44e7-a723-3361bfd90df3" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="urn:sds:fsk:stamkort:6a9578f6-ca58-4d7f-a298-a2b57bcc4294" id="urn:uuid:3849792b-14bf-44e3-a18c-49b9a992892c">
            <ns2:Name>
              <ns2:LocalizedString value="XDSDocumentEntry.uniqueId"/>
            </ns2:Name>
          </ns2:ExternalIdentifier>
        </ns2:ExtrinsicObject>
      </ns2:RegistryObjectList>
    </ns4:AdhocQueryResponse>
  </soap:Body>
</soap:Envelope>

Øvrige designbeslutninger

Java Servlets

FSK Registry er udviklet som en Java Servlet af flere årsager

  1. FSK Registry skulle kunne afvikles i en Wildfly applikationsserver
  2. FSK Registry skal kunne håndtere flere samtidig requests

Java Servlets opfylder disse behov, og er samtidig simpelt at arbejde med, uden at være afhængig af en række frameworks.

Logning vha. Log4j

Fejl- og debug-logning implementeres vha. log4j

Brug af NSPUtil til Service Level Agreement (SLA) logning

SLA-logning understøttes ved hjælp af (SLA) logningsfunktionaliteten i NSPUtil.

SLA-logningen logger alle kald til FSK Registry og består bl.a. af: Tidspunkt for kald, navn på den kaldte metode, tidsmæssig længde på kaldet, id (MessageID) på den besked der behandles.

Auditlogning

Auditlogning er fravalgt, da dette i forvejen ligger i DDS.

Statisk konfiguration i property-fil

Servicekonfigurationen foretages i en properties-fil, der skal deployes på webserveren et sted i applikationens classpath.

Ændringer i konfigurationen skal ledsages af genstart af servicen, da konfigurationen indlæses og verificeres ved opstart af de enkelte services. Properties kontrolleres for tilstedeværelse i property-filen, ikke for anførte værdi.

For en beskrivelse af hvad der skal opsættes i konfigurationen, se FSK Registry Adapter - Driftsvejledning.

Applikationskonfiguration konfigureres i property-fil (se FSK Registry Adapter - Driftsvejledning). Al konfiguration for FSK Registry angives i denne fil. Derudover angives også placeringen af logkonfigurationsfilen.

Logkonfiguration udpeges i applikationskonfigurationen. I logkonfigurationsfilen angives logger-properties for:

  • Generel FSK Registry fejl- og debug-logning. Den generelle logning konfigureres ved at angive en log4j-logger property med navn log4j.logger.dk.sds.

Beslutning vedrørende servicearkitektur

FSK Registry er udviklet som en Java Servlet af flere årsager
1. FSK Registry skulle kunne afvikles i en Wildfly applikationsserver
2. FSK Registry skal kunne håndtere flere samtidig requests
Java Servlets opfylder disse behov, og er samtidig simpelt at arbejde med, uden at være afhængig af en række frameworks.

Anvendelse af IPF Open eHealth Integration Platform

FSK Registry anvender komponenter fra IPF Open eHealth Integration Platform https://oehf.github.io/ipf/ipf-platform-camel-ihe/index.html 

Herunder specielt standard WSDL for servicen ITI-18 Registry Stored Query samt Java klasser til model.

Arkitekturdesign

Dette afsnit beskriver statiske såvel som dynamiske aspekter af systemarkitekturen, herunder baggrunden for de enkelte designvalg.

SLA logning

SLA loggeren sørger for at foretage SLA logning af alle servicekald.

SLA loggeren er implementeret som et servlet filter vha NSPUtils hjælpeklasser.

Integration og test

Integrationsstrategi

Der er ikke nogen specifik rækkefølge hvori FSK Registry og de services, den kalder, skal integreres.

For succesfuld gennemførelse af integrationstests skal den database, som FSK Registry er afhængig af dog være tilgængelige.

For en beskrivelse af byggeprocessen og eksterne/interne afhængigheder for servicen, se udviklerguiden.

Integrationstests

Der findes integrationstest til DRS. Se beskrivelse i Testvejledning

Unittests

Der findes en række unittests, der sikrer at de forskellige del-komponenter er implementeret korrekt. 


  • No labels