This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Algemene vragen over gebruik HL7"

From HL7Wiki
Jump to navigation Jump to search
 
Line 8: Line 8:
 
Van:Rene van Dijk mail:Rene.van.Dijk@qyn.nl<br>
 
Van:Rene van Dijk mail:Rene.van.Dijk@qyn.nl<br>
 
Verzonden: donderdag 14 april 2011 9:40<br>
 
Verzonden: donderdag 14 april 2011 9:40<br>
Aan:* Info HL7<br>
+
Aan: Info HL7<br>
 
Onderwerp: Algemene vragen over gebruik HL7<br>
 
Onderwerp: Algemene vragen over gebruik HL7<br>
 
<br>
 
<br>

Latest revision as of 08:11, 19 April 2011

Return to InM 19 april 2011 Agenda
Concept antwoord van:Rene Spronk
vrijdag - 15 april, 2011 14:17

Namens Hl7 Nederland, alwaar ook mede-voorzitter ben van een van de werkgroepen, een eerste reactie waarop enkele mede vrijwilligers (in CC) wellicht nog aanvullingen doen:

Van:Rene van Dijk mail:Rene.van.Dijk@qyn.nl
Verzonden: donderdag 14 april 2011 9:40
Aan: Info HL7
Onderwerp: Algemene vragen over gebruik HL7

Geachte mevrouw, mijnheer,

Introductie:
Ik ben mij aan het oriënteren rondom HL7 vanwege een vraag van een(mogelijke) klant. Ik ben op zoek naar de aanvullende informatie rondom de regels voor het gebruik van deze standaard. Ik zal het eerst even> toelichten.
QYN is een onderdeel van KPN dat zich bezighoudt met narrowcasting. In dat kader zijn wij benaderd door een ziekenhuis om onze standaard oplossing daarvoor te leveren. Daar is echter een belangrijke toevoeging bij; het tonen van de gemiddelde wachttijd bij een specialist.
Deze gegevens zijn afkomstig uit CS-Agenda. Het betreffende ziekenhuis heeft aangegeven zelf de berichten te kunnen configureren en via de communicatieserver te verspreiden. Dit zijn HL7 berichten.
Wij moeten een ontvanger maken voor deze berichten, de gegevens bewerken en verwerken (omzetten in wachttijden) en op een scherm tonen. Onze onbekendheid zit bij het ontvangen van de berichten. Wij zullen ons aan de standaarden moeten conformeren om de berichten te kunnen ‘ontleden’.
Hierbij moet worden aangegeven dat softwareontwikkeling voor ons geen core-business is. We hebben een klein team om koppelingen vanuit andere systemen te ontwikkelen en ons standaard systeem verder uit te breiden. Maar uitgebreide koppelingen als nu gewenst gaan voor ons misschien een stap te ver.

Vraag 1:
Als wij de koppeling zelf zouden willen ontwikkelen dan moeten we lid worden van de HL7 organisatie. Dan krijgen we de beschikking over de benodigde documentatie. Is het mogelijk om op basis van de documentatie zelf een koppelvak te ontwikkelen of is er aanvullende training noodzakelijk? (Wij hebben 2 zeer ervaren ontwikkelaars.)
Antwoord 1:
Ervaren ontwikkelaars zouden zonder meer in staat moeten zijn vrij snel een koppelvlak te ontwikkelen waarmee men HL7 versie 2 berichten kan ontvangen. Hierbij kan gebruik worden gemaakt van public domain API's zoals HAPI (voor Java) en nHAPI (voor .net). [Zie tevens http://hl7book.net/index.php?title=HL7_version_2 ; middelste kolom, en http://www.hl7.org.au/HL7-Tools.htm]. Er zijn tevens commerciële toolkits die het een leverancier vereenvoudigen een HL7 versie 2 koppeling te schrijven.

Vraag 2:
Geldt er daarna nog een vorm van certificering of iets dergelijks voor de software of een soort kwaliteitscontrole?
Antwoord 2:
Nee.

Vraag 3:
En waar hebben wij dan nog meer mee te maken, dus bijvoorbeeld regels> rondom gebruik, registratie etc.?
Antwoord 3:
Als HL7 lid kunnen de HL7 standaarden vrij gebruikt worden, zonder licenties of wat dan ook (zolang men maar lid is). Als organisatie mag men tevens (indien men zelf berichten zou sturen) relevante gedeelten van de documentatie aan klanten ter beschikking stellen.

Vraag 4:
Ik heb door de ledenlijst gekeken en gezien dat er enkele softwareleveranciers bij staan. Zijn er daarbij, bij uw weten, partijen die zich gespecialiseerd hebben in de ontwikkeling van maatwerk software voor derden. Mogelijk dat we een derde partij kunnen inhuren voor het realiseren van de ‘ontvangstmodule’ en dat wij ons kunnen richten op het tonen van de informatie.
Antwoord 4:
Er zijn ongetwijfeld leden die een dergelijke service zouden kunnen bieden. De HL7 organisatie zal echter geen aanbevelingen of verwijzingen (kunnen) doen, aangezien zij strikt leveranciersneutraal is. De ervaring leert dat indien de scope van het project beperkt is tot het verwerken/ontvangen van HL7 versie 2 berichten dat een programmeur dit redelijk snel om kan zetten.
Belangrijk in deze context is een gedetailleerde beschrijving, en voorbeelden, van de berichten die uit CS-Agenda komen.

Vraag 5:
Ik hoop dat u wat algemene tips voor mij heeft en kan aangeven waar ik rekening mee moet houden als we zelf willen ontwikkelen of het extern wil beleggen. Op de website heb ik hierover geen zaken gevonden (wat niet wil zeggen dat het er niet staat…, misschien heb ik niet goed gekeken). Vooral belangrijk is of wij op basis van de documentatie zelf kunnen ontwikkelen en welke regels er daarna gelden. Bij teveel randvoorwaarden moeten we serieus naar een derde partij gaan kijken.
Antwoord 5:
Er is geen licentie, en geen certificatie, dus u bent redelijk vrij in de wijze hoe u het in uw systeem inbouwt. Idealiter heeft u de beschikking over de CS-agenda berichtbeschrijving en een zo uitgebreid mogelijke set testberichten. Tezamen met HAPI of nHAPI kan een en ander dan vermoedelijk redelijk snel worden ontwikkeld.


Met vriendelijke groet, namens HL7 Nederland,

-Rene

Alvast bedankt.

Met vriendelijke groet,

Rene van Dijk Productmanager