Request with only BUSINESS_RULE violation not persisted

[RasmusThernoe]

The issue is blocking or Bug in the central solution.

According to https://scandihealth.github.io/lpr3-docs/aspects/index.html#service-endpoint-setup:

"If the submission contains no errors on level 1, level 2 and level 3 the reporting is stored for further processing".

When using the service endpoint https://lprws-test.sds.dsdn.dk/cda-ws/DocumentRepository_Service/PatientHealthcareReportingService.

We get a response with only one BUSINESS_RULE but our request is not stored:

BUSINESS_RULE|||parentDocument extension X must be same as extension of latest document in the set

We get the error because we "break the document chain". We are appending to the ClinicalDocument.id send in version 1 when reporting version 3 - but should have appended to ClinicalDocument.id in version 2. This could happen in a production setup.

Requests.zip

It is very critical that requests with business rule violations get persisted since reporters - according to the interface guide - must refer to the latest persisted document in LPR3.

[RolandPedersenSSE]

Another example is when we try to report an episode of care with an "Internal Episode Of Care Reference" to an episode of care that has not been reported yet. In that case we get a buniness rule error but nothing is persisted:

BUSINESS_RULE|||Internal Episode of Care 6dfb85f2-7109-40fd-9c18-f240ad07920d not found|||INTERNAL_EOC_NOT_FOUND|||6dfb85f2-7109-40fd-9c18-f240ad07920d"

It is very important for us that episode of cares can be persisted even though they refer to not yet reported episode of cares.

[jkiddo]

@RasmusThernoe total order of documents must be maintained

[jkiddo]

@RolandPedersenSSE you cannot refer to future episode of care with the exemption of episode of care elements that are external to the reporting authority i.e. episode of care links communicated through referrals.

[RasmusThernoe]

@jkiddo We know - that is not the problem.

The problem is that requests with only business rules violations are not persisted in LPR3 - the interface guide states that they should be.

It is a very important assumption in our solution that LPR3 persists the request if only business rules are returned.

[jonigkeit]

The exception is hard business error, i.e. those that would be integrity_check error when the integrity check header is set. See #33.

[jonigkeit]

We recommend setting the header: https://github.com/scandihealth/lpr3-docs/blob/master/src/interface/wsdl/ihe-xdr.wsdl#L157

[RasmusThernoe]

...but the interface documentation states:

All documents submitted to LPR3 are validated at the following levels:

1. Execute schema validation (XSD) according to CDA R2 standard
2. Execute schematron validation (SHCEMATRON) according to the profile specificed at the ART-DECOR site
3. Execute data coherency/conformity validation (INTEGRITY_CHECK)
4. Execute drools validation rules AKA business rules (BUSINESS_RULE)

...and it continues:

If the submission contains no errors on level 1, level 2 and level 3 the reporting is stored for further processing.

Hence level 4 (BUSINESS_RULE) must be persisted.

The header is optional.

[RasmusThernoe]

Is this correct?

Option 1: The optional header of integrity check is used - then it is guaranteed that requests that only returns business rule violations are always persisted?

Option 2: The optional header of integrity check is not used - then requests that only returns business rule violations are sometimes persisted and sometimes not persisted?

I cannot find the behaviour of the second option described in the interface guide.

[jkiddo]

Submissions that do not pass level 1, level 2 and level 3 are not persisted as stated in https://scandihealth.github.io/lpr3-docs/aspects/index.html#service-endpoint-setup - regardless of using the header or not. The errors that are listed in this issue "INTERNAL_EOC_NOT_FOUND" and "PARENT_DOCUMENT_ID_MISMATCH" are found on level 3.

[RasmusThernoe]

Level 3 is by default labeled as BUSINESS_RULE violation - as stated in https://scandihealth.github.io/lpr3-docs/aspects/index.html#using-optional-soap-header-to-specify-integrity-error-format:

Errors found at level 3 are by default reported on the BUSINESS_RULE format

So it is expected behaviour that requests that result in a response labeled only with BUSINESS_RULE violations might not be persisted?

Prior to introducing the integrity check I believe the service always persisted a response labeled only with BUSINESS_RULE violations.

[jkiddo]

if the error code is found in the range of https://scandihealth.github.io/lpr3-docs/aspects/index.html#data-integrity-rules it will not be persisted. Those are what @jonigkeit refers to as 'hard business error'.

[RasmusThernoe]

To conclude if reporters are using the optional header then a response labeled with BUSINESS_RULE are always persisted?

I was not aware of the distinction between 'business error' and 'hard business error'.

[jkiddo]

When using the service endpoint named PatientHealthcareReportingService (

supporting the asynchronous scenario that does validation on level 1, level 2 and level 3. If the submission contains no errors on level 1, level 2 and level 3 the reporting is stored for further processing. If errors are found at level 4, the error report is available at the prior-to-submission designated folder

), yes.

[RasmusThernoe]

Thank you.