DECOR-informatie voor project: Jeugdgezondheidszorg (jgz-)

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

-

-

Element 152 "(Kinder-)ziekten" was altijd van type AN, met een veldlengte van 200 en een cardinaliteit van 0..*. Nu is de cardinaliteit 0..1 geworden, maar de veldlengte is nog steeds 200. Aangezien het BDS-element zelf niet van nummer is gewijzigd en het dus hetzelfde BDS-element is, kan het dus zijn dat bij het aanpassen van de cardinaliteit de totale lengte van de oude waarden groter is dan de lengte van het 'nieuwe' veld.

Aanpassen naar max 4000 karakters. Ik dacht dat we dat hadden afgesproken, maar dat weet ik niet zeker.

Element 1497 "Bestandsnaam" heeft nu een maximale van 200 karakters. Echter, het maximum aantal karakters dat Windows in een filename toestaat is 255.

- Volgens de BDS is in rubriek 050 het veld 'statusInZorg' niet verplicht. In de careStatus (component 1197) is reasonCode echter wel verplicht.

- reasonCode bij component 1197 niet verplicht maken

-

Bij het element E1185Bestand zijn er aparte elementen aangemaakt voor de extensie en de naam van het bestand, maar bij E1006ScanVanOefeningenblad niet. Heeft de bestandsnaam en -extensie hier altijd een vaste waarde, of horen hier ook extra elementen bij te komen?

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

-

In de rubriek Externe documenten is het bestandstype Scan van oefeningenblad BFMT ook aanwezig. Daarmee dupliceert het element 1006 dus de functie van het element 1185 "Bestand". De scan kan niet in beide staan. Sinds versie 3.2.2 van de BDS kan in de rubriek externe documenten meer metainformatie worden meegegeven zoals bestandsnaam. De diverse leveranciers geven de voorkeur aan het opnemen van *alle* externe documenten in Rubriek 9. Op basis van de datum van de scan (element 1172) kan de scan aan de juiste activiteit met de betreffende BFMT worden gekoppeld.

- Niet (meer) gebruiken en de facto opheffen van element 1006 in de rubriek BFMT
- Element 1185 aanwijzen als de de factor plaats voor het doorgeven van 1 of meerdere BFMT scans (tekstuele aanpassing)
- Verplichting BDS om element 1172 Datum bestand bij de Scan een waarde te geven (in DOB optioneel)
- Eventueel: nieuw element "Scan aanwezig" toevoegen in rubriek BFMT

-

Ik heb een probleem waar ik nog geen oplossing voor zie. Het gaat om een element dat niet in de eerste kwalificatieset zit, maar wij wel in het bericht zetten, namelijk element 53: Ziektekostenverzekering (ja/nee).

Volgens template A_Coverage_minimal moet ik o.a. het volgende in het bericht plaatsen:

<coveredParty typeCode="COV" xsi:nil="true" nullFlavor="NI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />

Zoals je wellicht weet maken wij gebruik van JAXB om onze Java objecten om te zetten naar de Hl7v3 XML. JAXB ondersteunt zogenaamde 'nillable' elementen, d.w.z. als zo'n element niet geïnitialiseerd (null) is dan genereert JAXB hiervoor toch een XML-element, maar dan met xsi:nil="true", precies zoals de specificatie hierboven het voorschrijft.

Echter, wanneer coveredParty null is, dan is er geen object en heb ik dus ook geen object waar ik attributen aan kan toevoegen, dus het attribuut typeCode="COV" kan ik niet genereren op deze manier. JAXB genereert dan:

<coveredParty xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />

Dit is volgens de schema's niet valide, aangezien coveredParty als element wel aanwezig is, maar het verplichte attribuut typeCode="COV" niet.

Om dit op te lossen moet ik in Java de coveredParty property initialiseren ipv null te laten. Dan kan ik de typeCode en nullFlavor erop zetten. JAXB genereert dan het volgende:

<coveredParty typeCode="COV" nullFlavor="NI" />

Nu is er een ander probleem. Omdat coveredParty in Java niet meer null is, genereert JAXB ook geen xsi:nil="true" meer. Gevolg is dat nu validatie tegen de schematron faalt, want ik moet xsi:nil="true" genereren.

Zoals je ziet bevind ik me in een Catch-22 en kan ik geen kant op. Kan in de schema's aangepast worden dat een typeCode niet meer verplicht is wanneer het element nil is? Of moet de schematron worden aangepast?

• 1492 "Gewichtsklasse op basis van de BMI" is als berekend veld geen onderdeel van de DOB
• 6 "Voornaam", 5 "Roepnaam", 1 "Voorvoegsel achternaam", 2 "Achternaam" waren verkeerd gekoppeld in HL7 (er stonden naamcomponenten van de ouder/verzorger) -- nieuwe publicatie vereist
• 1457 "Startdatum geldigheid uitvoerende JGZ-organisatie" en 1458 "Einddatum geldigheid uitvoerende JGZ-organisatie" staan correct in de specificatie: ik zoek verder uit waarom ze de database niet hebben 'gehaald'
  

De volgende elementen verwacht ik in het DOB, maar vallen volgens de tabel BerichtElementen er buiten:
E0005Roepnaam
E0001VoorvoegselAchternaam
E0002Achternaam
E1492GewichtsklasseOpBasisVanBmi
E1457StartdatumGeldigheidUitvoerendeJgzOrganisatie
E1458EinddatumGeldigheidUitvoerendeJgzOrganisatie

Voorstel:

De tabel BerichtElementen aanpassen.

De elementen die horen bij het DOB kunnen met de volgende query opgevraagd worden: select * from berichtelementen where berichtid = '2.16.840.1.113883.2.4.3.11.60.100.4.20'

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

-

-

- Wanneer ik een rubriek 012 exporteer met een groep 19 (erfelijke ziekten) en slechthorende moeder, dan wordt volgens de WAARDEN tabel voor domein W0115 de code NMTH geëxporteerd. Deze code komt uit de WAARDEN tabel.

- Het is beter om hier MTH, FTH, BRO of SIS te exporteren omdat NMTH (natuurlijke moeder) een nauwkeuriger aanduiding is van 'moeder'  dan gewoon 'moeder'. Dit vereist een aanpassing in de BDS.

- Mail van Alexander:

NMTH en NFTH staat voor Natural mother en Natural Father. MTH en FTH zijn generalisaties van dezelfde concepten en staan voor Mother en Father zonder uitspraak over adoptie/natuurlijk/pleegstatus

De BDS is maar op een paar plaatsen zuiver in de behandeling van deze concepten en verder vrij vaag. Ik heb dus ook verschillende mappings gelegd afhankelijk van de of de BDS specifiek is of niet.

Ik zie dat hier inderdaad een inconsistentie is in de specificatie tussen de terminologyAssociation en de valueSet. De terminologyAssociation wordt gebruikt voor BDS en de valueSet voor schematron. Deze zeggen normaal hetzelfde maar hier niet. In dit geval klopt de valueSet echter wel en de BDS koppeling niet. MTH en FTH zijn de beste vertegenwoordigers van de inpreciese BDS-waarden Moeder en Vader. Natuurlijke moeder/vader zou een onterechte precisie suggereren.

Kun je deze als ART-DECOR issue opvoeren? Bij deze ook kopie naar Marja voor toevoeging in het wijzigingendocument.

@Marja: Deze valt onder dezelfde categorie als de BDS-koppeling van adrestype "Anders". De koppeling met HL7 staat weliswaar in de BDS, maar het is niet iets waarmee je een redactieraad kunt opzadelen. Ik zou willen voorstellen om de BDS-koppelingen aan te passen zodat ze hetzelfde zeggen als de waardenlijst. Ik zal kijken of ik hier nog een interne controle op kan leggen zodat Reini het niet hoeft te vinden: ik dacht dat ik die al had, maar blijkbaar is deze situatie niet ondervangen.

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

Niet meer meesturen in dossieroverdracht

-

Scenario DOB en Template rubricCluster19 bevatten een verplichting op element 748 Anamnese. Deze is in de BDS wel verplicht, maar historisch gezien misschien niet aanwezig.

Reini had issue#33 ingeschoten. Deze betreft de correcte constatering dat de modellering rondom "Papieren JGZ-dossier aanwezig" en de locatie ervan niet strookt met de BDS. Oplossen daarvan lukt in mijn beleving alleen met een modelwijziging. Deze wil ik graag aan jullie voorleggen.

Element 1167 "Papieren JGZ-dossier aanwezig" Ja is in HL7 een Observation met code 1167 en value true

Element 1167 "Papieren JGZ-dossier aanwezig" Nee is in HL7 een Observation met code 1167 en value false

Element 1168 Locatie papieren JGZ-dossier kan logischerwijs geen "location" participation zijn op de observatie "true" of "false" en wordt ook een Observation met code 1168 en value "Archieflocatie IJsselstein" (of iets dergelijks)

Deze twee observaties hebben geen duidelijke relatie met het elektronische dossier. Het zijn zo goed als losse opmerkingen t.o.v. de elektronische versie. Observations met niet-deterministische relatie t.o.v. een andere Act (hier: CareProvisionEvent) krijgen typeCode="PERT". Deze relatie bestond al voor de A_Zwangerschap gegevens (rubriek 14)

---

Om die reden zou de situatie ontstaan zoals in de bijlage aangegeven. Uiteraard betekent dit een schemawijziging maar vanwege het optioneel maken van de responsibleParty met daarin de Verantwoordelijke organisatie obv de GBA moest dat toch al gebeuren. Deze is echter wat ingrijpender.

---

Deze wijziging wil ik graag na mijn vakantie meenemen met de rest van alle wijzigingen op basis van jullie input tenzij er goede alternatieven zijn te vinden. Ik hoor graag jullie reactie.

Voorbeeld in XML:

- In de BDS is rubriek ExterneDocumenten (R009). Deze heeft één "Lokatie papieren JGZ dossier" en een lijst met bestandsgegevens (G072). In HL7 is de lokatie echter opgenomen in elk record van de appendages. Daar is dus per bestand aangegeven waar het papierendossier is gelokaliseerd.

- In HL7 de lokatie ook buiten de lijst met bestandsgegevens trekken

-  BDS:

 Papieren JGZ-dossier aanwezig: 1167 1..1 (W0004, BL, Ja Nee)

 Locatie papieren JGZ-dossier: 1168 0..1 (W0020, AN, Alfanumeriek 200)

 Toegevoegd bestand: G072, 0..*

 Bestand: 1185 1..1 (W0085, DOC, Document)

 Soort toegevoegd bestand: 1169 1..1 (W0084, KL_AN, Onderwerp document)

 Integraal dossier JGZ: 01, 01

 Scan van oefeningenblad BFMT: 02, 02

 Anders: 98, OTH (nullFlavor)

 Afzender bestand: 1171 1..1 (W0020, AN, Alfanumeriek 200)

 Datum bestand: 1172 1..1 (W0025, TS, Datum)

• 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

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)

Besproken en goedgekeurd tijdens telefonische vergadering dd 10-09-2013 door alle leveranciers en Bettie Carmiggelt (NCJ) met de volgende wijzigingen:

·      Naam Gemeente van inschrijving wijzigen naar Gemeente

·      Woonplaats uitbreiden van veldlengte 24 naar 80

·      Cardinaliteit Postcode wijzigen naar 1..1 R

·      Geboorteplaats bevat ipv code vrije tekst met maximale veldlengte 80

·      Indicatie geheim vervalt in dossieroverdrachtbericht

Twee opties voor wijziging:

1 “Gemeente van inschrijving” buiten de groep plaatsen

2 naam veranderen in “Gemeente”

Gemeente van inschrijving kan maar op 1 manier ingevuld worden, vanuit het GBA, maar het staat in een herhalende groep.

Optie 1

Adres kind: G001, 0..*

     Soort adres: 8 1..1 (W0003, KL_AN, Soort adres)

     Indicatie geheim adres: 697 0..1 (W0004, BL, Ja Nee)

     Woonplaats: 10 0..1 (W0006, AN, Alfanumeriek 24)

Gemeente van inschrijving: 9 0..1 (W0005, AN_EXT, Gemeente)
(buiten groep geplaatst)

Optie 2

Adres kind: G001, 0..*

     Soort adres: 8 1..1 (W0003, KL_AN, Soort adres)

     Indicatie geheim adres: 697 0..1 (W0004, BL, Ja Nee)

     Gemeente: 9 0..1 (W0005, AN_EXT, Gemeente)

            Woonplaats: 10 0..1 (W0006, AN, Alfanumeriek 24)

-

“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)

-

Drie opties voor wijziging:

1. “G045 VWO vraag 27” komt te vervallen en cardinaliteit “923 27. Houdt potlood met vingers vast” wordt 0..1
2. Groep blijft en cardinaliteit wordt 0..1
3. De optie “beiden” wordt toegevoegd in de groep

In de praktijk vullen organisaties alleen L of R in. Als toch 1 of 2, dan is dit lastig voor 2 leveranciers. Oplossing zou kunnen zijn de optie beiden toe te voegen.

Reactie beheerder BDS 26/8/13: 1 of 2 (dus zoals nu in de BDS) is zoals het in het Van Wiechen-boekje staat. 

Optie 1

VWO vraag 27: G045, 0..2

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

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

Optie 2

VWO vraag 27: G045, 0..1

     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)

Optie 3

VWO vraag 27: G045, 0..1

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

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

-

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)

-

“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

-