Relaxing cardinality on component

[cjonigkeit-csc]

From: #26

Would it be possible to relax the 1...1 cardinality on the ClinicalDocument/component element to be 0...1, since it may be desirable to send a document using RPLC without that component as a method of getting rid of all resources that were sent in a previous version of the document (rather than nullifying each of the sections that previously appeared in that document.) I think previous versions of art-décor specification used 0...1, and the change to 1...1 involves rethinking the design of some edge case situations on our side.

[cjonigkeit-csc]

Hi @DaveSS, We will put your request through the change management process, but expect no timely clarification as the process is somewhat cumbersome.

[DaveSS]

I appreciate you following up with this issue.. And please note that this was at some point a 0...1 constraint and then it was changed to be 1...1 during a recent update to art-décor. We had assumed the 0 ...1 option when designing our approach to LPR3 development and it was the recent switch to 1...1 that we are looking to revert back to its previous state. Should I just request an update about this issue after a few weeks, or will you be keeping this issue open and updating changes here when you get clarification from the change management process?

[jonigkeit]

We will update this issue as it progresses through the change management process.

[cjonigkeit-csc]

The reason for the change is that ClinicalDocument in POCD_MT000040.xsd actually requires a component. It is required but not mandatory so you can null flavor it.

[DaveSS]

The schematron doesn't allow the component to be nullFlavor. It seems to treat the component as mandatory. This is what I get when trying to send a nullFlavor for the ClinicalDocument/component:

System ID: C:\LPR3 Test Files\CDE\Null_Document.xml Main validation file: C:\LPR3 Test Files\CDE\Null_Document.xml Engine name: ISO Schematron (XSLT 2.0) Severity: error Description: (DKEpisodeOfCareSummariesDocument): element hl7:component[not(@nullFlavor)] is mandatory [min 1x]. (count(hl7:component[not(@nullFlavor)])>=1 / error) [assert] Start location: 2:77 URL: http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71

[cjonigkeit-csc]

Hi @DaveSS Am I right in assuming that you get this error when calling any of the endpoints in the test environment?

[DaveSS]

No. I am validating it via the schematron. I get the error when I use the last released schematron from January, and I get it when using the unstable schematron from 2/27/18.

[jonigkeit]

Hmm. Strange let me look

[jonigkeit]

The schematron for the main template 1.2.208.176.7.1.10.71 should have this content

<assert role="error" see="http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71" test="count(hl7:component)&gt;=1">(DKEpisodeOfCareSummariesDocument): element hl7:component is required [min 1x].</assert>
<assert role="error" see="http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71" test="count(hl7:component)&lt;=1">(DKEpisodeOfCareSummariesDocument): element hl7:component appears too often [max 1x].</assert>

and this

<!--
Template derived rules for ID: 1.2.208.176.7.1.10.71
Context: //hl7:ClinicalDocument[hl7:templateId[@root='1.2.208.176.7.1.10.71']][hl7:templateId[@root='2.16.840.1.113883.10.12.2']][hl7:templateId[@root='2.16.840.1.113883.10.12.1']]/hl7:component
Item: (DKEpisodeOfCareSummariesDocument)
-->
<rule context="//hl7:ClinicalDocument[hl7:templateId[@root='1.2.208.176.7.1.10.71']][hl7:templateId[@root='2.16.840.1.113883.10.12.2']][hl7:templateId[@root='2.16.840.1.113883.10.12.1']]/hl7:component" id="d127e6888-false-d38333e0">
  <assert role="error" see="http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71" test="string(@contextConductionInd)=('true')">(DKEpisodeOfCareSummariesDocument): The value for @contextConductionInd SHALL be 'true'.</assert>
  <assert role="error" see="http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71" test="not(@contextConductionInd) or string(@contextConductionInd)=('true','false')">(DKEpisodeOfCareSummariesDocument): Attribute @contextConductionInd SHALL be of data type 'bl'</assert>
  <assert role="error" see="http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71" test="string(@nullFlavor)=('NI') or not(@nullFlavor)">(DKEpisodeOfCareSummariesDocument): The value for @nullFlavor SHALL be 'NI'.</assert>
  <assert role="error" see="http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71" test="not(@nullFlavor) or (string-length(@nullFlavor)&gt;0 and not(matches(@nullFlavor,'\s')))">(DKEpisodeOfCareSummariesDocument): Attribute @nullFlavor SHALL be of data type 'cs'</assert>
  <assert role="error" see="http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71" test="count(hl7:structuredBody[not(@nullFlavor)])&gt;=1">(DKEpisodeOfCareSummariesDocument): element hl7:structuredBody[not(@nullFlavor)] is mandatory [min 1x].</assert>
  <assert role="error" see="http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?id=1.2.208.176.7.1.10.71" test="count(hl7:structuredBody[not(@nullFlavor)])&lt;=1">(DKEpisodeOfCareSummariesDocument): element hl7:structuredBody[not(@nullFlavor)] appears too often [max 1x].</assert>
</rule>

[jonigkeit]

@DaveSS There are multiple schematron files for template 1.2.208.176.7.1.10.71 be sure to use the one referred to by lpr-lpr3fr.sch which is <include href="include/1.2.208.176.7.1.10.71-2018-01-04T000000.sch"/>

[DaveSS]

I think the next problem then comes from the mandatory structuredBody element that is described in your schematron rule above. So even though I send a component with a nulLFlavor, since that component appears in the document, the structuredBody under it is mandatory (as is a component for one of the sections below it) so I receive the following error next: (DKEpisodeOfCareSummariesDocument): element hl7:structuredBody[not(@nullFlavor)] is mandatory [min 1x]. (count(hl7:structuredBody[not(@nullFlavor)])>=1 / error) [assert]

I'm not sure allowing a nullFlavor at the component level works unless the structuredBody below it is also required instead of mandatory... I'm not sure that is a good solution either, though, since the choice class below the structuredBody requires at least 1 section component and this problem might continue further down the chain. I think the problem is that the cardinality of all these elements is 1..., and I think something would need to be 0... in order to allow the null document. Please correct me if I am wrong about this, which is certainly possible. I may be missing something obvious that allows a null document to be sent.

[jonigkeit]

I will look into this tomorrow and perform the necessary changes.

[jonigkeit]

We have found a way.

The first element where you can "cut off" the xml is <xs:complexType name="POCD_MT000040.Section">. So we are relaxing the cardinality of entry in DK Nullify Section. As this is a change to the XDR interface it has to be approved by the Steering Committee.

[DaveSS]

That seems like it would work. There really isn't any place higher in the CDA document to truncate the document, and the nullify section makes logical sense for the use case. Please keep us updated with the status of this issue as it moves through the Steering Committee.

[jonigkeit]

@DaveSS the change request is still with SDS. We once again asked them for a response.

[KirstenLHSDS]

SDS has discussed this with the steering group and the enhancement has been approved

[jonigkeit]

RESOLUTION

The template has been updated.

[TueCN]

@DaveSS just wanted to let you know that the enhancement has now been deployed

[TueCN]

Reopening because the enhancement has not yet been fully implemented. See https://github.com/scandihealth/lpr3-docs/issues/200#issuecomment-443655705

[TueCN]

There was a misunderstanding: Empty nullify section has no effect in itself, it only serves as a dummy section so it is possible to send a Document replacement with no other content, thus effetively deleting everything in the document.

Empty nullify section in a ClinicalDocument that appends has no effect.

Document replacement using empty nullify works as expected as of version 3.8.256