Tähän ylläpidetään 2013 HL7 Finland helpdeskiin tulleet kysymykset ja vastaukset tuorein ylimpänä.
3. HL7 Finland XML-skeemamääritykset ja JAXB xjc …
Kysymys:
Onko teillä tietoa, millä työkaluilla HL7 Finlandin tekemiä XML-skeemoja on onnistuneesti mäpätty tietojärjestelmiin Java-luokiksi? Ainakaan yleisesti käytetty C ei tuohon suoraan näyttäisi kykenevän, sillä se antaa paljon seuraavan kaltaisia virheilmoituksia:
“This confusing error happened most likely because the schema uses a technique called “chameleon schema”, which causes a single definition to be loaded multiple times into different namespaces.”
Vai ovatko tällaiset “työkaluihin” liittyvät kysymykset toimintanne ulkopuolella?
Vastaus:
Koostettuna sähköpostikeskusteluista alla…
( http://wiki.hl7.org/index.php?title=Schema_based_code_generation) on hyvä yleiskuvaus aiheesta (tai ainakin osasta sitä).
Yleisesti: HL7 version 3 (mukaan lukien XML ITS ja CDA) skeemoja ei ole tarkoitettu eivätkä ne kovin hyvin sovi koodin generointiin esim. samalla tavoin kuin tyypillisissä web services / WSDL-rajapintamäärityksissä joissa elementtejä vastaavat luokat on helppo mäpätä suoraan tai päätellä.
Ks. myös: http://www.ringholm.com/column/Renovate_HL7_v3.htm / Re-use
Kokemustemme mukaan (mm. ajanvarausrajapinnoista) myös HL7 v3 viestinvälityksen toteuttamisessa HL7 versio 3 XML-sanomien välinetuetun koodin generoinnin sijaan on kannattanut käyttää XML-läheisempää kehittämismallia jossa käsitellään XML-dokumentteja, elementtejä ja attribuutteja. Esimerkiksi HL7 v3 Web services profiilin mukaiset WSDL-tiedostot eivät ole kovinkaan käyttökelpoisia koodin generointiin. Näitä kokemuksia on kuvattu myös mm.: http://ojs.tsv.fi/index.php/stty/article/view/6532
Alla myös HL7 Finland helpdesk kirjeenvaihtoa samasta aiheesta ja kameleonttikoodista vuodelta 2009. Ehkä tästä olisi hyvä tehdä FAQ-aihe jos sellaista ei vielä ole.
Liitteenä on myös Rene Spronkin “v3 implementation mechanics” tutoriaalimateriaalia / 2008 jossa koodin generointiaihetta käsitellään, josta voi poimia sisältöä vastaukseen (lähde mainiten) mikäli tarpeen.
Subject: Re: hl7hd-l: RE: Ajanvarausrajapinta HL7v3
1. Osassa HL7 v3 scheemoista (datatypes.xsd, datatypes-base.xsd, voc.xsd) ei ole targetnamespacea määritetty. Nämä scheemat includoidaan muihin scheemoihin ja ne saaavat includoivan scheeman targetnamespacen. Tästä käytetään nimeä. “Chameleon include”.
esim. infrastructureRoot.xsd tiedostossa
<xs:include schemaLocation=”../coreschemas/datatypes.xsd” />
<xs:include schemaLocation=”../coreschemas/voc.xsd” />
Nopealla etsinnällä allaolevan linkin mukaan Chameleon include on kielletty WSDL:ssä: http://www.stylusstudio.com/w3c/wsdl20-1/includes.htm sivulta löytyy kohta:
Note that because all WSDL descriptions have a target namespace, no-namespace includes (sometimes known as “chameleon includes”) never occur in WSDL.
Eli kaikissa scheemoissa on oltava määritys targetNamespace=”urn:hl7-org:v3″, tämän jälkeen koodin generoinnin pitäisi onnistua.
2. HL7 scheemojen käyttö koodin generointiin on haastavaa ja scheemoja on modifioitava hyvän tuloksen saamiseksi. Corescheemat (datatypes, datatypes-base ja voc ) sisältävät paljon tyyppejä, jotka ovat turhia ja voidaan poistaa. Ohessa esitys, joka käsittelee osittain tätä asiaa, erityisesti kohta “Validation and Parsing:Schema Based Code Generation”, sivut 32-33. Näitä toimenpiteitä ei tietysti tarvitse tehdä heti alussa mutta s.32 ohje “flatten the Schema’s” voi olla hyödyllinen vaikka tuloksena saatava scheema onkin kookas.
>Syötteeksi kuitenkin ajanvarauskehityksestä havaittua:
>Luokkien generointi HL7 v3-skeemoista on hieman ongelmallista: skeemat ovat rekursiivisia, ja “turhia” luokkia voi tulla todella paljon johtuen HL7 V3-skeemojen monimuotoisuudesta. WSDL ei ole versio 3-sanomissa luokkien generointiin kovin hyödyllinen tästä syystä. Koodin generointi toimii paremmin, kun parametrit ovat perustietotyyppien mukaisia eikä monimutkaisia, rekursiivisia ja syviä rakenteita (kuten v3-sanomissa). WSDL:n käyttöä v3-sanomissa on käsitelty HL7 v3 messaging-oppaassa.
>En tiedä, onko muilla kokemusta wsdl.exe:n käytöstä, mutta myös hakemisto-ongelmat tai v3 tietotyyppiskeema voivat ilmeisesti aiheuttaa ongelmia sen kanssa (virheilmoitus vaikuttaa osin siltä, että ei löydy oikeaa koodistotietotyyppiä):> http://groups.google.com/group/ihe-north-america-connectathon-2009/browse_thread/thread/acffa4f0e181ecf6
>>Tutustuin HL7-sivujen kautta ajanvarausrajapintojen HL7v3 määritykseen, josta löysin myös teidän sähköpostinne. Latasin paketin ja olen yrittänyt generoida WSDL-tiedostoista interfacen omaan webserviceen siinä onnistumatta. Ongelma tulee ajaessani WSDL-tiedostosta .cs-tiedostoa (C# kielelle). Olen käsittänyt, että WSDL-tiedostot on mahdollista ajaa .cs-tiedostoiksi, joita voi käyttää oman Webservicen rajapintana. Varsinaisen webservicen toteutan MS Visual Studio 8:lla. Minkä virheen teen, alla ote command promptista:…
2. HL7-laboratorio ORM -pyyntösanoman ORC10 ja ORC12 -kentät
Kysymys:
Missä kentässä siirretään tilaavan lääkärin tiedot HL7-sanomassa laboratoriopyynnöissä, onko se ORC-10?
Asiaa käsiteltiin HL7-yhdistyksen teknisessä komiteassa 3.12.2013. Todettiin seuraavaa:
HL7-Laboratoriomäärityksessä on seuraavasti:
ORC-10 on tilauksen syöttäjä
ORC-11 tarkistaja
ORC-12 hyväksyjä
ORC-19 tilaaja
Kuvantamisen uudessa määrityksessä tilaavan lääkärin kentäksi on määrätty ORC-12.
Selvitys osoittaa, että sekä laboratorioliikenteessä että kuvantamisen liikenteessä käytetään myös tietokenttää PV1-8 lähettävä lääkäri.
Kaikki edellä mainitut tietokentät ovat tietotyyppiä XCN:
<tunnistenumero (ST)> ^ <sukunimi (ST)> ^ <etunimi (ST)> ^ <muut etunimet (ST)> ^ <nimen takaliite (esim. JR tai III) (ST)> ^ <titteli (esim. Tri) (ST)> ^ <arvo (esim. LL) (ST)> ^ <lähdetaulu (IS)> ^ <järjestelmä/toimipiste (HD)> ^ <nimen tyyppikoodi (ID)> ^ <tunnisteen tarkistusmerkki (ST)> ^ <käytetyn tarkistusmerkkijärjestelmän tunnistekoodi (ID)> ^ <tunnisteen tyyppikoodi (IS)> ^ <alkuperäinen järjestelmä (HD)>
Eli ensimmäisessä komponentissa on tunnistenumero.
ORC-10 on tilauksen syöttäjä, joka voi toki jossain tapauksessa olla lääkärikin.
Vastaus: vastaanottavan ohjelmiston tulisi etsiä lääkäriä tietokentistä ORC-12 ja PV1-8, ORC-10 on tilauksen syöttäjä.
1. laboratorion HL7 ORU -sanoman hälytysarvot
Kysymys:
Onko olemassa virallisia määrityksiä laboratorion HL7 ORU -sanoman hälytysarvojen toimittamisesta, onko hälytysarvojen toimittaminen vastaussanomassa vapaaehtoista, ja onko hälytysarvojen tuottaminen/toimittaminen palvelun tuottajan tehtävä vaiko palvelun ostajan?
Vastaus:
TC:ssä käytiin asiaa läpi ja tämä vaatimus on HL7:ssa vapaaehtoinen, joten kysymys on enemmänkin tietoa välittävien organisaatioiden tietohallintojen välinen asia, että kuinka toteutetaan.
Terho Eskelinen totesi, että kenttä on tosiaan vapaaehtoinen ja kaikissa laboratoriojärjestelmissä tai tuloksissa tätä ei ole mahdollista liittää tulokseen.
Määrittelyjen mukaan L, LL, H, HH –arvot liittyvät numeraalivastauksiin ja A, AA –arvot tekstimuotoisiin vastauksiin. A –arvoa ei siis pitäisi käyttää numeraalivastauksilla.
Käytännössä kentän A-arvo kuitenkin aiheuttaa vastaanottavissa järjestelmissä tuloksen korostamisen ja parantaa tuloksen luettavuutta jonka takia tälle tavalle on olemassa hyvä perustelu.
Oma ehdotukseni on, että kenttää käytettäisiin standardiin kirjattujen sääntöjen mukaisesti. Jos A-arvoa käytetään numeraalituloksissa jo nyt niin käytäntöä ei ole tarve muuttaa ennenkuin ohjelmat tukevat L/H –koodeja. Mikrobiologian struktuurituloksille samaa kenttää käytetään ns. SRI-tulkintojen yhteydessä.
Kenttä on siis OBX-8 Poikkeustilanneviestit ID
Tämä tietokenttä sisältää tutkimusvastauksen statuksen koodin. HL7 taulussa 0078 on kuvattu poikkeustilanneviestit ja niiden sallitut arvot.
HL7 taulu 0078 – poikkeustilanneviestit
Päätettiin, että laitetaan help deskiin Terho Eskelisen kuvaus tilanteesta ja ehdotus ideaalista ja yhdenmukaisesta toimintatavasta. Näin tulisi toimia, mutta EI voida luottaa siihen, että arvo on olemassa sanomilla.