Item |
DT |
Card |
Conf |
Omschrijving |
Label |
|
|
1 .. 1 |
|
|
(opvragenLabUitslagen) |
Ingevoegd van 2.16.840.1.113883.2.4.3.11.60.66.10.9022 VZVZ AttentionLine ContextCode (DYNAMISCH)
|
|
hl7:attentionLine
|
|
|
0 .. * |
|
|
(opvragenLabUitslagen) |
|
|
hl7:keyWordText
|
|
SC |
1 .. 1 |
|
|
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
CONTEXT |
|
|
1 .. 1 |
F |
2.16.840.1.113883.2.4.15.1 (AttentionLineElementTypeNL) |
|
CONF |
elementinhoud moet "ContextCode" zijn |
|
|
|
hl7:value
|
|
CV |
1 .. 1 |
|
|
(opvragenLabUitslagen) |
|
CONF |
|
|
|
Gekoppeld aan concepten:
|
|
hl7:ControlActProcess
|
|
|
1 .. 1 |
M |
|
(opvragenLabUitslagen) |
|
|
@moodCode
|
|
|
1 .. 1 |
F |
EVN |
Ingevoegd van 2.16.840.1.113883.2.4.3.11.60.66.10.9023 VZVZ ControlAct Overseer Person (DYNAMISCH) 1..1
|
|
|
hl7:overseer
|
|
|
1 .. 1 |
|
Bericht-zender (mandaatverlener). Zorgverlener en zorgaanbieder |
(opvragenLabUitslagen) |
|
|
0 .. 1 |
F |
RESP |
|
Voorbeeld |
<overseer typeCode="RESP"> <assignedEntity> <id root="2.16.528.1.1007.3.1" extension="000002222"/> <code code="01.016" codeSystem="2.16.840.1.113883.2.4.15.111" displayName="Internist"/> <assignedPrincipalChoiceList> <assignedPerson> <name> <given>Anders de</given> <family>Ketenpartner 1</family> </name> </assignedPerson> </assignedPrincipalChoiceList> <Organization> <id root="2.16.528.1.1007.3.3" extension="00002222"/> <name>Gezondheidscentrum Amby</name> <telecom use="WP" value="+31761235987"/> <addr> <streetName>Ettensebaan</streetName> <houseNumber>100</houseNumber> <postalCode>4814NN</postalCode> <city>Breda</city> <country>Nederland</country> </addr> </Organization> </assignedEntity></overseer> |
|
|
1 .. 1 |
M |
|
(opvragenLabUitslagen) |
|
II.NL.UZI |
1 .. 1 |
M |
Zorgverlener-id |
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
2.16.528.1.1007.3.1 |
|
CV |
1 .. 1 |
M |
Zorgverlener-code |
(opvragenLabUitslagen) |
|
Schematron assert |
role |
error
|
|
test |
@codeSystem='2.16.840.1.113883.2.4.15.111' and not(@code='00.000') |
|
Melding |
Control Act: / moet een UZI-register rolcode bevatten en deze mag niet 00.000 zijn |
|
|
|
|
hl7:assignedPrincipalChoiceList
|
|
|
1 .. 1 |
M |
|
(opvragenLabUitslagen) |
|
|
1 .. 1 |
M |
Persoonsgegevens |
(opvragenLabUitslagen) |
|
PN |
1 .. 1 |
M |
Zorgverlener-naam |
(opvragenLabUitslagen) |
|
|
1 .. 1 |
M |
Organisatiegegevens |
(opvragenLabUitslagen) |
|
II |
1 .. 1 |
M |
Organisatie-id |
(opvragenLabUitslagen) |
|
Schematron assert |
role |
error
|
|
test |
@root='2.16.528.1.1007.3.3' and @extension |
|
Melding |
Control Act: / moet een URA bevatten |
|
CV |
0 .. 1 |
R |
Organisatietype. Geldige waarden komen uit RoleCodeNL - zorgaanbiedertype (2.16.840.1.113883.2.4.15.1060) |
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
2.16.840.1.113883.2.4.15.1060 (RoleCodeNL - zorgaanbiedertype (organisaties)) |
|
ON |
1 .. 1 |
M |
Organisatie-naam |
(opvragenLabUitslagen) |
|
AD |
1 .. 1 |
M |
Organisatie-adres |
(opvragenLabUitslagen) |
|
Schematron assert |
role |
error
|
|
test |
hl7:city |
|
Melding |
Control Act: / moet tenminste de vestigingsplaats bevatten |
|
|
hl7:queryByParameter
|
|
|
1 .. 1 |
M |
|
(opvragenLabUitslagen) |
|
II |
1 .. 1 |
|
|
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
2.16.840.1.113883.2.4.3.11.60.66.10.5 |
|
II |
1 .. 1 |
M |
Bevat de unieke identificatie van de vraag zoals geformuleerd in de vragende applicatie,
los van de identificatie van de interactie waarin de vraag wordt aangeboden. De waarde
van dit attribuut wordt in het antwoord teruggeleverd, zodat de antwoordberichten
kunnen worden gerelateerd aan de vraag.
|
(opvragenLabUitslagen) |
|
Voorbeeld |
<queryId extension="101" root="2.16.528.1.1007.3.3.2222.27"/>
|
|
CS |
1 .. 1 |
M |
Bevat de (nieuwe) status van de query. |
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
executing |
|
Voorbeeld |
<statusCode code="executing"/>
|
|
CS |
1 .. 1 |
M |
Definieert de timing en groepering van de antwoordberichten. |
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
R |
|
Voorbeeld |
<responseModalityCode code="R"/>
|
|
CS |
1 .. 1 |
M |
Geeft het tijdsframe aan waarbinnen het antwoord wordt verwacht, zoals ‘I’ (Immediate)
voor directe beantwoording.
|
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
I |
|
Voorbeeld |
<responsePriorityCode code="I"/>
|
|
|
|
hl7:executionAndDeliveryTime
|
|
TS |
1 .. 1 |
M |
Bevat het tijdstip waarop het antwoord uiterlijk moet zijn opgeleverd aan het vragende
systeem.
|
(opvragenLabUitslagen) |
|
Voorbeeld |
<executionAndDeliveryTime value="20120330121540"/>
|
|
|
1 .. 1 |
M |
Aanvragen/uitslagen. Dit element geeft aan dat er alleen gezocht wordt naar feitelijke
labuitslagen (geen aanvragen). Het is verplicht omdat dit in de Nederlandse standaard
zo is vastgelegd.
|
(opvragenLabUitslagen) |
|
Voorbeeld |
<actMoodCode> <value code="EVN" codeSystem="2.16.840.1.113883.5.1001"/> </actMoodCode> |
|
CV |
1 .. 1 |
|
De moodCode van de uitslag moet overeenkomen met de waarde van value. |
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
EVN |
|
|
1 .. 1 |
F |
2.16.840.1.113883.5.1001 (ActMood) |
|
|
|
hl7:observationEffectiveTime
|
|
|
0 .. 1 |
R |
Bepalingsdatum. Dit element is optioneel gevuld en geeft aan in welke periode de gezochte
labbepalingen moeten zijn uitgevoerd. Het <low> element geeft het ‘vanaf’ moment aan.
Het optionele <high> element geeft het ‘tot en met’ moment aan. Het gebruik van minuten
is verplicht om misverstanden over interpretatie van de bovengrens te voorkomen. Als
de hele dag bedoeld wordt, zoals normaal gesproken het geval is, moet 0000 resp. 2359
te worden gebruikt. Indien er geen <high> element is, wordt een open interval bedoeld.
In het template van de specificaties voor het opvragen van labuitslagen door apotheken
(uit AORTA v6.12) wordt alleen een ‘vanaf’ datum gebruikt, die wordt aangegeven door
het interval in te perken tot een time stamp (xsi:type=”TS”). Dit lijkt geen juiste
interpretatie, want een time stamp zou betekenen dat alleen uitslagen OP de betreffende
datum gezocht worden.
|
(opvragenLabUitslagen) |
|
|
Gekoppeld aan concepten:
|
|
Voorbeeld |
Resultaten vanaf 1-9-2013 <observationEffectiveTime> <value xsi:type="IVL_TS"> <low value="20130901"/> </value></observationEffectiveTime> |
|
Voorbeeld |
Resultaten tot en met 25-2-2015, dus inclusief de hele dag, aangeduid door tijd 23:59
<observationEffectiveTime> <value xsi:type="IVL_TS"> <high value="201502252359"/> </value></observationEffectiveTime> |
|
IVL_TS |
1 .. 1 |
M |
De effectiveTime van elke observatie (observationEvent) is na de waarde van value. |
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
IVL_TS |
|
Constraint |
Andere attributen en subelementen mogen niet aanwezig zijn. |
|
Constraint |
Onder- en bovengrens (low, high) is tot op de minuut te specificeren |
|
TS |
1 .. 1 |
M |
|
(opvragenLabUitslagen) |
|
|
Gekoppeld aan concepten:
|
|
TS |
0 .. 1 |
R |
Merk op dat dit een ‘tot’ datum is. Om alle bepalingen tot en met 3/12 te krijgen,
moet dus 4/12 als @value worden gebruikt.
|
(opvragenLabUitslagen) |
|
|
Gekoppeld aan concepten:
|
|
Schematron assert |
role |
error
|
|
test |
not(hl7:low) or string-length(hl7:low/@value)>=12 |
|
Melding |
Onder- en bovengrens (low, high) is tot op de minuut te specificeren |
|
Schematron assert |
role |
error
|
|
test |
not(hl7:high) or string-length(hl7:high/@value)>=12 |
|
Melding |
Onder- en bovengrens (low, high) is tot op de minuut te specificeren |
|
|
0 .. 1 |
R |
Bepalingstype. Dit element is optioneel gevuld en geeft aan welke typen labbepalingen
gezocht worden.
In het message type van de internationale labquery (POLB_MT300000) is het niet mogelijk
om meer dan één code door te geven. Weliswaar is het element <observationType> herhalend,
maar dit betekent een logische ‘AND’ (bepaling moet AL deze codes hebben. Voor een
logische ‘OR’ (bepaling moet één van deze codes hebben) moet <value> herhalen. Om
dit mogelijk te maken is een update in het XML Schema van het message type aangebracht,
vandaar de 02 versie (die doorwerkt in de query interactie).
Er zijn twee methoden om een set labcodes aan te duiden met deze parameter:
-
Gebruik van een groepscode uit het labcodesysteem.
Als één enkele bepalingscode gezocht wordt, dan kan dit gewoon door deze code (met
het codesysteem) door te geven. Als echter een groep bepalingen bedoeld wordt, dan
kan een code gebruikt worden die deze hele groep aanduidt. Binnen NHG tabel 45 is
er bijv. een code voor ‘bloedgassen’ als groep. Binnen LOINC zijn er veel meer codes
om groepen bepalingen aan te duiden. Welke (groeps)code er ook gebruikt wordt, het
is natuurlijk wel vereist dat de ontvanger deze ook kent en kan interpreteren welke
selectie bepalingscodes er moet worden opgeleverd.
voorbeeld: <value codeSystem="2.16.840.1.113883.2.4.4.30.45" code="106"/>
-
Gebruik van een herhalende <value> met labcodes.
Als geen groepscode beschikbaar is, moeten alle labcodes waaruit geselecteerd moet
worden stuk voor stuk opgesomd worden. Als het gaat om een lijst met tientallen of
zelfs honderden codes, levert dit vanzelfsprekend forse overhead op. Het is mogelijk
om het gebruik van groepscodes te combineren met herhalende <value>, zodat toch hele
groepen bepalingen met één code worden aangeduid. voorbeeld: <value codeSystem="2.16.840.1.113883.2.4.4.30.45" code="847"/> <value codeSystem="2.16.840.1.113883.2.4.4.30.45"
code="869"/> <value codeSystem="2.16.840.1.113883.2.4.4.30.45" code="844"/> etc.
Er is eerder geopperd om efficiënter willekeurige lijsten codes door te kunnen geven
door het gebruik van zogenaamde value set ID’s die een dergelijke lijst aanduiden.
Nadeel daarvan is echter dat het coördinatie vereist tussen de vragende systemen en
bronsystemen, die van nieuwe value sets op de hoogte gebracht moeten worden). Dit
is strijdig met het principe dat bronsystemen onafhankelijk moeten zijn van de vraagcontext.
Merk op dat er de uitdaging blijft van spraakverwarring door terminologie-verschillen.
De codes die als selectieparameter gebruikt worden, zullen moeten aansluiten bij de
codes die door het bronsysteem gehanteerd worden, of er moet een mechanisme zijn om
een mapping daarnaar te doen.
Een idee dat in gedachten gehouden wordt is het uitbreiden van de selectiemethodiek
naar bijv. het kunnen uitsluiten van bepaalde codesets. Als bijv. slechts een klein aantal bepalingen niet geautoriseerd
is, is het veel handiger om deze set te benoemen dan de grote set die wel toegestaan
is.
|
(opvragenLabUitslagen) |
|
CV |
1 .. * |
M |
|
(opvragenLabUitslagen) |
|
|
1 .. 1 |
R |
|
|
@codeSystem moet gevuld zijn met een OID van een code system of value set. |
|
|
1 .. 1 |
R |
|
|
@code mag gevuld zijn met een (groeps)code uit het benoemde code system. |
|
Constraint |
Andere attributen en subelementen mogen niet aanwezig zijn. |
|
|
Gekoppeld aan concepten:
|
Ingevoegd van 2.16.840.1.113883.2.4.3.11.60.66.10.9035 KEZO PART QRY patientId (DYNAMISCH) 1..1 Mandatory
|
|
|
1 .. 1 |
M |
Patiënt waarop de gegevens betrekking hebben (verplicht aanwezig). |
(opvragenLabUitslagen) |
|
II.NL.BSN |
1 .. 1 |
M |
Het burgerservicenummer (BSN) dat de gezochte patiënt uniek identificeert. Het is
niet mogelijk om via het LSP gegevens op te vragen op basis van lokale patiëntnummers.
|
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
2.16.840.1.113883.2.4.6.3 |
|
|
1 .. 1 |
R |
|
|
BSN |
|
|
Gekoppeld aan concepten:
|
|
|
1 .. 1 |
M |
Antwoordspecificatie. Dit element is verplicht gevuld en bevat het template ID waaraan
het antwoord op deze query moet voldoen. Omdat in de context van de zorgtoepassing
Ketenzorg vooralsnog slechts één antwoordtype wordt toegestaan, wordt een vaste waarde
gebruikt.
|
(opvragenLabUitslagen) |
|
Voorbeeld |
<responseTemplateId> <value root="2.16.840.1.113883.2.4.3.11.60.66.10.6"/> </responseTemplateId> |
|
II |
1 .. 1 |
M |
Het templateID van het antwoord komt overeen met de waarde van value. |
(opvragenLabUitslagen) |
|
|
1 .. 1 |
F |
2.16.840.1.113883.2.4.3.11.60.66.10.6 |
|
|
0 |
NP |
NP/niet aanwezig |