7kezo:V1.0 Geretourneerde response: verschil tussen versies
k (Tekst vervangen - "{{#customtitle:" door "{{DISPLAYTITLE:") |
|||
| (3 tussenliggende versies door 2 gebruikers niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
| − | {{ | + | {{DISPLAYTITLE: Geretourneerde response | Geretourneerde response}} |
<noinclude>{{DocumentPart|ns=7kezo|title=V1.0_HL7v3-uitwisseling_Ketenzorg}}</noinclude> | <noinclude>{{DocumentPart|ns=7kezo|title=V1.0_HL7v3-uitwisseling_Ketenzorg}}</noinclude> | ||
===Geretourneerde response=== | ===Geretourneerde response=== | ||
| Regel 5: | Regel 5: | ||
De response interacties vanuit de bronsystemen worden vervolgens door het LSP verzameld en gebundeld in een zogenaamde batchwrapper. Dit is hetzelfde mechanisme dat momenteel door het LSP wordt gehanteerd, alleen is het uitgangspunt nu dat de payloads van responses bestaan uit clinical statements die compatible zijn met CDA R2 (tenzij er al een install base bestaat voor een niet CDA-compatible AORTA-standaard). | De response interacties vanuit de bronsystemen worden vervolgens door het LSP verzameld en gebundeld in een zogenaamde batchwrapper. Dit is hetzelfde mechanisme dat momenteel door het LSP wordt gehanteerd, alleen is het uitgangspunt nu dat de payloads van responses bestaan uit clinical statements die compatible zijn met CDA R2 (tenzij er al een install base bestaat voor een niet CDA-compatible AORTA-standaard). | ||
| − | [[Image:Kezogeretourneerderesponse]] | + | [[Image:Kezogeretourneerderesponse.jpg|600px]] |
{{NoteBox|Er is serieus overwogen om ook het pull mechanisme te implementeren op basis van de uitwisseling van CDA documenten. Dit stuitte op weerstand van de leveranciers, omdat CDA zorgt voor extra overhead zonder duidelijke meerwaarde. Dit komt omdat het niet wenselijk wordt geacht dat het LSP gegevens uit de bronsystemen samenvoegt in één CDA document, omdat daarmee de bewerkersrol te groot zou worden. Dat betekent dat het vragend systeem een set CDA documenten zou ontvangen (één per bronsysteem), die in feite geen andere rol hebben dan een extra envelop rond de gegevens. | {{NoteBox|Er is serieus overwogen om ook het pull mechanisme te implementeren op basis van de uitwisseling van CDA documenten. Dit stuitte op weerstand van de leveranciers, omdat CDA zorgt voor extra overhead zonder duidelijke meerwaarde. Dit komt omdat het niet wenselijk wordt geacht dat het LSP gegevens uit de bronsystemen samenvoegt in één CDA document, omdat daarmee de bewerkersrol te groot zou worden. Dat betekent dat het vragend systeem een set CDA documenten zou ontvangen (één per bronsysteem), die in feite geen andere rol hebben dan een extra envelop rond de gegevens. | ||
| Regel 11: | Regel 11: | ||
Daarbij komt dat een gegevensset die ad hoc uit een database is onttrokken en waar hoogstens geautomatiseerd een tekstuele omschrijving bij gemaakt kan worden, niet echt meer aansluit bij het concept van een document als een samenhangende, eventueel ondertekende, persistente set gegevens. | Daarbij komt dat een gegevensset die ad hoc uit een database is onttrokken en waar hoogstens geautomatiseerd een tekstuele omschrijving bij gemaakt kan worden, niet echt meer aansluit bij het concept van een document als een samenhangende, eventueel ondertekende, persistente set gegevens. | ||
| − | Een praktisch argument is dat binnen AORTA al diverse | + | Een praktisch argument is dat binnen AORTA al diverse bouwsteenspecifieke queries bestaan (o.a. EMD, ICA en Lab), die kunnen worden hergebruikt als het pull mechanisme ook in de nieuwe opzet op basis van berichten wordt gerealiseerd (naast het hergebruik van de bouwsteenimplementatie zelf). |
}} | }} | ||
Huidige versie van 20 jul 2020 om 01:37
Dit materiaal is onderdeel van HL7v3-domein Ketenzorg V1.0_HL7v3-uitwisseling_Ketenzorg.
|
Geretourneerde response
De response interacties vanuit de bronsystemen worden vervolgens door het LSP verzameld en gebundeld in een zogenaamde batchwrapper. Dit is hetzelfde mechanisme dat momenteel door het LSP wordt gehanteerd, alleen is het uitgangspunt nu dat de payloads van responses bestaan uit clinical statements die compatible zijn met CDA R2 (tenzij er al een install base bestaat voor een niet CDA-compatible AORTA-standaard).
|
|
Er is serieus overwogen om ook het pull mechanisme te implementeren op basis van de uitwisseling van CDA documenten. Dit stuitte op weerstand van de leveranciers, omdat CDA zorgt voor extra overhead zonder duidelijke meerwaarde. Dit komt omdat het niet wenselijk wordt geacht dat het LSP gegevens uit de bronsystemen samenvoegt in één CDA document, omdat daarmee de bewerkersrol te groot zou worden. Dat betekent dat het vragend systeem een set CDA documenten zou ontvangen (één per bronsysteem), die in feite geen andere rol hebben dan een extra envelop rond de gegevens. Daarbij komt dat een gegevensset die ad hoc uit een database is onttrokken en waar hoogstens geautomatiseerd een tekstuele omschrijving bij gemaakt kan worden, niet echt meer aansluit bij het concept van een document als een samenhangende, eventueel ondertekende, persistente set gegevens. Een praktisch argument is dat binnen AORTA al diverse bouwsteenspecifieke queries bestaan (o.a. EMD, ICA en Lab), die kunnen worden hergebruikt als het pull mechanisme ook in de nieuwe opzet op basis van berichten wordt gerealiseerd (naast het hergebruik van de bouwsteenimplementatie zelf). |
