Purpose

This WS allows to create Composition entity by employees. This service is a single way to create any composition (medical conclusions) exept composition (medical conclusions) about temporary disability and birth. The structure of composition can be variety and depends on configuration of a specific composition type and category (based on configs). The main purpose of this service is to ensure the continuation of the main structure and ensure validation and control of the configuration of a specific composition.

Key points

1. Only authenticated and authorized employee with appropriate scope can create a Composition.

2. Request should be signed with DS.

3. The composition is created asynchronously.

4. The composition can be created both for persons and for prepersons.

5. When system validate resource and for current composition type config non exist, system skip validation

6. All validations using dictionaries apply only to those dictionary values ​​where is_active=true

Specification

https://ehealthmedicaleventsapi.docs.apiary.io/#reference/medical-events/composition/create-composition

Authorization

• Verify the validity of access token

  • in case of error - return 401 (“Invalid access token”) in case of validation fails

• Verify that token is not expired

  • in case of error - return 401 (“Invalid access token”)

• Check user and client scopes in order to perform this action (scope = 'composition:write')

  • return 403 (“Your scope does not allow to access this resource. Missing allowances: composition:write”) in case of invalid scope(s)

• If BLOCK_UNVERIFIED_PARTY_USERS is true, then check party's data match following condition: verification_status != NOT_VERIFIED or (verification_status = NOT_VERIFIED and updated_at > current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):

  • in case not match - return 403 ("Access denied. Party is not verified")

• If BLOCK_DECEASED_PARTY_USERS is true, check that party is not deceased (party_verification record does not equal to: dracs_death_verification_status = VERIFIED and dracs_death_verification_reason = MANUAL_CONFIRMED):

  • in case of error - return 403 ("Access denied. Party is deceased")

Validate Digital Sign

• Validate request is signed

  • in case of error - return 400 (“Invalid signed content”)

• Check DS is valid and not expired

• Validate that DS belongs to the employee who sign the Composition ($.attester)

  • Check that DRFO from DS and party.tax_id of the registrar matches

    • in case of error - return 422 (“Does not match the signer drfo“)

Validate Patient

• Get Patient identifier from the URL

• Check it exists in the Mongo DB

  • Return 404 ('Person is not found') in case of error

Validate request

1. Validate encoded and decoded request using JSON schema.

   1. Return 422 with the list of validation errors in case validation fails

      1. in case field value does not match the schema - return 422 with field-specific message

      2. in case additional fields exist in request - return 422 (‘schema does not allow additional properties’)

      3. in case required parameter does not exist in request - return 422 (‘required property %{property} was not present’)

      4. in case required amount of parameters does not exist in request - return 422 (‘expected a minimum of %{min} items but got %{actual}’)

2. Validate composition data using different configs depends on type and category of composition. Return 422 with the list of validation errors in case validation fails.
   List of validations for composition depends on type and category. For unique combination of type and category of composition exist only one active config file, if config setting is not exist in file - system must skip validation. Structure of table in DB describe here - https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/18207473689
   Find config where composition.type = сonfigurations.type and composition.category = сonfigurations.category and execute validation from config for current composition. Configs for validations stored in prm DB (like forbidden groups). Get file from prm then use it in validation composition process.

Config parsing logic:

Workflow:

a. get config by type and category (of composition) from [prm].composition

а.1 in case there is no record in PRM.configurations with requested combination of type and category return 422 - (“Category {{Composition.category}} is not allowed for type {{Composition.type}}”)
b. get setting and compare config.condition data to composition data to find the desired setting (in case when some values isn’t exist - skip validation)
c. compare data from config.check with data from composition

Config contains all variables settings ​​that determine logic and behavior of composition. Structure of config include condition section where describe all condition and check section wich include compared data to composition.

In case when rule from condition or check is not exist, config can have two options:

• field from this section isn’t exist, example:

condition has rule for section_code:
{
            "condition": {
                "section_code": {
                    "code": "MAIN_SECTION"
                    "system": "eHealth/composition_section_codes"
                },
                "resource_type": {
                    "system": "eHealth/resources",
                    "code": "episodes"
                }
            },
            "check": {
                "min": 0,
                "max": 365
            }
        }

condition hasn't rule for section_code (IN THIS CASE NEED TO VALIDATE section_code.system, value must be from composition_section_codes dictionary) :
{
            "condition": {
                "section_code": {
                    "system": "eHealth/composition_section_codes"
                },
                "resource_type": {
                    "system": "eHealth/resources",
                    "code": "episodes"
                }
            },
            "check": {
                "min": 0,
                "max": 365
            }
        }

• value for section = “any“, example:

check has rule for min and max value:
{
            "condition": {
                "section_code": {
                    "code": "MAIN_SECTION",
                    "system": "eHealth/composition_section_codes"
                },
                "resource_type": {
                    "system": "eHealth/resources",
                    "code": "episodes"
                }
            },
            "check": {
                "min": 0,
                "max": 365
            }
        }

check hasn't rule for min and max value:
{
            "condition": {
                "section_code": {
                    "code": "MAIN_SECTION",
                    "system": "eHealth/composition_section_codes"
                },
                "resource_type": {
                    "system": "eHealth/resources",
                    "code": "episodes"
                }
            },
            "check": "any"
        }

1. Config with condition and check parameters:

   1. condition - this section include all condition which need to compare with current composition data in order to find config object with same values in condition. In case when same values from condition and composition data is not exist - skip validation.

b. check - this section include data which must be checked with composition data. In case when process find same object for config with condition data but data in check section is not the same - system return an error (all errors describe in validations)

2. Config for sections with array parameters (for example - COMPOSITION_SECTION_CONFIG) wich used for section structure validation

• Return 422 ("Invalid data type for <parameter name>") in case when parameter has different data type

When system validate parameters that relate to the difference between two dates:

• difference in the configuration parameter is given in days;

• difference is given by the minimum and/or maximum values.

When validating parameters related to the value from dictionaries - configuration parameter indicates not only the code, but also by system.

If there is no settings config for current composition type and category, such validation is skipped and not performed.

Validate Composition

Validate root attributes of composition entity:

1. Status

Composition can be created only in “FINAL” status. Validate status of Composition according to status model - https://e-health-ua.atlassian.net/wiki/spaces/emal/pages/18119950362/NEW+Composition+status+model.

1. Get status from Composition.status and check (30.1) that status of composition corresponds to appropriate dictionary - COMPOSITION_STATUS

• Return 422 ("value is not allowed in enum") in case of error

2. Get status from Composition.status and check (30.1) that status of composition = FINAL

• Return 422 ("value is not allowed in enum") in case of error

2. Type

1. Get type from Composition.type.coding.code and check (30) that type of composition corresponds to appropriate dictionary - COMPOSITION_TYPES

• Return 422 ("value is not allowed in enum") in case of error

2. Check that Composition.type.coding.code is NOT from COMPOSITION_TYPE_BLACK_LIST

   1. Return 422 ("Composition type is not allowed by configuration") in case of error

3. Category

Get category from Composition.category.coding.code and execute next validations:

1. Check (30) that value of composition.category is based on COMPOSITION_CATEGORIES dictionary.

   • Return 422 ("value is not allowed in enum") in case of error

4. Date

Date when employee signed the composition. Get sign date from Composition.date and execute next validations

1. Check (27) that composition.date <= composition.event.period.start.

   • Return 422 ("Sign date must be less or equal composition.event.period.start") in case of error

*next validations use configs

2. Check (28) the difference between sign date and event.period.start - must be in range of min days and max days (for all items in composition.event). Base on config - COMPOSITION_SIGN_TERM.
   Logic: min >= composition.date - composition.event.period.start <= max
   or
   min >= composition.date - composition.event.period.start (in case when config has only one parameter)

   • Return 422 ("Difference between start date and sign date must be from <min> to <max> days") in case of error

5. Person

Get person id from URL and execute next validations

1. Validate (8) person verification_status is not equal to NOT_VERIFIED in case when composition.subject != preperson.

   • in case NOT_VERIFIED - return error 409 ("Patient is not verified")

2. Validate (9) person status = active in case when composition.subject type != preperson.

   • Return 422 ("Patient is not active") in case of error

*next validations use configs

3. Check (7) possibility to create composition for PREperson - COMPOSITION_PREPERSON_ALLOW.

   • Return 422 ("Forbidden to create composition with such category for preperson") in case of error

4. Validate (10) person age between min and max values in config - COMPOSITION_PERSON_AGE.

Skip this validation in case the patient is preperson with an empty age parameter

Calculating logic of person age:

• days: from birthday to current date (include leap years)

• months: from birthday of month to current days, in result must be integer value of full month

• years: from birthday to current day, in result must be integer value of full years

example:

1. birthday = 12.07.1991, current day = 03.10.1991. Days - 83, month - 2, years - 0

settings value: min - value: 18, units: days and max - value: 1, units: years
calculation logic:
min value 18 days less than 83 days - OK
max value 1 year more than 0 year - OK

2. birthday = 12.07.1991, current day = 23.05.1995. Days - 1411, month - 46, years - 3

settings value: min - value: 18, units: days and max - value: 1, units: years
calculation logic:
min value 18 days less than 1411 days - OK
max value 3 years more than 1 year - ERROR

1. Return 422 ("Forbidden to create composition for person of this age") in case of error

2. Validate (11) person gender must match the config value - COMPOSITION_PERSON_GENDER

   • Return 422 ("Invalid gender of person for such composition") in case of error

6. Custodian

Get LE identifier from Composition.custodian and execute next validations:

1. Check (6) that referenced legal_entity with such id exists (is_active = true)

   • in case of error - return 422 ("LegalEntity with such ID is not found")

2. Validate (6) that entity status is "ACTIVE" or “SUSPENDED“

   • in case of error - return 422 ("Legal entity referenced as performer is in invalid status")

3. Check (21.1) legal_entity_id from token. Check that composition.custodian id belongs to the LE from token.

   • Return 422 ("Invalid legal entity of employee") in case of error

4. Check (21.2) legal_entity_id from sign. Check that composition.custodian id belongs to the LE of user who sign composition.

   • Return 422 ("Invalid legal entity from sign") in case of error

*next validations use configs

5. Validate (6.1) LE type which base on config - COMPOSITION_LEGAL_ENTITY_TYPE

   • in case of error - return 422 ("Invalid custodian legal entity type")

6. Validate (6.2) LE verification status which base on config - COMPOSITION_LEGAL_ENTITY_VERIFICATION_STATUS

   • in case of error - return 422 ("Invalid legal entity verification status")

7. Encounter

Referenced encounter must have correct status, type and creation date depends on sign composition date. Get encounter data from Composition.encounter and execute next validations:

1. Check (3) composition.encounter.patient = composition.subject

   • Return 422 ("Referenced encounter not found for this patient") in case of error

*next validations use configs

2. Check (2) that referenced encounter in composition.encounter has type based on config - COMPOSITION_ENCOUNTER_TYPE.

   • Return 422 ("Forbidden to create composition with selected encounter type") in case of error

3. Check (4) that referenced encounter in composition.encounter has status based on config - COMPOSITION_ENCOUNTER_STATUS.

   • Return 422 ("Forbidden to create composition with selected encounter status") in case of error

4. Check (5) that difference with create encounter date and sign composition date must be in range of config - COMPOSITION_ENCOUNTER_SIGN_TERM:
   min >= composition.encounter.period.start - composition.date <= max
   or
   min >= composition.encounter.period.start - composition.date (in case when config has only one parameter)

   • Return 422 ("Difference between create encounter date and sign composition date must be in range of <min value> and <max value> days") in case of error

8. Author

Check author type, position, speciality and verify status. Get employee data from Composition.auhtor and execute next validations:

*next validations use configs

1. Check (12) that author verification status based on config - COMPOSITION_AUTHOR_VERIFICATION_STATUS.

   • Return 422 ("Employee with such verification status can’t create composition") in case of error

2. Check (13) that author type based on config - COMPOSITION_AUTHOR_TYPE.

   • Return 422 ("Forbidden to create composition with selected author type") in case of error

3. Check (14) that author position based on config - COMPOSITION_AUTHOR_POSITION.

   • Return 422 ("Forbidden to create composition with selected author position") in case of error

4. Check (15) that author speciality based on config - COMPOSITION_AUTHOR_SPECIALITY.

   • Return 422 ("Forbidden to create composition with selected author speciality") in case of error

5. Check (16) that author main speciality (employee.accreditation.speciality_officio = true ) based on config - COMPOSITION_AUTHOR_MAIN_SPECIALITY.

   • Return 422 ("Forbidden to create composition with selected author main speciality") in case of error

6. Check (16.1) that author has combination of allowed specialisation and position from config - COMPOSITION_AUTHOR_SPECIALITY_POSITION

   • Return 422 ("Forbidden to create composition with selected author speciality and position") in case of error

9. Extension

Check extension from Composition.extension in case when composition event code allow to include extension.

Extension parameters description:

CodeableConceptExtension

Extension

*next validations use configs

1. If composition.extension is not empty and there is an extension with extension.сode = "COMPOSITION_ADDITIONAL_CONDITION_ADMISSION" validate composition type = “DRIVERS“

   1. Return 422 (COMPOSITION_ADDITIONAL_CONDITION_ADMISSION extension is not allowed for {{composition_type}} composition type) in case of error

2. When (36) composition type = “DRIVERS“ and composition.extension is not empty, check that at least one of composition.event.code corresponds to appropriate config - COMPOSITION_EVENT_ADMIT_CODES

3. Return 422 ("Allow composition status must be Admit when extension is not empty") in case of error

4. If composition.extension is not empty, check that extension.сode of extension corresponds to appropriate config - COMPOSITION_EXTENSION_ALLOW

   • Return 422 ("Prohibited extension code") in case of error

*new validations

3. If (42.4) composition.extension is not empty
   AND
   extension.сode = “COMPOSITION_ADDITIONAL_CONDITION_ADMISSION“

   1. check that value in extension.valueCodeableConcept.coding.code is from COMPOSITION_ADDITIONAL_CONDITION_ADMISSION dictionary

      1. Return 422 ('value is not allowed in enum') in case of error

4. If (42.5) composition.extension is not empty
   AND
   extension.сode = "COMPOSITION_ADDITIONAL_CONDITION_ADMISSION"
   AND
   extension.valueCodeableConcept.extension.valueCodeableConcept.coding.code is not empty

   1. check that value is from the COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_LETTER_DESIGNATIONS dictionary

      1. Return 422 ('value is not allowed in enum') in case of error

5. If (42.6) composition.extension is not empty
   AND extension.сode = "COMPOSITION_ADDITIONAL_CONDITION_ADMISSION"
   AND extension.valueCodeableConcept.extension is not empty
   AND extension.valueCodeableConcept.extension.code = COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_LETTER_DESIGNATIONS
   check that:

   1. extension.valueCodeableConcept.extension.valueCodeableConcept.coding.code value is in configuration.check array, where configuration.condition.code is equal to extension.valueCodeableConcept.coding.code, configuration - ADDITIONAL_CONDITION_RELATED_LETTER_DESIGNATIONS

      1. Return 422 ('Invalid letter designation for the additional admission condition code') in case of error

6. If composition.extension is not empty
   AND extension.сode = "COMPOSITION_ADDITIONAL_CONDITION_ADMISSION"
   AND extension.value_codeable_concept.extension is not empty
   AND extension.value_codeable_concept.extension.code = “COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_VALUE"
   check that:

   1. parameter extension.value_codeable_concept.extension.value_decimal is present

      1. Return 422 ("value_decimal must be present for COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_VALUE extension") in case of error

   2. extension.value_codeable_concept.coding.code is in config.condition array of COMPOSITION_ADDITIONAL_CONDITION_VALUES
      AND config.check = false

      1. Return 422 ('COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_VALUE extension is not allowed for additional admission condition with code {{extension.value_codeable_concept.coding.code}}') in case of error

   3. there is only one extension in extension.value_codeable_concept.extension array with code =“COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_VALUE"

      1. Return 422 ("Only one COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_VALUE extension is allowed for each additional admission condition") in case of error

7. If (42.7) composition.extension is not empty
   AND extension.сode = "COMPOSITION_ADDITIONAL_CONDITION_ADMISSION"
   check config COMPOSITION_ADDITIONAL_CONDITION_VALUES:

   1. If extension.valueCodeableConcept.coding.code is in config.condition array
      AND config.check = true
      THEN

      1. Check that extension.value_codeable_concept.extension is present and extension.value_codeable_concept.extension.code = “COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_VALUE"

         1. Return 422 ('Missing required extension COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_VALUE for additional admission condition with code {{extension.value_codeable_concept.coding.code}}') in case of error

      2. parameter extension.value_codeable_concept.extension.value_decimal is present for this additional admission condition

         1. Return 422 ("value_decimal must be present for COMPOSITION_ADDITIONAL_CONDITION_ADMISSION_VALUE extension") in case of error

10. Relates to

New composition can replace previously created composition in case when employee add some new information or change patient data. In this case employee fill parameter “relates_to” - reference on previously composition. Get previously created composition identifier from Composition.relates_to and execute next validations:

1. Check (31) that previously created composition (parameter RelatedArtifact.type = 'replaces') from parameter composition.relates_to in status "entered_in_error"

   • Return 422 ("Previously created composition must be in status 'entered_in_error'") in case of error

2. Check (32) that previously created composition (parameter RelatedArtifact.type = 'replaces') from parameter composition.relates_to not used for another composition in FINAL status as composition.relates_to parameter

   • Return 422 ("Related composition used for another composition") in case of error

3. Check (34) type, category and subject of previously created composition(parameter RelatedArtifact.type = 'replaces') from parameter composition.relates_to and current composition - must be the same:
   composition.type = relates_to.composition.type
   and
   composition.category = relates_to.composition.category
   and
   composition.subject = relates_to.composition.subject

   • Return 422 ("Type, category and subject of composition and related composition must be the same") in case of error

4. Check (35) document type of related resource, must be ‘composition’

   • Return 422 ("Related document type must be 'Composition'") in case of error

*next validations use configs

5. Check (33) that differenсe from sign date in previously created composition(parameter RelatedArtifact.type = 'replaces') from parameter composition.relates_to and sign date of current composition between min and max. Base on config - COMPOSITION_CATEGORY_SIGN_DATE_REPLACE:
   min >= [old]composition.date (replaces) - [new]composition.date <= max
   or
   min >= [old]composition.date (replaces) - [new]composition.date (in case when config has only one parameter)

   • Return 422 ("Difference between sign date old and new composition must be from <min> to <max>") in case of error

11. Attester

Check employee data who sign composition. Get employee data from Composition.attester and execute next validations:

1. Check composition.Attester.mode.coding.system = "eHealth/composition_attester_modes"
   & composition.attester.mode.coding.code is a value from dictionary eHealth/composition_attester_modes

2. Check (18) that attester of composition work in same LE as custodian parameter: сomposition.attester legal_entity_id = composition.custodian

   • Return 422 ("Attester of composition must work in same LE as custodian") in case of error

3. Check (19) that attester employee is in active status

   • Return 422 ('Attester is not active') in case of error

4. Check (19.1) that composition.attester array has only one item

   • Return 422 ("Only one attester for composition must be submitted") in case of error

5. Extract (21) user_id from token. Check that attester belongs to the employee user who sign composition.

   • Return 422 ('Attester id doesn’t belongs to employee id from token') in case of error

*next validations use configs

5. Check (20) that attester verification status based on config - COMPOSITION_ATTESTER_VERIFICATION_STATUS.

   • Return 422 ("Employee with such verification status can’t sign composition") in case of error

6. Check (17) that author of composition work in same LE with attester: сomposition.author.legal_entity_id = composition.attester.legal_entity_id. Need validate when "sign_check" value = true - COMPOSITION_ATTESTER_SIGN_CHECK.

   • Return 422 ("Author and Attester of composition must work in same LE as custodian") in case of error

7. Check (22) that attester type based on config - COMPOSITION_ATTESTER_TYPE.

   • Return 422 ("Forbidden to create composition with this attester type") in case of error

8. Check (23) that attester position based on config - COMPOSITION_ATTESTER_POSITION.

   • Return 422 ("Forbidden to create composition with this attester position") in case of error

9. Check (24) that attester speciality is in allowed values from config - COMPOSITION_ATTESTER_SPECIALITY.

   • Return 422 ("Forbidden to create composition with this attester speciality") in case of error

10. Check (24.1) that attester has combination of allowed specialisation and position from config - COMPOSITION_ATTESTER_SPECIALITY_POSITION

    • Return 422 ("Forbidden to create composition with selected referenced attester speciality and position") in case of error

11. Check (26) that attester main speciality (employee.accreditation.speciality_officio = true ) is in allowed values from config - COMPOSITION_ATTESTER_MAIN_SPECIALITY

    • Return 422 ("Forbidden to create composition with this attester main speciality") in case of error

12. Event

Check all clinical service(s) being documented. Get events information from Composition.event and execute next validations:

1. When (39) composition type = “DRIVERS“ and composition.event.code = "DRIVERS_GROUP1_ADMIT" or "DRIVERS_GROUP2_ADMIT" - composition.event.period.start and composition.event.period.end is required

   • Return 422 ("Event period start and period end is required") in case of error

2. When (40) composition type = “DRIVERS“ and composition.event.code = "DRIVERS_GROUP1_DENY" or "DRIVERS_GROUP2_DENY" - composition.event.period.start is required and composition.event.period.end must be empty

   • Return 422 ("Event period start is required and event period end must be empty") in case of error

3. When (40.1) composition type = “ADOPTION“ and composition.event.code = "ADOPTION_ADOPTER_INELIGIBLE" or "ADOPTION_ADOPTER_RELATIVE_INELIGIBLE" - composition.event.period.start is required and composition.event.period.end must be empty

   Return 422 ("Event period start is required and event period end must be empty") in case of error

4. Check (38.1) all event.code must be unique. In case when composition has more than one event

   • Return 422 ("Event codes must be unique") in case of error

5. Check (37.1) that composition.event.code corresponds to appropriate dictionary - COMPOSITION_EVENTS

   • Return 422 ('value is not allowed in enum") in case of error

*next validations use configs

3. When (25) composition type = “DRIVERS“ check that event.period (event.period.end - event.period.start) less than duration (depending on person age and composition event.code). Base on config - COMPOSITION_EVENT_PERIOD_DURATION
   Calculating logic:
   composition.event.period.end - composition.event.period.start < config.check value

   • Return 422 ("Composition event period duration must be less than <check.value> <check.units>") in case of error

4. Check (38) all composition.event.code in composition - it must corresponds to appropriate config and match with at least one combination of statuses - COMPOSITION_EVENT_CODE
   examples:
   if composition category = “DRIVERS_GROUP1“ check what composition.event.code must be:
   "DRIVERS_GROUP1_ADMIT"
   OR
   "DRIVERS_GROUP1_DENY" and “DRIVERS_GROUP2_DENY“

   if composition category = “DRIVERS_GROUP2“ check that composition.event.code match with one of combination:
   “DRIVERS_GROUP1_ADMIT“ and “DRIVERS_GROUP2_DENY“
   OR
   “DRIVERS_GROUP1_ADMIT“ and “DRIVERS_GROUP2_ADMIT“
   OR
   “DRIVERS_GROUP1_DENY“ and “DRIVERS_GROUP2_DENY“

   if composition category = “ADOPTERS“ check that composition.event.code match with one of combination:
   ”ELIGIBLE”
   OR
   ”INELIGIBLE”

   • Return 422 ("Invalid event code for current composition category") in case of error

5. Check (28.1) that composition.event.period.start < composition.event.period.end

   • Return 422 ("Period end of event must be later than event start period") in case of error

13. Inform with

Validate value in the field $.inform_with, string, optional.

• Check that authentication method with type = 'THIRD_PERSON' is submitted in $.authorize_with for person (in composition.subject) that must be authorized by confidant person using following logic:

  1. persons age < no_self_registration_age global parameter;

  2. persons age between no_self_registration_age and person_full_legal_capacity_age global parameters and person does not have document with type from PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter;

  3. persons age > person_full_legal_capacity_age global parameter and exists at least one active and approved confidant person relationship for person (using following process Check confidant person relationship with person_id = person_id from request - expected :ok, :approved response)

     1. in case of error - return 422 ('Authentication method with type THIRD_PERSON must be submitted for this person')

• Check that $.inform_with is a valid uuid

  • in case error - return 422 ('string does not match pattern') with uuid regexp

• Check that authentication method exists in MPI database, person_authentication_methods table (with is_active = true), belongs to the same patient as set in the create composition request, is active (ended_at > now() or ended_at is null) and type != NA

  • in case error - return 422 ('Authentication method doesn't exist, is inactive or does not belong to this person')

• Get value of THIRD_PERSON_CONFIDANT_PERSON_RELATIONSHIP_CHECK config parameter, if it is set to true - for authentication method with type = ‘THIRD_PERSON’ check that person from value is an approved confidant for a patient from create composition request – exists active and approved confidant person relationship between person from request and person_id from authentication method value (using following logic: Check confidant person relationship with person_id = person_id from request and confidant_person_id = value from auth method - expected :ok, :approved response)

  1. in case of error - return 422 ('Authentication method doesn't exist, is inactive or does not belong to this person''Auth method is not active or confidant person relationship is invalid')

14. Title

1. Get count of records in ME.requisition_number where requisition_number is equal to Composition.title and entity is equal to “composition” and type is equal to Composition.type.coding[0].code and patient_id = patient_id from the request

   1. if count = 0 Return 422 ("Composition title is invalid or expired") in case of error

2. Check there is no Composition with the same title in the DB

   • in case of error return 422 “Composition with title <title> already exists“

15. Id

Validate value in the field $.id, uuid, required

• Check there is no Composition with the same ID in the DB

  • in case of error return 422 “Composition with title <title> already exists“

Validate Section

Validate $.section parameters in the composition, required. Check all sections - parent and child.

*next validations use configs

1. Check (43) count of medical records in composition.section.entry <= then value from config - COMPOSITION_SECTION_ENTRY_LIMIT.

   • Return 422 ("Limit of medical records for this composition type and category must be less or equal <RECORDS_LIMIT>") in case of error

2. Check (41) codes for all records from composition.section.entry where resource.type = "observation" on prohibited values for composition (all records not include prohibited codes), depends on event codes which included in config - COMPOSITION_SECTION_ENTRY_PROHIBITED_CODES where config.resource_type = "observation"

   • Return 422 ("Prohibited observation code - <code> in section.entry for current composition") in case of error

3. Check (41.1) codes for all records from composition.section.entry where resource.type = "condition" on prohibited values for composition (all records not include prohibited codes), depends on event codes which included in config - COMPOSITION_SECTION_ENTRY_PROHIBITED_CODES where config.resource_type = "condition"

   • Return 422 ("Prohibited condition code - <code> in section.entry for current composition") in case of error

4. Check (42) codes for all records from composition.section.entry where resource.type = "observation" on required values for composition (at least one record composition entry must contain) which depends on section.code wich included in config - COMPOSITION_SECTION_ENTRY_REQUIRED_CODES where config.resource_type = "observation"

   • Return 422 ("Empty required codes in section.entry for current composition") in case of error

5. Check (42.1) codes for all records from composition.section.entrywhere resource.type = "condition" on required values for composition (at least one record composition entry must contain) which depends on section.code wich included in config - COMPOSITION_SECTION_ENTRY_REQUIRED_CODES where config.resource_type = "condition"

   • Return 422 ("Empty required codes in section entry for current composition") in case of error

6. Check (44 + 45) existing in composition required and optional sections codes which depends on section.code - COMPOSITION_SECTION_CONFIG
   Logic description:
   Find all config.code where parameter config.mandatory = true and compare all codes to composition.section.[n].code. In case when config has nested sections but parameter mandatory = false - don't compare codes to nested sections.
   Logic description:

   • in case when object from config or config.sections.[n] have mandatory = true but composition.section.code or composition.section.section.[n].code hasn’t same value in config.code or config.sections.[n].code - return error

   • in case when composition.section.code has code wich hasn’t config.code - return error

   • Return 422 ("Invalid section content. Mandatory section {{code}} is missed") in case of error with empty required fields

7. Check (45.1) section codes for nested sections hierarchy from config which depends on config - COMPOSITION_SECTION_CONFIG
   Logic description:
   Check that all values from composition.section.code equal to config.code from config.sections on the same nested level where config.sectionAllowed = true

   • in case when value from composition.section.code hasn’t same values with nested config.code (from config.sections) or composition.section.code has codes wich doesn’t exist in config.code (from config.sections) - return error Return 422 ("Invalid section hierarchy for nested section") in case of error with empty required fields

   examples
   success case:
   Composition - composition.section.code = MAIN, nested section - composition.section.section.code = PEDIATRIST
   Config - config.sectionAllowed = true, config.code = MAIN, config.section.code = PEDIATRIST
   error case 1:
   Composition - composition.section.code = MAIN, nested section - composition.section.section.code = NURSING
   Config - config.sectionAllowed = true, config.code = MAIN, config.section.code = PEDIATRIST
   error case 2:
   Composition - composition.section.code = MAIN, nested section - composition.section.section.code = PEDIATRIST
   Config - config.sectionAllowed = true, config.code = MAIN, config.section.code = PEDIATRIST + config.section.code = MAIN

8. Check (45.2) section content for all sections which depends on section code - COMPOSITION_SECTION_CONFIG

   1. Configuration parameters description:

      • if sectionAllowed = true current section can contain nested sections

      • if isEmpty = true current section can contain emptyReason parameter instead of entry array

      • if containsResources = true current section can contain entry and orderBy parameters

   2. Validate section content:

      1. Check that current section contains just one of:

         1. nested section parameter

         2. emptyReason parameter

         3. entry parameter

         4. in case of error an error return 422 ("Section {{section_code}} must contain one AND only one of: nested section, emptyReason or entry")

      2. In case section contains entry parameter check that containsResources = true

         1. in case containsResources = false return 422 ("Section {{section_code}} can not contain entry")

      3. In case section contains emptyReason check that isEmpty = true

         1. in case isEmpty = false return 422 ("Section {{section_code}} can not contain emptyReason")

      4. In case section contains nested section check that sectionAllowed = true

         1. in case sectionAllowed = false return 422 ("Section {{section_code}} can not contain nested section")

9. Check (46) nesting level of sections <= the allowed limit - COMPOSITION_SECTION_NESTING_LEVEL

   • Return 422 ("Prohibited nested level for composition section") in case of error

10. Check (47) count of section <= than value from - COMPOSITION_SECTION_COUNT_LIMIT

    • Return 422 ("Prohibited amount of composition section") in case of error

Validate section content

Section have child sections so we need to execute all validations for $.section.section parameters for each sections

Validate section content

1. Check (53) that person status in composition.section.author <> not verified

   • Return 422 ("Status of person can’t be 'not verified' in composition.section.author") in case of error

*next validations use configs

3. Check (48) composition.section.title

   1. Check that composition.section.title is not empty.

   2. Also check value from COMPOSITION_SECTION_TITLE_MANUAL_FILL config (depends on composition.section.code)

      1. if config.value = "true" (or section with same code doesn't exist) - don’t validate composition.section.title

      2. else if value = "false"

         1. get display value from COMPOSITION_SECTION_CODES dictionary where key=composition.section.code

         2. check composition.section.title = display

   3. Return 422 ("Invalid title for composition.section") in case of error

4. Check (48.1) that section code (composition.section.code) corresponds to appropriate dictionary - COMPOSITION_SECTION_CODES

   • Return 422 ("Section code value is not allowed in enum") in case of error

5. Check (48.2) that section order by parameter (composition.section.orderby) corresponds to appropriate dictionary - COMPOSITION_SECTION_ORDERBY

   • Return 422 ("Section order by value is not allowed in enum") in case of error

6. Check (48.3) that empty reason (composition.section.emptyreason) corresponds to appropriate config - COMPOSITION_SECTION_EMPTY_REASON. In case when composition.section.emptyreason is not empty

   • Return 422 ("Empty reason value is not allowed in enum") in case of error

7. Check (50) that person from all records in composition.section.entry the same as composition.subject (or merged person in mpi.merged_person)

   • Return 422 ("Person from section.entry must be the same as composition.subject or composition.section.focus") in case of error

8. Check (54) that author position from section.author based on config - COMPOSITION_SECTION_AUTHOR_POSITION for selected section.code

   • Return 422 ("Section author position does not allow to create such composition") in case of error

9. Check (55) that author speciality from section.author based on config - COMPOSITION_SECTION_AUTHOR_SPECIALITY for selected section.code

   • Return 422 ("Section author speciality does not allow to create such composition") in case of error

10. Check (55.1) that author main speciality (employee.accreditation.speciality_officio = true ) from section.author based on based on config - COMPOSITION_SECTION_AUTHOR_MAIN_SPECIALITY

    • Return 422 ("Section author main speciality does not allow to create such composition") in case of error

11. Check (56) count of resources from composition.section.entry selected section.code - COMPOSITION_SECTION_SECTION_ENTRY_LIMIT

    • Return 422 ("Max count of resources in section.entry - <count>") in case of error

12. Check (56.1) that the resource type of the resource in composition.section.entry is allowed by config COMPOSITION_SECTION_SECTION_ENTRY_RESOURCES for this section.code and event.code

    • Return 422 ("Resource type is not allowed in this section for this event code") in case of error

Referenced resources validations

Get referenced resources from section.entry and check data. If entry section is not empty - execute validations depends on resource type.

Referenced episode of care

Validate resources where ResourceType = “episodes”

*next validations use configs

1. Check (57) that referenced episode (if entry has resource with this type) from composition.section.entry has type based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TYPE

   • Return 422 ("Invalid referenced episode type in section.entry") in case of error

2. Check (58) that referenced episode (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced episode status in section.entry") in case of error

3. Check (59) that different from sign composition date and referenced episode (if entry has resource with this type) period.start in composition.section.entry between min and max (depending on Composition type, category and section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_PERIOD_START:
   min >= composition.date - episode.period.start <= max
   or
   min >= composition.date - period.start (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced episode start date must be from <min> to <max>") in case of error

Referenced diagnostic report

Validate resources where ResourceType = “diagnostic_reports”

*next validations use configs

1. Check (60) that referenced diagnostic report (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced diagnostic report status in section.entry") in case of error

2. Check (61) that referenced diagnostic report (if entry has resource with this type) from composition.section.entry has code based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CODE where resource_type = "diagnostic report"

   • Return 422 ("Invalid code in referenced diagnostic report at section.entry") in case of error

3. Check (62) that referenced diagnostic report (if entry has resource with this type) from composition.section.entry has category based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CATEGORY

   • Return 422 ("Invalid category in referenced diagnostic report at section.entry") in case of error

4. Check (63) that different from sign composition date and referenced diagnostic report (if entry has resource with this type) effective_period.end in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_PERIOD_END:
   min >= composition.date - diagnostic_report.effective_period.end <= max
   or
   min >= composition.date - diagnostic_report.effective_period.end (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced diagnostic report end date must be from <min> to <max>") in case of error

5. Check (63.1) that different from sign composition date and referenced diagnostic report (if entry has resource with this type) issued in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CREATED_AT:
   min >= composition.date - diagnostic_report.issued <= max
   or
   min >= composition.date - diagnostic_report.issued (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced diagnostic report issued date must be from <min> to <max>") in case of error

Referenced encounter

Validate resources where ResourceType = “encounters”

*next validations use configs

1. Check (64) that referenced encounter (if entry has resource with this type) from composition.section.entry has type based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TYPE where resource_type = "encounter"

   • Return 422 ("Invalid referenced encounter type in section.entry") in case of error

2. Check (65) that referenced encounter (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced encounter status in section.entry") in case of error

3. Check (66) that referenced encounter (if entry has resource with this type) from composition.section.entry has class (class.coding.code and class.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_ENCOUNTER_CLASS

   • Return 422 ("Invalid referenced encounter class in section.entry") in case of error

4. Check (67) that different from sign composition date and referenced encounter (if entry has resource with this type) period.end or date (depending on which parameter is filled) in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_PERIOD_END:
   min >= composition.date - encounter.period.end or encounter.date<= max
   or
   min >= composition.date - encounter.period.end or encounter.date (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced encounter (in section.entry) end date must be from <min> to <max>") in case of error

Referenced care plan

Validate resources where ResourceType = “care_plans”

*next validations use configs

1. Check (67.1) that referenced care plan (if entry has resource with this type) from composition.section.entry has category based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CATEGORY

   • Return 422 ("Invalid category in referenced care plan at section.entry") in case of error

2. Check (68) that referenced care plan (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced care plan status in section.entry") in case of error

3. Check (70) that different from sign composition date and referenced care plan (if entry has resource with this type)period.start in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_PERIOD_START:
   min >= composition.date - care_plan.period.start <= max
   or
   min >= composition.date - care_plan.period.start (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced care plan start date must be from <min> to <max>") in case of error

Referenced activities

Validate resources where ResourceType = “activities”

*next validations use configs

1. Check (71) that referenced activity (if entry has resource with this type) from composition.section.entry has detail.kind based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_ACTIVITY_DETAIL_KIND

   • Return 422 ("Invalid referenced activity detail.kind in section.entry") in case of error

2. Check (72) that referenced activity (if entry has resource with this type) from composition.section.entry has detail.product_reference (care_plan) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_ACTIVITY_DETAIL_PRODUCT_REFERENCE

   • Return 422 ("Invalid referenced activity detail.product_reference in section.entry") in case of error

3. Check (73) that referenced activity (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced activity status in section.entry") in case of error

Referenced procedure

Validate resources where ResourceType = “procedures”

*next validations use configs

1. Check (74) that referenced procedure (if entry has resource with this type) from composition.section.entry has code (code.identifier.type.coding.code and code.identifier.type.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TYPE

   • Return 422 ("Invalid referenced procedure type in section.entry") in case of error

2. Check (75) that referenced procedure (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced procedure status in section.entry") in case of error

3. Check (76) that different from sign composition date and referenced procedure (if entry has resource with this type) between min and max (depends on section code):
   if procedure has filled performed_period.end in composition.section.entry calculate:
   min >= composition.date - procedure.performed_period.end <= max
   or
   min >= composition.date - procedure.performed_period.end (in case when config has only one parameter)
   Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_PERIOD_END where resource_type = "procedure"
   if procedure has filled performed_date_time in composition.section.entry calculate:
   min >= composition.date - procedure.performed_date_time <= max
   or
   min >= composition.date - procedure.performed_date_time (in case when config has only one parameter)
   Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TERM where resource_type = "procedure" and action = "performed"

   • Return 422 ("Difference between sign composition date and referenced procedure date must be from <min> to <max>") in case of error

Referenced condition

Validate resources where ResourceType = “conditions”

*next validations use configs

1. Check (77) that referenced condition (if entry has resource with this type) from composition.section.entry has code (at least one item in code.coding array (code.coding.code and code.coding.system)) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CODE where resource_type = "condition"

   • Return 422 ("Invalid referenced condition code.coding in section.entry") in case of error

2. Check (78) that referenced condition (if entry has resource with this type) from composition.section.entry has clinical_status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced condition clinical_status in section.entry") in case of error

3. Check (79) that referenced condition (if entry has resource with this type) from composition.section.entry has verification_status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_CONDITION_VERIFICATION_STATUS

   • Return 422 ("Invalid referenced condition verification_status in section.entry") in case of error

4. Check (80) that different from sign composition date and referenced condition (if entry has resource with this type) asserted_date in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TERM where resource_type = "condition" and action = "asserted":
   min >= composition.date - condition.asserted_date <= max
   or
   min >= composition.date - condition.asserted_date (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced condition asserted date must be from <min> to <max>") in case of error

5. Check (81) that different from sign composition date and referenced condition (if entry has resource with this type) onset_date in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TERM where resource_type = "condition" and action = "onset":
   min >= composition.date - condition.onset_date <= max
   or
   min >= composition.date - condition.onset_date (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced condition onset date must be from <min> to <max>") in case of error

Referenced observation

Validate resources where ResourceType = “observations”

*next validations use configs

1. Check (82) that referenced observation (if entry has resource with this type) from composition.section.entry has code (code.coding.code and code.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CODE where resource_type = "observation"

   • Return 422 ("Invalid code in referenced observation at section.entry") in case of error

2. Check (83) that referenced observation (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced observation status in section.entry") in case of error

3. Check (84) that referenced observation (if entry has resource with this type) from composition.section.entry has category based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CATEGORY

   • Return 422 ("Invalid category in referenced observation at section.entry") in case of error

4. Check (85) that different from sign composition date and referenced observation (if entry has resource with this type) issued in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TERM where resource_type = "observation" and action = "issued":
   min >= composition.date - observation.issued <= max
   or
   min >= composition.date - observation.issued (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced observation issued date must be from <min> to <max>") in case of error

   • Return 422 ("Invalid referenced observation date in section.entry") in case of error

5. Check (86) that different from sign composition date and referenced observation (if entry has resource with this type) between min and max (depends on section code):
   if observation has filled effective_period.end in composition.section.entry calculate:
   min >= composition.date - observation.effective_period.end <= max
   or
   min >= composition.date - observation.effective_period.end (in case when config has only one parameter)
   Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_PERIOD_END where resource_type = "observation"
   if observation has filled effective_date_time in composition.section.entry calculate:
   min >= composition.date - observation.effective_date_time <= max
   or
   min >= composition.date - observation.effective_date_time (in case when config has only one parameter)
   Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TERM where resource_type = "observation" and action = "effective"

   • Return 422 ("Difference between sign composition date and referenced observation date must be from <min> to <max>") in case of error

Referenced immunization

Validate resources where ResourceType = “immunizations”

*next validations use configs

1. Check (90) that referenced immunization (if entry has resource with this type) from composition.section.entry has explanation.reason_not_given (explanattion.reason_not_given.coding.code and explanation.reason_not_given.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_IMMUNIZATION_EXPLANATION_REASON_NOT_GIVEN

   • Return 422 ("Invalid referenced immunization explanation reason not given in section.entry") in case of error

2. Check (91) that referenced immunization (if entry has resource with this type) from composition.section.entry has explanation.reason (explanattion.reason.coding.code and explanation.reason.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_IMMUNIZATION_EXPLANATION_REASON

   • Return 422 ("Invalid referenced immunization explanation reason in section.entry") in case of error

3. Check (92) that referenced immunization (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced immunization status in section.entry") in case of error

4. Check (93) that referenced immunization (if entry has resource with this type) from composition.section.entry has vaccine_code (vaccine_code.coding.code and vaccine_code.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CODE where resource_type = "immunization"

   • Return 422 ("Invalid vaccine code in referenced immunization at section.entry") in case of error

5. Check (94) that referenced immunization (if entry has resource with this type) from composition.section.entry has report_origin (report_origin.coding.code and report_origin.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_IMMUNIZATION_REPORT_ORIGIN

   • Return 422 ("Invalid referenced immunization report origin in section.entry") in case of error

6. Check (95) that different from sign composition date and referenced immunization (if entry has resource with this type) date in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TERM where resource_type = "immunization" and action = "date":
   min >= composition.date - immunization.date <= max
   or
   min >= composition.date - immunization.date (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced immunization date must be from <min> to <max>") in case of error

Referenced medication request

Validate resources where ResourceType = “medical_requests”

*next validations use configs

1. Check (96) that referenced medication request (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced medication request status in section.entry") in case of error

2. Check (97) that different from sign composition date and referenced medication request (if entry has resource with this type) created_at in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TERM where resource_type = "medication request" and action = "created":
   min >= composition.date - medication_request.created_at <= max
   or
   min >= composition.date - medication_request.created_at (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced medication request created date must be from <min> to <max>") in case of error

3. Check (98) that different from sign composition date and referenced medication request (if entry has resource with this type) started_at in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_PERIOD_START:
   min >= composition.date - medication_request.started_at <= max
   or
   min >= composition.date - medication_request.started_at (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and referenced medication request started at date must be from <min> to <max>") in case of error

Referenced service request

Validate resources where ResourceType = “service_requests”

*next validations use configs

1. Check (100) that referenced service request (if entry has resource with this type) from composition.section.entry has category (category.coding.code and category.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CATEGORY

   • Return 422 ("Invalid category in referenced service request at section.entry")

2. Check (101) that referenced service request (if entry has resource with this type) from composition.section.entry has code.identifier (code.identifier.type.coding.code and code.identifier.type.coding.system) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_CODE where resource_type = "service request"

   • Return 422 ("Invalid code identifier in referenced service request at section.entry") in case of error

3. Check (102) that referenced service request (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced service request status in section.entry") in case of error

4. Check (103) that different from sign composition date and referenced service request (if entry has resource with this type) between min and max (depends on section code):
   if service request has filled occurrence_period.start in composition.section.entry calculate:
   min >= composition.date - service_request.occurrence_period.start <= max
   or
   min >= composition.date - service_request.occurrence_period.start (in case when config has only one parameter)
   Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_PERIOD_START where resource_type = "service request"
   if service request has filled occurrence_date_time in composition.section.entry calculate:
   min >= composition.date - service_request.occurrence_date_time <= max
   or
   min >= composition.date - service_request.occurrence_date_time (in case when config has only one parameter)
   Base on config - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TERM where resource_type = "service request" and action = "occurrence"

   • Return 422 ("Difference between sign composition date and referenced service request date must be from <min> to <max>") in case of error

Referenced division

Validate resources where ResourceType = “divisions”

*next validations use configs

1. Check (120) that referenced division (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_STATUS

   • Return 422 ("Invalid referenced division status in section.entry") in case of error

2. Check (121) that referenced division (if entry has resource with this type) from composition.section.entry has type based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_RESOURCE_TYPE

   • Return 422 ("Invalid referenced division type in section.entry") in case of error

Referenced employee

Validate resources where ResourceType = “employees”

*next validations use configs

1. Check (122) that referenced employee (if entry has resource with this type) from composition.section.entry has status based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_EMPLOYEE_STATUS

   • Return 422 ("Invalid referenced employee status in section.entry") in case of error

2. Check (123) that referenced employee (if entry has resource with this type) from composition.section.entry has position based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_EMPLOYEE_POSITION

   • Return 422 ("Invalid referenced employee position in section.entry") in case of error

3. Check (124) that referenced employee (if entry has resource with this type) from composition.section.entry has speciality based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_EMPLOYEE_SPECIALITY

   • Return 422 ("Invalid referenced employee speciality in section.entry") in case of error

4. Check (124.1) that referenced employee (if entry has resource with this type) from composition.section.entry has main speciality (employee.accreditation.speciality_officio = true ) based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_EMPLOYEE_MAIN_SPECIALITY

   • Return 422 ("Invalid referenced employee main speciality in section.entry") in case of error

5. Check (125) that referenced employee (if entry has resource with this type) from composition.section.entry has type based on dictionary which depends on section.code - COMPOSITION_SECTION_SECTION_ENTRY_EMPLOYEE_TYPE

   • Return 422 ("Invalid referenced employee type in section.entry") in case of error

6. Check (126) that different from sign composition date and referenced employee (if entry has resource with this type) start working date - start_date in composition.section.entry between min and max (depends on section code). Base on config - COMPOSITION_SECTION_SECTION_ENTRY_DEVICE_DISPENSE_WHEN_HANDED_OVER:
   min >= composition.date - employee.start_date <= max
   or
   min >= composition.date - employee.start_date (in case when config has only one parameter)

   • Return 422 ("Difference between sign composition date and employee start working date must be from <min> to <max>") in case of error

Service logic

1. Save signed content to media storage, in the bucket pointed in MEDIA_STORAGE_COMPOSITION_BUCKET chart parameter

2. Set subject with hashed mpi identifier from URL

3. Get encounter where id = Composition.encounter.identifier.value

   1. Set Composition.context_episode_id = encounter.episode

4. Save data to compositions collection in DB according to composition data model

5. Save link from media storage to the $.signed_content_links field in compositions collection

6. Create job and return it’s id.

7. If $.authorize_with is submitted send SMS to patient with composition number via template CREATE_{{COMPOSITION_TYPE}}_COMPOSITION_SMS_TEMPLATE. Use $.authorize_with as patient’s authentication method

Response structure

https://ehealthmedicaleventsapi.docs.apiary.io/#reference/medical-events/composition/create-composition

Example: