GemsTracker

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Data uitwisseling met GemsTracker ======
(to be translated to English)

GemsTracker  is een web-applicatie geschreven in PHP binnen het Zend Framework en  kent verschillende mogelijkheden voor de import van gegevens vanuit externe systemen. Van handmatige invoer, bulk import, tot (semi)automatische import van gegevens. Onderscheid wordt gemaakt in de import van:
    -  gegevens uit EPD’s met bijvoorbeeld NAW, afspraak en lab gegevens en 
  -   de import van reeds verzamelde antwoorden op vragenlijsten.

===== 1. Import algemeen =====

GemsTracker kan standaard middels een import wizard bestanden in verschillende formaten inlezen. Automatische inlezing is ook eenvoudig te regelen, maar moet meestal project specifiek opgezet worden.
Bestandsnamen
Als één van de handmatige import wizards gebruikt wordt volstaat het voor bestanden om de correcte extensie te hebben.

Bij de automatische import van middels FTP of andere methodes aangeleverde bestanden moeten de bestanden (voor de automatische verwerking) een naam hebben met de structuur “datatype.[optionele delen.][csv|txt|xml]”. 
Datatype
Het datatype bepaald het soort import. Dit kan per project aangepast worden, maar de aanbeveling is dat elk project bestanden die met “respondent.” beginnen automatisch laat verwerken als een bestand met patiëntinformatie. Als de naam met “appointment.” begint moet het om een bestand met afspraakinformatie gaan. Daarnaast kunnen project specifieke namen gebruikt worden bijvoorbeeld voor labwaarden.

Datatype	Inhoud	Opmerkingen
respondent	Patiënt informatie	
appointment	Afspraak informatie	
labvalues	Labwaarden	Project specifieke lab import

==== Extensie ====

De extensies csv, txt en xml bepalen of het bestand als comma separated values, tabbed ascii dan wel als xml bestand verwerkt wordt.

==== Optionele delen ====

Het tussenliggende gedeelte is vrij te bepalen. Aangeraden wordt hierin de datum van aanmaak te zetten in het formaat yyyy-mm-dd[-hh-mm-ss] zodat bij de verwerking het oudste bestand als eerste verwerkt wordt.
Kolomvolgorde en herhaling
De gebruikte kolommen worden altijd bepaald door het importbestand zelf. Bij tekstimport door de veldnamen op de eerste regel te plaatsen, bij XML middels de tagnamen van de elementen waarin de gegevens opgeslagen worden. De volgorde van de gegevens (per item element of tekstregel) binnen een bestand is wel van belang, want die bepaalt de volgorde waarin de gegevens verwerkt worden. Als de gegevens van één patiënt twee keer voorkomen in de import, worden de gegevens twee keer verwerkt; waarbij de gegevens van het tweede voorkomen als laatste verwerkt en dus bewaard worden.

==== Tekst bestanden ====


Tekst “.txt” bestanden moeten een inhoud in UTF-8 formaat bevatten. Ze mogen beginnen met een UTF-8 Byte Order Mark, maar dit is niet verplicht. Test dit s.v.p. uit met tekens zoals “ăãçéêëĭñ”. Indien UTF-8 niet mogelijk is, moet met de ontwikkelaar overlegd worden over welke characterset dan gebruikt zal worden.

Bij tekstimport wordt geen verschil gemaakt tussen lege tekstwaarden en null-waarden. Zowel de tekst “NULL” als een lege string worden geïnterpreteerd als null-waarden.

De kolomvolgorde wordt bepaald door de eerste regel. Die regel moet de namen van de aangeleverde velden bevatten.  De volgorde moet dus wel constant zijn binnen een bestand, maar kan per bestand verschillen.

Als een veld niet aangeleverd kan worden, moet deze kolom geheel weggelaten worden. Lege waarden overschrijven namelijk handmatig ingevoerde waarden, maar een weggelaten kolom laat al ingevulde waarden met rust.

Alle velden en veldnamen worden gescheiden door \t tabs en mogen geen tabs of regeleindes bevatten. (Dus niet: \t\r\n aangezien deze gebruikt worden om de data te scheiden.)

Zowel \r\n als \n zijn toegestaan als regeleindes.

==== CSV bestanden ====


Comma Separated Values “.csv” werken hetzelfde als tekst bestanden, waaronder dat de inhoud in UTF-8 formaat moet zijn en er een UTF-8 Byte Order Mark gebruikt kan worden.

Velden worden gescheiden door komma’s (,). Tekst velden die komma’s of regeleindes (\r of \n) bevatten moeten tussen dubbele aanhalingstekens (") staan. Andere velden mogen tussen aanhalingstekens staan. Bij tekstvelden met een dubbele aanhalingstekens in de inhoud moet dat aanhalingteken voorafgegaan worden door een slash (\") . Numeriek velden gebruiken een punt (.) als decimaal teken en gebruiken geen scheidingsteken voor duizendtallen. Zowel \r\n als \n zijn toegestaan als regeleindes.

Net als bij tekst wordt er geen verschil gemaakt tussen lege tekstwaarden en null-waarden en wordt de kolomvolgorde wordt bepaald door de eerste regel. 

==== XML-bestanden ====


XML-bestanden moeten bestaan uit een root-element dat nul of meer individuele import-elementen bevat. Het advies is voor het root element de tag-naam “gems” te gebruiken met de data-type naam als tag-naam voor de import elementen. Dus “respondent” voor de patiënt import-elementen en “appointment” voor de afspraak import elementen. Deze benaming van de import elementen is zelfs verplicht bij gemende aanlevering van patiënt en afspraak gegevens in een enkel bestand.

Binnen de import elementen moeten de veldnamen zoals die in dit document gedefiniëerd voor het bijbehorende data-type gebruikt worden als tag-naam voor de diverse data elementen.

Hier een voorbeeld xml bestand voor de gemengde import van patient- en afspraakgegevens met een deel van de velden:
<code xml>
<?xml version="1.0" encoding="UTF-8"?>
<gems>
    <respondent id="bsn">
        <patient_id>BSN614448384</patient_id>
        <organization_id>70</organization_id>
        <bsn>614448384</bsn>
        <email_bussiness>mjong@magnafacta.nl</email_bussiness>
        <initials>M.D.</initials>
        <first_names>Matijs</first_names>
        <surname_prefix>de</surname_prefix>
        <last_name>Jong</last_name>
        <gender>M</gender>
        <birthday>1966-25-09</birthday>
        <city>Rotterdam</city>
    </respondent>
    <respondent>
        <patient_id>BSN461795887</patient_id>
        <organization_id>70</organization_id>
        <bsn>461795887</bsn>
        <surname_prefix/>
        <last_name>Luçañĭ</last_name>
        <gender>F</gender>
        <email_home>test@test.org</email_home>
        <initials>T.E.</initials>
        <first_names>Tëst</first_names>
        <birthday>1999-08-07T00:00:00</birthday>
        <city>Rotterdam</city>
    </respondent>
    <appointment>
        <patient_id>BSN461795887</patient_id>
        <organization_id>70</organization_id>
        <appointment_id>1001</appointment_id>
        <admission_time>2013-07-14T10:00:15-02:00</admission_time>
        <status>AC</status>
        <type>A</type>
        <attended_by>Some dude</attended_by>
        <activity>Intake</activity>
        <procedure />
        <location>Dijkzicht</location>
    <appointment>
</gems>
</code>

De volgorde van de XML elementen met velden binnen een patiënt is niet van belang.

De lege waarden <veld></veld>,  <veld/> en <veld xsi:nil=”true”/> worden alle drie als null waarde geïnterpreteerd en als zodanig in de database opgeslagen. (Bij deze laatste moet wel de xsi: namespace gedefinieerd zijn, oftewel het moet om een geldig XML document gaan.

Het ontbreken van een veld daarentegen wordt geïnterpreteerd als dat het veld niet gewijzigd is en dus zijn huidige waarde behoudt dan wel (bij nieuwe patiënten) de standaard waarden van het systeem hebben. Daarom is het belangrijk om als gegevens niet aanwezig zijn in het aanleverende systeem de betreffende velden niet toe te voegen aan de export. Een lege waarde overschrijft in dat geval namelijk handmatig ingevoerde waarden.

Welke velden aangeleverd worden kan binnen een bestand in principe per respondent-item verschillen. Zo kan van de ene patiënt alleen een telefoonnummer doorgegeven worden, terwijl van de andere patiënt alle gegevens overgedragen worden. Dan wordt van de eerste patiënt alleen dat telefoonnummer aangepast, terwijl van de tweede alle gegevens overgenomen worden.

In de praktijk zal dit weinig voorkomen, want de meeste aanleverende software zal voor alle geselecteerde velden output generen, ook al is de informatie eerder verzonden.

==== 1. Import NAW gegevens ====

Veldenoverzicht patiënt gegevens

Elke import wizard heeft één of meer vertaal methodes om kolommen te benoemen. Deze kolom namen worden getoont in een overzicht in de wizard. Dit is zo opgezet dat met minimale moeite nieuwe vertaal methodes gemaakt kunnen worden.

De onderstaande velden kunnen gebruikt worden bij de import van patiëntgegevens. De vetgedrukte velden dienen minimaal aangeleverd te worden.

Nogmaals als uw systeem een veld niet heeft en ook geen vergelijkbaar veld heeft, dan is het belangrijk die velden weg te laten uit de import, zodat de gegevens alsnog handmatig ingevoerd kunnen worden.

grs_patient_nr	varchar(15) not null -- zoals in het eigen ziekenhuis bekend
gr2o_organization_id	varchar(10) -- een unique identificatie, kan uit GemsTracker komen, bij voorkeur het URA of AGB nummer

grs_sbsn	varchar(128) -- hash wordt opgeslagen, kan leeg zijn

grs_email 	varchar(100)
grs_initials_name	varchar(30)
grs_first_name	varchar(30)
grs_surname_prefix	varchar(10)
grs_last_name	varchar(50)
grs_gender	char(1) default 'U' -- One of M, F, U, case insensitive
grs_birthday	date -- yyyy-mm-dd of ISO 8601 timestamp

grs_address_1	varchar(80)
grs_zipcode	varchar(10)
grs_city	varchar(40)
grs_iso_country	char(2) default 'NL', case sensitive
grs_phone_1	varchar(25)
grs_phone_2	varchar(25)
grs_phone_3	varchar(25) 
grs_phone_4	varchar(25) 

De onderstaande velden kunnen opgenomen worden in de export, maar dit moet alleen gebeuren als het ziekenhuissysteem deze informatie ook echt inhoudelijk aan kan leveren.

gr20_consent	varchar(20) not null default 'Unknown' -- One of ‘Yes’, ‘No’, ‘Unknown’, case sensitive
gr2o_reception_code	varchar(20) default 'OK' -- kan ook  ‘dead' of ‘moved’ zijn, case sensitive

Het adres
De correcte methode om in XML het adres aan te leveren is door een address element te maken met daarin de elementen voor de diverse onderdelen van het adres:

<grs_address_1><street>Mariniersweg</street> <house_nr>151</house_nr>
<house_letter>A</house_letter> <house_extra_1>6e
</house_extra_1> <house_extra_1>etage</house_extra_1></grs_address_1>

Spaties zijn significant, ook tussen de elementen. Het bovenstaande element levert het adres “Mariniersweg 151A 6e etage” op, dus zonder spatie tussen huisnummer en huisletter.

Indien de gegevens niet gescheiden aangeleverd kunnen worden, kan ook volstaan worden met het gebruik van enkel het address element:

< grs_address_1>Mariniersweg 151A 6e etage</ grs_address_1>

Het resultaat is hetzelfde adres als met de sub elementen. 

Ten slotte kunnen de gegevens ook nog in de afzonderlijke adres tags aangeleverd worden.
<street>Mariniersweg</street>
<house_nr>151</house_nr>
<house_letter>A</house_letter>
<house_extra_1>6e</house_extra_1>
<house_extra_2>etage</house_extra_2>

Het nadeel hiervan is dat het systeem hier niet weet tussen welke onderdelen wel en niet spaties horen, dus wordt overal een spatie tussen geplaatst. De bovenstaande elementen leveren dus het adres “Mariniersweg 151 A 6e etage” op, met spatie tussen huisnummer en huisletter.

Hetzelfde gebeurt overigens als de adresvelden afzonderlijk aangeleverd worden bij een tekstimport.

==== 2. Import Afspraak gegevens ====

Veldenoverzicht afspraakgegevens

Afspraakgegevens worden alleen bewaard als de patiënt al bekend is in het systeem.

De onderstaande velden kunnen gebruikt worden bij de import van afspraakgegevens. De vetgedrukte velden dienen minimaal aangeleverd te worden.

Nogmaals, als uw systeem een veld niet heeft en ook geen vergelijkbaar veld heeft, dan is het belangrijk die velden weg te laten uit de import, zodat de gegevens alsnog handmatig ingevoerd kunnen worden.

gap_patient_nr	varchar(15) not null
gap_organization_id	varchar(10) -- een unique identificatie, kan uit GemsTracker komen

gap_appointment_id	varchar(20) -- een unique identificatie zodat het verschil tussen nieuwe en gewijzigde afspraken te zien is

gap_admission_time	datetime -- ISO 8601 timestamp: yyyy-mm-ddThh:nn:ss[+/-00:00] 
gap_discharge_time	datetime -- ISO 8601 timestamp: yyyy-mm-ddThh:nn:ss[+/-00:00] 

gap_admission_code	varchar(1) default ‘A’ – één van Ambulatory, Emergency, Field, Home, Inpatient, Short stay, Virtual, waarbij alleen de eerste letter gebruikt wordt. Zie http://wiki.hl7.org/index.php?title=PA_Patient_Encounter
gap_status_code	varchar(2) default ‘AC’ – één van ABorted, ACtive, CAncelled, COmpleted (gemist = aborted, afgezegd = cancelled, planned = active, etc…)

gap_attended_by	varchar(250) – Degene met wie de afspraak is
gap_referred_by	varchar(250) – Optioneel, degene die de afspraak geïnitieerd heeft
gap_activity	varchar(250) – Waarvoor de afspraak is
gap_procedure	varchar(250) – Wat er tijdens afspraak gebeurt
gap_location	varchar(250) – De locatie van de afspraak

gap_subject	varchar(250) – Vrije tekst invoer
gap_comment	text – Vrij tekst invoer

=== Het appointment id ===

Aan de inhoud van het afspraak_id worden geen eisen gesteld, anders dan dat dit uniek is voor een specifieke afspraak, zodat als een afspraak opnieuw doorgegeven wordt, bijvoorbeeld omdat de afspraak afgezegd is of niet uitgevoerd kan worden, we weten dat het om die afspraak gaat die we moeten aanpassen.

Dit is van belang omdat we vragenlijsten aan een afspraak koppelen en als die afspraak afgezegd wordt moeten hun tijdstippen ook aangepast worden.

Bij wijze van spreken kan dit veld dus gewoon een datum/tijd waarde bevatten indien het zeker is dat een patiënt nooit twee afspraken op hetzelfde moment kan hebben.

=== Datum-tijd velden ===

Datum-tijd velden moeten volgens de ISO 8601 specificatie aangeleverd worden, wat betekent dat als de tijdszone niet meegeleverd wordt ervan uitgegaan wordt dat het tijdstip in tijdszone Europa / Amsterdam valt, oftewel +01:00 tijdens wintertijd en +02:00 tijdens de zomertijd.

Bij voorkeur wordt een datum-tijd compleet aangeleverd inclusief tijdszone. Indien alleen een datum aangeleverd wordt, dan wordt de tijd automatisch gezet op 00:00:00 in de tijdszone Europa / Amsterdam.

=== De admission en status code ===

Deze codes zijn toegevoegd volgens de bestaande HL7 normering. De informatie in deze codes is ter voorlichting van de gebruikers van GemsTracker. Voor de werking van GemsTracker wordt alleen het onderscheidt tussen de status codes AC/CO (active/completed) en de codes AB/CA (aborte/cancelled) gebruikt. De eerste twee codes betreffen actieve afspraken die plaats zullen vinden (AC), dan wel waarvan bevestigd is dat ze plaatsgevonden hebben (CO). De andere twee betreffen afspraken die afgezegd zijn voor die plaats zouden vinden (CA) dan wel afspraken die niet afgezegd zijn maar die gemist zijn (AB).

Afspraken met de eerste twee status codes kunnen gekoppeld worden aan het afnemen van vragenlijsten. De andere twee status codes zijn met name van belang als een bestaande afspraak afgezegd wordt en de code dus veranderd in een afzegging. In dat geval moeten de tijdstippen van de gekoppelde vragenlijsten veranderd worden.

In geval van twijfel ten aanzien van het vertalen van de lokaal gebruikte status codes naar deze codes,: overleg met Liesbeth Dusink <e.dusink@erasmusmc.nl> en / of Matijs de Jong <mjong@magnafacta.nl>.

Voor de rest worden deze gegevens alleen gebruikt om de gebruikers van het systeem te informeren.

==== Het activity veld en procedure veld ====

Activity is een beschrijving van een afspraak op hoog niveau, bijv. een controle, operatie, fysiotherapie of overig. Procedure beschrijft de effecten van een afspraak op de patiënt bv. conditieverbetering, verlichting, zekerheid, een specifieke operatie, ...

=== Lange tekst velden ===

De lange tekst velden ‘attended_by’, ‘referred_by’, ‘activity’, ‘procedure’ en ‘location’ worden opgeslagen in aparte tabellen die o.a. de behandelaar / verwijzer kunnen koppelen aan gebruikers van GemsTracker. Hoe deze velden gevuld worden is voor GemsTracker minder van belang – hoewel het voor de gebruikers wel veel scheelt als de tekst gewoon leesbaar is – maar wel van belang is dat dezelfde informatie telkens op dezelfde manier doorgegeven wordt.

Of de locatie nu ‘’s Gravendijkwal’, ‘Sophia’ of ‘AE-127’ is dus minder belangrijk dan de zekerheid dat de volgende keer hier niet ‘Hs’, ‘Sp’ dan wel ‘Westzeedijk’ is.

Voor behandelaar / verwijzer adviseren wij om die door te geven in de vorm achternaam[, ][titels ] [voornaam of initalen], zolang dokter Richard Atkins maar niet de ene keer als “Atkins, Richard’ en de volgende keren als ‘Atkins, R.’, ‘Richard Atkins’’of ‘21870922-23671020’ doorgegeven wordt. Overigens is dit laatste, het doorgeven van het UZI nummer van de zorgverlener, dus een valide vorm van doorgeven.

De velden ‘activity’ en ‘procedure’ worden op dezelfde manier behandeld en mogen ontbreken. Maar GemsTracker kan zo geconfigureerd worden dat patiënten die op ‘controle’ (of een andere tekst komen) automatisch een meettraject toegewezen krijgen, terwijl patiënten die niet krijgen voor een ‘intake’.

De ‘subject’ en ‘comment’ velden worden gewoon als tekstveld bij de afspraak opgeslagen. Ze hoeven niet aangeleverd te worden, maar als er informatie is die overgezet moet worden en niet in de andere velden past, dan zijn deze velden daarvoor geschikt.

===== 3. Import vragenlijst data =====

Ook mogelijk om antwoorden op vragenlijsten te importeren op een (semi) geautomatiseerde manier.  
Importeren van antwoorden
Vanaf versie 1.6.4. bevat GemsTracker de mogelijkheid antwoorden op vragenlijsten te importeren.
Gedurende de import moet elk antwoord gekoppeld worden aan een bestaand token (van reeds aangemaakte een vragenlijst). GemsTracker kijkt ook naar al bestaande antwoorden, en kan deze naar wens afhandelen.
Om antwoorden te importeren moet je natuurlijk eerst de juiste rechten hebben om dit te mogen doen. Gegeven deze rechten, dank kan een vragenlijst in de traject bouwer geselecteerd worden en antwoorden worden geïmporteerd of je kan een gebruik maken van een generieke import wizard waar je ook de vragenlijst kan selecteren voor import. Zie de interface hier beneden:
 

Na het selecteren van de vragenlijst , zal de wizard de velden tonen die aanwezig zijn in de vragenlijst. Sommige velden zijn afhankelijk van de import definitie die je kiest, de antwoorden in de vragenlijst zijn normaal hetzelfde voor elke importdefinitie. De default importdefinities bepalen alleen de methode om een set van antwoorden te linken aan een specifiek token.

Daarna kan of gekozen worden voor het uploaden van de file of kan gekozen worden om de gegevens in een groot tekstveld te plakken. GemsTracker ondersteund op dit moment drie file formaten: XML, CSV en tabbed tekst. De tekst velden ondersteunen alleen tabbed tekst (e.g. een directe copy and paste vanuit Excel).
De import importeert alleen die gegevens die in de import worden ingevoerd. Niet aangeleverde data worden leeg gelaten of – wanneer het antwoord al bestaat- worden niet overschreven door de import.
 
=== Importeren van de invuldatum ===

Wanneer de import een completion_date veld bevat, dan wordt de invuldatum gezet op deze datum. Zo niet, dan wordt de invuldatum gezet op het moment van importeren, als tenminste de invuldatum al niet aanwezig was in de vragenlijstantwoorden.
Dit gebeurt te allen tijde, onafhankelijk van ander gebruik van het completion_date veld zoals ingesteld in de import definitie.

=== Linken van antwoorden aan tokens ===

Er zijn drie manieren om een antwoord aan een token te linken.

== Link via patiënt id en organisatie ==

Gebruik deze optie wanneer de data een patient_id en een organization_id bevat. Het organization id kan een intern GemsTracker organisatie nummer zijn of een ID van de aanleverende organisatie, een code naam of gewoonweg de naam van de organisatie zoals opgegeven onder beheer > organisaties in Gemstracker. 
Deze optie maakt gebruik van het eerste niet ingevulde token van een individuele patiënt. Als er geen niet-ingevulde tokens zijn dan wordt de meest recent ingevulde token gebruikt.

== Link via patient id, organisatie en invuldatum ==

Gebruik deze optie als de data ook een completion_date veld bevat.
GemsTracker zal dan alleen de tokens selecteren die geldig waren op de invuldatum. Ook bij deze optie maakt gebruik van het eerste niet ingevulde token van de patiënt dat bovendien geldig is voor de invuldatum. Als er geen niet-ingevulde tokens zijn dan wordt de meest recent ingevulde token gebruikt.

== Link via token ==

Als het GemsTracker token in de import aanwezig is, gebruik deze optie. Dit is natuurlijk de meest betrouwbare manier om antwoorden aan een token te linken. 

== Afhandelen van ingevulde tokens ==
Wanneer er geen tokens gevonden kunnen worden dan geeft het system een error, voordat er antwoorden worden geïmporteerd. Dit is ook de default afhandeling wanneer er antwoorden worden gelinkt aan tokens met een invuldatum. Er zijn echter twee manieren om hier mee om te gaan zoals hieronder beschreven.

== Oude tokens verwijderen en nieuwe aanmaken ==
Eerst kijkt de import wizard of de te importeren antwoorden compatible zijn met de al bestaande antwoorden. Als de antwoorden hetzelfde zijn of de nieuwe antwoorden waren nog niet beantwoord, dan worden de nieuwe antwoorden ingevuld op de plek van de al bestaande antwoorden. 

Alleen wanneer de nieuwe antwoorden niet compatible zijn met de oude antwoorden, dan wordt het huidige token wordt verwijderd en wordt een nieuw token aangemaakt. De nieuwe antwoorden en alle antwoorden niet in de import worden geïmporteerd als de nieuwe set van antwoorden.

Wanneer antwoorden op deze wijze vervangen worden dan zal in GemsTracker zichtbaar zijn dat de oude antwoorden zijn verwijderd (doorgestreept), met daaronder de nieuwe antwoorden.

== Creëren van een nieuwe set aan antwoorden ==
Wanneer deze optie wordt gekozen of wanneer de import file twee of meer antwoorden bevatten voor hetzelfde token, en automatisch overschrijven is niet geselecteerd, dan zal GemsTracker automatisch ook een nieuw token creëren. Het verschil is dat de oude set met antwoorden niet overschreven wordt, en noch worden de eerdere antwoorden die niet in de import aanwezig waren gekopieerd naar de nieuwe set van antwoorden.

Deze import methode kijkt ook naar de specifieke antwoorden in de import en de aanwezigheid van de antwoorden bij het huidige token. Als je bijvoorbeeld een XML importeert die meerdere rijen bevat voor hetzelfde token en de antwoorden overlappen elkaar niet (zijn niet hetzelfde), dan worden alle antwoorden in een enkele set van antwoorden gezet. Als er wel verschillende antwoorden zijn, dan worden nieuwe tokens gegenereerd. 
Wanneer de geïmporteerde gegevens getoond worden in GemsTracker,  dan worden de antwoorden als individuele tokens getoond in de volgorde zoals zij geïmporteerd werden.

===== 4. Import lab gegevens =====

Veldenoverzicht laboratoriumgegevens
Dit is een voorbeeld van een project specifieke vragenlijst import, ter illustratie van wat mogelijk is.
 
De onderstaande velden kunnen gebruikt worden bij de import van laboratoriumgegevens. De vetgedrukte velden dienen minimaal aangeleverd te worden. Voor elke labwaarde wordt opnieuw patiënt_id, organization_id, lab_id en acquisition_time aangeleverd. In GemsTracker worden deze op intelligente wijze samengevoegd.

patient_id	varchar(15) not null
organization_id	varchar(10) -- een unique identificatie, kan uit GemsTracker komen

lab_id	varchar(20) -- een unique identificatie van het lab, liefst URA

acquisition_time	datetime -- ISO 8601 timestamp: yyyy-mm-ddThh:nn:ss[+/-00:00] 
blood_indicator	varchar(80) –mogelijke waardes zie hieronder
indicator_value	varchar(80) 
indicator_unit	varchar(80)
reference_high	varchar(80)
reference_low	varchar(80)
measurement_method	varchar(250) 
indicator_flag	varchar(80) – wordt vaak gebruikt bij voorlopige uitslagen
lab_id
De labidentifier het liefst URA of in geval van het ziekenhuislaboratorium het organization_id
blood_indicator
Voor de bloedwaardes kunnen o.a. de volgende codes gebruikt worden:  bse(=bezinking), crp, Hb, leucocyten, trombocyten, ASAT, ALAT, kreatinine, tot. cholesterol, HDL,LDL, triglyceriden, chol/HDL, rf(=reumafactor), anti-ccp, ANA, HLA-B27, urinezuur. 
indicator_value

De waarde kan zowel een getal zijn als een uitspraak over de indicator
indicator_unit

De eenheid waarin de indicator_value gelezen moet worden. Niet alle indicator_values hebben een eenheid.
reference_high en reference_low

Een aantal indicatoren hebben reference_values (=normaalwaardes) voor wat ze zouden moeten zijn, eventueel afhankelijk van het geslacht en de leeftijd. Als die opgegeven zijn, dan moeten die meegegeven worden. Bij die gegevens die maar 1 reference_value hebben graag die waarde als reference_high aanleveren.

Er kan behalve een waarde ook een vlag meegegeven worden of een waarde pos of neg is, of H of L. Als die niet in de labuitslag zit, kan dit veld uiteraard genegeerd worden.
<code xml>
<?xml version="1.0" encoding="UTF-8"?>
<gems>
    <laboratory>
        <patient_id>BSN461795887</patient_id>
        <organization_id>70</organization_id>
        <lab_id>1001</lab_id>
        <acquisition_time>2013-07-14T10:00:15-02:00</acquisition_time>
        <bloodindicator>bse</bloodindicator>
        <indicator_value>7,8</indicator_value>
        <indicator_unit>mmol/l</indicator_unit>
        <indicator_flag>pos</indicator_flag >
    </ laboratory >
</gems>
</code>
GemsTracker

User Tools

Site Tools

Page Tools
