Test Suite: EHR_SERVICE / I_CONTRIBUTION Interface

Normative Reference

Items under this validation suite conceptually use these abstract interfaces from the Abstract Platform Service Model, EHR/EHR_CONTRIBUTION component.

Dependencies

This test suite depends on other test suites:

Test Environment

  1. The server under test should support at least OPTs, 1.4 or 2, but OPT 1.4 if more frequent since modeling tools supporting this were around for a long time. Could also support ADL, 1.4 or 2.

  2. The server should support at least one of the XML or JSON representations of CONTRIBUTIONs for committing data, and integrate the corresponding schemas (XML or JSON) to validate data syntactically (before validating against an OPT).

Test Data Sets

General CONTRIBUTION Commit Data Sets

  1. CONTRIBUTIONs with single valid VERSION<COMPOSITION> (minimal, one for each entry type)

  2. CONTRIBUTIONs with multiple valid VERSION<COMPOSITION> (reuse the minimal ^)

  3. CONTRIBUTION with single valid VERSION<COMPOSITION> with maximal data sets

  4. Empty CONTRIBUTION (no VERSIONs)

  5. CONTRIBUTIONs with invalid VERSION<COMPOSITION>

    1. Invalid data

    2. Wrong change_type

    3. Wrong lifecycle

  6. CONTRIBUTIONs with multiple VERSION<COMPOSITION>, with mixed valid and invalid ones

these cases do not consider which RM type is contained in the VERSIONs, it could be COMPOSITION, FOLDER, EHR_STATUS, etc.

COMPOSITION CONTRIBUTION Commit Data Sets

Since there are many combinations of data that could be used for testing the Commit CONTRIBUTION service, we decided to create three main kinds of CONTRIBUTIONs that should be tested:

  1. Valid

    1. minimal COMPOSITIONs with one type of ENTRY (one ENTRY each, all ENTRYs covered)

    2. maximal COMPOSITION (all data types, all ENTRY types, and SECTIONs)

    3. a persistent COMPOSITION (e.g. problem list, medication list, immunization list, …)

    4. time series COMPOSITION (observation with many events, e.g. CPR compressions intervals)

    5. COMPOSITION with alternative types (e.g. lab result DV_COUNT, DV_QUANTITY and DV_CODED_TEXT)

    6. COMPOSITION with DV_CODED_TEXT instance on nodes declared as DV_TEXT in the OPT

    7. COMPOSITION with empty ELEMENT.value and not empty ELEMENT.null_flavour

  2. Invalid

    1. Invalid COMPOSITIONs (e.g. mandatory items not present, wrong types, extra items not declared in OPT, invalid values)

    2. Referenced OPT not loaded (this has to do more with the state of the system than to invalid data)

  3. Change type combinations (these are the minimal required, all supported change types can be found in the openEHR Terminology)

    1. VERSION.commit_audit.change_type = creation

    2. VERSION.commit_audit.change_type = modification

    3. VERSION.commit_audit.change_type = delete

there could be many combinations of flows to use the different Change Types mentioned above. The minimal required by this specification it that the server is capable of this flow: 1. creation 2. modification (one or many times) 3. deleted

Data Set Considerations

change_type

Each VERSION in a CONTRIBUTION has an AUDIT_DETAILS which contains a change_type attribute. The value on that attribute determines the internal behavior for processing each VERSION, and each VERSION in the same CONTRIBUTION could have a different change_type. The most used change types are:

  1. creation: the VERSION represents the first version of a COMPOSITION.

  2. amendment: the VERSION represents a new version of an existing COMPOSITION, with the purpose of adding data.

  3. modification: the VERSION represents a new version of an existing COMPOSITION, with the purpose of changing data, maybe to fix an error.

  4. deleted:the VERSION represents a new version of an existing COMPOSITION, with the purpose of deleting it.

Internally, amendment and modification might be processed in the exact same way, because the difference is semantic not functional.

Here is a full list.

lifecycle_state

Each VERSION in a CONTRIBUTION contains an lifecycle_state attribute, which value gives semantics about the contents of the VERSION. The values could be:

  1. incomplete: the COMPOSITION was committed incomplete and should be completed (reviewed, validated, amended) later.

  2. complete: the COMPOSITION was complete at the moment it was committed.

  3. deleted: the COMPOSITION was committed for deletion.

These codes are defined in the openEHR Terminology.

lifecycle state machine

Combinations of data sets

These combinations can be tested by doing a single commit. The same combinations with flows of multiple commits could lead to different results.

One commit (no previous commits were done), single version cases:

All change types but creation should fail on the first commit, since other change types need a previous commit. Last one could fail because the first commit can’t be change_type = deleted or because the lifecycle_state = |complete| can’t be with change_type = deleted.
change_type lifecycle_state* composition category composition validity** expected

creation

complete

event

valid

accepted

amendment

complete

event

valid

rejected

modification

complete

event

valid

rejected

deleted

complete

event

valid

rejected

creation

complete

persistent

valid

accepted

amendment

complete

persistent

valid

rejected

modification

complete

persistent

valid

rejected

deleted

complete

persistent

valid

rejected

creation

deleted

event

valid

rejected

amendment

deleted

event

valid

rejected

modification

deleted

event

valid

rejected

deleted

deleted

event

valid

rejected
the incomplete cases should be equal to the complete, because the flag is just adding semantics about the content, not setting how the content should be processed.
the invalid cases will make the accepted cases on the previous table to be rejected because the content in the COMPOSITION is not valid.

One commit (no previous commits were done), multiple versions cases:

the tables below represent one VERSION in the committed CONTRIBUTION.

  1. Creating two valid, complete event COMPOSITIONs in one commit should be accepted.

    change_type+ lifecycle_state++ composition category composition validity

    creation

    complete

    event

    valid

    creation

    complete

    event

    valid

    This CONTRIBUTION should be accepted.

  2. Creating two valid, complete persistent COMPOSITIONs in one commit should be accepted.

    depending on the server implementation, some servers might not accept the second COMPOSITION if both COMPOSITIONs reference the same persistent OPT. So this test case considers both COMPOSITIONs reference different persistent OPTs.
    change_type+ lifecycle_state++ composition category composition validity

    creation

    complete

    persistent

    valid

    creation

    complete

    persistent

    valid

    This CONTRIBUTION should be accepted.

  3. Creating two valid, complete and mixed category COMPOSITIONs in one commit should be accepted.

    change_type+ lifecycle_state++ composition category composition validity

    creation

    complete

    event

    valid

    creation

    complete

    persistent

    valid

    This CONTRIBUTION should be accepted.

  4. If any COMPOSITION is invalid in a CONTRIBUTION, the whole commit should fail. It doesn’t matter if it is complete or incomplete, event or persistent (just showing some of the combinations below).

    change_type+ lifecycle_state++ composition category composition validity

    creation

    complete

    event

    valid

    creation

    complete

    event

    invalid
    change_type+ lifecycle_state++ composition category composition validity

    creation

    complete

    persistent

    valid

    creation

    complete

    persistent

    invalid
    change_type+ lifecycle_state++ composition category composition validity

    creation

    complete

    event

    valid

    creation

    complete

    persistent

    invalid
    change_type+ lifecycle_state++ composition category composition validity

    creation

    complete

    event

    invalid

    creation

    complete

    persistent

    valid

    These CONTRIBUTIONs should be REJECTED.

(+) for other change types than creation, the first commit will be rejected, so not included in the table those cases but should be tested.
(++) the incomplete cases should be equal to the complete, because the flag is just adding semantics about the content, not setting how the content should be processed.

EHR_STATUS CONTRIBUTION Commit Data Sets

Combinations for data sets

The following accepted and rejected apply under any of these scenarios:

  1. The server has an EHR with the default EHR_STATUS (the EHR was created without providing an EHR_STATUS).

  2. The server has an EHR created by providing an EHR_STATUS.

  3. The server has an EHR with modifications already done to its EHR_STATUS (consecutive modifications).

Reject Cases:

  1. CONTRIBUTIONs with VERSION, where VERSION.commit_audit.change_type IN [creation, deleted] should be rejected, because the default EHR_STATUS was already created in the EHR, and the EHR_STATUS can’t be deleted once created.

  2. CONTRIBUTIONs with VERSION, where VERSION.lifecycle_state = incomplete should be rejected, because the incomplete state doesn’t apply to EHR_STATUS. Though there is an open issue related to this: https://specifications.openehr.org/jira/browse/SPECPR-368

  3. Any other case with an invalid EHR_STATUS in VERSION should also be rejected.

Accepted Cases:

  1. CONTRIBUTIONs with VERSION where VERSION.commit_audit.change_type IN [modification, amendment] and valid EHR_STATUS, should be accepted. This inscludes the following combinations for EHR_STATUS:

is_modifiable is_queryable subject.external_ref

true

true

HIER_OBJECT_ID

true

true

GENERIC_ID

true

true

NULL

true

false

HIER_OBJECT_ID

true

false

GENERIC_ID

true

false

NULL

false

true

HIER_OBJECT_ID

false

true

GENERIC_ID

false

true

NULL

false

true

HIER_OBJECT_ID

false

true

GENERIC_ID

false

true

NULL

false

false

HIER_OBJECT_ID

false

false

GENERIC_ID

false

false

NULL
Since EHR_STATUS is LOCATABLE, is should have an archetype_id assigned. It is recommended to test the combination described above, combined with different values for EHR_STATUS.archetype_id.

FOLDER CONTRIBUTION Commit Data Sets

All the datasets are specified at the EHR.directory level, since that is the current level of operation of the openEHR REST API for FOLDERs to create, update or delete.

Data Set Combinations

Valid payload should include these cases:

  1. minimal directory

  2. directory with items

  3. directry with subfolders

  4. directory with items and subfolders

  5. directory with items and subfolders with items

Sample structure of FOLDERs with items:

Folders with items

Table of data combinations:

change_type lifecycle_state payload expected

creation

complete / incomplete

valid

accepted

amendment / modification

complete / incomplete

valid

accepted

deleted

deleted

valid

accepted

Any invalid payload should be rejected.

Test Cases

Service Model operation: I_EHR_CONTRIBUTION.commit_contribution()

Service Model reference: I_EHR_CONTRIBUTION.commit_contribution()

Test Case I_EHR_CONTRIBUTION.commit_contribution-valid_composition

Description

Successfully commit CONTRIBUTION of COMPOSITION

Pre-conditions

  1. An EHR with known ehr_id exists

  2. OPTs for each valid cases are loaded on the server

Post-conditions

  1. The EHR with ehr_id should have a new CONTRIBUTION

  2. The ID(s) of the created VERSION(s) are correct

    1. the version ID matches the change_type executed (creation = 1, modification/amendment = 2, 3, …)

    2. ID(s) can be used to retrieve a VERSION<COMPOSITION>)

Flow

  1. Invoke commit CONTRIBUTION service with the existing ehr_id and valid data sets

    1. The COMPOSITIONs reference existing OPTs on the server

  2. The result should be positive and retrieve the id of the CONTRIBUTION just created

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-invalid_composition

Description

Commit CONTRIBUTION with invalid COMPOSITION

Pre-conditions

  1. An EHR with known ehr_id exists

  2. OPTs for each valid cases are loaded on the server

Post-conditions

None

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the invalid VERSION<COMPOSITION>

    1. The COMPOSITIONs reference existing OPTs on the server

  2. The result should be negative and provide info about the errors with the data committed

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-empty

Description

Commit CONTRIBUTION with no content.

Pre-conditions

  1. An EHR with known ehr_id exists

Post-conditions

None

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and no data in the CONTRIBUTION

  2. The result should be negative and retrieve an error indicating the empty list of VERSION<COMPOSITION> in the CONTRIBUTION

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-valid_invalid_compositions

Description

Commit CONTRIBUTION with mixed valid and invalid COMPOSITIONs.

Pre-conditions

  1. An EHR with known ehr_id exists

  2. OPTs for each valid cases are loaded on the server

Post-conditions

None

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and multiple VERSION<COMPOSITION>

    1. Some VERSIONs are valid, some aree invalid

    2. The COMPOSITIONs reference existing OPTs on the server

  2. The result should be negative and retrieve an error related invalid VERSION<COMPOSITION>

Test runners

REST API / Robot
the whole commit should behave like a transaction and fail, no CONTRIBUTIONs or VERSIONs should be created on the server.

Test Case I_EHR_CONTRIBUTION.commit_contribution-event_composition

Description

Commit CONTRIBUTION with event COMPOSITION.

Pre-conditions

  1. An EHR with known ehr_id exists

  2. OPTs for each valid cases are loaded on the server

Post-conditions

  1. There should be two VERSIONs of the same COMPOSITION in the EHR with ehr_id

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION has category = event

    2. The COMPOSITION reference existing an OPT on the server

  2. The result should be positive, returning the created CONTRIBUTION with the ID of the created VERSION<COMPOSITION>

  3. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION should have the same template_id as the one used in 1.

    2. The VERSION change_type = modification and preceding_version_uid = version id returned in 2.

  4. The result should be positive and the returned version id should reflect it’s a new version of an existing COMPOSITION created in 1. (has the same OBJECT_VERSION_ID with version number = 2)

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-persistent_composition

Description

Commit CONTRIBUTION with persistent COMPOSITIONs.

Pre-conditions

  1. An EHR with known ehr_id exists

  2. OPTs for each valid case are loaded on the server

Post-conditions

  1. There should be two VERSIONs of the same COMPOSITION in the EHR with ehr_id

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION.category = persistent

    2. The COMPOSITION references an existing OPT on the server

  2. The result should be positive, returning the version id for the created VERSION

  3. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION should have the same template_id as the one used in 1.

    2. The VERSION.change_type = modification

    3. The VERSION.preceding_version_uid = version id returned in 2.,

  4. The result should be positive and the returned version id should reflect it is a new version of an existing COMPOSITION created in 1. (has the same OBJECT_VERSION_ID with version number = 2)

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-delete

Description

Commit CONTRIBUTION deleting a COMPOSITION.

Pre-conditions

  1. An EHR with known ehr_id exists

  2. OPTs for each valid case are loaded on the server

Post-conditions

  1. Two VERSIONs of the same COMPOSITION should exist in the EHR with ehr_id

  2. The VERSIONED_OBJECT should be logically deleted NOTE: the effect of a VERSIONED_OBJECT being deleted might vary in different implementations. This needs further specification at the openEHR Service Model

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION references an existing OPT on the server

  2. The result should be positive, returning the version id for the created VERSION

  3. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION should reference the same template_id as the one used in 1.

    2. The VERSION.change_type = deleted

    3. The VERSION.preceding_version_uid = version id returned in 2.

  4. The result should be positive and the returned version id should reflect it is a new version of an existing COMPOSITION created in 1. (has the same OBJECT_VERSION_ID with version number = 2, which should be deleted)

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-two_commits_second_invalid

Description

Commit two CONTRIBUTIONa on same COMPOSITION with second containing invalid content.

Pre-conditions

  1. An EHR with known ehr_id exists

  2. OPTs for each valid case are loaded on the server

Post-conditions

  1. There will be just one VERSION in the EHR with ehr_id

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION references an existing OPT on the server

  2. The result should be positive, returning the version id for the created VERSION

  3. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION references the same template_id as the one used in 1.

    2. The VERSION has change_type = modification

    3. The VERSION has preceding_version_uid = version id returned in 2.

    4. The COMPOSITION is one of the invalid data sets

  4. The result should be negative, and retrieve some info about the errors found on the data committed

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-two_commits_second_creation

Description

Commit two CONTRIBUTIONa on same COMPOSITION with second having change_type = creation

Pre-conditions

  1. An EHR with known ehr_id exists

  2. OPTs for each valid case are loaded on the server

Post-conditions

  1. There will be just one VERSION in the EHR with ehr_id

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION references an existing OPT on the server

  2. The result should be positive, returning the version id for the created VERSION

  3. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION references the same template_id as the one used in 1.

    2. The VERSION.change_type = creation

    3. The VERSION.preceding_version_uid = version id returned in 2.

  4. The result should be negative, and retrieve some info about the wrong change type (see notes)

Test runners

REST API / Robot
Validity criterion: only one 'create' operation is allowed for persistent COMPOSITIONs, the next operations over an existing persistent COMPOSITION should be modification.

Test Case I_EHR_CONTRIBUTION.commit_contribution-non_exiting_opt

Description

Commit CONTRIBUTION with COMPOSITION referencing a non existing OPT

Pre-conditions

  1. An EHR with known ehr_id exists

  2. There are no OPTs loaded on the server

Post-conditions

None

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and a valid VERSION<COMPOSITION>

    1. The COMPOSITION references a random OPT template_id

  2. The result should be negative and retrieve an error indicating the missing OPT

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-minimal_ehr_status

Description

Commit CONTRIBUTION containing minimal EHR_STATUS

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR contains a default EHR_STATUS

Post-conditions

  1. The EHR should have a new CONTRIBUTION

  2. The EHR should have a new VERSION for the EHR_STATUS

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the valid data sets (see section B.3.)

    1. For EHR_STATUS CONTRIBUTIONs, the change_type is always modification or amendment

  2. The result should be positive and retrieve the id of the CONTRIBUTION just created

  3. Verify expected CONTRIBUTION uids and CONTRIBUTION count for the EHR with ehr_id

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-full_ehr_status

this case is the same as previous but the precondition 2. is different.

Description

Commit CONTRIBUTION containing full EHR_STATUS

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR contains a full EHR_STATUS (all the optional information is set, i.e. subject.external_ref etc)

Post-conditions

  1. The EHR should have a new CONTRIBUTION

  2. The EHR should have a new VERSION for the EHR_STATUS

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the valid data sets (see above)

    1. Use change_type = modification or amendment

  2. The result should be positive and retrieve the id of the CONTRIBUTION just created

  3. Verify expected CONTRIBUTION uids and CONTRIBUTION count for the EHR with ehr_id

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-ehr_status_invalid_change_type

Description

Commit CONTRIBUTION containing EHR_STATUS with invalid change type

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR has the default EHR_STATUS

Post-conditions

None

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the valid data sets (see above)

    1. Use change_type = create and delete

  2. The result should be negative and retrieve an error indicating the EHR_STATUS already existing for the EHR

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-invalid_ehr_status

Description

Commit CONTRIBUTION containing invalid EHR_STATUS

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR has the default EHR_STATUS

Post-conditions

None

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the invalid data sets (see above)

    1. Use change_type = modification

  2. The result should be negative and retrieve an error indicating the invalid EHR_STATUS

Test Case I_EHR_CONTRIBUTION.commit_contribution-valid_directory

Description

Commit CONTRIBUTION containing valid FOLDER

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR doesn’t have a directory (root FOLDER)

Post-conditions

  1. The EHR with ehr_id should have a new CONTRIBUTION and a directory

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the valid data sets (see above) and change_type = creation

  2. The result should be positive and retrieve the id of the CONTRIBUTION just created

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-fail_create_existing_directory

Description

Commit CONTRIBUTION attempting to create an EHR directory that already exists

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR has a directory (root FOLDER)

Post-conditions

None

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the valid data sets (see above) and change_type = creation

  2. The result should be negative, and retrieve an error indicating the wrong change_type because the root FOLDER already exists

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-fail_modify_non_existing_directory

Description

Commit CONTRIBUTION attempting to modify an EHR directory that doesn’t exist

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR has no directory (root FOLDER)

Post-conditions

None

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the valid data sets

    1. Use change_type = modification

    2. Use a random preceding_version_uid

  2. The result should be negative since, and retrieve an error indicating the wrong change_type, because it’s trying to modify something that doesn’t exist

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.commit_contribution-update_existing_directory

Description

Commit CONTRIBUTION updating an EHR directory

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR has a directory (root FOLDER)

Post-conditions

  1. The EHR should have a new CONTRIBUTION and a new VERSION for the root FOLDER

Flow

  1. Invoke commit CONTRIBUTION service with an existing ehr_id and the valid data sets with change_type = modification or amendment

  2. The result should be positive and retrieve the id of the CONTRIBUTION just created

Test runners

REST API / Robot

Service Model operation: I_EHR_CONTRIBUTION.list_contributions()

Service Model reference: I_EHR_CONTRIBUTION.list_contributions()

CONTRIBUTIONs can contain COMPOSITION, EHR_STATUS or FOLDER, or any mix of those. Each flow below applies to a specific type, except when 'ANY' is mentioned, in which case the flow applies to any of those three types.

Test Case I_EHR_CONTRIBUTION.list_contributions-post_commit

Description

List CONTRIBUTIONs following successful commit

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR as a CONTRIBUTION with known uid

  3. The CONTRIBUTION contains a VERSION<COMPOSITION>

Post-conditions

  1. The EHR should have a new CONTRIBUTION and a new VERSION for the root FOLDER

Flow

  1. Invoke list CONTRIBUTIONs service with the existing ehr_id

  2. The result should be positive and retrieve a list of CONTRIBUTIONs with one item

  3. The CONTRIBUTION should contain a VERSION<COMPOSITION>

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.list_contributions-empty

Description

List CONTRIBUTIONs of existing EHR with no CONTRIBUTIONS

Pre-conditions

  1. An EHR with known ehr_id should exist

  2. The EHR has no CONTRIBUTIONs

Post-conditions

None

Flow

  1. Invoke get CONTRIBUTIONs service by the existing ehr_id

  2. The result should be positive and retrieve an empty list

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.list_contributions-non_existing_ehr

Description

List CONTRIBUTIONs of non-existing EHR (ANY)

Pre-conditions

  1. There are no EHRs on the server

Post-conditions

None

Flow

  1. Invoke list CONTRIBUTIONs service with a random ehr_id

  2. The result should be negative and retrieve an error indicating "EHR with `ehr_id doesn’t exist"`

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.list_contributions-ehr_containing_ehr_status

Description

List CONTRIBUTIONs post commit of CONTRIBUTION containing EHR_STATUS

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR has a CONTRIBUTION with known uid

  3. The CONTRIBUTION contains a VERSION<EHR_STATUS>

Post-conditions

None

Flow

  1. Invoke list CONTRIBUTIONs service by the existing ehr_id

  2. The result should be positive and retrieve a list of CONTRIBUTIONs with one item

  3. The CONTRIBUTION should contain an EHR_STATUS

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.list_contributions-ehr_containing_directory

Description

List CONTRIBUTIONs post commit of CONTRIBUTION containing a directory

Pre-conditions

  1. An EHR with known ehr_id exists

  2. The EHR has a CONTRIBUTION with known uid

  3. The CONTRIBUTION contains a VERSION<FOLDER>

Post-conditions

None

Flow

  1. Invoke get CONTRIBUTIONs service by the existing ehr_id

  2. The result should be positive and retrieve a list of CONTRIBUTIONs with one item

  3. The CONTRIBUTION should contain a FOLDER

Test runners

REST API / Robot

Service Model operation: I_EHR_CONTRIBUTION.has_contribution()

Service Model reference: I_EHR_CONTRIBUTION.has_contribution()

Test Case I_EHR_CONTRIBUTION.has_contribution-existing

Description

Test presence of CONTRIBUTIONs post commit of CONTRIBUTION

Pre-conditions

  1. An EHR should exist in the system with a known ehr_id

  2. The EHR has a CONTRIBUTION with known uid

Post-conditions

None

Flow

  1. Invoke has CONTRIBUTION service with the known ehr_id and CONTRIBUTION uid

  2. The result should be true

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.has_contribution-empty_ehr

Description

Test presence of CONTRIBUTIONs on empty EHR

Pre-conditions

  1. An EHR should exists in the system with a known ehr_id

  2. The EHR doesn’t have any CONTRIBUTIONs

Post-conditions

None

Flow

  1. Invoke has CONTRIBUTION service with the known ehr_id and a random CONTRIBUTION uid

  2. The result should be false

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.has_contribution-bad_ehr

Description

Test presence of CONTRIBUTIONs on non-existent EHR

Pre-conditions

  1. There are no EHRs on the server

Post-conditions

None

Flow

  1. Invoke has CONTRIBUTION service with a random ehr_id and a random CONTRIBUTION uid

  2. The result should be negative, and retrieve an error indicating "the EHR with ehr_id doesn’t exist"

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.has_contribution-bad_contribution

Description

Test presence of CONTRIBUTION that doesn’t exist

Pre-conditions

  1. An EHR should exist on the server with a known ehr_id

  2. The EHR has CONTRIBUTIONs

Post-conditions

None

Flow

  1. Invoke has CONTRIBUTION service with the known ehr_id and a random, not existing CONTRIBUTION uid

  2. The result should be false

Test runners

REST API / Robot

Service Model operation: I_EHR_CONTRIBUTION.get_contribution()

Service Model reference: I_EHR_CONTRIBUTION.get_contribution()

Test Case I_EHR_CONTRIBUTION.get_contribution-existing

Description

Test get CONTRIBUTION from EHR with existing CONTRIBUTION

Pre-conditions

  1. An EHR should exist in the system with a known ehr_id

  2. The EHR has a CONTRIBUTION with known uid

Post-conditions

None

Flow

  1. Invoke has CONTRIBUTION service with the known ehr_id and CONTRIBUTION uid

  2. The result should be the existing CONTRIBUTION

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.get_contribution-empty_ehr

Description

Test get CONTRIBUTION from empty EHR

Pre-conditions

  1. An EHR should exists in the system with a known ehr_id

  2. The EHR doesn’t have any CONTRIBUTIONs

Post-conditions

None

Flow

  1. Invoke has CONTRIBUTION service with the known ehr_id and a random CONTRIBUTION uid

  2. The result should be negative and retrieve an error indicating the non-existing CONTRIBUTION

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.get_contribution-bad_ehr

Description

Test get CONTRIBUTION from non-existing EHR

Pre-conditions

  1. There are no EHRs on the server

Post-conditions

None

Flow

  1. Invoke has CONTRIBUTION service with a random ehr_id and a random CONTRIBUTION uid

  2. The result should be negative, and retrieve an error indicating "the EHR with ehd_id doesn’t exist"

Test runners

REST API / Robot

Test Case I_EHR_CONTRIBUTION.get_contribution-bad_contribution

Description

Test get CONTRIBUTION from EHR with non-existing CONTRIBUTION

Pre-conditions

  1. An EHR should exist on the server with a known ehr_id

  2. The EHR has CONTRIBUTIONs

Post-conditions

None

Flow

  1. Invoke has CONTRIBUTION service with the known ehr_id and a random, non-existing CONTRIBUTION uid

  2. The result should be negative and retrieve an error indicating the non-existing CONTRIBUTION

Test runners

REST API / Robot