...

Attributter, der ikke refereres af ovenstående tabel vil ikke være en del af DocumentEntries, men vil udelukkende persisteres som en del af xml feltet i tabellen DocumentEntryContent.

Migrering

Migrering af data fra OpenText Registry til NXRG skal sikre, at al data, der ligger i OpenText Registry overføres til NXRG på en måde, så data bevares: Det vil sige, at de data, der kan udsøges gennem NXRGs snitflader svarer 1:1 til det data, der kan udsøges gennem OpenText Registrys snitflader.

Den interne datarepræsentation vil ændre sig fra OpenText Registry til NXRG, men det logiske data skal bevares.

Valg af migreringsstrategi

Der har i forbindelsen med migreringen været arbejdet med nedenstående diagram for at komme frem til en migreringsstrategi.

Image Added

Diagrammet viser de forskellige niveauer, som data kan eksporteres henholdsvis importeres på. De forskellige muligheder er blevet diskuteret på workshops, og fravalg og tilvalg er dokumenteret på diagrammet.

Konklusionen på analysearbejdet er således, at:

1. Data eksporteres fra OpenText Registry på xDB niveau: Driften kan trække en liste over alle objekter i xDB og hvornår disse senest er ændret. Listen kan anvendes til at lave eksport af de (ændrede) objekter til en relationel database (MariaDB).
2. Data importeres i NXRG fra kommandolinje tool: Importen af data skal operere på den relationelle migreringsdatabase, som blev nævnt under eksport. Ved at køre et kommandolinje tool er det muligt at transformere data i migreringsdatabasen til SQL scripts under hensyntagen til NXRGs datamodel. Disse scripts kan derefter (bulk) indlæses i NXRGs database (også MariaDB)

Der har været et ønske om at kunne lave løbende (delta)migreringer af OpenText data til NXRG. Dette ønske bunder i, at der i produktion i dag er ca 11 mio XDS objekter (submissionsets med associations samt document entries) i OpenText Registry databasen.

Selv med et effektitivt migreringstool, så vil det tage tid (< 5 dage) at migrere al data. Hvis en migreringsstrategi kræver et servicevindue, så vil dokumentdeling på NSP være utilgængeligt i flere dage, hvilket er blevet vurderet til problematisk.

Da driften kan trække liste over nye/opdaterede data i OpenText Registry (se pkt 1 ovenfor) er det muligt at lave en trinvis migrering. Dette betyder yderligere, at det bliver muligt at komme i gang med migreringen på et tidligere tidspunkt (da det kan foretages uden at der skal meldes servicevinduer ud).

TODO

...

Migreringsprocessen er markeret med blå i diagrammet ovenfor. Det er tanken at bevare Migreringsdatabasen efterfølgende som en backup for OpenText Registry data. Når licensen udløber for xDB databasen, så vil migreringsdatabasen være masterdata (i tilfælde af, at man skulle opdage fejl i import til NXRG efterfølgende).

Der skal laves verifikation af migreringsprocessen - både en kvantitativ verifikation og en kvalitativ verifikation. Denne del af processen er beskrevet nedenfor.

Tabelformat for migreringsdata

Dataene fra OpenText registry'et i en MariaDB-database, som deles mellem eksport- og import-jobbet. Databasen indeholder to tabeller, contents og status. Tabellernes indhold beskrives nedenfor. Man kan hente et eksempel-datasæt på

Contents

Status

XML-format

OpenText registry'et eksporterer sine data i et xml-format, som der ind til videre ikke er tilvejebragt noget schema for. Nedenfor kan man se et eksempel på et submissionset og et tilhørende document i dette format.

...

<?xml version="1.0"?>
<document id="urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906">
  <xds:documentEntry xmlns:xds="http://www.openehealth.org/ipf/xds">
    <entryUuid>urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906</entryUuid>
    <logicalUuid>urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906</logicalUuid>
    <version>
      <versionName>1</versionName>
    </version>
    <uniqueId>437f8b60-9563-11e3-a5e2-0800200c7020^1.2.208.184</uniqueId>
    <patientId extension="2606481234" root="1.2.208.176.1.2"/>
    <availabilityStatus>Approved</availabilityStatus>
    <title language="en-US">Hjemmemonitorering for 2606481234</title>
    <limitedMetadata>false</limitedMetadata>
    <sourcePatientId extension="2606481234" root="1.2.208.176.1.2"/>
    <sourcePatientInfo>
      <name>
        <given>Janus</given>
        <family>Berggren</family>
      </name>
      <gender>M</gender>
      <birthTime>1948-06-26T00:00:00Z</birthTime>
    </sourcePatientInfo>
    <creationTime>2013-02-17T08:15:00Z</creationTime>
    <author>
      <authorPerson>
        <id/>
        <name>
          <given>M</given>
          <family>Madsen</family>
        </name>
      </authorPerson>
      <authorInstitution>
        <idNumber>77668685</idNumber>
        <assigningAuthority universalId="1.2.208.176.1.2" universalIdType="ISO"/>
        <name>Odense Universitetshospital, Odense</name>
      </authorInstitution>
    </author>
    <legalAuthenticator>
      <id/>
      <name>
        <given>Lars</given>
        <family>Olsen</family>
      </name>
    </legalAuthenticator>
    <serviceStartTime>2013-02-11T08:11:00Z</serviceStartTime>
    <serviceStopTime>2013-02-16T10:14:00Z</serviceStopTime>
    <classCode code="001" codeSystemName="1.2.208.184.100.9" displayName="Clinical report"/>
    <confidentialityCode code="N" codeSystemName="2.16.840.1.113883.5.25" displayName="N"/>
    <eventCode code="NPU03011" codeSystemName="1.2.208.176.2.1" displayName="O2 sat.;Hb(aB)"/>
    <eventCode code="MCS88016" codeSystemName="1.2.208.184.100.8" displayName="FVC"/>
    <formatCode code="urn:ad:dk:medcom:appointmentsummary:full" codeSystemName="1.2.208.184.100.10" displayName="DK Appointment Summary Document schema"/>
    <healthcareFacilityTypeCode code="550621000005101" codeSystemName="2.16.840.1.113883.6.96" displayName="hjemmesygepleje"/>
    <languageCode>da-DK</languageCode>
    <practiceSettingCode code="419192003" codeSystemName="2.16.840.1.113883.6.96" displayName="intern medicin"/>
    <typeCode code="53576-5" codeSystemName="2.16.840.1.113883.6.1" displayName="Personal Health Monitoring Report"/>
    <repositoryUniqueId>1.2.208.176.43210.8.10.11</repositoryUniqueId>
    <mimeType>text/xml</mimeType>
    <size>27302</size>
    <hash>da39a3ee5e6b4b0d3255bfef95601890afd80709</hash>
    <type>stable</type>
  </xds:documentEntry>
</document>

Verifikation af migreringen

TODO