• Created by Unknown User (jeroen.brackez@imec.be), last modified by Unknown User (gaelle.laurent.ext@imec.be) on Sept 22, 2020

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Current »


General

The Vitalink Gateway will validate the incoming Kmehrmessage.

The end users software application should prevent a failing validation as much as possible, by composing the Kmehrmessage correctly.

If however for some reason a validation fails at runtime, the application should try to present its user with a proper error message. This way, the end user can perhaps solve the problem or at least pass this information to the helpdesk of the vendor.

The validation will occur in two steps:

  • Kmehr XSD validation
  • Additional business validation

Kmehr XSD validation

The medication scheme Kmehrmessage must satisfy version “20161201-kmehr” of the XSD definition, see External Links#kmehrmessage-xschema.

To be revised

Along with the XSD scheme validation the kmehr message will also be subjected to a general structure validation. This structure validation will on the one hand produce errors and on the other hand warnings. In the event that errors occur during the validation, the action will be suspended and the error reported. In the event that there are only warnings, the request will be dealt with. The final response will however be enhanced with the warnings, to construct a correct request.

Additional business validation

The Vitalink business project uses an extended Kmehrmessage, by defining its own transactions. The Vitalink Gateway requires extra requirements, on top of the standard Kmehr validation. This results in the next extra business validation rules:

Description

‘cd’ in ‘standard’ must be ‘20161201’

‘id’ in ‘header’ must be entered

‘cd’ in ‘hcparty’ (sender, recipient and author) must be entered

‘name’ in ‘recipient’ must be ‘Vitalink’

‘cd’ in ‘recipient’ must be ‘application’

Contains exactly 1 ‘folder’

‘firstname’, ‘familyname’ and ‘id’ in ‘patient’ must be entered

When using a ‘date’, this ‘date must have a full date format (day, month and year)

Example: ‘beginmoment’ or ‘endmoment’

Each transaction contains exact 1 ‘URI’:’id’ with S=”LOCAL” and SL=”vitalinkuri”

For each transaction, being an addition or an update, the author must match with the one from the SAML token

Contains exactly 1 ‘medicationscheme’ transaction for which:

Contains exact 1 ‘version’

Contains transaction(s) ‘medicationschemeelement’ for which:

Contains exactly 1 healthcare element for which ‘CD-ITEM-MS’ = ‘adaptationflag’

Contains exactly 1 item ‘medication’ for which:

Contains exactly 1 ‘beginmoment’

‘beginmoment’ cannot contain a ‘time’, this should be specified in the ‘regimen’

Contains exactly 1 of: ‘medicinalproduct’, ‘substanceproduct’, ‘compoundprescription’ or ‘CD-EAN’ list

If ‘compoundprescription’ or ‘CD-EAN’ list is included: contains exactly 1 associated ‘text’ field

If ‘medicinalproduct’ or ‘substanceproduct’ is included: ‘intendedcd’ and ‘intendedname’ must be entered

If ‘CD-EAN’ is included: ‘cd’ and ‘text’ field must be entered

If ‘compoundprescription’ is included: ‘compoundprescription’ and ‘text’ field must be entered

If ‘temporality’ is included: ‘CD-TEMPORALITY’ allows only following values: “acute”, “chronic” and “oneshot”.

If ‘frequency’ is included:

‘frequency’ makes use of ‘periodicity’

For ‘periodicity’ the values ‘Per 5h (UQ)’, ‘Per 7h (US)’, ‘Per 9h (UN)’, ‘Per 10h (UX)’ and ‘Per 11h (UE)’ are not permitted

If the values ‘Per hour (U)’, ‘Per 8h (UA)’ , ‘Per 3h (UD)’ , ‘Per half hour (UH)’ , ‘Per 2h (UT)’ , ‘Per 4h (UV)’ , ‘Per 12h (UW)’ or ‘Per 6h (UZ)’ are used, then the use of ‘regimen’ is not allowed.

Contains exactly 1 ‘posology’ or ‘regimen’ (they do not occur together)

If ‘posology’ is included: ‘posology’ makes use of a completed ‘text’ field

If ‘text’ filled: no control on unit in ‘text” field

If ‘regimen’ is included:

For ‘dayperiod’ the values ‘aftermeal’, ‘betweenmeals’, ‘afternoon:’, ‘evening’, ‘night’ are not permitted

‘dayperiod’ is only allowed once per day per ‘regimen’

If ‘quantity’ is included:

Contains exact 1 element ‘unit’

All ‘unit’ elements have the same value within the transaction

For all ‘healthcareelement’:

Contains exactly 1 ‘cd’ with list ‘CD-ITEM-MS’ (permitted values: ‘origin’, ‘adaptationflag’, ‘medicationuse’, ‘medicationtype’, ‘begincondition’ or ‘endcondition’)

If ‘adaptationflag’ is included: contains at least 1 ‘cd’ with list ‘CD-MS-ADAPTATION’

(permitted values: ‘nochanges’, ‘medications’, ‘posology’ or ‘treatmentsuspension’)

If ‘origin’ is included: contains exactly 1 ‘cd’ with list ‘CD-MS-ORIGIN’ (permitted values:

‘regularprocess’ or ‘recorded’)

If ‘medicationtype’ is included: contains exactly 1 ‘cd’ with list ‘CD-MS-MEDICATIONTYPE’

(permitted values: ‘onprescription’, ‘otc’ or ‘other’)

If ‘medicationuse’ is included: contains exactly 1 completed ‘text’ field

Included as ‘begincondition’: contains exactly 1 completed ‘text’ field

If ‘endcondition’ is included: contains exactly 1 completed ‘text’ field

The Kmehr-element ‘Instructionforoverdosing’ is not being used, therefor will not be mentioned in the medication scheme

For all ‘treatmentsuspension’ transactions:

Contains exactly 1 item ‘medication’ for which:

Contains exactly 1 of: ‘medicinalproduct’, ‘substanceproduct’, ‘compoundprescription’ or ‘CD-EAN’ list (identical to the definition in the transaction ‘medicationschemeelement’)

Contains exactly 1 ‘start moment’

Contains exactly 1 ‘lifecycle’ with list ‘CD-LIFECYCLE’ (permitted values: ‘suspended’ or ‘stopped’)

If ‘stopped’ only an end date may be inputted, no begin date

Contains exact 1 ‘lnk’ (the validation on ‘exact 1 lnk’ applies to the type ‘treatmentsuspension’. Since a folder now contains multiple medications, there must be a link with a treatmentsuspension to the correct medication for which:

Attribute URL:XPath to the concerning ‘medicationschemeelement’

 Attribute Type: isplannedfor



  • No labels