CDR Tickets

See if we can use the link property mechanism to inject the necessary rule.

It appears to me from the statement of the problem that there are two
things we can check.

  1. Is the linked-to document a health professional Summary, and 

  2. Does the language of the linked-to document match the language of
     the linking document.

The first can easily be accomplished by using the existing link property
software.  We would need to create a new link type that links from
Summary/PatientVersionOf to Summary so we could assign it a property
that doesn't affect other Summary links.  We might call this new link
type an "HP Summary Link".  Then we'd specify a link rule that the
linked-to Summary must have:

  /Summary/SummaryMetaData/SummaryAudience = "Health professionals"

We'd also have to index the SummaryAudience element.


I don't see a good way to check the language using that technique.  The
link property software that we have now only checks for properties in a
linked-to document.  It doesn't allow the user to specify that the
linked-to document must contain a string matching a value in the linking
document.

We could modify the link processing software to support that capability,
but I think that a much cheaper approach would be to write a schema rule
that incorporates a database check.  It would really be a link check,
not a schema check but, well, sometimes time and cost trump elegance and
purity.  If we think we want to add lots of new link checking rules,
expanding the link checker's capability might be warranted, but it
doesn't appear that we have such requirements.

Using the schema rule check would also require the specification of a
new indexing path to index the SummaryLanguage element.  However the
number of Summaries is small and the total new indexing would not add
anything significant in database size or reduce performance.

Beyond that, I haven't thought of anything more to check.  It would be
nice to be able to validate that the linked to document is indeed the HP
version of the patient summary, but if we could do that we wouldn't have
needed the PatientVersionOf element in the first place.  The vendor
filters would have been able to create it from the data during
publishing.

At our meeting today we said to proceed with this.  However, just to be
sure we're on the same page, here's what I will be doing:

    Create a new link type named "HP Summary Link".

        Can link from:  "Summary" // "PatientVersionOf"
          Can link to:  "Summary"

    Add a link rule to the new link type that requires:

        "/Summary/SummaryMetaData/SummaryAudience" = "Health professionals"

    Add two new rows in the query_term_def table:

        "/Summary/SummaryMetaData/SummaryAudience"
        "/Summary/SummaryMetaData/SummaryLanguge"

        Then re-index the Summary document type.

    Create a custom rule in the SummarySchema.xml file that asserts
    that:

        If there is a PatientVersionOf element in the Summary, then:

            "/Summary/SummaryMetaData/SummaryLanguge" of the
            linking-from and linking-to documents match.

            Implementation note: This would be handled by a database
            query built-in to the assertion rule.

Implementation deployment notes:

    The deployment of these changes in Prod and other tiers will not be
    done by the usual CBIIT installation of new software on Prod.
    It will be safer instead to recreate the steps performed on Dev,
    specifically:

        Create the new link type with the new link rules as above.

        Add the two new rows in the query_term_def table.

        Run the reindex utility (from the Bastion host in Prod) on
        Summaries.

        Install the modified SummarySchema.xml.
            This need only be done once to deploy this change and the
            change for OCECDR-3718.  Both tasks require modifications
            of the same schema.

Could someone (William?, Robin?) confirm that the above steps will be
what (and only what) we need to do to complete this task?

Thanks.

Quote:

If there is a PatientVersionOf element in the Summary, then:

"/Summary/SummaryMetaData/SummaryLanguge" of the
linking-from and linking-to documents match.
End Quote.

Does this mean that it will permit a link to another Spanish HP summary, for example. (That is, as long as the the language matches?). Would it be possible to permit only the type and language of summary that should be linked using the PatientVersionOf element? In this case it will be the Spanish HP summary only.

I'm not certain that I understand the question but I'll try to answer.

If we're in a Patient Summary that has a PatientVersionOf element then we'll do the following:

From the Patient Summary:
Get the language of the Patient Summary (English or Spanish)
Get the CDR ID of the Summary linked-to.

From the linked-to Summary:
Get the audience type of the Summary (HP or Patient)
Get the language of the Summary (English or Spanish)

If the audience type of the linked-to Summary is anything other than HP, it's an error.

If the language of the linked-to Summary doesn't match the Patient Summary, it's an error.

This will catch the errors you mention but will also catch possible errors in the English Patient Summaries. If an English Patient Summary points to a Spanish Summary or anything other than an HP Summary, we'll declare the error.

I can reduce that to only check the Spanish - which is probably where all of the errors have been, or leave it as above - whichever you wish.

This answers my question, especially this part:

"If the audience type of the linked-to Summary is anything other than HP, it's an error."

and sorry about the ambiguous question. I should have referred to the Patient summary where I said HP summary. Somehow, I did not see that linking to a summary that is not HP would raise an error.

I see I made a mistake in an earlier comment. I said that we needed to create an index query_term_defs for /Summary/SummaryAudience and Summary/SummaryLanguage because they weren't already there.

I was right that they weren't there, but wrong that we needed to create them. The correct query_term_defs are for:

/Summary/SummaryMetaData/SummaryAudience and Summary/SummaryMetaData/SummaryLanguage.

They are already there.

I have completed the work for this on Dev (see checklist below) and it
seems to be working, ready for user test.

When we're ready to deploy, I'll need to do the same work on Prod.  We
can do QA either by hand or, if testing on Dev is adequate, deploy
straight to Prod and it will appear on QA the next time the QA database
is refreshed from Prod.

All of the changes are in the database, none in code.  Deployment can
therefore be done whenever we like without having to synchronize with a
release cycle.

Tasks:

  Dev
    [x] Remove PatientVersionOf element from "Summary" link type.
        Have to do this before creating new type for PatientVersionOf link.
    [x] Create new link type "HP Summary Link".
        From:  /Summary/PatientVersionOf  To:  Summary
    [x] Check Property "LinkTargetContains".
    [x] Add PropertyValue:
        /Summary/SummaryMetaData/SummaryAudience = "Health professionals"
    [x] Add description:
        Link that can only go to a Health Professional version of a Summary,
        not to a Patient version.

    [x] Add custom schema rule to SummarySchema.xml:
        SummaryLanguage in link-from and link-to docs must match.
    [x] Commit the schema change to subversion.

  Prod
    [ ] Remove PatientVersionOf element from "Summary" link type.
        Have to do this before creating new type for PatientVersionOf link.
    [ ] Create new link type "HP Summary Link".
        From:  /Summary/PatientVersionOf  To:  Summary
    [ ] Check Property "LinkTargetContains".
    [ ] Add PropertyValue:
        /Summary/SummaryMetaData/SummaryAudience = "Health professionals"
    [ ] Add description:
        Link that can only go to a Health Professional version of a Summary,
        not to a Patient version.

    [ ] Add custom schema rule to SummarySchema.xml:
        SummaryLanguage in link-from and link-to docs must match.

The rules appear to work well except when you link to another Spanish patient summary; it is supposed to raise an error since the correct summary type to link to is the Spanish HP summary. But when linked to another Spanish patient summary, no validation error comes up.
Sample document on DEV - CDR0000256661.

I believe this is fixed. For some reason the "Create new link type ..." step above didn't take. I haven't tried too hard to figure out why, just did it again and I see it there in managing links and the link validation works.

Unlike the other validations, this one will only work if "Link Validation" is checked in the validation request dialog box from XMetal. Attempting to create a publishable version will force the check to occur but to just check for testing purposes it's necessary to check the box.

(I won't reveal how much time I spent trying to figure out why it didn't work before I realized I hadn't checked the box, but I'll admit that it was more than the 30 seconds it should have taken me.)

It is working well on DEV. Thanks!

Verified on QA.

The validation does not appear to work well on Prod. It validates well against the language. That is, if you choose English instead of Spanish, you get a validation error. However, if you choose a Spanish summary that is either Patient or HP, it validates without any problems. If you select a Patient summary instead of a Health Professional summary, it is supposed to make the document invalid but it does not.

Another observation is that on either DEV or QA or both, I remember seeing that when you did a wild card search, the only documents that were retrieved were Spanish Patient summaries but I don't see that on Prod and when I went back to QA and Dev to double-check, I didn't see it work on there either so may be I was just dreaming about it :-).

I'll check out the validation issues when I'm in on Monday.

As for the wild card searches, I can understand your only dreaming that something was broken. I often find that I only dreamed that I fixed something.

Is it possible we're depending on query term indexing which isn't present?

Maybe I only dreamed that we were up to date on query terms.

I'll check the code on Monday, see what query terms it's using, and make sure the paths are all there.

William,

Can you post the CDR document ID of a doc that passes the validation but should not, and include the steps to see the incorrect result?

Thanks.

Sure, you can use this Spanish Supportive Care Patient Summary- CDR0000256661.

1. Retrieve CDR0000256661
2. Scroll down to the end of the document to the PatientVersionOf element
3. Type Control Enter to bring up the search window
4. Type % to retrieve the list of possible documents
5. Select an English HP or Patient summary (this produces the right error message)
6. Select a Spanish HP summary(This correctly does not produce any error) Example 62891
7. Select a Spanish Patient summary (This does not produce an error when it should) Examples: 269587, 269124

It appears to me that the problem is on both Dev and Prod and I have a theory about the cause.

The comment marked: "Wednesday, 5 Mar 2014 12:07 AM" included these instructions:

Dev
[x] Remove PatientVersionOf element from "Summary" link type.
Have to do this before creating new type for PatientVersionOf link.
[x] Create new link type "HP Summary Link".
From: /Summary/PatientVersionOf To: Summary
[x] Check Property "LinkTargetContains".
[x] Add PropertyValue:
/Summary/SummaryMetaData/SummaryAudience = "Health professionals"
[x] Add description:
Link that can only go to a Health Professional version of a Summary,
not to a Patient version.

It showed that the work had been done on Dev but not yet on Prod.

I suspect what happened was that the work was done on Dev. Then, later, we refreshed the Dev database from Prod, which wiped out the changes on Dev. Then, later, we deployed Release 3.2 to Prod.

As part of the release, we compared the link tables on Dev and Prod and didn't find any differences. All of the link table info on Dev was also on Prod. Well, that was true, but not all of the link table info that should have been on both Dev and Prod was actually on either one.

Sorry about that. There are an awful lot of things to remember and, even though I made notes about this here in JIRA, I didn't remember to look at them.

To fix it, I think that all I need to do is to update the link tables on all servers. Fortunately, this can be done without requiring CBIIT assistance, so we can do it at any time.

I'm re-opening this issue. However, since I'm working on some relatively high priority tasks at the moment, I'd like to defer the implementation. Let's talk about it at the status meeting on Thursday and set a priority for it.

Re-opening this issue until we have updated the link tables on all servers and checked to be sure this fixes the failure of our validation software to detect that a Patient Summary's PatientVersionOf element links to another Patient Summary instead of an HP Summary.

See the previous comment from today.

This is now implemented and tested on Dev, QA, and Prod.

Since it was already tested before, and since it's easy to change things from the CDR admin system (see instructions above in the comment dated "Wednesday, 5 Mar 2014 12:07 AM"), I went ahead and implemented it in Production without waiting for another user test.

I'm marking this Resolved as Fixed.

Verified on PROD.