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.
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).
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 |
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:
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.
Udover den simple verifikation, så skal der opsættes en CPR validering, der anvender CPRExists service til verficering af CPR-numre. CPR valideringen kan køre i følgende tre modes:
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.
I dette afsnit fastholdes væsentlige design beslutninger samt deres rationale. Hvis relevant, fastholdes også designs, som er afvist samt rationalet herfor.
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^^^&1.2.208.176.1.2&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^^^^^&1.2.208.176.1.1&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^^^&1.2.208.176.1.2&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> |
FSK Registry er udviklet som en Java Servlet af flere årsager
Java Servlets opfylder disse behov, og er samtidig simpelt at arbejde med, uden at være afhængig af en række frameworks.
Fejl- og debug-logning implementeres vha. log4j
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 er fravalgt, da dette i forvejen ligger i DDS.
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:
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.
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.
Dette afsnit beskriver statiske såvel som dynamiske aspekter af systemarkitekturen, herunder baggrunden for de enkelte designvalg.
SLA loggeren sørger for at foretage SLA logning af alle servicekald.
SLA loggeren er implementeret som et servlet filter vha NSPUtils hjælpeklasser.
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.
Der findes integrationstest til DRS. Se beskrivelse i Testvejledning
Der findes en række unittests, der sikrer at de forskellige del-komponenter er implementeret korrekt.