Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: CR-207
Table of Contents

...

  1. Invoke Get patient by ID

  2. Validate person_id - mpi_id exists

    • in case invalid return 422 (422 Person not found)

  3. Save temporary variables from: $.data.authentication_methods

  4. Validate Response $.data.is_active==TRUE 

    1. if not found - return 422 error (message: "Only for active MPI record can be created medication request!")

  5. Validate person's verification status:

    1. If MRR has based_on with valid activity, then skip this validation.

    2. Else check patient's verification_status is not equal to NOT_VERIFIED.

      1. in case of error return 409, "Patient is not verified"

Validate dates

  1. created_at - similar to assertion date in FHIR -> Actual date medication request being created

  2. inserted_at - date when Medication request was registered in E-Health

  3. dispence_valid_from - Used for dispense validation. As for now equals Created at.

  4. dispense_valid_to - Dispense valid from + medication_dispense_period parameter value. Implements dispense expiration period.

...

  1. Validate that created_at, started_at, ended_at in date format

    1. in case invalid return 422 with msg ("expected \"%{actual}\" to be a valid ISO 8601 date")

  2. Validate ended_at >= started_at

    1. if invalid - return 422 error  (message: "Ended date must be >= Started date!")

  3. Validate started_at` >= created_at

    1. if invalid - return 422 error  (message: "Started date must be >= Created date!")

  4. Validate started_at >= current_date()

    1. if invalid - return 422 error  (message: "Started date must be >= current date!")

  5. Validate created_at >= current_date() - mrr_delay_input

    1. if invalid - return 422 error  (message: "Create date must be = current date!")

  6. Validate started_at regarding frequency of receiving drugs

    1. get $.medical_programs.medical_program_setting by medical_program_id from request

      1. validate skip_mnn_in_treatment_period variable

        1. in case skip_mnn_in_treatment_period == FALSE (or absent)

          1. validate request according to logic: PreQualify Medication request#2.Checkabsencethesamemedicationsfortheprograms

        2. in case skip_mnn_in_treatment_period == TRUE

          1. skip validating frequency of receiving drugs

  7. Validate created_at regarding frequency of receiving drugs

    1. get $.medical_programs.medical_program_setting by medical_program_id from request

      1. validate skip_mnn_in_treatment_period variable

        1. in case skip_mnn_in_treatment_period == FALSE (or absent)

          1. validate request according to logic: PreQualify Medication request#2.Checkabsencethesamemedicationsfortheprograms

        2. in case skip_mnn_in_treatment_period == TRUE

          1. skip validating frequency of receiving drugs

  8. Validate period length (ended_at - started_at):

    1. If medical program has been submitted:

      1. validate request according to logic: PreQualify Medication request: 7. Validate period

    2. else:

      1. Check that medication request period less than or equal to MEDICATION_REQUEST_MAX_PERIOD_DAY parameter from charts

        1. in case of error - return 409 “Period length exceeds default maximum value“

...

  1. Invoke Get INNM Dosage by ID

  2. Validate medication_id - medication_id exists

    1. in case of error return 422 ("Medication not found")

  3. Validate Response code == 200

    1. if invalid - return 422 error (message: "Only medication with type `INNM_DOSAGE` can be use for created medication request!")\

  4. Validate Response $.is_active==TRUE

    1. if not found - return 422 error (message: "Only active innm_dosage can be use for created medication request!")

Validate context

  1. Validate "context" is present in the request

    1. in case of error return 422 ("required property context was not present")

  2. Validate "context" is an active (not entered-in-error) entity from corresponding dictionary, that belongs to the current patient

    1. Validate there is an entity in collection $.data.context.identifier.type.coding[0].code with id == $.data.context.identifier.value that belongs to the current patient

      1.  in case of error 409 "{$.data.context.identifier.type.coding[*].code} not found"

    2. Validate that entity is not in status "entered-in-error"

      1. in case of error 409 "Entity in status "entered-in-error" can not be referenced"

...

  1. Verify Care plan:

    1. It should belong to the same person as set in MRR

      1. in case of error return 422 with msg ("Care plan not found")

    2. It should be in active status

    3. Care plan's period end (if exist) should be greater than current date or equal.

  2. Verify submitted Activity:

    1. It belongs to the Care plan.

      1. in case of error return 422 with msg ("Activity not found")

    2. It has activity.detail.kind=medication_request;

      1. in case of error return 422 with msg ("Invalid activity kind")

    3. activity.detail.product_reference=medication_id.

      1. in case of error return 422 with msg ("Invalid activity product reference")

    4. It has scheduled, in_progress status

    5. If it has quantity then calculate remaining quantity:

      1. select all MRR in status NEW which based on current activity

      2. select all MR in statuses ACTIVE, COMPLETED based on current activity

      3. calculate reserved at the moment medication quantity as sum of medication_qty in the filtered MRR  and MR list, including medication_qty from current MRR

      4. calculate remaining quantity by subtracting reserved quantity from activity quantity

      5. Check remaining quantity is greater then or equal to zero 

        1. in case of error return 409 "The total amount of the prescribed medication quantity exceeds quantity in care plan activity"

    6. check that medical_program_id equal to $.activity[].program

      1. in case of error return 422 with msg ("Medical program from activity should be equal to medical program from request")

  3. Verify activity period: 

    1. If it has scheduled_timing:

      1. if bounds_period.end defined then check it greater than current date or equal.

    2. If it has scheduled_period:

      1. if scheduled_period.end defined then check it greater than current date or equal.

  4. Validate started_at/ended_at of Medication request Request: 

    1. if care plan activity has detail.scheduled_timing.repeat.bounds_period - validate started_at/ended_at within bounds_period

    2. if care plan activity has detail.scheduled_period - validate started_at/ended_at within scheduled_period

    3. else - validate started_at/ended_at within care_plan.period

      1. in the case of started_at/ended_at is not within care_plan.period return 422 with msg  ("Invalid care plan period")

Validate medical program

  1. Validate medical_program_id is present in the request

    1. in case of error return 422 ("required property medical_program_id was not present")

  2. Validate medical_program_id - medical_program_id exists

    1. in case of error return 422 ("Medical program not found")

  3. Validate context with encounter is present in the request

    1. in case of error return 422 ("Context with encounter is required as medical program is present in the request")

    2. encounter diagnosis is not empty in $.encounter.diagnosis

      1. in case of error return 422 ("Encounter without diagnosis can not be referenced")

  4. Validate medical_programs.medical_program_setting parameters

    1. check if care_plan_required == true then the request should contain a based_on with care plan and activity that contains the same medical program

      1. in case of error return 422 with msg ("Care plan and activity with the same medical program should be present in request")

    2. If there is CONDITIONS_ICD10_AM_ALLOWED parameter, then:

      1. Check if primary diagnosis from the encounter in context has code from eHealth/ICD10_AM/condition_codes dictionary

        1. Check diagnosis code in CONDITIONS_ICD10_AM_ALLOWED

          1. in case of error - return 422 “Encounter in context has no primary diagnosis allowed for the medical program“

    3. If there is CONDITIONS_ICPC2_ALLOWED parameter, then:

      1. Check if primary diagnosis from the encounter in context has code from eHealth/ICPC2/condition_codes dictionary

        1. Check diagnosis code in CONDITIONS_ICPC2_ALLOWED

          1. in case of error - return 422 “Encounter in context has no primary diagnosis allowed for the medical program“

...

  • Generate human readable number for receipt (See specs)

    Code Block
    Structure number XXXX-1234-5678-9012-345-C , where:
    - XXXX - series: numbers + only some letters (A, E, H, K, M, P, T, X)
    - 1234-5678-9012-345 - randomly generated numbers
    - C - checksum: Should be calculated using the Damn algorithm or Verhoeff algorithm
    After new Request number was generated we should check that it is unique in the DB (entity: medication_request + medication_request_request
    
    • Generate verification_code for MPI.person_authentication_methods == OTP or OFFLINE

      Code Block
      Structure code 1234, where:
      - 1234 - randomly generated numbers 
      

...