Deze CMET wordt gebruikt om waarschuwingen en fouten te identificeren die zijn gevonden
bij het trigger event dat voorafging aan een interactie, of zijn gevonden gedurende
het verwerken van het bericht. Het wordt gebruikt om de business-rules te identificeren
waarmee de subject Act strijdig is. Fouten en/of waarschuwingen met betrekking tot
routering, interne fouten, syntax (bijvoorbeeld met betrekking tot kardinaliteit)
en een beperkt aantal problemen gerelateerd aan codesystemen dienen in het Transmission
wrapper element AcknowledgementDetail te worden
teruggegeven. Per keer dat deze CMET wordt gebruikt, kan één waarschuwing/fout worden
doorgegeven, waarbij de volgorde van de klassen niet vastgelegd is; uit de volgorde
mag geen prioriteit worden afgeleid. In een initiële interactie wordt deze CMET gebruikt
door de zender, om aan te geven dat hij op de hoogte is van business-rule gerelateerde
uitkomsten bij de verwerking van de berichtinhoud door de ontvanger. Hij anticipeert
daarmee op deze uitkomsten en stelt tevens hoe de zender denkt dat de ontvanger hiermee
om zou moeten gaan. Of zulke omstandigheden kunnen worden
gebruikt door de zender en of en hoe een ontvanger hierop mag danwel moet reageren,
moet zijn gespecificeerd in een toepassing. Een voorbeeld van een gebruikscenario
waarin deze functionaliteit werd gespecificeerd is opvraging bij noodgeval. Op deze
wijze kon de zender de ontvanger vragen om toegang tot gegevens waar hij onder normale
omstandigheden niet bij zou kunnen. In een antwoordinteractie wordt deze CMET gebruikt
door de antwoordende partij om waarschuwingen en/of fouten door te geven welke zijn
opgetreden bij de verwerking van de interactie waarop wordt geantwoord. Een
voorbeeld is een actuele conditie bij een patiënt waardoor een gevraagde toediening
niet kan worden uitgevoerd. Toepassingen specificeren altijd de geldende verwerkingsregels
en op welke wijze bij problemen daarbij moet worden gereageerd. Klassificatie/catogorisatie
Bij het definiëren van meldingen bij business-rules kan gebruik worden gemaakt van
onder andere deze methoden:
De melding wordt zo specifiek mogelijk gemaakt in justifiedDetectedIssueEvent/code.
De melding wordt onder een bepaalde categorie geplaatst in justifiedDetectedIssueEvent/code. De categorie komt uit de internationale waardenset ActDetectedIssueCode. De feitelijke
melding komt gecodeerd in in justifiedDetectedIssueEvent/value. Deze methode wordt gehanteerd bij meldingen in SBV-Z-specificaties.
Merk op dat de exacte eerste elementnaam afhangt van de wijze waarop het CMET wordt
gekoppeld. Voorkomende namen zijn onder andere "justifyingDetectedIssueEvent" en "justifiedDetectedIssueEvent".
Classificatie
HL7v3 Payload level template
Open/gesloten
Open (ook andere dan gedefinieerde elementen zijn toegestaan)
<justifiedDetectedIssue> <codecode="UNSUPPORTEDQUERYPARAMETER"codeSystem="2.16.840.1.113883.2.4.6.6.1.1000"displayName="Het queryparameter RoleType is niet geldig omdat het queryattribuut Code niet wordt
ondersteund."/></justifiedDetectedIssue>
Voorbeeld
Hoofdcategorie in code en specifieke subcategorie in value
<justifiedDetectedIssue> <codecode="INSPAR"codeSystem="2.16.840.1.113883.5.4"/><valuexsi:type="CE"code="BR02"codeSystem="2.16.528.1.1007.4.2.3"displayName="De ingevoerde waarde voor het veld BSN voldoet niet aan de 11-proef."/></justifiedDetectedIssue>
Bevat de code voor de typering van de melding. De meeste situaties worden afgedekt
in de fouttabel uit de AORTA documentatie. Codes komen uit de HL7-tabel ActDetectedIssueCode
met OID “2.16.840.1.113883.5.4” of uit de AcknowledgementDetailCodeAORTA met OID “2.16.840.1.113883.2.4.6.6.1.1000”.
Merk op dat berichten ook andere meldingen kunnen bevatten uit andere codesystemen,
herkenbaar via de OID in @codeSystem.
Bevat de specifieke aard van de melding. Het datatype is niet van tevoren bepaald
waardoor deze informatie bijvoorbeeld gecodeerd kan worden (CD, CE, CV) of bijvoorbeeld
als eenvoudige string (ST), eventueel met code (SC).
(Detent)
hl7:triggerFor
0 … *
Bevat uit te voeren acties door het ontvangende systeem op basis van de onder DetectedIssueEvent
genoemde business-rule.
•(initiërende interacties) de uitleg/reden(en) waarom de onder DetectedIssueEvent genoemde
business-rule moet worden genegeerd/niet als probleem moet worden gezien door een
ontvanger, of
•(applicatieantwoorden) de mogelijke codes waarmee een initiërende applicatie de reagerende
applicatie kan instrueren de op dit moment geconstateerde business-rules te negeren.
De initiërende applicatie moet daartoe zijn verzoek opnieuw aanbieden met gebruikmaking
van deze codes.