DECOR-informatie voor project: Jeugdgezondheidszorg (jgz-)

In de wsdl van het nieuwe overdrachtsbericht (ZorgOverdrachtVerzoekJGZ-02.wsdl) staat de volgende SoapAction gedefinieerd: <soap:operation soapAction="urn:hl7-org:v3/ZorgOverdrachtVerzoekJGZ02_ZorgOverdrachtVerzoek" />. De PoC omgevingen van VZVZ ondersteunen alleen de oorspronkelijke SoapAction, namelijk zonder de 02: "urn:hl7-org:v3/ZorgOverdrachtVerzoekJGZ_ZorgOverdrachtVerzoek". Dit blijkt ook uit onze testen: met de 02 krijgen we de foutmelding "Unsupported SOAPAction", zonder de 02 kunnen we succesvol berichten sturen naar de onbeveiligde omgeving van VZVZ.

De SoapAction aanpassen.

-

Waar gaan we de lengte van het veld Anders (lengte 80) vastleggen in de documentatie? (vraag Kyndylan, mail 27-8-2013)

-

-

Toevoegen “Beoordeling bloeddruk” met waarden te laag, normaal en te hoog en cardinaliteit 0..1 (kan berekend worden op basis van afkapwaarden, echter waarde wel meesturen in dob).

  NB  Dat de groep vervalt, is vrijwel zeker. De toevoeging is een stuk minder zeker. De vraag of dat op dit moment moet of in volgende versie kan.

Beoordeling bloeddruk: nieuw 0..1

     Te laag

     Normaal

     Te hoog

-

• 1 kleurloos 2.16.840.1.113883.2.4.4.13.18
• 2 meconium 2.16.840.1.113883.2.4.4.13.18
• 3 bloederig 2.16.840.1.113883.2.4.4.13.18

BDS-element 1159 "Verwijzing naar" is in de technische versie 3.2.1 gewijzigd in "Advies en verwijzing naar", maar daarbij had ook de handleidingnaam meegenomen moeten worden. Dit is onterecht niet gebeurd

Handleidingnaam van BDS-element 1159 ook wijzigen

Melding Bettie

Bij de template voor de hielprik is een slecht leesbare (Nederlands en ambigu) omschrijving voor het attribuut @negationInd en de conditie direct daar onder.

Corrigeren op leesbaarheid

Melding Rens Verhage

• 12 Huisnummer (nummer)
• 13 Huisletter (vrij tekstveld)
• 14 Huisnummertoevoeging (vrij tekstveld)
• 16 Postcode (vrij tekstveld)

Hier ontbreken de elementen uit de keuze waardoor niet goed duidelijk is hoe je afspraken en contactmomenten koppeling aan het dossier

HTML-generatieproces doorlopen zodat de informatie die er wel is ook doorkomt en overwegen meer tekst toe te voegen waar relevant

Melding Rens

- De status van de encounter is volgens art-decor een keuze tussen 'completed' en 'aborted' en volgens de BDS (en de database export) is het 'complete' en 'cancelled'.

<component7>
   <encounter moodCode="EVN">
     <id extension="3800993" root="2.16.528.1.1007.3.3.2233445.3"/>
     <code code="09" codeSystem="2.16.840.1.113883.2.4.4.40.308"
     displayName="9 maanden PGO A"/>
     <statusCode code="complete"/>

Ook schematron klaagt hierover en keurt berichten af met een status 'complete' omdat schematron denkt dat het 'completed' moet zijn.

- de statuscode in het HL7 bericht wijzigen in de opties 'complete' en 'cancelled' zoals in de database exporttabel 'WAARDEN' van de BDS staat aangegeven:

"W0190";"Uitgevoerd/Verschenen op afspraak";"01";"complete";"";1;"2.16.840.1.113883.2.4.3.11.60.100.12.190";"2.16.840.1.113883.5.14"
"W0190";"Niet uitgevoerd/Niet verschenen op afspraak";"02";"cancelled";"";2;"2.16.840.1.113883.2.4.3.11.60.100.12.190";"2.16.840.1.113883.5.14"

-

- Wanneer ik het voorbeeld uit de "subjectOf" node toepas, krijg ik een xsd validie fout, omdat de "assignedEntity" ontbreekt in de author:

- Documentatie aanpassing, of xsd ...

Fout genererende code:

                        <subjectOf>
                            <careStatus>
                                <code code="1197" codeSystem="2.16.840.1.113883.2.4.4.40.267"
                                    displayName="status in zorg"/>
                                <effectiveTime value="20130220"/>
                                <reasonCode code="01" codeSystem="2.16.840.1.113883.2.4.4.40.376"/>
                                <author>
                                    <time nullFlavor="UNK"/>
                                </author>
                            </careStatus>
                        </subjectOf>

Volgens xsd correcte code:

                        <subjectOf>
                            <careStatus>
                                <code code="1197" codeSystem="2.16.840.1.113883.2.4.4.40.267"
                                    displayName="status in zorg"/>
                                <effectiveTime value="20130220"/>
                                <reasonCode code="01" codeSystem="2.16.840.1.113883.2.4.4.40.376"/>
                                <author>
                                    <time nullFlavor="UNK"/>
                                    <assignedEntity classCode="ASSIGNED">
                                        <templateId root="2.16.840.1.113883.2.4.6.10.100.122"/>
                                        <id extension="1122" root="2.16.528.1.1007.3.3"/>
                                    </assignedEntity>
                                </author>
                            </careStatus>
                        </subjectOf>

- De XSD validatie keurt het ontbreken van een use attribuut in de node <addr> goed, terwijl schematron deze afkeurt. Volgens de documentatie op Art-Decor is het attribuut ook verplicht. We lieten het attribuut weg, omdat we graag type 'anders' uit de BDS in het DOB willen mappen, dit was een optie.

- Oplossing zoeken om adrestype 'anders' van de BDS te mapping in het DOB

- Volgens ArtDecor template "Care Provision Dossier" moet de summary node aan het einde van de CareProvisionEvent node staan. Volgens REPC_IN902120NL.xsd moet de summary echter tussen "authorization" en "pertinentInformation" staan

- documantatie gelijktrekken aan xsd of omgekeerd :-)

-

- Wanneer ik een afgebroken activiteit converteer, wordt de status van de encounter 'cancelled' ,zoals op de AD site aangegeven en in de maplijst WAARDEN. Echter, schematron accepteerd alleen 'completed' en 'aborted'

- Schematron aanpassen

-

- De lengtemeting methode bij rubriek 'Groei' (R027), element 236, is in de BDS optioneel. Echter, in HL7 is deze verplicht

- Ook optioneel maken in HL7

-

Voor in elk geval de hielprik geldt dat deze nog 'hard' op vertrouwensniveau midden staat. Deze moet waarschijnlijk op 'laag'. Dat heeft effect op transactiebeschrijvingen, templates en schema's

Correcte vertrouwensniveau's opvragen bij Marja en doorvoeren

Melding Ron Rensen

A_Rijksvaccinatie-informational-all ondersteunt geen bezwaar op geplande vaccinaties. RIVM ondersteunt mogelijk wel bezwaar op nog te geven vaccinaties. Dit zou dan ondersteund moeten worden in de GGR voor bericht 1 en 2.

-

Melding Yvonne Pijnacker Hordijk

- Wanneer in de BDS een soortActiviteit is ingevoerd van het type 'Anders' (id=98) met een omschrijving, mag deze omschrijving niet worden overgenomen in het DOB, omdat de @code moet worden vervangen door een @nullFlavor='OTH' zònder displayName

- oplossing zoeken, zodat er geen informatie verloren gaat

- In de omschrijving van de soortActiviteit staat be4schreven om welke activiteit het gaat. Ook als het om een soort 'Anders' gaat. Zonder de omschrijving gaat verloren om welke activiteit het gaat

Het element 1492 "Gewichtsklasse op basis van BMI" is gekoppeld aan waardendomein W0167 "Berekend veld", dit moet waardendomein W0668 "Gewichtsklasse op basis van de BMI" zijn.

In twee templates is de huisletter gekoppeld aan het HL7-element houseNumber in plaats van buildingNumberSuffix

Koppeling aanpassen

-

Het doorgegeven van iets als "derde archiefkast links" heeft weinig toegevoegde waarde voor een ontvanger van een dossieroverdrachtverzoek

Niet meer meesturen in dossieroverdracht

-

Omdat zinvol bestanden te kunnen overdragen moet ook een bestandsnaam en bestandstype bekend zijn. Op deze manier kunnen de organisaties later ook aan hetzelfde bestand refereren en kan de ontvanger goed determineren wat voor soort bestand het is.

Toevoegen Bestandsnaam en Bestand mimetype in de BDS en HL7

Uitkomst van telefonische vergadering met alle leveranciers en Bettie Carmiggelt (NCJ) dd 2013-09-10

Cardinaliteit Afzender bestand wijzigen van 1..1 naar 0..1. Afzender is conditioneel, als scan van het DD JGZ dan geen afzender en anders wel

-

-

- De activeiteitcode 29 wordt in het DOB (<code code="29" codeSystem="2.16.840.1.113883.2.4.4.40.308"/>) door schematron afgekeurd. De code staat wel in de WAARDEN lijst met omschrijving "Consultatie/inlichtingen vragen"

- Schematron aanpassen

- lokatie:

 <component7>
      <encounter moodCode="EVN">
          <id extension="4099191" root="2.16.528.1.1007.3.3.2233445.3"/>
          <code code="29" codeSystem="2.16.840.1.113883.2.4.4.40.308"  displayName="Consultatie/inlichtingen vragen"/>
          <statusCode code="completed"/>

“G022 Huid/haar/nagels” groep laten vervallen waardoor de cardinaliteit van “163 Bijzonderheden huid/haar/nagels” verandert in 0..* en “164 Toelichting huidaandoening” een algemene toelichting wordt op alle binnen dat contactmoment geconstateerde bijzonderheden wordt.

In de praktijk wordt deze groep niet gebruikt maar als een meerkeuze lijst met een algemene toelichting. De situatie is nu dat veel organisaties dit als niet BDS-element hebben ingebouwd om die reden.

Huid/haar/nagels: G022, 0..*

Bijzonderheden huid/haar/nagels: 163 0..1 (W0217, KL_AN, Bijzonderheden huid/haar/nagels)

Toelichting huidaandoening: 164 0..1 (W0020, AN, Alfanumeriek 200)

-

BDS/HL7: groep 27 Bovenste extremiteiten vervalt, element 802 Bijzonderheden bovenste extremiteiten wordt 0..1 en element 803 Lichaamskant bijzonderheden bovenste extremiteiten vervalt.

“G027 Bovenste extremiteiten” vervalt. “803 Lichaamskant bijzonderheden bovenste extremiteiten” vervalt. “802 Bijzonderheden bovenste extremiteiten” wordt cardinaliteit 0..1.

Aparte combi: vrij tekstbeld met lichaamskant in een groep. In een vrij tekstveld kan men alle relevante info zetten. Groep en lichaamskant zijn niet nodig.

Bovenste extremiteiten: G027, 0..*

Bijzonderheden bovenste extremiteiten: 802 0..1 (W0082, AN, Alfanumeriek 4000)

Lichaamskant bijzonderheden bovenste extremiteiten: 803 0..1 (W0206, KL_AN, Rechts Links)

-

E-mail Ron Alders (11-09-2013): Deze vraag hebben wij momenteel gemodelleerd als een aanvinklijst aangezien de vraag meerdere keren voor mag komen. Alleen Dan is de laatste optie in deze lijst wel erg gek en mogelijk tegenstrijdig.

Eigenlijk zijn het twee vragen die in 1 element zijn gestopt. En dit zie je nergens anders op deze manier terug in de BDS.

Wat gaan/kunnen we hier aan doen?

• Optie 1:
  We zouden we twee vragen van kunnen maken namelijk:
  Zwemles: BL, Ja Nee
  Schoolzwemmen: BL, Ja Nee
• Optie 2:
  De vraag niet herhaalbaar maken maar een vast lijst gebruiken:
  Zwemles:
  - Zwemles
  - Schoolzwemmen
         -  Zowel zwemles als schoolzwemmen
         -  Geen zwemles en geen schoolzwemmen
• Optie 3:
  Niets doen maar dan ben ik bang dat de vraag nooit in gebruik wordt genomen op deze manier

-

-

-

-

-

Bij het implementeren van de BDS hebben wij een fout gevonden in de database in de elementen 1433, 1434 (Diagnose Audiologisch Centrum gehoor links / rechts) en 1435 (Interventie Audiologisch Centrum). Deze vragen maken gebruik van de waardendomeinen W0661 en W0662. In de tabel waardendomeinen staat voor beide domeinen als type 'N', dit moet echter 'KL_AN' zijn. (citaat van Rens – Topicus, mail van 26-8-2013, 16.50 uur)

-

-

of

afhankelijk van de communicatiepartners en de ouderdom/herkomst van de gegevens in het bronsysteem.

De specificatie op huisletter bestond al in de vorm van het element "buildingNumberSuffix". Indien het bronsysteem deze gescheiden heeft dan kan deze ook gescheiden worden doorgegeven. Als het bronsysteem deze niet heeft echter, dan blijft de mogelijkheid bestaan deze samen met het huisnummer door te geven in het element houseNumber.

Dat was altijd al de intentie van de specificatie, maar stond er zodanig dat ik er zelf ook overeen keek. Ik heb daarom de omschrijving bij houseNumber als volgt aangepast:

Het element houseNumber moet het het huisnummer bevatten. Het huisnummer kan niet-numerieke gedeelten bevatten die het adres mede identificeren, bijv. "23a", maar alleen als de bron deze niet gescheiden kan aanbieden. Huisletter dienen indien mogelijk in het element buildingNumberSuffix te worden doorgegeven. Gegevens zoals "to" (woonboten) of "3 hoog achter" maken geen deel uit van dit attribuut. Dit type gegevens is elders in het Adres datatype opgenomen.

Uiteraard betekent e.e.a. dat zodra huisnummer en huisletter eenmaal aan elkaar vast zitten, dat scheiding ervan niet meer (zo makkelijk) lukt.

Volgens de handleiding mappen zowel element 13 huisletter als 14 huisnummertoevoeging naar het HL7-element buildingNumberSuffix. In dit element is slechts plaats voor één waarde. Hoe moeten de elementen gecombineerd worden, zodat ze tijdens het importeren weer eenduidig uit elkaar kunnen worden gehaald?

Een mogelijke oplossing is als volgt. We kiezen een karakter dat niet kan voorkomen in een huisletter of huisnummertoevoeging, en plakken de twee elementen in een vaste volgorde aan elkaar met dat karakter er tussen. Bij het importeren kan de waarde gesplitst worden aan de hand van het karakter, en omdat de volgorde vaststaat kunnen beide helften als huisletter en huisnummertoevoeging geïmporteerd worden.

In een eerdere e-mailuitwisseling is besloten dat de huisletter niet meer in een houseNumber komt, maar in een buildingNumberSuffix. Dit lost het probleem van de ambiguïteit echter niet op.

Overige opmerkingen:

In de handleiding staat het element 13 nog bij de klasse houseNumber i.p.v. bij de buildingNumberSuffix. Dit issue hoort bij R_PatientNL-JGZ-universal. Het lukte me helaas niet om het issue daar aan te maken, omdat de knop op de website het niet deed.

Waardenlijst komt in publicatie op http://decor.nictiz.nl/jeugdgezondheidszorg/BDS321/?elementInfo=true maar half voor, terwijl hij in decor bij de waardenlijsten wel in zijn geheel voorkomt.

Nagaan waarom op bepaalde plekken niet volledig getoond wordt.

-

De BDS zegt dat element 9 Geboorteplaats uit GBA tabel 33 moet komen, maar de GBA zelf heeft naast tabel 33 ook mogelijkheid op vrije tekst om ook bijvoorbeeld gemeenten/plaatsen uit het buitenland door te geven of zelfs een lengte- of breedtegraad (GBA Logisch Model 3.7)

BDS-definitie aanpassen zodat dit element overeenstemt met de GBA waar de informatie ook vandaan komt.

De HL7-implementatie is reeds in lijn met de GBA definitie (min of meer toevallig)

Score 1 en Score 2 zijn nu numeriek gemodelleerd terwijl dit beter vergelijkbaar aan de Proef van Romberg een tweetal gecodeerde waarden kan zijn.

code 1 = Kruis niet herkenbaar
code 2 = Kruis herkenbaar

-

“G112 Bloeddruk” vervalt. “G113 Afkapwaarden bloeddruk systolisch” vervalt. “G114 Afkapwaarden bloeddruk diastolisch” vervalt.

“1486 Bloeddruk systolisch” en “1487 Bloeddruk diastolisch” komen niet in groep en worden cardinaliteit 0..1

NB  De elementen van de afkapwaarden hebben G-nummers (voor groepen niet voor elementen)?

Bloeddruk wordt mogelijk meerdere keren gemeten maar 1x geregistreerd.

De afkapwaarden komen uit een vaste tabel en een beoordeling of de bloeddruk te hoog is, is functionaliteit dossier. Afkapwaarden worden niet meegestuurd in overdrachtsbericht.

Bloeddruk: G112, 0..*

Bloeddruk systolisch: 1486 0..1 (W0667, PQ, Bloeddruk)

Afkapwaarden bloeddruk systolisch: G113, 1..1

Bloeddruk diastolisch: 1487 0..1 (W0667, PQ, Bloeddruk)

Afkapwaarden bloeddruk diastolisch: G114, 1..1

-

Alle toelichtingelementen in de BDS die teruggrijpen naar meer dan 1 element zijn AN..4000

Omzetten van W0020 AN..200 naar W0082 AN..4000

-

Wijzigen: bij “G045 VWO vraag 27” “925 Opmerking bij VWO 27”  buiten groep plaatsen met cardinaliteit 0..1

De opmerking in de groep maakt de groep technisch gecompliceerd. De noodzaak om de toelichting bij de lichaamskant te houden is er niet. In HL7 is het al op deze wijze gemodelleerd.

VWO vraag 27: G045, 0..2

     27. Houdt potlood met vingers vast: 923 1..1 (W0175, KL_AN, Plus Min)

     Lichaamskant VWO 27: 924 0..1 (W0206, KL_AN, Rechts Links)

Opmerking bij VWO 27: 925 0..1 (W0020, AN, Alfanumeriek 200)
(buiten groep geplaatst)     

-