DOCSEARCHbyAlgolia
Submit Docs

KMEHR-tests Documentation

website·Indexed 29 days ago

https://smals-jy.github.io/KMEHR-tests

A collection of test scenarios and documentation for validating software compatibility with KMEHR (Medication Scheme) and PCDH standards. It includes test cases for medication product formats, posologies, drug administration units, and temporality, as well as guidance on using tools like EVS (External Validation Service) and GfddppGui.

Tokens
13.1K
Snippets
49
Records
70
Agent score
75%

What's inside KMEHR-tests

  1. Overview of KMEHR-tests project goals and capabilities

    The KMEHR-tests project is a standalone testing framework designed to handle the complexity of the KMEHR format used in Belgian eHealth services (specifically within the VIDIS project for RIZIV). The framework provides tools to ensure frontend applications reliably handle KMEHR data and prevent regressions. Key capabilities include:

    • Generating MS KMEHR XML files from JSON or TypeScript configuration files.
    • Validating KMEHR outputs against official specifications.
    • Validating MS files using Vitalink's Schematron rules.
    • Generating PCDH (FarmaFlux) XML files for FarmaFlux integrations.

  5. Verify KMEHR posology format handling

    The KMEHR standard supports two primary ways of defining posology within a medication item: free-text posology and codified regimens. Software must be able to parse and display these formats according to the MS Cookbook specifications.
    <transaction>
    <item>
        <id S="ID-KMEHR" SV="1.0">2</id>
        <cd S="CD-ITEM" SV="1.11">medication</cd>
        <!-- Free-text posology -->
        <posology>
            <!-- Content here -->
        </posology>
        <!-- Codified posology -->
        <regimen>
            <!-- Content here -->
        </regimen>
    </item>
</transaction>

  6. Implement medication suspensions in KMEHR XML

    To represent a medication suspension in KMEHR, use a transaction with the code treatmentsuspension. The suspension is linked to a specific medication transaction via a link (lnk) with TYPE="isplannedfor".

    Key requirements for suspension transactions:

    • Reason: Include an item with code transactionreason to specify why the medication is suspended.
    • Timing: Use <beginmoment> for the start of the suspension. For temporary suspensions, an <endmoment> must be specified to indicate the restart date.
    • Lifecycle Status: Use the <lifecycle> element with CD-LIFECYCLE to distinguish the type of suspension:
      • suspended: Indicates a temporary suspension.
      • stopped: Indicates a definitive suspension.
    <!-- Suspension Transaction -->
<transaction>
    ...
    <cd S="CD-TRANSACTION" SV="1.4">treatmentsuspension</cd>
    ...
    <!-- The reason -->
    <item>
        ...
        <cd S="CD-ITEM" SV="1.14">transactionreason</cd>
        <content>
          <text L="nl">Temporary suspension</text>
        </content>
    </item>
    <!-- The medication under suspension -->
    <item>
        ...
        <cd S="CD-ITEM" SV="1.4">medication</cd>
        ...
        <!-- When this suspension start -->
        <beginmoment>
            <date>2022-07-02</date>
        </beginmoment>
        <!-- Only for temporary suspension, a restart date must be specified -->
        <endmoment>
            <date>2022-07-03</date>
        </endmoment>
        <!-- Kind of suspension: "suspended" for temporary, "stopped" for definitive -->
        <lifecycle>
            <cd SV="1.3" S="CD-LIFECYCLE">suspended</cd>
        </lifecycle>
        ...
        <!-- Reference to the medication transaction ID (e.g., ID 13) -->
        <lnk TYPE="isplannedfor" URL="//transaction[id[@S='ID-KMEHR']='13']"/>
    </item>
</transaction>

  7. Verify PCDH posology format handling (TS-04)

    Test case TS-04 validates that software correctly processes and displays medication posology within the <model:administrationInstructions> block of a PCDH dispensation. The test covers four specific scenarios: free-text posology, missing administration instructions, single-line codified regimens, and multi-line codified regimens. Codified regimens must be translated into the user's language as specified by the codification.
    <model:dispensation>
    ...
    <model:administrationInstructions>
        <!-- Free text posology -->
        <model:posology>
            <!-- The focus on the test -->
        </model:posology>
        <!-- Codified posology -->
        <model:regimen>
            <!-- The focus on the test -->
        </model:regimen>
    </model:administrationInstructions>
    ...
</model:dispensation>

  8. Set up the KMEHR testing environment

    To prepare for updated Medication Scheme specifications, set up the testing project by cloning the repository and installing dependencies using Node.js LTS.
    git clone https://github.com/smals-jy/KMEHR-tests
cd KMEHR-tests
npm install

  9. Test PCDH medication data edge cases (TS-05)

    Test case TS-05 verifies that software can correctly process edge cases and corner cases within PCDH medication data, specifically focusing on smc:PharmaceuticalCareEventType events. The test ensures that the patient's delivered medication history is handled correctly under the following conditions:

    1. Negative Delivery Amounts: Returned medications with negative delivery amounts must be processed correctly (e.g., 'Iso-Betadine Dermicum 10 % cut. opl. 50 x 10 ml UD').
    2. Long Drug Names: Extremely long medication names must be displayed correctly without truncation or errors (e.g., 'Efavirenz/Emtricitabine/Tenofovir Disoproxil Mylan 600 mg - 200 mg - 245 mg filmomh. tabl. 90 (3 x 30)').
    <smc:events>
    ...
    <smc:event xsi:type="smc:PharmaceuticalCareEventType">
        <!-- Focus of the test: edge cases in medication data -->
    </smc:event>
    ...
</smc:events>

  10. Validate CD-TEMPORALITY values in medication schemes (TS-14)

    Verify that the software correctly handles the authorized values for the CD-TEMPORALITY code system as defined by the MS Cookbook. Only a specific subset of values is authorized; any other values (such as 'ifnecessary') should be rejected by the vaults.

    Authorized values include:

    • acute
    • chronic
    • oneshot

    Expected results: For each authorized value, the medication must be present in the patient medication scheme, and the human-readable translation of the temporality must align with the CD-TEMPORALITY standard table.

    <transaction>
    ...
    <item>
        <id S="ID-KMEHR" SV="1.0">2</id>
        <cd S="CD-ITEM" SV="1.11">medication</cd>
        ...
        <temporality>
            <!-- The focus on the test -->
            <cd "CD-TEMPORALITY" SV="1.0">oneshot</cd>
        </temporality>
    </item>
    ...
</transaction>

  11. Validate software handling of invalid medication scenarios (TS-11)

    The TS-11 test suite verifies if software can handle scenarios that should have failed validation. The expected behavior for software processing these unexpected scenarios is as follows:

    1. Stability: The software must not crash when encountering these scenarios.
    2. Best Effort: The software should employ a 'best effort' strategy, displaying as much information as possible.
    3. User Notification: The software may provide warnings to professional users to allow for the correction of medication lines (e.g., fixing an Invalid CNK).

    Common invalid scenarios tested include:

    • Frequency/Date Mismatches: Using weekdays when frequency is a multiple of days (EVSREF 100), or using dates when frequency is a multiple of weeks (EVSREF 102).
    • Out-of-Range Values: Daynumber exceeding frequency (EVSREF 101), or quantity values exceeding 4 digits (EVSREF 114).
    • Missing/Invalid Data: Missing temporality (EVSREF 111), invalid CNK/INNCLUSTER codes (EVSREF 126), or quantity values $\le 0$ (EVSREF 120).
    • Constraint Violations: Instruction for patient exceeding 340 characters (EVSREF 112), or using both endmoment and duration together (EVSREF 117).

  12. Validate software handling of RIZIV real-life medication scenarios

    The RIZIV_01 test suite is used to verify if the software under test can correctly handle common real-life medication situations provided by RIZIV. The test cases include various administration routes (oral, inhalation, subcutaneous), specific timings (e.g., 8:00 a.m., 6:00 p.m., 10:00 p.m.), and dietary constraints (empty stomach, with breakfast, before dinner).

    Test Case Scenarios

    • PANTOPRAZOL EG (EUROGENERICS) 40 mg tablet: 1 tablet per day, 8:00 a.m., orally, on an empty stomach.
    • KREDEX 25 mg tablet: 1 tablet at 8:00 a.m. (with breakfast) and 1 tablet at 6:00 p.m. (with dinner), orally.
    • TRIXEO dosed aerosol dispenser: 2 puffs at 8:00 a.m. (before breakfast) and 2 puffs at 6:00 p.m. (before dinner), by inhalation.
    • JARDIANCE 10 mg tablet: 1 tablet per day, 8:00 a.m., orally, with breakfast.
    • TRESIBA pre-filled FlexTouch pen: 12 units per day, 10:00 p.m. (before bedtime), subcutaneously.