openEHR Platform Conformance Test Schedule
Issuer: openEHR Specification Program | |
---|---|
Release: CNF development |
Status: DEVELOPMENT |
Revision: [latest_issue] |
Date: [latest_issue_date] |
Keywords: conformance, test |
© 2017 - 2024 The openEHR Foundation | |
---|---|
The openEHR Foundation is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform implementations. |
|
Licence |
Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/ |
Support |
Issues: Problem Reports |
Acknowledgements
This specification was developed and is maintained by the openEHR Specifications Editorial Committee (SEC).
1. Preface
1.1. Purpose
This document specifies the openEHR Platform Conformance test schedule, which may be used to determine the conformance of openEHR platform products to openEHR plaform-related specifications. The audience of this document includes:
-
Software development organisations developing healthcare information systems;
-
Customer (i.e. procuring) organisations.
1.3. Status
This specification is in the DEVELOPMENT state. The development version of this document can be found at https://specifications.openehr.org/releases/CNF/development/platform_test_schedule.html.
Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:
TBD: (example To Be Determined paragraph)
1.4. Feedback
Feedback may be provided on the openEHR Conformance forum.
Issues may be raised on the specifications Problem Report tracker.
To see changes made due to previously reported issues, see the CNF component Change Request tracker.
2. Glossary of Terms and Acronyms
The following terms and acronyms are used in this document.
Term | Meaning |
---|---|
AOM |
Archetype Object Model (model of constraints). |
API |
Application Programmer Interface. |
CDS |
Clinical Decision Support. |
REST |
Representational state transfer,
a type of web service. REST-compliant Web services allow requesting systems to access and manipulate |
RM |
openEHR Reference Model |
SUT |
System under test. |
3. Overview
3.1. Scope
As described in the openEHR Conformance Guide, the following aspects of a System Under Test (SUT) are tested to determine conformance to published specifications:
Test aspect | How assessed | Methodology |
---|---|---|
API conformance |
Conformance of the implemented APIs to the published APIs, in a concrete API technology |
Regression of test client running API call-in test cases against reference results |
Data Validation conformance |
Conformance of platform’s validation of data against semantic models (archetypes etc) |
Regression of test client committing variable data sets against reference validity |
The main part of this specification is divided into sections according to the three test aspects shown above. Specific methods related to each aspect are described in the sub-sections below.
Specific applications are also outside the scope of this specification, however, it is assumed that in order for solutions to be testable, a minimal generic viewing tool is provided to enable viewing of data and other testable events.
3.2. API Conformance Test Design
API conformance is assessed by running tests on the SUT API, and determining deviations from expected results. As described in Section 4.2 of the openEHR Conformance Guide, the test cases defined here are based on the openEHR Platform Abstract Service Model API operations. Each such operation is a testable capability of a system that relates to a business function. For example, SM operations for an EHR service include create_EHR
, update_EHR
, and so on. For any such operation, there may be multiple test cases, each of which is individually identified. For each test case, there may be multiple data sets. A 'test' is therefore the execution of a particular test case with a particular data set.
Each test case is documented in the form shown in the following sub-section.
3.2.1. Test Case <SERVICE_COMPONENT>.<operation>-<test-specific id>
Description |
<test case description> |
---|---|
Pre-conditions |
<conditions required of the SUT prior to test case execution> |
Post-conditions |
<conditions true of the SUT subsequent to test case execution> |
Flow |
<steps required to execute the test> |
In most automated test frameworks, pre-conditions, setup, actions, post-conditions, and cleanup steps can be directly implemented.
Note
|
The supported RM version(s) by the SUT should be stated in the Conformance Statement, because this will determine some variations on the data sets used for testing. The minimum required version is RM 1.0.2. |
3.3. Data Validation Conformance Test Design
Data validation conformance is defined in terms of test cases with multiple data sets. These test cases are documented in the same basic way as described above, along with multiple data sets, typically shown in tabulated form. They are described in Section 14.
4. Test Suite: DEFINITION Service / I_DEFINITION_ADL2 and I_DEFINITION_ADL14 Interfaces
4.1. Normative Reference
Items under this validation suite conceptually use these abstract interfaces defined in the openEHR Platform Service Model:
These are concretely realised in implementation technology specfic APIs, such as the Definitions REST API.
This test suite uses artefacts defined by the following specifications:
TODO: add ref to dependency diagram in SM/Platform service model.
4.2. Test Environment
The server under test should support:
-
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;
-
validation of OPTs and archetypes uploaded to it, or even provide a service to do so before uploading (useful while developing);
-
different versions of the same OPTs and archetypes.
The following should be taken into account when testing any given product:
-
The server under test should support the full cycle of OPT management, including: validation, loading, versioning, retrieving, delete or deactivation (data for this OPT is loaded but no new data should be accepted for it). For the delete, the internal behavior should be defined: 1. if data was committed referencing an OPT, can it be physically deleted? or should be logically deleted? 2. if there is no data, can the OPT be deleted physically? Logical delete might work as the deactivation mentioned above.
-
The test cases are the same for OPT 1.4/2, but tests should be written separately and different datasets should be created for 1.4 and 2.
-
Different implementations might use specific formats for the template IDs, when testing each server, the template IDs should be adapted to prevent failures for wrong format on the template ID. This is due to openEHR not yet defining a format for the template IDs in the specifications.
4.3. OPT 1.4/2 Test cases
4.3.1. Service Model operation: I_DEFINITION_ADL14.validate_opt()
Service Model reference: I_DEFINITION_ADL14.validate_opt()
4.3.1.1. Test Data Sets
-
minimal valid OPT (each containing each entry type);
-
maximal valid OPT (all types in the RM);
-
invalid OPT (empty file);
-
invalid OPT (empty
template_id
); -
invalid OPT (removed mandatory elements);
-
invalid OPT (added multiple elements that had an upper bound of 1)
4.3.1.2. Test Case I_DEFINITION_ADL14.validate_opt-valid_opt
Description |
Validate valid OPTs |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None (validation should not change the state of the system). |
Flow |
|
Test runners |
Note
|
some servers might not have a way to just validate the OPT, and validation might be part of the OPT upload functionality. In that case, the validation should upload and validate the OPT, and in the cases of valid OPTs, the OPT should be deleted afterwards, so the system state doesn’t change. For invalid OPTs, the upload should fail. |
4.3.1.3. Test Case I_DEFINITION_ADL14.validate_opt-invalid_opt
Description |
Validate invalid OPTs |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None (validation should not change the state of the system). |
Flow |
|
Test runners |
Implementation note: when a step says “for each X, invoke service Y”, means that the test should run completely for each X, that is, the pre-conditions and post-conditions apply to the run for X. So if we have:
Test set: a, b, c
Test case:
-
ensure pre-conditions
-
verify post-conditions
-
flow
-
for each X in data set, run service Y
-
verify result
-
The run should be:
-
ensure pre-conditions
-
invoke Y(a)
-
verify result
-
verify post-conditions
-
ensure pre-conditions
-
invoke Y(b)
-
verify result
-
verify post-conditions
-
ensure pre-conditions
-
invoke Y(c)
-
verify result
-
verify post-conditions
4.3.2. Service Model operation: I_DEFINITION_ADL14.upload_opt()
Service Model reference: I_DEFINITION_ADL14.upload_opt()
4.3.2.1. Data set
-
minimal valid OPT (each with one type of entry, cover all entries)
-
minimal valid OPT, two versions
-
maximal valid OPT (all types in the RM)
-
invalid OPT (empty file)
-
invalid OPT (empty
template_id
) -
invalid OPT (removed mandatory elements)
-
invalid OPT (added multiple elements that had an upper bound of 1)
4.3.2.2. Test Case I_DEFINITION_ADL14.upload_opt-valid_opt
Description |
upload valid OPTs |
---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
Post-conditions |
A new OPT with the given NOTE: the server should be able to retrieve the template by `template_id` or retrieve if an OPT exists or not by `template_id`. |
Flow |
|
Test runners |
4.3.2.3. Test Case I_DEFINITION_ADL14.upload_opt-invalid_opt
Description |
upload invalid OPTs |
---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
Post-conditions |
No OPTs should be loaded on the system. |
Flow |
|
Test runners |
4.3.2.4. Test Case I_DEFINITION_ADL14.upload_opt-valid_opt_twice_conflict
Note
|
since there is no formal versioning mechanism for templates 1.4 (OPT 2 might use the archetype id format for the template id that also includes a version number, but this is not widely used), the OPT upload service needs to handle a version parameter, for instance this is the solution on the openEHR REST API. If the version information is not available when uploading OPTs, then uploading an OPT with the same template_id twice will make the second upload fail (conflict).
|
An alternative solution for the version parameter is to add the version number to the other_details of the OPT, or directly into the template_id
.
See: SPECBASE-30 and SPECITS-42.
Description |
Upload valid OPT twice with conflict |
||
---|---|---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
||
Post-conditions |
A new OPT with the given
|
||
Flow |
|
||
Test runners |
4.3.2.5. Test Case I_DEFINITION_ADL14.upload_opt-valid_opt_twice_no_conflict
Note
|
considering the note on the previous flow, for this flow the version parameter is provided, and both service invocations contain a different version value. |
Description |
upload valid OPT twice with conflict |
||
---|---|---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
||
Post-conditions |
Two new OPTs with the given
|
||
Flow |
|
||
Test runners |
4.3.3. Service Model operation: I_DEFINITION_ADL14.get_opt()
Service Model reference: I_DEFINITION_ADL14.get_opt()
Note
|
the flows of this test case will include flows from the Upload OPT test case, in order to have something to retrieve. |
4.3.3.1. Data sets
-
minimal valid OPT (covering all entry types)
-
minimal valid OPT, two versions
-
maximal valid OPT (all types in the RM)
4.3.3.2. Test Case I_DEFINITION_ADL14.get_opt-retrieve_single
Description |
Retrieve a single OPT |
---|---|
Pre-conditions |
All valid OPTs should be loaded into the system, only the single versioned ones. |
Post-conditions |
None (retrieve should not change the state of the system). |
Flow |
|
Test runners |
4.3.3.3. Test Case I_DEFINITION_ADL14.get_opt-retrieve_fail
Description |
Empty server OPT retrieve fail test |
---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
Post-conditions |
None |
Flow |
|
Test runners |
4.3.3.4. Test Case I_DEFINITION_ADL14.get_opt-retrieve_latest_version
Description |
retrieve last version of versioned OPT |
---|---|
Pre-conditions |
OPTs with more than one version should be loaded. |
Post-conditions |
None |
Flow |
|
Test runners |
4.3.3.5. Test Case I_DEFINITION_ADL14.get_opt-retrieve_specific_version
Description |
retrieve a specific version (not last) of versioned OPT |
---|---|
Pre-conditions |
OPTs with more than one version should be loaded. |
Post-conditions |
None |
Flow |
|
Test runners |
4.3.4. Service Model operation: I_DEFINITION_ADL14.get_opts()
Service Model reference: I_DEFINITION_ADL14.get_opts()
4.3.4.1. Data sets
-
minimal valid OPT (covering each type of entry);
-
minimal valid OPT, two versions;
-
maximal valid OPT (all types in the RM).
4.3.4.2. Test Case I_DEFINITION_ADL14.get_opts-retrieve_all
Description |
retrieve all loaded OPTs |
---|---|
Pre-conditions |
All valid OPTs should be loaded. |
Post-conditions |
None |
Flow |
|
Test runners |
4.3.4.3. Test Case I_DEFINITION_ADL14.get_opts-retrieve_all_no_opts
Description |
retrieve all loaded OPTs when none is loaded |
---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
Post-conditions |
None |
Flow |
|
Test runners |
4.3.5. Service Model operation: I_DEFINITION_ADL14.delete_opt()
Service Model reference: I_DEFINITION_ADL14.delete_opt()
Note
|
the OPT delete can only happen if there is no associated data with the OPT, or if there exists a newer revision (minor version of the same OPT) in the server under test. For all these tests, there is not data committed to the server, so the delete can happen. |
Implementation recommendations: the delete could be logical, so the OPT exists in the server but is not available, and there could be a service to retrieve deleted OPTs. Those can be undeleted or physically deleted (this can’t be undone), and only users with admin permissions should be able to physically delete OPTs.
4.3.5.1. Data sets
-
minimal valid OPT
-
minimal valid OPT, two versions
-
maximal valid OPT (all types in the RM)
4.3.5.2. Test Case I_DEFINITION_ADL14.delete_opt-delete_existing
Description |
delete existing OPTs |
---|---|
Pre-conditions |
All valid OPTs should be loaded into the system. |
Post-conditions |
None |
Flow |
|
Test runners |
4.3.5.3. Test Case I_DEFINITION_ADL14.delete_opt-delete_latest_version
Description |
delete last version of a versioned OPT |
---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
Post-conditions |
None |
Flow |
|
Test runners |
4.3.5.4. Test Case I_DEFINITION_ADL14.delete_opt-delete_specific_version
Description |
delete specific version of a versioned OPT |
---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
Post-conditions |
None |
Flow |
|
Test runners |
4.3.5.5. Test Case I_DEFINITION_ADL14.delete_opt-delete_non_existing
Description |
delete a non existing OPT |
---|---|
Pre-conditions |
No OPTs should be loaded on the system. |
Post-conditions |
None |
Flow |
|
Test runners |
5. Test Suite: DEFINITION Service / I_DEFINITION_QUERY Interface
5.1. Normative Reference
Items under this validation suite conceptually use these abstract interfaces defined in the Platform Service Model:
-
I_DEFINITION_QUERY
These are concretely realised in implementation technology specfic APIs, such as the Definitions REST API.
This test suite uses artefacts defined by the following specifications:
5.4. Test cases
5.4.1. Service Model operation: I_DEFINITION_QUERY.has_query()
Service Model reference: I_DEFINITION_QUERY.has_query()
5.4.2. Service Model operation: I_DEFINITION_QUERY.valid_query()
Service Model reference: I_DEFINITION_QUERY.valid_query()
5.4.2.1. Test Case I_DEFINITION_QUERY.valid_query-valid
Description |
xx |
---|---|
Pre-conditions |
xx |
Post-conditions |
xx |
Flow |
xx |
Test runners |
5.4.2.2. Test Case I_DEFINITION_QUERY.valid_query-invalid
Description |
xx |
---|---|
Pre-conditions |
xx |
Post-conditions |
xx |
Flow |
xx |
Test runners |
5.4.3. Service Model operation: I_DEFINITION_QUERY.list_queries()
Service Model reference: I_DEFINITION_QUERY.list_queries()
5.4.3.1. Test Case I_DEFINITION_QUERY.list_queries-empty
Description |
xx |
---|---|
Pre-conditions |
xx |
Post-conditions |
xx |
Flow |
xx |
Test runners |
5.4.3.2. Test Case I_DEFINITION_QUERY.list_queries-non_empty
Description |
xx |
---|---|
Pre-conditions |
xx |
Post-conditions |
xx |
Flow |
xx |
Test runners |
6. Test Suite: EHR_SERVICE
6.1. Normative Reference
Items in this validation suite conceptually use the following abstract interfaces from the Abstract Platform Service Model, EHR component.
-
I_EHR_SERVICE
-
I_EHR
-
I_EHR_STATUS
These are concretely realised in implementation technology specfic APIs, such as the EHR REST API.
This test suite uses artefacts defined by the following information model specifications:
6.2. Test Environment
The server under test should support:
-
at least the OPT 1.4 format, and optionally OPT 2.
-
at least the XML representation of COMPOSITIONs for committing data, which may be validated by the openEHR XSDs.
6.3. Test Data Sets
These are the data set classes:
-
VALID:
-
not providing an
EHR_STATUS
(empty input, the server creates the default structures and data) -
providing a valid
EHR_STATUS
-
-
INVALID:
-
providing invalid
EHR_STATUS
-
Valid data sets when the EHR_STATUS
is provided and internal strucrures are valid (data set class 1.a):
No. | is_queryable | is_modifiable | subject | other_details | ehr_id |
---|---|---|---|---|---|
1 |
true |
true |
provided |
not provided |
not provided |
2 |
true |
false |
provided |
not provided |
not provided |
3 |
false |
true |
provided |
not provided |
not provided |
4 |
false |
false |
provided |
not provided |
not provided |
5 |
true |
true |
provided |
provided |
not provided |
6 |
true |
false |
provided |
provided |
not provided |
7 |
false |
true |
provided |
provided |
not provided |
8 |
false |
false |
provided |
provided |
not provided |
9 |
true |
true |
provided |
not provided |
provided |
10 |
true |
false |
provided |
not provided |
provided |
11 |
false |
true |
provided |
not provided |
provided |
12 |
false |
false |
provided |
not provided |
provided |
13 |
true |
true |
provided |
provided |
provided |
14 |
true |
false |
provided |
provided |
provided |
15 |
false |
true |
provided |
provided |
provided |
16 |
false |
false |
provided |
provided |
provided |
Any other data set is invalid, for instance providing EHR_STATUS
with:
-
missing
is_queryable
,is_modifiable
-
empty
is_queryable, `_is_modifiable
-
missing or empty
subject_id
-
invalid
subject_id
-
invalid
other_details
Notes:
-
When the
ehr_id
is not present, it is expected that it is assigned by the server. -
The server should set the
EHR.system_id
value to a known value (defined by the server’s configuration). -
The default values that should be assigned by the server for is_modifiable and is_queryable are 'true', and for the subject it defaults to an instance of
PARTY_SELF
. -
There are no cases to check if the provided
ehr_id
is valid, since in the openEHR Platform Service Model the parameters are typed toUUID
, any other format will be an invalid call. -
The validity of an
EHR_STATUS
can be checked in its JSON form by validating against the JSON schemas.
6.4. Test Cases
6.4.1. Service Model operation: I_EHR_SERVICE.has_ehr()
Service Model reference: I_EHR_SERVICE.has_ehr()
6.4.1.1. Test Case I_EHR_SERVICE.has_ehr-existing_ehr_id
Description |
Check has EHR with existing EHR |
---|---|
Pre-conditions |
An EHR should exist in the system with a known |
Post-conditions |
None |
Flow |
|
Test runners |
6.4.1.2. Test Case I_EHR_SERVICE.has_ehr-existing_subject_id
Description |
Check has EHR with existing EHR by |
---|---|
Pre-conditions |
An EHR should exist in the system with a known subject_id. |
Post-conditions |
None |
Flow |
|
Test runners |
Note
|
subject_id refers to the PARTY_REF class instance containing the identifier of a patient represented by PARTY_SELF in the openEHR Reference Model.
|
6.4.1.3. Test Case I_EHR_SERVICE.has_ehr-non_existing_ehr_id
Description |
Check has EHR with non existing EHR |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None |
Flow |
|
Test runners |
6.4.1.4. Test Case I_EHR_SERVICE.has_ehr-non_existing_subject_id
Description |
Check has EHR with non existing EHR by |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None |
Flow |
|
Test runners |
6.4.2. Service Model operation: I_EHR_SERVICE.create_ehr()
Service Model reference: I_EHR_SERVICE.create_ehr()
6.4.2.1. Test Case I_EHR_SERVICE.create_ehr-main
Description |
Create new EHR |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
A new EHR will exist in the system and be consistent with the data sets used. |
Flow |
|
Test runners |
6.4.2.2. Test Case I_EHR_SERVICE.create_ehr-same_ehr_twice
Description |
Attempt to create same EHR twice |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
A new EHR will exist in the system, the first one created, and be consistent with the data sets used. |
Flow |
|
Test runners |
6.4.2.3. Test Case I_EHR_SERVICE.create_ehr-two_ehrs_same_patient
Description |
Create two EHRs for the same patient |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
A new EHR will exist in the system. |
Flow |
|
Test runners |
6.4.3. Service Model operation: I_EHR_SERVICE.get_ehr()
Service Model reference: I_EHR_SERVICE.get_ehr()
6.4.3.1. Test Case I_EHR_SERVICE.get_ehr-existing_ehr_by_ehr_id
Description |
Get existing EHR |
---|---|
Pre-conditions |
An EHR should exist in the system with a known |
Post-conditions |
None. |
Flow |
|
Test runners |
6.4.3.2. Test Case I_EHR_SERVICE.get_ehr-existing_ehr_by_subject_id
Description |
Get existing EHR by |
---|---|
Pre-conditions |
An EHR should exist in the system with a known |
Post-conditions |
None. |
Flow |
|
Test runners |
6.4.3.3. Test Case I_EHR_SERVICE.get_ehr-get_ehr_by_invalid_ehr_id
Description |
Get non existing EHR |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None. |
Flow |
|
Test runners |
6.4.3.4. Test Case I_EHR_SERVICE.get_ehr-get_ehr_by_invalid_subject_id
Description |
Get non existing EHR by |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None. |
Flow |
|
Test runners |
6.5. EHR_STATUS Test Cases
6.5.1. Service Model operation: I_EHR_STATUS.get_ehr_status()
Service Model reference: I_EHR_STATUS.get_ehr_status()
6.5.1.1. Test Case I_EHR_STATUS.get_ehr_status-get_by_ehr_id
Description |
Get status of an existing EHR |
---|---|
Pre-conditions |
An EHR with known |
Post-conditions |
None. |
Flow |
|
Test runners |
6.5.1.2. Test Case I_EHR_STATUS.get_ehr_status-bad_ehr
Description |
Get status of a non-existing EHR |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None. |
Flow |
|
Test runners |
6.5.2. Service Model operation: I_EHR_STATUS.set_ehr_queryable()
Service Model reference: I_EHR_STATUS.set_ehr_queryable()
6.5.2.1. Test Case I_EHR_STATUS.set_ehr_queryable-existing_ehr
Description |
Set EHR queryable of an existing EHR |
---|---|
Pre-conditions |
An EHR with known |
Post-conditions |
|
Flow |
|
Test runners |
6.5.2.2. Test Case I_EHR_STATUS.set_ehr_queryable-bad_ehr
Description |
Set EHR queryable of non existing EHR |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None |
Flow |
|
Test runners |
6.5.3. Service Model operation: I_EHR_STATUS.set_ehr_modifiable()
Service Model reference: I_EHR_STATUS.set_ehr_modifiable()
6.5.3.1. Test Case I_EHR_STATUS.set_ehr_modifiable-existing_ehr
Description |
Set EHR modifiable of an existing EHR |
---|---|
Pre-conditions |
An EHR with known |
Post-conditions |
|
Flow |
|
Test runners |
6.5.3.2. Test Case I_EHR_STATUS.set_ehr_modifiable-bad_ehr
Description |
Set EHR modifiable of non-existing EHR |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None |
Flow |
|
Test runners |
6.5.4. Service Model operation: I_EHR_STATUS.clear_ehr_queryable()
Service Model reference: I_EHR_STATUS.clear_ehr_queryable()
6.5.4.1. Test Case I_EHR_STATUS.clear_ehr_queryable-existing_ehr
Description |
Clear EHR queryable of an existing EHR |
---|---|
Pre-conditions |
An EHR with known |
Post-conditions |
|
Flow |
|
Test runners |
6.5.4.2. Test Case I_EHR_STATUS.clear_ehr_queryable-bad_ehr
Description |
Clear EHR queryable of non-existing EHR |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None |
Flow |
|
Test runners |
6.5.5. Service Model operation: I_EHR_STATUS.clear_ehr_modifiable()
Service Model reference: I_EHR_STATUS.clear_ehr_modifiable()
6.5.5.1. Test Case I_EHR_STATUS.clear_ehr_modifiable-existing_ehr
Description |
Clear EHR modifiable of an existing EHR |
---|---|
Pre-conditions |
An EHR with known |
Post-conditions |
|
Flow |
|
Test runners |
6.5.5.2. Test Case I_EHR_STATUS.clear_ehr_modifiable-bad_ehr
Description |
Clear EHR modifiable of non existing EHR |
---|---|
Pre-conditions |
The server should be empty (no EHRs, no commits, no OPTs). |
Post-conditions |
None |
Flow |
|
Test runners |
7. Test Suite: EHR_SERVICE / I_COMPOSITION Interface
7.1. Normative Reference
Items in this validation suite conceptually use the following abstract interfaces from the Abstract Platform Service Model, EHR/COMPOSITION component.
-
I_EHR_COMPOSITION
These are concretely realised in implementation technology specfic APIs, such as the EHR REST API.
This test suite uses artefacts defined by the following information model specifications:
7.2. Dependencies
This test suite depends on other test suites:
-
Functional Conformance: Definitions Component, providing OPTs;
-
Functional Conformance: EHR Component, providing EHRs.
7.3. Test Environment
-
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.
-
The server should support at least one of the XML or JSON representations of COMPOSITIONs for committing data, and integrate the corresponding schemas (XML or JSON) to validate data syntactically (before validating against an OPT).
7.4. Test Cases
7.4.1. Service Model operation: I_EHR_COMPOSITION.has_composition()
Service Model reference: I_EHR_COMPOSITION.has_composition()
7.4.1.1. Test Case I_EHR_COMPOSITION.has_composition
Description |
Has existing |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.1.2. Test Case I_EHR_COMPOSITION.has_composition-bad_composition
Description |
Has |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.1.3. Test Case I_EHR_COMPOSITION.has_composition-bad_ehr
Description |
Has |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.2. Get COMPOSITION latest
Implementation consideration:
When a COMPOSITION
is retrieved from a service, it will comply with a specific format. There could be a variant for each test to retrieve the COMPOSITION
in any of the supported openEHR formats, and the syntactic validation of those retrieved formats should be done by using the corresponding schemas (XML, JSON, etc). That would be the minimal validation for conformance testing. Though it would be ideal to have semantic validation of the retrieved COMPOSITIONs
to ensure conformance, which is achieved by validating against the corresponding OPT in the testing layer.
Service Model reference: I_EHR_COMPOSITION.get_composition_latest()
7.4.2.1. Test Case I_EHR_COMPOSITION.get_composition_latest
Description |
Get existing |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.2.2. Test Case I_EHR_COMPOSITION.get_composition_latest-bad_composition
Description |
Get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.2.3. Test Case I_EHR_COMPOSITION.get_composition_latest-bad_ehr
Description |
Get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.3. Get COMPOSITION at time
Service Model reference: I_EHR_COMPOSITION.get_composition_at_time()
7.4.3.1. Test Case I_EHR_COMPOSITION.get_composition_at_time
Description |
Get existing |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.3.2. Test Case I_EHR_COMPOSITION.get_composition_at_time-no_time_arg
Description |
Get existing |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.3.3. Test Case I_EHR_COMPOSITION.get_composition_at_time-bad_composition
Description |
Get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.3.4. Test Case I_EHR_COMPOSITION.get_composition_at_time-bad_ehr
Description |
Get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.3.5. Test Case I_EHR_COMPOSITION.get_composition_at_times
Description |
Get existing |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.4. Get COMPOSITION at version
Service Model reference: I_EHR_COMPOSITION.get_composition_version()
7.4.4.1. Test Case I_EHR_COMPOSITION.get_composition_version
Description |
Get existing |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.4.2. Test Case I_EHR_COMPOSITION.get_composition_version-bad_version
Description |
Get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.4.3. Test Case I_EHR_COMPOSITION.get_composition_version-bad_ehr
Description |
Get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.4.4. Test Case I_EHR_COMPOSITION.get_composition_versions
Description |
Get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.5. Get VERSIONED COMPOSITION
Service Model reference: I_EHR_COMPOSITION.get_versioned_composition()
7.4.5.1. Test Case I_EHR_COMPOSITION.get_versioned_composition
Description |
Get existing |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
Note
|
To consider different cases, try with VERSIONED_COMPOSITION that contain just one VERSION or many VERSIONs
|
Note
|
For that, the valid test cases for Create COMPOSITION could be used to comply with the preconditions of this test flow
|
7.4.5.2. Test Case I_EHR_COMPOSITION.get_versioned_composition-non_existent
Description |
Get non-existent |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.5.3. Test Case I_EHR_COMPOSITION.get_versioned_composition-bad_ehr
Description |
Get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.6. Create COMPOSITION
Service Model reference: I_EHR_COMPOSITION.create_composition()
7.4.6.1. Test Case I_EHR_COMPOSITION.create_composition-event
Description |
Create new event |
---|---|
Pre-conditions |
|
Post-conditions |
A new event |
Flow |
|
Test runners |
7.4.6.2. Test Case I_EHR_COMPOSITION.create_composition-persistent
Description |
Create new persistent |
---|---|
Pre-conditions |
|
Post-conditions |
A new persistent |
Flow |
|
Test runners |
7.4.6.3. Test Case I_EHR_COMPOSITION.create_composition-same_opt_twice
Description |
Create persistent |
---|---|
Pre-conditions |
|
Post-conditions |
A new persistent |
Flow |
|
Test runners |
Notes:
-
Current criteria is: only one ‘create’ operation is allowed for persistent
COMPOSITIONs
, the next operations over an existing persistentCOMPOSITION
should be ‘modifications’. -
This is under debate in the openEHR SEC since some implementations permit 'persistent'
COMPOSIITONS
to have more than one instance in the same EHR and some others not. This is due to the lack of information in the openEHR specifications. There is also a discussion to define other types of categories forCOMPOSITIONs
to allow different behaviors.
7.4.6.4. Test Case I_EHR_COMPOSITION.create_composition-invalid_event
Description |
Create new invalid event |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.6.5. Test Case I_EHR_COMPOSITION.create_composition-invalid_persistent
Description |
Create new invalid persistent |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.6.6. Test Case I_EHR_COMPOSITION.create_composition-event_bad_opt
Description |
Create new event |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.6.7. Test Case I_EHR_COMPOSITION.create_composition-event_bad_ehr
Description |
Create new event |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.7. Update COMPOSITION
The update COMPOSITION
service needs the VERSION.preceding_version_uid
attribute to be set, so the server knows which existing VERSION
of the COMPOSITION
will be associated with the newly committed COMPOSITION
. The Service Model spec is not clear about where that attribute is defined. By taking into account the Reference Model, the COMPOSITION
doesn’t contain that value but the VERSION
does. For the COMPOSITION
update service the preceding_version_uid
should be a parameter or the definition in the SM should mention this.
Service Model reference: I_EHR_COMPOSITION.update_composition()
7.4.7.1. Test Case I_EHR_COMPOSITION.update_composition-event
Description |
Update an existing event |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
7.4.7.2. Test Case I_EHR_COMPOSITION.update_composition-persistent
Description |
Update an existing persistent |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
7.4.7.3. Test Case I_EHR_COMPOSITION.update_composition-non_existent
Description |
Update a non-existing |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
7.4.7.4. Test Case I_EHR_COMPOSITION.update_composition-wrong_template
Description |
Update an existing |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
7.4.8. Delete COMPOSITION
Service Model reference: I_EHR_COMPOSITION.delete_composition()
7.4.8.1. Test Case I_EHR_COMPOSITION.delete_composition-event
Description |
Delete event |
---|---|
Pre-conditions |
|
Post-conditions |
|
deleted |
` |
Flow |
|
Test runners |
Note
|
The common implementation of the delete operation is two create a new VERSION of the COMPOSITION that has VERSION.commit_audit.change_type = openehr::523|deleted| , and VERSION.lifecycle_state = openehr::523|deleted| . So the delete operation is not a physical delete but a logical delete. Some implementations might add the option of a physical deleted. This test case considers the postcondition to be a logical delete, which behaves like an update operation in which a new VERSION of an existing COMPOSITION is created.
|
7.4.8.2. Test Case I_EHR_COMPOSITION.delete_composition-persistent
Description |
Delete persistent |
---|---|
Pre-conditions |
|
Post-conditions |
|
deleted |
` |
Flow |
|
Test runners |
7.4.8.3. Test Case I_EHR_COMPOSITION.delete_composition-non_existent
Description |
Delete persistent |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8. Test Suite: EHR_SERVICE / I_CONTRIBUTION Interface
8.1. Normative Reference
Items under this validation suite conceptually use these abstract interfaces from the Abstract Platform Service Model, EHR/EHR_CONTRIBUTION component.
8.2. Dependencies
This test suite depends on other test suites:
-
Functional Conformance: Definitions Component, providing OPTs;
-
Functional Conformance: EHR Component, providing EHRs.
8.3. Test Environment
-
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.
-
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).
8.4. Test Data Sets
8.4.1. General CONTRIBUTION Commit Data Sets
-
CONTRIBUTIONs
with single validVERSION<COMPOSITION>
(minimal, one for each entry type) -
CONTRIBUTIONs
with multiple validVERSION<COMPOSITION>
(reuse the minimal ^) -
CONTRIBUTION
with single validVERSION<COMPOSITION>
with maximal data sets -
Empty
CONTRIBUTION
(noVERSIONs
) -
CONTRIBUTIONs
with invalidVERSION<COMPOSITION>
-
Invalid data
-
Wrong
change_type
-
Wrong
lifecycle
-
-
CONTRIBUTIONs
with multipleVERSION<COMPOSITION>
, with mixed valid and invalid ones
Note
|
these cases do not consider which RM type is contained in the VERSIONs , it could be COMPOSITION , FOLDER , EHR_STATUS , etc.
|
8.4.2. 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:
-
Valid
-
minimal
COMPOSITIONs
with one type of ENTRY (oneENTRY
each, allENTRYs
covered) -
maximal
COMPOSITION
(all data types, allENTRY
types, andSECTIONs
) -
a persistent
COMPOSITION
(e.g. problem list, medication list, immunization list, …) -
time series
COMPOSITION
(observation with many events, e.g. CPR compressions intervals) -
COMPOSITION
with alternative types (e.g. lab resultDV_COUNT
,DV_QUANTITY
andDV_CODED_TEXT
) -
COMPOSITION
withDV_CODED_TEXT
instance on nodes declared asDV_TEXT
in the OPT -
COMPOSITION
with emptyELEMENT.value
and not emptyELEMENT.null_flavour
-
-
Invalid
-
Invalid
COMPOSITIONs
(e.g. mandatory items not present, wrong types, extra items not declared in OPT, invalid values) -
Referenced OPT not loaded (this has to do more with the state of the system than to invalid data)
-
-
Change type combinations (these are the minimal required, all supported change types can be found in the openEHR Terminology)
-
VERSION.commit_audit.change_type = creation
-
VERSION.commit_audit.change_type = modification
-
VERSION.commit_audit.change_type = delete
-
Note
|
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 |
8.4.2.1. 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:
-
creation: the
VERSION
represents the first version of aCOMPOSITION
. -
amendment: the
VERSION
represents a new version of an existingCOMPOSITION
, with the purpose of adding data. -
modification: the
VERSION
represents a new version of an existingCOMPOSITION
, with the purpose of changing data, maybe to fix an error. -
deleted:the
VERSION
represents a new version of an existingCOMPOSITION
, 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.
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:
-
incomplete: the
COMPOSITION
was committed incomplete and should be completed (reviewed, validated, amended) later. -
complete: the
COMPOSITION
was complete at the moment it was committed. -
deleted: the
COMPOSITION
was committed for deletion.
These codes are defined in the openEHR Terminology.
lifecycle state machine
8.4.2.2. 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:
Note
|
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 |
Note
|
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. |
Note
|
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:
Note
|
the tables below represent one VERSION in the committed CONTRIBUTION .
|
-
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. -
Creating two valid, complete persistent
COMPOSITIONs
in one commit should be accepted.Notedepending on the server implementation, some servers might not accept the second COMPOSITION
if bothCOMPOSITIONs
reference the same persistent OPT. So this test case considers bothCOMPOSITIONs
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. -
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. -
If any
COMPOSITION
is invalid in aCONTRIBUTION
, 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.
Note
|
(+) for other change types than creation, the first commit will be rejected, so not included in the table those cases but should be tested. |
Note
|
(++) 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. |
8.4.3. EHR_STATUS CONTRIBUTION Commit Data Sets
8.4.3.1. Combinations for data sets
The following accepted and rejected apply under any of these scenarios:
-
The server has an EHR with the default
EHR_STATUS
(the EHR was created without providing anEHR_STATUS
). -
The server has an EHR created by providing an
EHR_STATUS
. -
The server has an EHR with modifications already done to its
EHR_STATUS
(consecutive modifications).
Reject Cases:
-
CONTRIBUTIONs
withVERSION
, whereVERSION.commit_audit.change_type
IN [creation
,deleted
] should be rejected, because the defaultEHR_STATUS
was already created in the EHR, and theEHR_STATUS
can’t be deleted once created. -
CONTRIBUTIONs
withVERSION
, whereVERSION.lifecycle_state
=incomplete
should be rejected, because theincomplete
state doesn’t apply toEHR_STATUS
. Though there is an open issue related to this: https://specifications.openehr.org/jira/browse/SPECPR-368 -
Any other case with an
invalid
EHR_STATUS
inVERSION
should also be rejected.
Accepted Cases:
-
CONTRIBUTIONs
withVERSION
whereVERSION.commit_audit.change_type
IN [modification
,amendment
] andvalid
EHR_STATUS
, should be accepted. This inscludes the following combinations forEHR_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 |
Note
|
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 .
|
8.4.4. 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.
8.4.4.1. Data Set Combinations
Valid
payload should include these cases:
-
minimal directory
-
directory with items
-
directry with subfolders
-
directory with items and subfolders
-
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.
8.5. Test Cases
8.5.1. Service Model operation: I_EHR_CONTRIBUTION.commit_contribution()
Service Model reference: I_EHR_CONTRIBUTION.commit_contribution()
8.5.1.1. Test Case I_EHR_CONTRIBUTION.commit_contribution-valid_composition
Description |
Successfully commit |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.1.2. Test Case I_EHR_CONTRIBUTION.commit_contribution-invalid_composition
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.1.3. Test Case I_EHR_CONTRIBUTION.commit_contribution-empty
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.1.4. Test Case I_EHR_CONTRIBUTION.commit_contribution-valid_invalid_compositions
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
Note
|
the whole commit should behave like a transaction and fail, no CONTRIBUTIONs or VERSIONs should be created on the server.
|
8.5.1.5. Test Case I_EHR_CONTRIBUTION.commit_contribution-event_composition
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.1.6. Test Case I_EHR_CONTRIBUTION.commit_contribution-persistent_composition
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.1.7. Test Case I_EHR_CONTRIBUTION.commit_contribution-delete
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.1.8. Test Case I_EHR_CONTRIBUTION.commit_contribution-two_commits_second_invalid
Description |
Commit two |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.1.9. Test Case I_EHR_CONTRIBUTION.commit_contribution-two_commits_second_creation
Description |
Commit two |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
Note
|
Validity criterion: only one 'create' operation is allowed for persistent COMPOSITIONs , the next operations over an existing persistent COMPOSITION should be modification.
|
8.5.1.10. Test Case I_EHR_CONTRIBUTION.commit_contribution-non_exiting_opt
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.1.11. Test Case I_EHR_CONTRIBUTION.commit_contribution-minimal_ehr_status
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.1.12. Test Case I_EHR_CONTRIBUTION.commit_contribution-full_ehr_status
Note
|
this case is the same as previous but the precondition 2. is different. |
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.1.13. Test Case I_EHR_CONTRIBUTION.commit_contribution-ehr_status_invalid_change_type
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.1.14. Test Case I_EHR_CONTRIBUTION.commit_contribution-invalid_ehr_status
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
8.5.1.15. Test Case I_EHR_CONTRIBUTION.commit_contribution-valid_directory
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.1.16. Test Case I_EHR_CONTRIBUTION.commit_contribution-fail_create_existing_directory
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.1.17. Test Case I_EHR_CONTRIBUTION.commit_contribution-fail_modify_non_existing_directory
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.1.18. Test Case I_EHR_CONTRIBUTION.commit_contribution-update_existing_directory
Description |
Commit |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.2. Service Model operation: I_EHR_CONTRIBUTION.list_contributions()
Service Model reference: I_EHR_CONTRIBUTION.list_contributions()
Note
|
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.
|
8.5.2.1. Test Case I_EHR_CONTRIBUTION.list_contributions-post_commit
Description |
List |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
8.5.2.2. Test Case I_EHR_CONTRIBUTION.list_contributions-empty
Description |
List |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.2.3. Test Case I_EHR_CONTRIBUTION.list_contributions-non_existing_ehr
Description |
List |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.2.4. Test Case I_EHR_CONTRIBUTION.list_contributions-ehr_containing_ehr_status
Description |
List |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.2.5. Test Case I_EHR_CONTRIBUTION.list_contributions-ehr_containing_directory
Description |
List |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.3. Service Model operation: I_EHR_CONTRIBUTION.has_contribution()
Service Model reference: I_EHR_CONTRIBUTION.has_contribution()
8.5.3.1. Test Case I_EHR_CONTRIBUTION.has_contribution-existing
Description |
Test presence of |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.3.2. Test Case I_EHR_CONTRIBUTION.has_contribution-empty_ehr
Description |
Test presence of |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.3.3. Test Case I_EHR_CONTRIBUTION.has_contribution-bad_ehr
Description |
Test presence of |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.3.4. Test Case I_EHR_CONTRIBUTION.has_contribution-bad_contribution
Description |
Test presence of |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.4. Service Model operation: I_EHR_CONTRIBUTION.get_contribution()
Service Model reference: I_EHR_CONTRIBUTION.get_contribution()
8.5.4.1. Test Case I_EHR_CONTRIBUTION.get_contribution-existing
Description |
Test get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.4.2. Test Case I_EHR_CONTRIBUTION.get_contribution-empty_ehr
Description |
Test get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.4.3. Test Case I_EHR_CONTRIBUTION.get_contribution-bad_ehr
Description |
Test get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
8.5.4.4. Test Case I_EHR_CONTRIBUTION.get_contribution-bad_contribution
Description |
Test get |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9. Test Suite: EHR_SERVICE / I_DIRECTORY Interface
9.1. Normative Reference
Items in this validation suite conceptually use the following abstract interfaces from the Abstract Platform Service Model, EHR/DIRECTORY component.
-
I_EHR_DIRECTORY
These are concretely realised in implementation technology specfic APIs, such as the EHR REST API.
This test suite uses artefacts defined by the following information model specifications:
9.2. Dependencies
This test suite depends on other test suites:
-
Functional Conformance: Definitions Component, providing OPTs;
-
Functional Conformance: EHR Component, providing EHRs.
9.4. Test Data Sets
For the creation and modification of the EHR.directory
structure it is important to explore the hierarchical nature of the FOLDER
structures and consider the edge cases for EHR.directory
.
9.4.1. Tests of EHR.directory
-
FOLDER
-
FOLDER with items
-
FOLDER with subfolders
-
FOLDER with subfolders and items on all the folders
-
FOLDER with n levels of subfolders and items (to detect any implementation limitations)
9.4.2. Tests of Reference FOLDER structure
Note
|
the following image is provided for reference. The items in the FOLDER are references to VERSIONED_OBJECTs that may contain COMPOSITION , EHR_STATUS and FOLDER . This documentation focuses on testing COMPOSITION as content in the FOLDERs . Discourse discussion.
|
9.5. Test Cases
9.5.1. Service Model operation: I_EHR_DIRECTORY.has_directory()
Service Model reference: I_EHR_DIRECTORY.has_directory()
9.5.1.1. Test Case I_EHR_DIRECTORY.has_directory-empty_ehr
Description |
Test has_directory on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.1.2. Test Case I_EHR_DIRECTORY.has_directory-ehr_with_directory
Description |
Test has_directory on EHR containing a directory |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.1.3. Test Case I_EHR_DIRECTORY.has_directory-bad_ehr
Description |
Test has_directory on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.2. Service Model operation: I_EHR_DIRECTORY.has_path()
Service Model reference: I_EHR_DIRECTORY.has_path()
9.5.2.1. Test Case I_EHR_DIRECTORY.has_path-empty_ehr
Description |
Test has_path on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.2.2. Test Case I_EHR_DIRECTORY.has_path-ehr_root_directory
Description |
Test has_path on EHR with just root directory |
||||||||
---|---|---|---|---|---|---|---|---|---|
Pre-conditions |
|
||||||||
Post-conditions |
None |
||||||||
Flow |
|
||||||||
Data set |
|
||||||||
Test runners |
9.5.2.3. Test Case I_EHR_DIRECTORY.has_path-folder_structure
Description |
Test has_path on EHR with folder structure |
||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Pre-conditions |
|
||||||||||||||||||||||||||||||
Post-conditions |
None |
||||||||||||||||||||||||||||||
Flow |
|
||||||||||||||||||||||||||||||
Data set |
Assuming the following structure in / +--- emergency | | | +--- episode-x | | | | | +--- summary-composition-x | | | +--- episode-y | | | +--- summary-composition-y | +--- hospitalization | +--- summary-composition-z
|
||||||||||||||||||||||||||||||
Test runners |
9.5.2.4. Test Case I_EHR_DIRECTORY.has_path-bad_ehr
Description |
Test has_path on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.3. Service Model operation: I_EHR_DIRECTORY.create_directory()
Service Model reference: I_EHR_DIRECTORY.create_directory()
9.5.3.1. Test Case I_EHR_DIRECTORY.create_directory-empty_ehr
Description |
Test create_directory on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
9.5.3.2. Test Case I_EHR_DIRECTORY.create_directory-ehr_with_directory
Description |
Test create_directory on EHR with directory |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.3.3. Test Case I_EHR_DIRECTORY.create_directory-bad_ehr
Description |
Test create_directory on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.4. Service Model operation: I_EHR_DIRECTORY.get_directory()
Service Model reference: I_EHR_DIRECTORY.get_directory()
9.5.4.1. Test Case I_EHR_DIRECTORY.get_directory-empty_ehr
Description |
Test get_directory on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.4.2. Test Case I_EHR_DIRECTORY.get_directory-ehr_root_directory
Description |
Test get_directory on EHR with a root directory |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.4.3. Test Case I_EHR_DIRECTORY.get_directory-directory_with_structure
Description |
Test get_directory on EHR with a directory containing sub-structure |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.4.4. Test Case I_EHR_DIRECTORY.get_directory-bad_ehr
Description |
Test get_directory on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.5. Service Model operation: I_EHR_DIRECTORY.get_directory_at_time()
Service Model reference: I_EHR_DIRECTORY.get_directory_at_time()
9.5.5.1. Test Case I_EHR_DIRECTORY.get_directory_at_time-empty_ehr
Description |
Test get_directory_at_time on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.5.2. Test Case I_EHR_DIRECTORY.get_directory_at_time-empty_ehr_empty_time
Description |
Test get_directory_at_time on empty EHR with empty time |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.5.3. Test Case I_EHR_DIRECTORY.get_directory_at_time-ehr_with_directory
Description |
Test get_directory_at_time on empty EHR with directory |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.5.4. Test Case I_EHR_DIRECTORY.get_directory_at_time-ehr_with_directory_empty_time
Description |
Test get_directory_at_time on EHR with directory with empty time |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.5.5. Test Case I_EHR_DIRECTORY.get_directory_at_time-ehr_with_directory_versions
Description |
Test get_directory_at_time on EHR with directory containing multiple versions |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.5.6. Test Case I_EHR_DIRECTORY.get_directory_at_time-ehr_with_directory_versions_empty_time
Description |
Test get_directory_at_time on EHR with directory containing multiple versions with empty time |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.5.7. Test Case I_EHR_DIRECTORY.get_directory_at_time-bad_ehr
Description |
Test get_directory_at_time on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.5.8. Test Case I_EHR_DIRECTORY.get_directory_at_time-multiple_versions_first
Description |
Test get_directory_at_time on EHR with directory with multiple versions first version |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.6. Service Model operation: I_EHR_DIRECTORY.update_directory()
Service Model reference: I_EHR_DIRECTORY.update_directory()
9.5.6.1. Test Case I_EHR_DIRECTORY.update_directory-ehr_with_directory
Description |
Test update_directory on EHR with directory |
---|---|
Pre-conditions |
|
Post-conditions |
|
Flow |
|
Test runners |
9.5.6.2. Test Case I_EHR_DIRECTORY.update_directory-empty_ehr
Description |
Test update_directory on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.6.3. Test Case I_EHR_DIRECTORY.update_directory-bad_ehr
Description |
Test update_directory on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.7. Service Model operation: I_EHR_DIRECTORY.delete_directory()
Service Model reference: I_EHR_DIRECTORY.delete_directory()
9.5.7.1. Test Case I_EHR_DIRECTORY.delete_directory-empty_ehr
Description |
Test delete_directory on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.7.2. Test Case I_EHR_DIRECTORY.delete_directory-ehr_with_directory
Description |
Test delete_directory on EHR with directory |
||
---|---|---|---|
Pre-conditions |
|
||
Post-conditions |
|
||
Flow |
|
||
Test runners |
9.5.7.3. Test Case I_EHR_DIRECTORY.delete_directory-bad_ehr
Description |
Test delete_directory on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.8. Service Model operation: I_EHR_DIRECTORY.has_directory_version()
Service Model reference: I_EHR_DIRECTORY.has_directory_version()
9.5.8.1. Test Case I_EHR_DIRECTORY.has_directory_version-empty_ehr
Description |
Test has_directory_version on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.8.2. Test Case I_EHR_DIRECTORY.has_directory_version-directory_with_two_versions
Description |
Test has_directory_version on EHR that has two versions of directory |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.8.3. Test Case I_EHR_DIRECTORY.has_directory_version-bad_ehr
Description |
Test has_directory_version on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.9. Service Model operation: I_EHR_DIRECTORY.get_directory_at_version()
Service Model reference: I_EHR_DIRECTORY.get_directory_at_version()
9.5.9.1. Test Case I_EHR_DIRECTORY.get_directory_at_version-empty_ehr
Description |
Test get_directory_at_version on empty EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.9.2. Test Case I_EHR_DIRECTORY.get_directory_at_version-directory_with_two_versions
Description |
Test get_directory_at_version on EHR that has two versions of directory |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.9.3. Test Case I_EHR_DIRECTORY.get_directory_at_version-bad_ehr
Description |
Test get_directory_at_version on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.10. Service Model operation: I_EHR_DIRECTORY.get_versioned_directory()
Service Model reference: I_EHR_DIRECTORY.get_versioned_directory()
9.5.10.1. Test Case I_EHR_DIRECTORY.get_versioned_directory-empty_ehr
Description |
Test get_versioned_directory on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.10.2. Test Case I_EHR_DIRECTORY.get_versioned_directory-directory_with_two_versions
Description |
Test get_versioned_directory on EHR that has two versions of directory |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
9.5.10.3. Test Case I_EHR_DIRECTORY.get_versioned_directory-bad_ehr
Description |
Test get_versioned_directory on non-existent EHR |
---|---|
Pre-conditions |
|
Post-conditions |
None |
Flow |
|
Test runners |
10. Test Suite: DEMOGRAPHIC_SERVICE
10.1. Normative Reference
Items in this validation suite conceptually use the following abstract interfaces from the Abstract Platform Service Model, DEMOGRAPHIC component.
-
I_DEMOGRAPHIC_SERVICE
These are concretely realised in implementation technology specfic APIs, such as the EHR REST API.
This test suite uses artefacts defined by the following information model specifications:
-
Service Interfaces:
-
Information Models:
10.2. Dependencies
This test suite depends on other test suites:
-
Functional Conformance: Definitions Component, providing OPTs.
10.5. Test Cases
10.5.1. Service Model operation: I_DEMOGRAPHIC_SERVICE.create_party()
Service Model reference: I_DEMOGRAPHIC_SERVICE.create_party()
10.5.2. Service Model operation: I_DEMOGRAPHIC_SERVICE.get_party()
Service Model reference: I_DEMOGRAPHIC_SERVICE.get_party()
10.5.3. Service Model operation: I_DEMOGRAPHIC_SERVICE.get_party_at_time()
Service Model reference: I_DEMOGRAPHIC_SERVICE.get_party_at_time()
10.5.4. Service Model operation: I_DEMOGRAPHIC_SERVICE.update_party()
Service Model reference: I_DEMOGRAPHIC_SERVICE.update_party()
10.5.5. Service Model operation: I_DEMOGRAPHIC_SERVICE.delete_party()
Service Model reference: I_DEMOGRAPHIC_SERVICE.delete_party()
10.5.6. Service Model operation: I_DEMOGRAPHIC_SERVICE.get_party_at_version()
Service Model reference: I_DEMOGRAPHIC_SERVICE.get_party_at_version()
10.5.7. Service Model operation: I_DEMOGRAPHIC_SERVICE.create_party_relationship()
Service Model reference: I_DEMOGRAPHIC_SERVICE.create_party_relationship()
10.5.8. Service Model operation: I_DEMOGRAPHIC_SERVICE.get_party_relationship()
Service Model reference: I_DEMOGRAPHIC_SERVICE.get_party_relationship()
10.5.9. Service Model operation: I_DEMOGRAPHIC_SERVICE.get_party_relationship_at_time()
Service Model reference: I_DEMOGRAPHIC_SERVICE.get_party_relationship_at_time()
10.5.10. Service Model operation: I_DEMOGRAPHIC_SERVICE.update_party_relationship()
Service Model reference: I_DEMOGRAPHIC_SERVICE.update_party_relationship()
10.5.11. Service Model operation: I_DEMOGRAPHIC_SERVICE.delete_party_relationship()
Service Model reference: I_DEMOGRAPHIC_SERVICE.delete_party_relationship()
10.5.12. Service Model operation: I_DEMOGRAPHIC_SERVICE.get_party_relationship_at_version()
Service Model reference: I_DEMOGRAPHIC_SERVICE.get_party_relationship_at_version()
11. Test Suite: QUERY_SERVICE
11.1. Normative Reference
Items in this validation suite conceptually use the following abstract interfaces from the Abstract Platform Service Model, QUERY component.
-
I_QUERY_SERVICE
These are concretely realised in implementation technology specfic APIs, such as the QUERY REST API.
This test suite uses artefacts defined by the following information model specifications:
-
Service Interfaces:
-
Language Specifications:
11.2. Dependencies
This test suite depends on other test suites:
-
Functional Conformance: Definitions Component, providing OPTs.
11.5. Test Cases
11.5.1. Service Model operation: I_QUERY_SERVICE.execute_stored_query()
Service Model reference: I_QUERY_SERVICE.execute_stored_query()
11.5.1.1. Test Case I_QUERY_SERVICE.smoke_test
Description |
xx |
---|---|
Pre-conditions |
xx |
Post-conditions |
xx |
Flow |
xx |
Test runners |
11.5.2. Service Model operation: I_QUERY_SERVICE.execute_ad_hoc_query()
Service Model reference: I_QUERY_SERVICE.execute_ad_hoc_query()
11.5.2.1. Test Case I_QUERY_SERVICE.execute_ad_hoc_query-empty_db
Description |
xx |
---|---|
Pre-conditions |
xx |
Post-conditions |
xx |
Flow |
xx |
Test runners |
12. Test Suite: ADMIN_SERVICE
12.1. Normative Reference
Items in this validation suite conceptually use the following abstract interfaces from the Abstract Platform Service Model, ADMIN component.
-
I_ADMIN_SERVICE
-
I_ADMIN_DUMP_LOAD
-
I_ADMIN_ARCHIVE
These are concretely realised in implementation technology specfic APIs, such as the {openehr_admin_rest_api}[ADMIN REST API^].
This test suite uses artefacts defined by the following information model specifications:
-
Service Interfaces:
12.5. Test Cases
12.5.1. Service Model operation: I_ADMIN_SERVICE.list_contributions()
Service Model reference: I_ADMIN_SERVICE.list_contributions()
12.5.2. Service Model operation: I_ADMIN_SERVICE.contribution_count()
Service Model reference: I_ADMIN_SERVICE.contribution_count()
12.5.3. Service Model operation: I_ADMIN_SERVICE.versioned_composition_count()
Service Model reference: I_ADMIN_SERVICE.versioned_composition_count()
12.5.4. Service Model operation: I_ADMIN_SERVICE.composition_version_count()
Service Model reference: I_ADMIN_SERVICE.composition_version_count()
12.5.5. Service Model operation: I_ADMIN_SERVICE.physical_ehr_delete()
Service Model reference: I_ADMIN_SERVICE.physical_ehr_delete()
12.5.6. Service Model operation: I_ADMIN_SERVICE.physical_party_delete()
Service Model reference: I_ADMIN_SERVICE.physical_party_delete()
12.5.7. Service Model operation: I_ADMIN_DUMP_LOAD.export_ehrs()
Service Model reference: I_ADMIN_DUMP_LOAD.export_ehrs()
12.5.8. Service Model operation: I_ADMIN_ARCHIVE.archive_ehrs()
Service Model reference: I_ADMIN_ARCHIVE.archive_ehrs()
12.5.9. Service Model operation: I_ADMIN_ARCHIVE.archive_parties()
Service Model reference: I_ADMIN_ARCHIVE.archive_parties()
13. Test Suite: MESSAGE_SERVICE
13.1. Normative Reference
Items in this validation suite conceptually use the following abstract interfaces from the Abstract Platform Service Model, MESSAGE component.
-
I_EHR_EXTRACT
-
I_TDD
These are concretely realised in implementation technology specfic APIs, such as the {openehr_message_rest_api}[MESSAGE REST API^].
This test suite uses artefacts defined by the following information model specifications:
-
Service Interfaces:
-
Information Models:
13.5. Test Cases
13.5.1. Service Model operation: I_EHR_EXTRACT.export_ehr()
Service Model reference: I_EHR_EXTRACT.export_ehr()
13.5.2. Service Model operation: I_EHR_EXTRACT.export_ehr_extract()
Service Model reference: I_EHR_EXTRACT.export_ehr_extract()
13.5.3. Service Model operation: I_EHR_EXTRACT.export_ehr()
Service Model reference: I_EHR_EXTRACT.export_ehr()
13.5.4. Service Model operation: I_EHR_EXTRACT.export_ehrs()
Service Model reference: I_EHR_EXTRACT.export_ehrs()
13.5.5. Service Model operation: I_EHR_EXTRACT.export_ehr_extracts()
Service Model reference: I_EHR_EXTRACT.export_ehr_extracts()
13.5.6. Service Model operation: I_TDD.import_tdd()
Service Model reference: I_TDD.import_tdd()
13.5.7. Service Model operation: I_TDD.import_tdds()
Service Model reference: I_TDD.import_tdds()
14. Data Validation Conformance
14.1. Overview
The test cases defined here are for creating archetypes expressing specific constraints over data defined by the openEHR RM. Different data instances should be generated in order to test the constraints. It’s recommended to have at least one success case, one failure case and all border cases covered. That is, for each archetype constraint specified, at least three data instances should be created.
Since there are many combinations of constraints possible in archetypes and templates, we separate them into different classes and focus on each constraint set class independently from the other sets. The sets are defined by:
-
A top-level LOCATABLE class: COMPOSITION, EHR_STATUS, FOLDER, PARTY.
-
Constraint sets on top-level attributes for each class.
-
Internal LOCATABLE class: SECTION, ENTRY, HISTORY, ITEM_STRUCTURE, ITEM, DATA_VALUE.
-
Constraint sets on internal structures and attributes (at any level in the RM hierarchy in the internal LOCATABLE class).
In this section, the following terms are used:
-
Archetypable class: any class that extends LOCATABLE.
-
Archetypable field: generic fields on archetypable classes that can be constrained in archetypes.
For testing a 'multiple attribute' cardinality, we use this set of cardinality intervals:
-
0..*
-
1..*
-
3..*
-
0..1
-
1..1
-
3..5
14.1.1. Implementation notes
The constraint combinations described in the cases below could be implemented in different archetypes, or in a generic archetype then defining the specific constraints at the template level. Which option to use might depend on the modeling tools used to create archetypes and templates.
We suggest to automate the archetype/template test cases generation instead of creating each constraint combination manualy.
When there is no constraint defined for an attribute, it means anything is allowed on that attribute. It is recommended to include data not defined by the archetype, but valid in the RM, when generating the data instances.
14.2. COMPOSITION Test Cases
These cases are defined to verify the constraints defined over archetypable attributes of the top-level class COMPOSITION specified in the openEHR RM, COMPOSITION package.
The constraints combinations described below could be tested in two ways:
-
Isolation: by not constraining the COMPOSITION.content at all, or adding an open/‘any allowed’ constraint \{*} at the COMPOSITION.content in the archetype/template. This means anything, even nothing, is accepted at the COMPOSITION.content at runtime.
-
Combination: with constraints set for COMPOSITION.content, for any CONTENT_ITEM (SECTION or ENTRY). Below there is a specification of the constraint combinations for each class accepted at COMPOSITION.content
Note
|
we suggest to test with both strategies. |
14.2.1. Test Case CONT-COMP-content_card_any-context_any
Description: COMPOSITION content cardinality 0..*, no constraint over context
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, success)
-
COMPOSITION with one entry (success)
-
COMPOSITION with 3 entries (success)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
accepted |
|
one entry |
no context |
accepted |
|
three entries |
no context |
accepted |
|
no entries |
context without other_context |
accepted |
|
one entry |
context without other_context |
accepted |
|
three entries |
context without other_context |
accepted |
|
no entries |
context with other_context |
accepted |
|
one entry |
context with other_context |
accepted |
|
three entries |
context with other_context |
accepted |
14.2.2. Test Case CONT-COMP-content_card_1plus-context_any
Description: COMPOSITION content cardinality 1..*, no constraint over context
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, fail)
-
COMPOSITION with one entry (border case, success)
-
COMPOSITION with 3 entries (success)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
no context |
accepted |
|
three entries |
no context |
accepted |
|
no entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context without other_context |
accepted |
|
three entries |
context without other_context |
accepted |
|
no entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context with other_context |
accepted |
|
three entries |
context with other_context |
accepted |
14.2.3. Test Case CONT-COMP-content_card_3plus-context_any
Description: COMPOSITION content cardinality 3..*, no constraint over context
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, fail)
-
COMPOSITION with one entry (fail)
-
COMPOSITION with 3 entries (border case, success)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
no context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
no context |
accepted |
|
no entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
context without other_context |
accepted |
|
no entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
context with other_context |
accepted |
14.2.4. Test Case CONT-COMP-content_card_opt-context_any
Description: COMPOSITION content cardinality 0..1, no constraint over context
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, success)
-
COMPOSITION with one entry (border case, success)
-
COMPOSITION with 3 entries (fail)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
accepted |
|
one entry |
no context |
accepted |
|
three entries |
no context |
rejected |
COMPOSITION.content: cardinality.upper |
no entries |
context without other_context |
accepted |
|
one entry |
context without other_context |
accepted |
|
three entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.upper |
no entries |
context with other_context |
accepted |
|
one entry |
context with other_context |
accepted |
|
three entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.upper |
14.2.5. Test Case CONT-COMP-content_card_mand-context_any
Description: COMPOSITION content cardinality 1..1, no constraint over context
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, fail)
-
COMPOSITION with one entry (border case, success)
-
COMPOSITION with 3 entries (fail)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
no context |
accepted |
|
three entries |
no context |
rejected |
COMPOSITION.content: cardinality.upper |
no entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context without other_context |
accepted |
|
three entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.upper |
no entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context with other_context |
accepted |
|
three entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.upper |
14.2.6. Test Case CONT-COMP-content_card_3to5-context_any
Description: COMPOSITION content cardinality 3..5, no constraint over context
COMPOSITION data sets:
-
COMPOSITION with no entries (fail)
-
COMPOSITION with one entry (fail)
-
COMPOSITION with 3 entries (border case, success)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
no context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
no context |
accepted |
|
no entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
context without other_context |
accepted |
|
no entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
context with other_context |
accepted |
14.2.7. Test Case CONT-COMP-content_card_any-context_mand
Description: COMPOSITION content cardinality 0..*, context occurrences 1..1
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, success)
-
COMPOSITION with one entry (success)
-
COMPOSITION with 3 entries (success)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.context occurrences.lower |
one entry |
no context |
rejected |
COMPOSITION.context occurrences.lower |
three entries |
no context |
rejected |
COMPOSITION.context occurrences.lower |
no entries |
context without other_context |
accepted |
|
one entry |
context without other_context |
accepted |
|
three entries |
context without other_context |
accepted |
|
no entries |
context with other_context |
accepted |
|
one entry |
context with other_context |
accepted |
|
three entries |
context with other_context |
accepted |
14.2.8. Test Case CONT-COMP-content_card_1plus-context_mand
Description: COMPOSITION content cardinality 1..*, context occurrences 1..1
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, fail)
-
COMPOSITION with one entry (border case, success)
-
COMPOSITION with 3 entries (success)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.content: cardinality.lower, COMPOSITION.context occurrences.lower |
one entry |
no context |
rejected |
COMPOSITION.context occurrences.lower |
three entries |
no context |
rejected |
COMPOSITION.context occurrences.lower |
no entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context without other_context |
accepted |
|
three entries |
context without other_context |
accepted |
|
no entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context with other_context |
accepted |
|
three entries |
context with other_context |
accepted |
14.2.9. Test Case CONT-COMP-content_card_3plus-context_mand
Description: COMPOSITION content cardinality 3..*, context occurrences 1..1
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, fail)
-
COMPOSITION with one entry (fail)
-
COMPOSITION with 3 entries (border case, success)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.content: cardinality.lower, COMPOSITION.context occurrences.lower |
one entry |
no context |
rejected |
COMPOSITION.content: cardinality.lower, COMPOSITION.context occurrences.lower |
three entries |
no context |
rejected |
COMPOSITION.context occurrences.lower |
no entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
context without other_context |
accepted |
|
no entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
context with other_context |
accepted |
14.2.10. Test Case CONT-COMP-content_card_opt-context_mand
Description: COMPOSITION content cardinality 0..1, context occurrences 1..1
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, success)
-
COMPOSITION with one entry (border case, success)
-
COMPOSITION with 3 entries (fail)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.context occurrences.lower |
one entry |
no context |
rejected |
COMPOSITION.context occurrences.lower |
three entries |
no context |
rejected |
COMPOSITION.content: cardinality.upper, COMPOSITION.context occurrences.lower |
no entries |
context without other_context |
accepted |
|
one entry |
context without other_context |
accepted |
|
three entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.upper |
no entries |
context with other_context |
accepted |
|
one entry |
context with other_context |
accepted |
|
three entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.upper |
14.2.11. Test Case CONT-COMP-content_card_mand-context_mand
Description: COMPOSITION content cardinality 1..1, context occurrences 1..1
COMPOSITION data sets:
-
COMPOSITION with no entries (border case, fail)
-
COMPOSITION with one entry (border case, success)
-
COMPOSITION with 3 entries (fail)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.content: cardinality.lower, COMPOSITION.context occurrences.lower |
one entry |
no context |
rejected |
COMPOSITION.context occurrences.lower |
three entries |
no context |
rejected |
COMPOSITION.content: cardinality.upper, COMPOSITION.context occurrences.lower |
no entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context without other_context |
accepted |
|
three entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.upper |
no entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context with other_context |
accepted |
|
three entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.upper |
14.2.12. Test Case CONT-COMP-content_card_3to5-context_mand
Description: COMPOSITION content cardinality 3..5, context occurrences 1..1
COMPOSITION data sets:
-
COMPOSITION with no entries (fail)
-
COMPOSITION with one entry (fail)
-
COMPOSITION with 3 entries (border case, success)
Combine those cases with:
-
COMPOSITION with no context
-
COMPOSITION with context but no other_context
-
COMPOSITION with context and other_context
All the context structures should be valid.
content | context | expected | constraints violated |
---|---|---|---|
no entries |
no context |
rejected |
COMPOSITION.content: cardinality.lower, COMPOSITION.context occurrences.lower |
one entry |
no context |
rejected |
COMPOSITION.content: cardinality.lower, COMPOSITION.context occurrences.lower |
three entries |
no context |
rejected |
COMPOSITION.context occurrences.lower |
no entries |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context without other_context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
context without other_context |
accepted |
|
no entries |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
one entry |
context with other_context |
rejected |
COMPOSITION.content: cardinality.lower |
three entries |
context with other_context |
accepted |
14.3. OBSERVATION Test Cases
In this section there are specifications of constraint combinations for OBSERVATION.
Each data set in this section could be combined with the test data sets for COMPOSITION.content defined in section 2.
OBSERVATION data sets:
-
OBSERVATION with no state and no protocol
-
OBSERVATION with no state and protocol
-
OBSERVATION with state and no protocol
-
OBSERVATION with state and protocol
Note
|
since data is mandatory by the RM we can’t have a case for an AOM constraint with no OBSERVATION data. Though any OBSERVATION committed to the SUT without data will return a validation error comming from the RM/Schema, and this should be tested. |
The constraints combinations described below could be tested in two ways:
-
Isolation: by not constraining OBSERVATION.data, OBSERVATION.state and OBSERVATION.protocol, or using the open/'any allowed' constraint \{*} for those attributes.
-
Combination: with constraints defined at the HISTORY level (for data and state) and ITEM_STRUCTURE (for protocol).
Note
|
we suggest to test with both strategies. |
14.3.1. Test Case CONT-OBS-state_ex_opt-protocol_ex_opt
Description: OBSERVATION state existence = 0..1, protocol existence = 0..1
data | state | protocol | expected | constraints violated |
---|---|---|---|---|
absent |
absent |
absent |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
absent |
absent |
present |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
absent |
present |
absent |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
absent |
present |
present |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
present |
absent |
absent |
accepted |
|
present |
absent |
present |
accepted |
|
present |
present |
absent |
accepted |
|
present |
present |
present |
accepted |
14.3.2. Test Case CONT-OBS-state_ex_opt-protocol_ex_mand
Description: OBSERVATION state existence = 0..1, protocol existence = 1..1
data | state | protocol | expected | constraints violated |
---|---|---|---|---|
absent |
absent |
absent |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint), OBSERVATION.protocol existence.lower |
absent |
absent |
present |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
absent |
present |
absent |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint), OBSERVATION.protocol existence.lower |
absent |
present |
present |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
present |
absent |
absent |
rejected |
OBSERVATION.protocol existence.lower |
present |
absent |
present |
accepted |
|
present |
present |
absent |
rejected |
OBSERVATION.protocol existence.lower |
present |
present |
present |
accepted |
14.3.3. Test Case CONT-OBS-state_ex_mand-protocol_ex_opt
Description: OBSERVATION state existence = 1..1, protocol existence = 0..1
data | state | protocol | expected | constraints violated |
---|---|---|---|---|
absent |
absent |
absent |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint), OBSERVATION.state existence.lower |
absent |
absent |
present |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint), OBSERVATION.state existence.lower |
absent |
present |
absent |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
absent |
present |
present |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
present |
absent |
absent |
rejected |
OBSERVATION.state existence.lower |
present |
absent |
present |
rejected |
OBSERVATION.state existence.lower |
present |
present |
absent |
accepted |
|
present |
present |
present |
accepted |
14.3.4. Test Case CONT-OBS-state_ex_mand-protocol_ex_mand
Description: OBSERVATION state existence = 1..1, protocol existence = 1..1
data | state | protocol | expected | constraints violated |
---|---|---|---|---|
absent |
absent |
absent |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint), OBSERVATION.protocol existence.lower, OBSERVATION.state existence.lower |
absent |
absent |
present |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint), OBSERVATION.state existence.lower |
absent |
present |
absent |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint), OBSERVATION.protocol existence.lower |
absent |
present |
present |
rejected |
OBSERVATION.data existence.lower (RM/schema constraint) |
present |
absent |
absent |
rejected |
OBSERVATION.protocol existence.lower, OBSERVATION.state existence.lower |
present |
absent |
present |
rejected |
OBSERVATION.state existence.lower |
present |
present |
absent |
rejected |
OBSERVATION.protocol existence.lower |
present |
present |
present |
accepted |
14.4. HISTORY Test Cases
In this section there are specifications of constraint combinations for HISTORY, specified in the openEHR Data Structures IM.
Each data set in this section could be combined with the test data sets for HISTORY defined in section 3.
HISTORY data sets:
-
HISTORY with no events and no summary
-
HISTORY with events and no summary
-
HISTORY with no events and summary
-
HISTORY with events and summary
The constraints combinations described below could be tested in two ways:
-
Isolation: by not constraining HISTORY.events and HISTORY.summary, or using the open/'any allowed' constraint \{*} for those attributes.
-
Combination: with constraints defined at the EVENT level (for events) and ITEM_STRUCTURE (for summary).
Note
|
we suggest to test with both strategies. |
14.4.1. Test Case CONT-HIST-events_card_any-summary_ex_opt
Description: HISTORY events cardinality 0..*, summary existence 0..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
accepted |
|
one event |
absent |
accepted |
|
three events |
absent |
accepted |
|
no event |
present |
accepted |
|
one event |
present |
accepted |
|
three events |
present |
accepted |
14.4.2. Test Case CONT-HIST-events_card_1plus-summary_ex_opt
Description: HISTORY events cardinality 1..*, summary existence 0..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.events cardinality.lower |
one event |
absent |
accepted |
|
three events |
absent |
accepted |
|
no event |
present |
rejected |
HISTORY.events cardinality.lower |
one event |
present |
accepted |
|
three events |
present |
accepted |
14.4.3. Test Case CONT-HIST-events_card_3plus-summary_ex_opt
Description: HISTORY events cardinality 3..*, summary existence 0..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.events cardinality.lower |
one event |
absent |
rejected |
HISTORY.events cardinality.lower |
three events |
absent |
accepted |
|
no event |
present |
rejected |
HISTORY.events cardinality.lower |
one event |
present |
rejected |
HISTORY.events cardinality.lower |
three events |
present |
accepted |
14.4.4. Test Case CONT-HIST-events_card_opt-summary_ex_opt
Description: HISTORY events cardinality 0..1, summary existence 0..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
accepted |
|
one event |
absent |
accepted |
|
three events |
absent |
rejected |
HISTORY.events cardinality.upper |
no event |
present |
accepted |
|
one event |
present |
accepted |
|
three events |
present |
rejected |
HISTORY.events cardinality.upper |
14.4.5. Test Case CONT-HIST-events_card_mand-summary_ex_opt
Description: HISTORY events cardinality 1..1, summary existence 0..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.events cardinality.lower |
one event |
absent |
accepted |
|
three events |
absent |
rejected |
HISTORY.events cardinality.upper |
no event |
present |
rejected |
HISTORY.events cardinality.lower |
one event |
present |
accepted |
|
three events |
present |
rejected |
HISTORY.events cardinality.upper |
14.4.6. Test Case CONT-HIST-events_card_3to5-summary_ex_opt
Description: HISTORY events cardinality 3..5, summary existence 0..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.events cardinality.lower |
one event |
absent |
rejected |
HISTORY.events cardinality.lower |
three events |
absent |
accepted |
|
no event |
present |
rejected |
HISTORY.events cardinality.lower |
one event |
present |
rejected |
HISTORY.events cardinality.lower |
three events |
present |
accepted |
14.4.7. Test Case CONT-HIST-events_card_any-summary_ex_mand
Description: HISTORY events cardinality 0..*, summary existence 1..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.summary existence.lower |
one event |
absent |
rejected |
HISTORY.summary existence.lower |
three events |
absent |
rejected |
HISTORY.summary existence.lower |
no event |
present |
accepted |
|
one event |
present |
accepted |
|
three events |
present |
accepted |
14.4.8. Test Case CONT-HIST-events_card_1plus-summary_ex_mand
Description: HISTORY events cardinality 1..*, summary existence 1..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.events cardinality.lower, HISTORY.summary existence.lower |
one event |
absent |
rejected |
HISTORY.summary existence.lower |
three events |
absent |
rejected |
HISTORY.summary existence.lower |
no event |
present |
rejected |
HISTORY.events cardinality.lower |
one event |
present |
accepted |
|
three events |
present |
accepted |
14.4.9. Test Case CONT-HIST-events_card_3plus-summary_ex_mand
Description: HISTORY events cardinality 3..*, summary existence 1..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.events cardinality.lower, HISTORY.summary existence.lower |
one event |
absent |
rejected |
HISTORY.events cardinality.lower, HISTORY.summary existence.lower |
three events |
absent |
rejected |
HISTORY.summary existence.lower |
no event |
present |
rejected |
HISTORY.events cardinality.lower |
one event |
present |
rejected |
HISTORY.events cardinality.lower |
three events |
present |
accepted |
14.4.10. Test Case CONT-HIST-events_card_opt-summary_ex_mand
Description: HISTORY events cardinality 0..1, summary existence 1..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.summary existence.lower |
one event |
absent |
rejected |
HISTORY.summary existence.lower |
three events |
absent |
rejected |
HISTORY.events cardinality.upper, HISTORY.summary existence.lower |
no event |
present |
accepted |
|
one event |
present |
accepted |
|
three events |
present |
rejected |
HISTORY.events cardinality.upper |
14.4.11. Test Case CONT-HIST-events_card_mand-summary_ex_mand
Description: HISTORY events cardinality 1..1, summary existence 1..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.events cardinality.lower, HISTORY.summary existence.lower |
one event |
absent |
rejected |
HISTORY.summary existence.lower |
three events |
absent |
rejected |
HISTORY.events cardinality.upper, HISTORY.summary existence.lower |
no event |
present |
rejected |
HISTORY.events cardinality.lower |
one event |
present |
accepted |
|
three events |
present |
rejected |
HISTORY.events cardinality.upper |
14.4.12. Test Case CONT-HIST-events_card_3to5-summary_ex_mand
Description: HISTORY events cardinality 3..5, summary existence 1..1
events | summary | expected | constraints violated |
---|---|---|---|
no events |
absent |
rejected |
HISTORY.events cardinality.lower, HISTORY.summary existence.lower |
one event |
absent |
rejected |
HISTORY.events cardinality.lower, HISTORY.summary existence.lower |
three events |
absent |
rejected |
HISTORY.summary existence.lower |
no event |
present |
rejected |
HISTORY.events cardinality.lower |
one event |
present |
rejected |
HISTORY.events cardinality.lower |
three events |
present |
accepted |
14.5. EVENT Test Cases
EVENT data sets:
-
EVENT with no state
-
EVENT with state
Note
|
since data is mandatory by the RM we can’t have a case for an AOM constraint with “no EVENT.data”. Though any EVENT committed to the SUT without data will return a validation error comming from the RM/Schema, and this should be tested. |
EVENT type combinations:
-
EVENT is POINT_EVENT
-
EVENT is INTERVAL_EVENT
Note
|
testing both EVENT subclasses shouldn’t affect the result of testing combinations with the rest of the constraints defined for EVENT or on container classes. It will affect only the type checking test if the wrong type of EVENT is provided. So instead of combining the expected results with the rest of the constraints, we will define separate test cases. |
The constraints combinations described below could be tested in two ways:
-
Isolation: by not constraining EVENT.data and EVENT.state, or using the open/‘any allowed’ constraint \{*} for those attributes.
-
Combination: with constraints defined at the ITEM_STRUCTURE level (for data and state).
Note
|
we suggest to test with both strategies. |
14.5.1. Test Case CONT-EVENT-state_ex_opt
Description: EVENT state existence 0..1
data | state | expected | constraints violated |
---|---|---|---|
absent |
absent |
rejected |
EVENT.data existence.lower (RM/schema constraint) |
absent |
present |
rejected |
EVENT.data existence.lower (RM/schema constraint) |
present |
absent |
accepted |
|
present |
present |
accepted |
14.5.2. Test Case CONT-EVENT-state_ex_mand
Description: EVENT state existence 1..1
data | state | expected | constraints violated |
---|---|---|---|
absent |
absent |
rejected |
EVENT.data existence.lower (RM/schema constraint), EVENT.state existence.lower |
absent |
present |
rejected |
EVENT.data existence.lower (RM/schema constraint) |
present |
absent |
rejected |
EVENT.state existence.lower |
present |
present |
accepted |
14.5.3. Test Case CONT-EVENT-type_any
Description: EVENT is any EVENT subtype
In the AOM/TOM the constraint for the EVENT type is using the abstract class EVENT, so it allows any EVENT subclass at this position at runtime.
event | expected | constraints violated |
---|---|---|
POINT_EVENT |
accepted |
|
INTERVAL_EVENT |
accepted |
14.6. ITEM_STRUCTURE Test Cases
ITEM_STRUCTURE type combinations:
-
ITEM_STRUCTURE is ITEM_TREE
-
ITEM_STRUCTURE is ITEM_LIST
-
ITEM_STRUCTURE is ITEM_TABLE
-
ITEM_STRUCTURE is ITEM_SINGLE
Note
|
testing with any of the ITEM_STRUCTURE subclasses shouldn’t affect the result of testing combinations with the rest of the constraints defined on container classes. It will affect only the type checking test if the wrong type of ITEM_STRUCTURE is provided. So instead of combining the expected results with the rest of the constraints, we will define separate test cases. |
14.6.1. Test Case CONT-ITEM_STR-type_any
Description: ITEM_STRUCTURE is any ITEM_STRUCTURE subtype
In the AOM/TOM the constraint for the ITEM_STRUCTURE type is using the abstract class ITEM_STRUCTURE, so it allows any ITEM_STRUCTURE subclass at this position at runtime.
event | expected | constraints violated |
---|---|---|
ITEM_TREE |
accepted |
|
ITEM_LIST |
accepted |
|
ITEM_TABLE |
accepted |
|
ITEM_SINGLE |
accepted |
14.6.2. Test Case CONT-ITEM_STR-type_item_tree
Description: ITEM_STRUCTURE is ITEM_TREE
event | expected | constraints violated |
---|---|---|
ITEM_TREE |
accepted |
|
ITEM_LIST |
rejected |
Class not allowed |
ITEM_TABLE |
rejected |
Class not allowed |
ITEM_SINGLE |
rejected |
Class not allowed |
14.6.3. Test Case CONT-ITEM_STR-type_item_list
Description: ITEM_STRUCTURE is ITEM_LIST
event | expected | constraints violated |
---|---|---|
ITEM_TREE |
rejected |
Class not allowed |
ITEM_LIST |
accepted |
|
ITEM_TABLE |
rejected |
Class not allowed |
ITEM_SINGLE |
rejected |
Class not allowed |
14.7. Data Types - Basic Package
14.7.1. DV_BOOLEAN
Internally DV_BOOLEAN is constrained by C_BOOLEAN.
14.7.1.1. Test Case CONT-DV_BOOLEAN-anything_allowed
value | C_BOOLEAN.true_valid | C_BOOLEAN.false_valid | expected | constraints violated |
---|---|---|---|---|
true |
true |
true |
accepted |
|
false |
true |
true |
accepted |
14.7.2. DV_IDENTIFIER
Internally DV_IDENTIFIER attributes are constrainted by C_STRING.
Note the constraints for each attribute are all checked, so the errors are accumulated. If one validation fails for one attribute, the validation for the whole type fails.
14.7.2.1. Test Case CONT-DV_IDENTIFIER-validate_all_pattern
issuer | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
XYZ.* |
NULL |
rejected |
C_STRING.pattern |
ABC |
XYZ.* |
NULL |
rejected |
C_STRING.pattern |
XYZ |
XYZ.* |
NULL |
accepted |
assigner | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
XYZ.* |
NULL |
rejected |
C_STRING.pattern |
ABC |
XYZ.* |
NULL |
rejected |
C_STRING.pattern |
XYZ |
XYZ.* |
NULL |
accepted |
id | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
XYZ.* |
NULL |
rejected |
RM/Schema: this is mandatory in the RM |
ABC |
XYZ.* |
NULL |
rejected |
C_STRING.pattern |
XYZ |
XYZ.* |
NULL |
accepted |
type | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
XYZ.* |
NULL |
rejected |
C_STRING.pattern |
ABC |
XYZ.* |
NULL |
rejected |
C_STRING.pattern |
XYZ |
XYZ.* |
NULL |
accepted |
14.7.2.2. Test Case CONT-DV_IDENTIFIER-validate_all_list
issuer | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
NULL |
[XYZ] |
rejected |
C_STRING.list |
ABC |
NULL |
[XYZ] |
rejected |
C_STRING.list |
XYZ |
NULL |
[XYZ] |
accepted |
assigner | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
NULL |
[XYZ] |
rejected |
C_STRING.list |
ABC |
NULL |
[XYZ] |
rejected |
C_STRING.list |
XYZ |
NULL |
[XYZ] |
accepted |
id | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
NULL |
[XYZ] |
rejected |
RM/Schema: this is mandatory in the RM |
ABC |
NULL |
[XYZ] |
rejected |
C_STRING.list |
XYZ |
NULL |
[XYZ] |
accepted |
type | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
NULL |
[XYZ] |
rejected |
C_STRING.list |
ABC |
NULL |
[XYZ] |
rejected |
C_STRING.list |
XYZ |
NULL |
[XYZ] |
accepted |
14.7.3. DV_STATE
Note
|
this datatype is not used and not supported by modeling tools (Discourse discussion). |
14.8. Data Types - text Package
14.8.1. DV_TEXT
Internally DV_TEXT can be constrained by a C_STRING. This type also allows an instance of the subclass DV_CODED_TEXT at runtime.
14.8.1.1. Test Case CONT-DV_TEXT-validate_open
In ADL this would mean the C_OBJECT for DV_TEXT matches {*}, but different Archetype Editors might model this differently, for instance LinkEHR does a DV_TEXT.value matches {'.*'} which is using the C_STRING pattern that matches anything.
value | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
NULL |
NULL |
rejected |
RM/Schema mandatory |
ABC |
NULL |
NULL |
accepted |
|
XYZ |
NULL |
NULL |
accepted |
14.8.1.2. Test Case CONT-DV_TEXT-validate_open
Note
|
if the type is DV_CODED_TEXT at runtime, the value attribte still needs to comply with the C_STRING constraint. |
value | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
XYZ |
NULL |
rejected |
RM/Schema mandatory |
ABC |
XYZ |
NULL |
rejected |
C_STRING.pattern |
XYZ |
XYZ |
NULL |
accepted |
14.8.1.3. Test Case CONT-DV_TEXT-validate_list
Note
|
if the type is DV_CODED_TEXT at runtime, the value attribte still needs to comply with the C_STRING constraint. |
value | C_STRING.pattern | C_STRING.list | expected | constraints violated |
---|---|---|---|---|
NULL |
NULL |
[XYZ, OPQ] |
rejected |
RM/Schema mandatory |
ABC |
NULL |
[XYZ, OPQ] |
rejected |
C_STRING.list |
XYZ |
NULL |
[XYZ, OPQ] |
accepted |
14.8.2. DV_CODED_TEXT
Internally the DV_CODED_TEXT can be constrained by a C_CODE_PHRASE. Note that in the cases for DV_TEXT we already tested when the type is constrained by a C_STRING (when the declared type is DV_TEXT but the runtime type is DV_CODED_TEXT).
14.8.2.1. Test Case CONT-DV_CODED_TEXT-validate_open
In ADL this would mean the C_OBJECT for DV_CODED_TEXT matches {*}
.
code_string | terminology_id | C_CODE_PHRASE. code_list |
C_CODE_PHRASE. terminology_id |
expected | constraints violated |
---|---|---|---|---|---|
NULL |
NULL |
NULL |
NULL |
rejected |
RM/Schema mandatory both code_String and terminology_id |
ABC |
NULL |
NULL |
NULL |
rejected |
RM/Schema mandatory terminology_id |
NULL |
local |
NULL |
NULL |
rejected |
RM/Schema mandatory code_string |
ABC |
local |
NULL |
NULL |
accepted |
|
82272006 |
SNOMED-CT |
NULL |
NULL |
accepted |
14.8.2.2. Test Case CONT-DV_CODED_TEXT-validate_local_codes
Note
|
having C_CODE_PHRASE.terminology_id = local and C_CODE_PHRASE.code_list = EMPTY, would be possible at the archetype level, but would be invalid at the template level, so that case is not considered here since it should be validated when the template is uploaded to the SUT. |
code_string | terminology_id | C_CODE_PHRASE. code_list |
C_CODE_PHRASE. terminology_id |
expected | constraints violated |
---|---|---|---|---|---|
NULL |
NULL |
[ABC, OPQ] |
local |
rejected |
RM/Schema mandatory both code_String and terminology_id |
ABC |
NULL |
[ABC, OPQ] |
local |
rejected |
RM/Schema mandatory terminology_id |
NULL |
local |
[ABC, OPQ] |
local |
rejected |
RM/Schema mandatory code_string |
ABC |
local |
[ABC, OPQ] |
local |
accepted |
|
82272006 |
SNOMED-CT |
[ABC, OPQ] |
local |
rejected |
C_CODE_PHRASE.terminology_id |
14.8.2.3. Test Case CONT-DV_CODED_TEXT-validate_ext_term
In this case the DV_CODED_TEXT is constrained by a CONSTRAINT_REF. For the CONSTRAINT_REF to be valid in the template, there shoudld be a constraint_binding entry in the template ontology for the acNNNN code of the CONSTRAINT_REF. Without that, the SUT doesn’t know which terminology_id can be used in that DV_CODED_TEXT. Note that multiple bindings are possible, so there could be more than one terminology_id for the coded text. The cases where there are no constraint_bindings are not tested here, that should be part of the OPT validation.
Note
|
the COSNTRAINT_REF in ADL is transformed by the Template Designer into a C_CODE_REFERENCE in OPT, which is a C_CODE_PHRASE subclass with an extra referenceSetUri attribute. |
code_string | terminology_id | CONSTRAINT_REF. reference |
constraint_bindings | expected | constraints violated |
---|---|---|---|---|---|
NULL |
NULL |
ac0001 |
[SNOMED_CT] |
rejected |
RM/Schema mandatory both code_String and terminology_id |
ABC |
NULL |
ac0001 |
[SNOMED_CT] |
rejected |
RM/Schema mandatory terminology_id |
NULL |
local |
ac0001 |
[SNOMED_CT] |
rejected |
RM/Schema mandatory code_string |
ABC |
local |
ac0001 |
[SNOMED_CT] |
rejected |
constraint_binding: terminology_id not found |
82272006 |
SNOMED-CT |
ac0001 |
[SNOMED_CT] |
accepted |
14.8.3. DV_PARAGRAPH
Note
|
this DB is not used or supported by modeling tools, see https://discourse.openehr.org/t/is-dv-paragraph-used/2187 |
14.9. Data Types - quantity Package
14.9.1. DV_ORDINAL
DV_ORDINAL is constrained by C_DV_ORDINAL from the openEHR AM 1.4 Archetype Profile, which contains a list of DV_ORDINAL that could be empty.
Note
|
in ADL it is possible to have a C_DV_ORDINAL constraint with an empty list constraint. At the OPT level this case should be invalid, since is like defining a constraint for a DV_CODED_TEXT with terminology_id local but no given codes, since all codes in a C_DV_ORDINAL have terminology_id local , at least one code in the list is required at the OPT level. This constraint is valid at the archetypel evel. See commend on 2.3.2.
|
14.9.1.1. Test Case CONT-DV_ORDINAL-validate_open
This case is when the ADL has DV_ORDINAL matches {*}
symbol | value | expected | constraints violated |
---|---|---|---|
NULL |
NULL |
rejected |
RM/Schema value and symbol are mandatory |
NULL |
1 |
rejected |
RM/Schema symbol is mandatory |
local::at0005 |
NULL |
rejected |
RM/Schema value is mandatory |
local::at0005 |
1 |
accepted |
|
local::at0005 |
666 |
accepted |
14.9.1.2. Test Case CONT-DV_ORDINAL-validate_constraint
symbol | value | C_DV_ORDINAL.list | expected | constraints violated |
---|---|---|---|---|
local::at0005 |
1 |
1|[local::at0005], 2|[local::at0006] |
accepted |
|
local::at0005 |
666 |
1|[local::at0005], 2|[local::at0006] |
rejected |
C_DV_ORDINAL.list: no matching value |
local::at0666 |
1 |
1|[local::at0005], 2|[local::at0006] |
rejected |
C_DV_ORDINAL.list: no matching symbol |
14.9.2. DV_SCALE
DV_SCALE was introduced to the RM 1.1.0 (Discourse discussion), it is analogous to DV_ORDINAL with a Real value. So test cases for DV_SCALE and DV_ORDINAL are similar.
Note
|
if this specification is implemented on a system that supports a RM < 1.1.0, then these tests shouldn’t run against the system. |
14.9.2.1. Test Case CONT-DV_SCALE-validate_open
This case is when the ADL has DV_SCALE matches {*}
symbol | value | expected | constraints violated |
---|---|---|---|
NULL |
NULL |
rejected |
RM/Schema value and symbol are mandatory |
NULL |
1.5 |
rejected |
RM/Schema symbol is mandatory |
local::at0005 |
NULL |
rejected |
RM/Schema value is mandatory |
local::at0005 |
1.5 |
accepted |
|
local::at0005 |
666 |
accepted |
14.9.2.2. Test Case CONT-DV_SCALE-validate_constraint
Note
|
there is no current C_DV_SCALE constraint in the Archetype Profile, so modeling tools are not yet supporting constraints for this type. This is a [known issue](https://openehr.atlassian.net/browse/SPECPR-381). Though we can assume the constraint type will be analogous to the C_DV_ORDINAL. |
symbol | value | C_DV_SCALE.list | expected | constraints violated |
---|---|---|---|---|
local::at0005 |
1.5 |
1.5|[local::at0005], 2.0|[local::at0006] |
accepted |
|
local::at0005 |
66.6 |
1.5|[local::at0005], 2.0|[local::at0006] |
rejected |
C_DV_SCALE.list: no matching value |
local::at0666 |
1.5 |
1.5|[local::at0005], 2.0|[local::at0006] |
rejected |
C_DV_SCALE.list: no matching symbol |
14.9.3. DV_COUNT
Internally this type is constrained by a C_INTEGER which could contain a range or a list of values.
14.9.3.1. Test Case CONT-DV_COUNT-validate_open
This case represents the DV_COUNT matching {*}, in this case the C_INTEGER is not present in the OPT.
magnitude | expected | constraints violated |
---|---|---|
NULL |
rejected |
RM/Schema magnitude is mandatory |
0 |
accepted |
|
1 |
accepted |
|
15 |
accepted |
|
30 |
accepted |
14.9.3.2. Test Case CONT-DV_COUNT-validate_range
magnitude | C_INTEGER.range | C_INTEGER.list | expected | constraints violated |
---|---|---|---|---|
NULL |
10..20 |
NULL |
rejected |
RM/Schema magnitude is mandatory |
0 |
10..20 |
NULL |
rejected |
C_INTEGER.range |
1 |
10..20 |
NULL |
rejected |
C_INTEGER.range |
15 |
10..20 |
NULL |
accepted |
|
30 |
10..20 |
NULL |
rejected |
C_INTEGER.range |
14.9.3.3. Test Case CONT-DV_COUNT-validate_list
Note
|
some modeling tools might not support the list constraint. |
magnitude | C_INTEGER.range | C_INTEGER.list | expected | constraints violated |
---|---|---|---|---|
NULL |
NULL |
[10,15,20] |
rejected |
RM/Schema magnitude is mandatory |
0 |
NULL |
[10,15,20] |
rejected |
C_INTEGER.list |
1 |
NULL |
[10,15,20] |
rejected |
C_INTEGER.list |
15 |
NULL |
[10,15,20] |
accepted |
|
30 |
NULL |
[10,15,20] |
rejected |
C_INTEGER.list |
14.9.4. DV_QUANTITY
Internally DV_QUANTITY is constrained by a C_DV_QUANTITY, which allows to specify an optional physical property and a list of C_QUANTITY_ITEM, which can contain a mandatory units and optional interval constraints for magnitude and precision.
14.9.4.1. Test Case CONT-DV_QUANTITY-validate_open
This case represents the DV_QUANTITY matching {*}, in this case the C_DV_QUANTITY is not present in the OPT.
magnitude | units | expected | constraints violated |
---|---|---|---|
NULL |
NULL |
rejected |
RM/Schema both magnitude and untis are mandatory |
NULL |
cm |
rejected |
RM/Schema magnitude is mandatory |
1.0 |
NULL |
rejected |
RM/Schema untis is mandatory |
0.0 |
cm |
accepted |
|
1.0 |
cm |
accepted |
|
5.7 |
cm |
accepted |
|
10.0 |
cm |
accepted |
14.9.4.2. Test Case CONT-DV_QUANTITY-validate_property
The C_DV_QUANTITY is present in the OPT and has a value for property
, but doesn’t have a list of C_QUANTITY_ITEM.
Note
|
in this case all units for the property are allowed, so the validation should look into UCUM for all the possible units of measure or that physical property (the possible values are not un the OPT).
|
magnitude | units | C_DV_QUANTITY.property | C_DV_QUANTITY.list | expected | constraints violated |
---|---|---|---|---|---|
NULL |
NULL |
openehr::122 (length) |
NULL |
rejected |
RM/Schema both magnitude and untis are mandatory |
NULL |
cm |
openehr::122 (length) |
NULL |
rejected |
RM/Schema magnitude is mandatory |
1.0 |
NULL |
openehr::122 (length) |
NULL |
rejected |
RM/Schema untis is mandatory |
0.0 |
mg |
openehr::122 (length) |
NULL |
rejected |
C_DV_QUANTITY.property: |
0.0 |
cm |
openehr::122 (length) |
NULL |
accepted |
|
1.0 |
cm |
openehr::122 (length) |
NULL |
accepted |
|
5.7 |
cm |
openehr::122 (length) |
NULL |
accepted |
|
10.0 |
cm |
openehr::122 (length) |
NULL |
accepted |
14.9.4.3. Test Case CONT-DV_QUANTITY-validate_property_units
magnitude | units | C_DV_QUANTITY.property | C_DV_QUANTITY.list | expected | constraints violated |
---|---|---|---|---|---|
NULL |
NULL |
openehr::122 (length) |
[cm, m] |
rejected |
RM/Schema both magnitude and untis are mandatory |
NULL |
cm |
openehr::122 (length) |
[cm, m] |
rejected |
RM/Schema magnitude is mandatory |
1.0 |
NULL |
openehr::122 (length) |
[cm, m] |
rejected |
RM/Schema untis is mandatory |
0.0 |
mg |
openehr::122 (length) |
[cm, m] |
rejected |
C_DV_QUANTITY.property: |
0.0 |
cm |
openehr::122 (length) |
[cm, m] |
accepted |
|
0.0 |
km |
openehr::122 (length) |
[cm, m] |
rejected |
C_DV_QUANTITY.list: |
1.0 |
cm |
openehr::122 (length) |
[cm, m] |
accepted |
|
5.7 |
cm |
openehr::122 (length) |
[cm, m] |
accepted |
|
10.0 |
cm |
openehr::122 (length) |
[cm, m] |
accepted |
14.9.4.4. Test Case CONT-DV_QUANTITY-validate_property_units_mag
magnitude | units | C_DV_QUANTITY.property | C_DV_QUANTITY.list | expected | constraints violated |
---|---|---|---|---|---|
NULL |
NULL |
openehr::122 (length) |
[cm 5.0..10.0, m] |
rejected |
RM/Schema both magnitude and untis are mandatory |
NULL |
cm |
openehr::122 (length) |
[cm 5.0..10.0, m] |
rejected |
RM/Schema magnitude is mandatory |
1.0 |
NULL |
openehr::122 (length) |
[cm 5.0..10.0, m] |
rejected |
RM/Schema untis is mandatory |
0.0 |
mg |
openehr::122 (length) |
[cm 5.0..10.0, m] |
rejected |
C_DV_QUANTITY.property: |
0.0 |
cm |
openehr::122 (length) |
[cm 5.0..10.0, m] |
rejected |
C_DV_QUANTITY.list: magnitude not in range for unit |
0.0 |
km |
openehr::122 (length) |
[cm 5.0..10.0, m] |
rejected |
C_DV_QUANTITY.list: |
1.0 |
cm |
openehr::122 (length) |
[cm 5.0..10.0, m] |
rejected |
C_DV_QUANTITY.list: magnitude not in range for unit |
5.7 |
cm |
openehr::122 (length) |
[cm 5.0..10.0, m] |
accepted |
|
10.0 |
cm |
openehr::122 (length) |
[cm 5.0..10.0, m] |
accepted |
14.9.5. DV_PROPORTION
The DV_PROPORTION is contrained by a C_COMPLEX_OBJECT, which internally has C_REAL constraints for numerator
and denominator
. C_REAL defines two types of constraints: range and list of values. Though current modeling tools only allow range contraints. For the type
atribute, a C_INTEGER constraint is used, which can hold list and range constraints but modeling tools only use the list.
This type has intrinsic constraints that should be semantically consistent depending on the value of the numerator, denominator, precision and type attributes. For instance, this if type = 2, the denominator value should be 100 and can’t be anything else. In te table below we express the valid combinations of attribute values.
type | meaning (kind) | numerator | denominator | precision | comment |
---|---|---|---|---|---|
0 |
ratio |
any |
any != 0 |
any |
|
1 |
unitary |
any |
1 |
any |
|
2 |
percent |
any |
100 |
any |
|
3 |
fraction |
integer |
integer != 0 |
0 |
presentation is num/den |
4 |
integer fraction |
integer |
integer != 0 |
0 |
presentation is integral(num/den) decimal(num/den), e.g. for num=3 den=2: 1 1/2 |
Note
|
the difference between fraction and integer fraction is the presentation, the data and constraints are the same. |
14.9.5.1. Test Case CONT-DV_PROPORTION-validate_open
This test case is used to check the internal rules of the DV_PROPORTION are correctly implemented by the SUT.
type | meaning (kind) | numerator | denominator | precision | expected | constraints violated |
---|---|---|---|---|---|---|
0 |
ratio |
10 |
500 |
0 |
accepted |
|
0 |
ratio |
10 |
0 |
0 |
rejected |
valid_denominator (invariant) |
1 |
unitary |
10 |
1 |
0 |
accepted |
|
1 |
unitary |
10 |
0 |
0 |
rejected |
valid_denominator (invariant) |
1 |
unitary |
10 |
500 |
0 |
rejected |
unitary_validity (invariant) |
2 |
percent |
10 |
0 |
0 |
rejected |
valid_denominator (invariant) |
2 |
percent |
10 |
100 |
0 |
accepted |
|
2 |
percent |
10 |
500 |
0 |
rejected |
percent_validity (invariant) |
3 |
fraction |
10 |
0 |
0 |
rejected |
valid_denominator (invariant) |
3 |
fraction |
10 |
100 |
0 |
accepted |
|
3 |
fraction |
10 |
500 |
1 |
rejected |
fraction_validity (invariant) |
3 |
fraction |
10.5 |
500 |
1 |
rejected |
is_integral_validity (invariant) |
3 |
fraction |
10 |
500.5 |
1 |
rejected |
is_integral_validity (invariant) |
4 |
integer fraction |
10 |
0 |
0 |
rejected |
valid_denominator (invariant) |
4 |
integer fraction |
10 |
100 |
0 |
accepted |
|
4 |
integer fraction |
10 |
500 |
1 |
rejected |
fraction_validity (invariant) |
4 |
integer fraction |
10.5 |
500 |
1 |
rejected |
is_integral_validity (invariant) |
4 |
integer fraction |
10 |
500.5 |
1 |
rejected |
is_integral_validity (invariant) |
666 |
10 |
500 |
0 |
rejected |
type_validity (invariant) |
14.9.5.2. Test Case CONT-DV_PROPORTION-validate_ratio
The C_INTEGER constraint applies to the type
attribute.
type | meaning (kind) | numerator | denominator | precision | C_INTEGER.list | expected | constraints violated |
---|---|---|---|---|---|---|---|
0 |
ratio |
10 |
500 |
0 |
[0] |
accepted |
|
1 |
unitary |
10 |
1 |
0 |
[0] |
rejected |
C_INTEGER.list |
2 |
percent |
10 |
100 |
0 |
[0] |
rejected |
C_INTEGER.list |
3 |
fraction |
10 |
500 |
0 |
[0] |
rejected |
C_INTEGER.list |
4 |
integer fraction |
10 |
500 |
0 |
[0] |
rejected |
C_INTEGER.list |
Note
|
all the fail cases related with invariants were already contemplated in 3.6.1. |
14.9.5.3. Test Case CONT-DV_PROPORTION-validate_unitary
The C_INTEGER constraint applies to the type
attribute.
type | meaning (kind) | numerator | denominator | precision | C_INTEGER.list | expected | constraints violated |
---|---|---|---|---|---|---|---|
0 |
ratio |
10 |
500 |
0 |
[1] |
reejcted |
C_INTEGER.list |
1 |
unitary |
10 |
1 |
0 |
[1] |
accepted |
|
2 |
percent |
10 |
100 |
0 |
[1] |
rejected |
C_INTEGER.list |
3 |
fraction |
10 |
500 |
0 |
[1] |
rejected |
C_INTEGER.list |
4 |
integer fraction |
10 |
500 |
0 |
[1] |
rejected |
C_INTEGER.list |
14.9.5.4. Test Case CONT-DV_PROPORTION-validate_percent
The C_INTEGER constraint applies to the type
attribute.
type | meaning (kind) | numerator | denominator | precision | C_INTEGER.list | expected | constraints violated |
---|---|---|---|---|---|---|---|
0 |
ratio |
10 |
500 |
0 |
[2] |
reejcted |
C_INTEGER.list |
1 |
unitary |
10 |
1 |
0 |
[2] |
rejected |
C_INTEGER.list |
2 |
percent |
10 |
100 |
0 |
[2] |
accepted |
|
3 |
fraction |
10 |
500 |
0 |
[2] |
rejected |
C_INTEGER.list |
4 |
integer fraction |
10 |
500 |
0 |
[2] |
rejected |
C_INTEGER.list |
14.9.5.5. Test Case CONT-DV_PROPORTION-validate_fraction
The C_INTEGER constraint applies to the type
attribute.
| type | meaning (kind) | numerator | denominator | precision | C_INTEGER.list | expected | constraints violated
0 | ratio | 10 | 500 | 0 | [3] | rejected | C_INTEGER.list |
---|---|---|---|---|---|---|---|
1 |
unitary |
10 |
1 |
0 |
[3] |
rejected |
C_INTEGER.list |
2 |
percent |
10 |
100 |
0 |
[3] |
rejected |
C_INTEGER.list |
3 |
fraction |
10 |
500 |
0 |
[3] |
accepted |
|
4 |
integer fraction |
10 |
500 |
0 |
[3] |
rejected |
C_INTEGER.list |
14.9.5.6. Test Case CONT-DV_PROPORTION-validate_integer_fraction
The C_INTEGER constraint applies to the type
attribute.
type | meaning (kind) | numerator | denominator | precision | C_INTEGER.list | expected | constraints violated |
---|---|---|---|---|---|---|---|
0 |
ratio |
10 |
500 |
0 |
[4] |
reejcted |
C_INTEGER.list |
1 |
unitary |
10 |
1 |
0 |
[4] |
rejected |
C_INTEGER.list |
2 |
percent |
10 |
100 |
0 |
[4] |
rejected |
C_INTEGER.list |
3 |
fraction |
10 |
500 |
0 |
[4] |
rejected |
C_INTEGER.list |
4 |
integer fraction |
10 |
500 |
0 |
[4] |
accepted |
14.9.5.7. Test Case CONT-DV_PROPORTION-validate_any_fraction
This case is similar to the previous one, it just tests a combination of possible types for the proportion.
type | meaning (kind) | numerator | denominator | precision | C_INTEGER.list | expected | constraints violated |
---|---|---|---|---|---|---|---|
0 |
ratio |
10 |
500 |
0 |
[3, 4] |
reejcted |
C_INTEGER.list |
1 |
unitary |
10 |
1 |
0 |
[3, 4] |
rejected |
C_INTEGER.list |
2 |
percent |
10 |
100 |
0 |
[3, 4] |
rejected |
C_INTEGER.list |
3 |
fraction |
10 |
500 |
0 |
[3, 4] |
accepted |
|
4 |
integer fraction |
10 |
500 |
0 |
[3, 4] |
accepted |
14.9.5.8. Test Case CONT-DV_PROPORTION-validate_ratio_range
The C_INTEGER constraint applies to the type
attribute. The C_REAL constraints apply to numerator and denominator respectively.
type | meaning (kind) | numerator | denominator | precision | C_INTEGER.list | C_REAL.range (num) | C_REAL.range (den) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|
0 |
ratio |
10 |
500 |
0 |
[0] |
5..20 |
200..600 |
accepted |
|
0 |
ratio |
10 |
1 |
0 |
[0] |
5..20 |
200..600 |
rejected |
C_REAL.range (den) |
0 |
ratio |
30 |
500 |
0 |
[0] |
5..20 |
200..600 |
rejected |
C_REAL.range (num) |
0 |
ratio |
3 |
1000 |
0 |
[0] |
5..20 |
200..600 |
rejected |
C_REAL.range (num), C_REAL.range (den) |
14.9.6. DV_INTERVAL<DV_COUNT>
14.9.6.1. Test Case CONT-DV_INTERVAL_DV_COUNT-validate_open
The DV_INTERVAL<DV_COUNT> constraint is {*}.
Note
|
the failure instance for this test case are related with violated interval semantics. |
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | expected | constraints violated |
---|---|---|---|---|---|---|---|
NULL |
NULL |
true |
true |
false |
false |
accepted |
|
NULL |
100 |
true |
false |
false |
false |
accepted |
|
NULL |
100 |
true |
false |
false |
true |
accepted |
|
0 |
NULL |
false |
true |
false |
false |
accepted |
|
0 |
NULL |
false |
true |
true |
false |
accepted |
|
-20 |
-5 |
false |
false |
false |
false |
accepted |
|
0 |
100 |
false |
false |
true |
true |
accepted |
|
10 |
100 |
false |
false |
true |
true |
accepted |
|
-50 |
50 |
false |
false |
true |
true |
accepted |
|
NULL |
NULL |
true |
true |
true |
false |
rejected |
lower_included_valid (invariant) |
0 |
NULL |
false |
true |
false |
true |
rejected |
upper_included_valid (invariant) |
200 |
100 |
false |
false |
true |
true |
rejected |
limits_consistent (invariant) |
14.9.6.2. Test Case CONT-DV_INTERVAL_DV_COUNT-validate_lower_upper
Lower and upper are DV_COUNT, which are constrainted internally by C_INTEGER. C_INTEGER has range and list constraints.
Note
|
the lower and upper limits are not constrained in terms of existence or occurrences, so both are optional. |
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | C_INTEGER.range (lower) | C_INTEGER.range (upper) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|
NULL |
NULL |
true |
true |
false |
false |
0..100 |
0..100 |
accepted |
|
0 |
NULL |
false |
true |
true |
false |
0..100 |
0..100 |
accepted |
|
NULL |
100 |
true |
false |
false |
true |
0..100 |
0..100 |
accepted |
|
0 |
100 |
false |
false |
true |
true |
0..100 |
0..100 |
accepted |
|
-10 |
100 |
false |
false |
true |
true |
0..100 |
0..100 |
rejected |
C_INTEGER.range (lower) |
0 |
200 |
false |
false |
true |
true |
0..100 |
0..100 |
rejected |
C_INTEGER.range (upper) |
-10 |
200 |
false |
false |
true |
true |
0..100 |
0..100 |
rejected |
C_INTEGER.range (lower), C_INTEGER.range (upper) |
14.9.6.3. Test Case CONT-DV_INTERVAL_DV_COUNT-validate_lower_upper_list
Lower and upper are DV_COUNT, which are constrainted internally by C_INTEGER. C_INTEGER has range and list constraints.
Note
|
not all modeling tools allow a list constraint for the lower and upper attributes of the DV_INTERVAL. |
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | C_INTEGER.list (lower) | C_INTEGER.list (upper) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|
NULL |
NULL |
true |
true |
false |
false |
[0, 5, 10, 100] |
[0, 5, 10, 100] |
accepted |
|
0 |
NULL |
false |
true |
true |
false |
[0, 5, 10, 100] |
[0, 5, 10, 100] |
accepted |
|
NULL |
100 |
true |
false |
false |
true |
[0, 5, 10, 100] |
[0, 5, 10, 100] |
accepted |
|
0 |
100 |
false |
false |
true |
true |
[0, 5, 10, 100] |
[0, 5, 10, 100] |
accepted |
|
-10 |
100 |
false |
false |
true |
true |
[0, 5, 10, 100] |
[0, 5, 10, 100] |
rejected |
C_INTEGER.list (lower) |
0 |
200 |
false |
false |
true |
true |
[0, 5, 10, 100] |
[0, 5, 10, 100] |
rejected |
C_INTEGER.list (upper) |
-10 |
200 |
false |
false |
true |
true |
[0, 5, 10, 100] |
[0, 5, 10, 100] |
rejected |
C_INTEGER.list (lower), C_INTEGER.list (upper) |
14.9.7. DV_INTERVAL<DV_QUANTITY>
14.9.7.1. Test Case CONT-DV_INTERVAL_DV_QUANTITY-validate_open
The DV_INTERVAL<DV_QUANTITY> constraint is {*}.
Note
|
the failure instance for this test case are related with violated interval semantics. |
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | expected | constraints violated |
---|---|---|---|---|---|---|---|
NULL |
NULL |
true |
true |
false |
false |
accepted |
|
NULL |
100 mg |
true |
false |
false |
false |
accepted |
|
NULL |
100 mg |
true |
false |
false |
true |
accepted |
|
0 mg |
NULL |
false |
true |
false |
false |
accepted |
|
0 mg |
NULL |
false |
true |
true |
false |
accepted |
|
0 mg |
100 mg |
false |
false |
true |
true |
accepted |
|
10 mg |
100 mg |
false |
false |
true |
true |
accepted |
|
NULL |
NULL |
true |
true |
true |
false |
rejected |
lower_included_valid (invariant) |
0 mg |
NULL |
false |
true |
false |
true |
rejected |
upper_included_valid (invariant) |
200 mg |
100 mg |
false |
false |
true |
true |
rejected |
limits_consistent (invariant) |
14.9.7.2. Test Case CONT-DV_INTERVAL_DV_QUANTITY-validate_upper_lower
The lower and upper constraints are C_DV_QUANTITY.
Note
|
in all cases the C_DV_QUANTITY.property referes to temperature to keep tests as simple as possible and be able to use negative values (for other physical properties negative values don’t make sense). All temperatures will be measured in degree Celsius (Cel in UCUM).
|
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | C_DV_QUANTITY.list (lower) | C_DV_QUANTITY.list (upper) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|
NULL |
NULL |
true |
true |
false |
false |
[0..100 Cel] |
[0..100 Cel] |
accepted |
|
0 Cel |
NULL |
false |
true |
true |
false |
[0..100 Cel] |
[0..100 Cel] |
accepted |
|
NULL |
100 Cel |
true |
false |
false |
true |
[0..100 Cel] |
[0..100 Cel] |
accepted |
|
0 Cel |
100 Cel |
false |
false |
true |
true |
[0..100 Cel] |
[0..100 Cel] |
accepted |
|
-10 Cel |
100 Cel |
false |
false |
true |
true |
[0..100 Cel] |
[0..100 Cel] |
rejected |
C_DV_QUANTITY (lower) |
0 Cel |
200 Cel |
false |
false |
true |
true |
[0..100 Cel] |
[0..100 Cel] |
rejected |
C_DV_QUANTITY (upper) |
-10 Cel |
200 Cel |
false |
false |
true |
true |
[0..100 Cel] |
[0..100 Cel] |
rejected |
C_DV_QUANTITY (lower),C_DV_QUANTITY (upper) |
14.9.8. DV_INTERVAL<DV_DATE_TIME>
14.9.8.1. Test Case CONT-DV_INTERVAL_DV_DATE_TIME-validate_open
The DV_INTERVAL<DV_DATE_TIME> constraint is {*}.
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | expected | constraints violated |
---|---|---|---|---|---|---|---|
NULL |
NULL |
false |
false |
true |
true |
rejected |
RM/Schema: value is mandatory for lower and upper |
NULL |
"" |
false |
false |
true |
true |
rejected |
RM/Schema: value is mandatory for lower. ISO8601: at least year is required for upper. |
"" |
NULL |
false |
false |
true |
true |
rejected |
ISO8601: at least year is required for lower. RM/Schema: value is mandatory for upper. |
2021 |
NULL |
false |
false |
true |
true |
rejected |
RM/Schema: value is mandatory for upper. |
NULL |
2022 |
false |
false |
true |
true |
rejected |
RM/Schema: value is mandatory for lower. |
2021 |
2022 |
false |
false |
true |
true |
accepted |
|
2021-00 |
2022-01 |
false |
false |
true |
true |
rejected |
ISO8601: month in 01..12 for lower. |
2021-01 |
2022-01 |
false |
false |
true |
true |
accepted |
|
2021-01-00 |
2022-01-01 |
false |
false |
true |
true |
rejected |
ISO8601: day in 01..31 for lower. |
2021-01-32 |
2022-01-01 |
false |
false |
true |
true |
rejected |
ISO8601: day in 01..31 for lower. |
2021-01-01 |
2022-01-00 |
false |
false |
true |
true |
rejected |
ISO8601: day in 01..31 for upper. |
2021-01-30 |
2022-01-00 |
false |
false |
true |
true |
rejected |
ISO8601: day in 01..31 for upper. |
2021-01-30 |
2022-01-15 |
false |
false |
true |
true |
accepted |
|
2021-10-24T48 |
2022-01-15T10 |
false |
false |
true |
true |
rejected |
ISO8601: hours in 00..23 for lower. |
2021-10-24T21 |
2022-01-15T73 |
false |
false |
true |
true |
rejected |
ISO8601: hours in 00..23 for upper. |
2021-10-24T05 |
2022-01-15T10 |
false |
false |
true |
true |
accepted |
|
2021-10-24T05:95 |
2022-01-15T10:45 |
false |
false |
true |
true |
rejected |
ISO8601: minutes in 00..59 for lower. |
2021-10-24T05:30 |
2022-01-15T10:61 |
false |
false |
true |
true |
rejected |
ISO8601: minutes in 00..59 for upper. |
2021-10-24T05:30 |
2022-01-15T10:45 |
false |
false |
true |
true |
accepted |
|
2021-10-24T05:30:78 |
2022-01-15T10:45:13 |
false |
false |
true |
true |
rejected |
ISO8601: seconds in 00..59 for lower. |
2021-10-24T05:30:47 |
2022-01-15T10:45:69 |
false |
false |
true |
true |
rejected |
ISO8601: seconds in 00..59 for upper. |
2021-10-24T05:30:47 |
2022-01-15T10:45:13 |
false |
false |
true |
true |
accepted |
|
2021-10-24T05:30:47.5 |
2022-01-15T10:45:13.6 |
false |
false |
true |
true |
accepted |
|
2021-10-24T05:30:47.333 |
2022-01-15T10:45:13.555 |
false |
false |
true |
true |
accepted |
|
2021-10-24T05:30:47.333333 |
2022-01-15T10:45:13.555555 |
false |
false |
true |
true |
accepted |
|
2021-10-24T05:30:47Z |
2022-01-15T10:45:13Z |
false |
false |
true |
true |
accepted |
|
2021-10-24T05:30:47-03:00 |
2022-01-15T10:45:13-03:00 |
false |
false |
true |
true |
accepted |
14.9.8.2. Test Case CONT-DV_INTERVAL_DV_DATE_TIME-validate_lower_upper_constraint
Note
|
the C_DATE_TIME has invariants that define if a higher precision component is optional or prohibited, lower precision components should be optional or prohibited. In other words, if month is optional, day , hours , minutes , etc. are optional or prohibited. These invariants should be checked in an archetype editor and template editor, we consider the following tests to follow those rules without checking them, since that is related to archetype/template validation, not with data validation.
|
Note
|
if different components of each lower/upper date time expression fail the validity constraint for mandatory , the only required contraint violated to be reported is the higher precision one, since it implies the lower precision components will also fail. For instance if the hour, second and millisecond are mandatory , and the corresponding date time expression doesn’t have hour, it is accepted if the reported constraints violated is only the hour_validity, and optionally the SUT can report the minute_validity, second_validity and millisecond_validity constraints as violated too. In the data sets below we show all the constraints violated.
|
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | month_val. (lower) | day_val. (lower) | month_val. (upper) | day_val. (upper) | hour_val. (lower) | minute_val. (lower) | second_val. (lower) | millisecond_val. (lower) | timezone_val. (lower) | hour_val. (upper) | minute_val. (upper) | second_val. (upper) | millisecond_val. (upper) | timezone_val. (upper) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2021 |
2022 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
rejected |
month_val. (lower), day_val. (lower), month_val. (upper), day_val. (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), second_val. (lower), second_val. (upper), millisecond_val. (lower), millisecond_val. (upper), timezone_val. (lower), timezone__val. (upper) |
2021 |
2022 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
month_validity (lower), month_validity (upper), timezone_val. (lower), timezone__val. (upper) |
2021 |
2022 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
rejected |
month_validity (lower), month_validity (upper) |
2021 |
2022 |
false |
false |
true |
true |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021 |
2022 |
false |
false |
true |
true |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
accepted |
|
2021 |
2022 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
mandatory |
rejected |
month_validity (lower), month_validity (upper), timezone_val. (lower), timezone__val. (upper) |
2021 |
2022 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
month_validity (lower), month_validity (upper) |
2021 |
2022 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021 |
2022 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
accepted |
|
2021-10 |
2022-10 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
rejected |
day_validity (lower), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), second_val. (lower), second_val. (upper), millisecond_val. (lower), millisecond_val. (upper), timezone_val. (lower), timezone__val. (upper) |
2021-10 |
2022-10 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone_val. (upper) |
2021-10 |
2022-10 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
accepted |
|
2021-10 |
2022-10 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
mandatory |
mandatory |
rejected |
timezone_val. (lower), timezone_val. (upper) |
2021-10 |
2022-10 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
accepted |
|
2021-10 |
2022-10 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
mandatory |
rejected |
month_validity (lower), month_validity (upper), timezone_val. (lower), timezone_val. (upper) |
2021-10 |
2022-10 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
month_validity (lower), month_validity (upper) |
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | month_val. (lower) | day_val. (lower) | month_val. (upper) | day_val. (upper) | hour_val. (lower) | minute_val. (lower) | second_val. (lower) | millisecond_val. (lower) | timezone_val. (lower) | hour_val. (upper) | minute_val. (upper) | second_val. (upper) | millisecond_val. (upper) | timezone_val. (upper) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2021-10-24 |
2022-10-24 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
rejected |
hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), second_val. (lower), second_val. (upper), millisecond_val. (lower), millisecond_val. (upper), timezone_val. (lower), timezone_val. (upper) |
2021-10-24 |
2022-10-24 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
rejected |
hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), timezone_val. (lower), timezone_val. (upper) |
2021-10-24 |
2022-10-24 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
rejected |
hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper) |
2021-10-24 |
2022-10-24 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24 |
2022-10-24 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24 |
2022-10-24 |
false |
false |
true |
true |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24 |
2022-10-24 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
day_validity (lower), day_validity (upper) |
2021-10-24 |
2022-10-24 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
month_validity (lower), day_validity (lower), month_validity (upper), day_validity (upper) |
2021-10-24T22 |
2022-10-24T07 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
rejected |
minute_val. (lower), minute_val. (upper), second_val. (lower), second_val. (upper), millisecond_val. (lower), millisecond_val. (upper), timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22 |
2022-10-24T07 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
rejected |
minute_val. (lower), minute_val. (upper), timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22 |
2022-10-24T07 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
rejected |
minute_val. (lower), minute_val. (upper) |
2021-10-24T22 |
2022-10-24T07 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24T22 |
2022-10-24T07 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22 |
2022-10-24T07 |
false |
false |
true |
true |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24T22 |
2022-10-24T07 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
day_validity (lower), day_validity (upper), hour_val. (lower), hour_val. (upper) |
2021-10-24T22 |
2022-10-24T07 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
month_validity (lower), day_validity (lower), month_validity (upper), day_validity (upper), hour_val. (lower), hour_val. (upper) |
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | month_val. (lower) | day_val. (lower) | month_val. (upper) | day_val. (upper) | hour_val. (lower) | minute_val. (lower) | second_val. (lower) | millisecond_val. (lower) | timezone_val. (lower) | hour_val. (upper) | minute_val. (upper) | second_val. (upper) | millisecond_val. (upper) | timezone_val. (upper) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2021-10-24T22:10 |
2022-10-24T07:47 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
rejected |
second_val. (lower), second_val. (upper), millisecond_val. (lower), millisecond_val. (upper), timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22:10 |
2022-10-24T07:47 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22:10 |
2022-10-24T07:47 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22:10 |
2022-10-24T07:47 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24T22:10 |
2022-10-24T07:47 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22:10 |
2022-10-24T07:47 |
false |
false |
true |
true |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24T22:10 |
2022-10-24T07:47 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
day_validity (lower), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper) |
2021-10-24T22:10 |
2022-10-24T07:47 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
month_validity (lower), day_validity (lower), month_validity (upper), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper) |
2021-10-24T22:10:45 |
2022-10-24T07:47:13 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
rejected |
millisecond_val. (lower), millisecond_val. (upper), timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22:10:45 |
2022-10-24T07:47:13 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22:10:45 |
2022-10-24T07:47:13 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22:10:45 |
2022-10-24T07:47:13 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24T22:10:45 |
2022-10-24T07:47:13 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22:10:45 |
2022-10-24T07:47:13 |
false |
false |
true |
true |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24T22:10:45 |
2022-10-24T07:47:13 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
day_validity (lower), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), second_val. (lower), second_val. (upper) |
2021-10-24T22:10:45 |
2022-10-24T07:47:13 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
month_validity (lower), day_validity (lower), month_validity (upper), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), second_val. (lower), second_val. (upper) |
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | month_val. (lower) | day_val. (lower) | month_val. (upper) | day_val. (upper) | hour_val. (lower) | minute_val. (lower) | second_val. (lower) | millisecond_val. (lower) | timezone_val. (lower) | hour_val. (upper) | minute_val. (upper) | second_val. (upper) | millisecond_val. (upper) | timezone_val. (upper) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2021-10-24T22:10:45.5 |
2022-10-24T07:47:13.666666 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
rejected |
timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22:10:45.5 |
2022-10-24T07:47:13.666666 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22:10:45.5 |
2022-10-24T07:47:13.666666 |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22:10:45.5 |
2022-10-24T07:47:13.666666 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24T22:10:45.5 |
2022-10-24T07:47:13.666666 |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22:10:45.5 |
2022-10-24T07:47:13.666666 |
false |
false |
true |
true |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
rejected |
timezone_val. (lower), timezone__val. (upper) |
2021-10-24T22:10:45.5 |
2022-10-24T07:47:13.666666 |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
day_validity (lower), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), seoncd_val. (lower), second_val. (upper), millisecond_val. (lower), millisecond_val. (upper) |
2021-10-24T22:10:45.5 |
2022-10-24T07:47:13.666666 |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
month_validity (lower), day_validity (lower), month_validity (upper), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), seoncd_val. (lower), second_val. (upper), millisecond_val. (lower), millisecond_val. (upper) |
2021-10-24T22:10:45Z |
2022-10-24T07:47:13Z |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
rejected |
millisecond_val. (lower), millisecond_val. (upper) |
2021-10-24T22:10:45Z |
2022-10-24T07:47:13Z |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
accepted |
|
2021-10-24T22:10:45Z |
2022-10-24T07:47:13Z |
false |
false |
true |
true |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
mandatory |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22:10:45Z |
2022-10-24T07:47:13Z |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
accepted |
|
2021-10-24T22:10:45Z |
2022-10-24T07:47:13Z |
false |
false |
true |
true |
mandatory |
optional |
mandatory |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
accepted |
|
2021-10-24T22:10:45Z |
2022-10-24T07:47:13Z |
false |
false |
true |
true |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
optional |
mandatory |
optional |
optional |
optional |
optional |
mandatory |
accepted |
|
2021-10-24T22:10:45Z |
2022-10-24T07:47:13Z |
false |
false |
true |
true |
mandatory |
prohibited |
mandatory |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
day_validity (lower), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), second_val. (lower), second_val. (upper), timezone_val. (lower), timezone_val. (upper) |
2021-10-24T22:10:45Z |
2022-10-24T07:47:13Z |
false |
false |
true |
true |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
prohibited |
rejected |
month_validity (lower), day_validity (lower), month_validity (upper), day_validity (upper), hour_val. (lower), hour_val. (upper), minute_val. (lower), minute_val. (upper), second_val. (lower), second_val. (upper), timezone_val. (lower), timezone_val. (upper) |
14.9.8.3. Test Case CONT-DV_INTERVAL_DV_DATE_TIME-validate_lower_upper_range
lower | upper | lower_unbounded | upper_unbounded | lower_included | upper_included | C_DATE_TIME.range (lower) | C_DATE_TIME.range (upper) | expected | constraints violated |
---|---|---|---|---|---|---|---|---|---|
2021 |
2022 |
false |
false |
true |
true |
2020..2030 |
2020..2030 |
accepted |
|
2021 |
2022 |
false |
false |
true |
true |
2000..2010 |
2020..2030 |
rejected |
C_DATE_TIME.range (lower) |
2021 |
2022 |
false |
false |
true |
true |
2020..2030 |
2020..2021 |
rejected |
C_DATE_TIME.range (upper) |
2021-10 |
2022-11 |
false |
false |
true |
true |
2020-01..2030-12 |
2020-01..2030-12 |
accepted |
|
2021-10 |
2022-11 |
false |
false |
true |
true |
2000-01..2010-12 |
2020-01..2030-12 |
rejected |
C_DATE_TIME.range (lower) |
2021-10 |
2022-11 |
false |
false |
true |
true |
2020-01..2030-12 |
2020-01..2021-12 |
rejected |
C_DATE_TIME.range (upper) |
2021-10-24 |
2022-11-02 |
false |
false |
true |
true |
2020-01-01..2030-12-31 |
2020-01-01..2030-12-31 |
accepted |
|
2021-10-24 |
2022-11-02 |
false |
false |
true |
true |
2000-01-01..2010-12-31 |
2020-01-01..2030-12-31 |
rejected |
C_DATE_TIME.range (lower) |
2021-10-24 |
2022-11-02 |
false |
false |
true |
true |
2020-01-01..2030-12-31 |
2020-01-01..2021-12-31 |
rejected |
C_DATE_TIME.range (upper) |
2021-10-24T10 |
2022-11-02T19 |
false |
false |
true |
true |
2020-01-01T00..2030-12-31T23 |
2020-01-01T00..2030-12-31T23 |