CDR Tickets

BZDATETIME::2010-03-22 11:22:30
BZCOMMENTOR::Bob Kline
BZCOMMENT::1

This can't be done until the users have finished reviewing the implementation for task #4630. Otherwise feedback from that review which changes data structures used for the mailers would likely mean that we would have to re-do the specs we give to Cancer.gov for the services for this task.

BZDATETIME::2010-06-10 09:17:24
BZCOMMENTOR::Bob Kline
BZCOMMENT::2

(In reply to comment #1)
> This can't be done until the users have finished reviewing the implementation
> for task #4630. Otherwise feedback from that review which changes data
> structures used for the mailers would likely mean that we would have to re-do
> the specs we give to Cancer.gov for the services for this task.

Based on comment #71 of the GP mailer task (#4630) I'm hoping that it's safe to proceed with this one. This is your last chance to make sure that the structures for the information we're collecting in the mailers are really what you want. Unless I hear otherwise I'm going to begin on this task in earnest.

BZDATETIME::2010-06-17 11:52:04
BZCOMMENTOR::Bob Kline
BZCOMMENT::3

This is the first draft of a schema which I'll give to cancer.gov for the service they will invoke to send the information collected on the form for genetics professionals applying for inclusion in the NCI Cancer Genetics Services Directory. I tried to keep the structure and names as close to what the GP mailers are using, and I also tried to keep the changes to the original application form to a minimum. These two goals conflict with each other in places, so I had to make some decisions.

1. The original application form has a single Name field, where the
mailer has articulated GivenName, MiddleInitial, Surname, and
Suffix elements. I went with the articulated structure.

2. I dropped the <PublishInDirectory/> element.

3. The application form currently has a single textarea field for extra
practice locations; they'll need to replace that with separate
fields for Institution/Address/Telephone.

4. The application schema includes a ProfessionalLicenseInfo element
to pick up the field labeled "Provide professional license and/or
national certification number and state."

5. The application form will need to implement the more complex
table of specific board specialty/certifications to match the
emailer.

6. The application schema has a SupportingProfessionalInfo block
not in the emailers, to pick up the information provided in
section 4 of the application ("What specific training or professional
experience do you have in cancer genetics? Please include
information about all of the following that apply:").

The Team Services, Syndromes, Societies, Specialties, and Professional Types blocks will be created with values obtained from the first web service which supplies the valid values.

Let's talk about how closely this matches what it should look like.

Attachment GP.xml has been added with description: Draft schema for second service

BZDATETIME::2010-06-18 12:19:19
BZCOMMENTOR::Bob Kline
BZCOMMENT::4

Lakshmi, Margaret, and William will look over the schema and the list I posted in the previous comment. We didn't have enough time in yesterday's meeting to go through the details together, so I propose we do that at next Thursday's meeting.

BZDATETIME::2010-07-02 10:10:43
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::5

CIAT had two questions which were discussed and answered in yesterday's review meeting:

1. The problem of professionals providing Contact address which is usually the same as the Practice location address.

Answer:
Bob explained that when a professional provides exactly the same Contact address as a Practice location address, the cancer.gov service will give us only one address and not two.

2. The problem of professionals providing URLs which should typically go into the organization document and not the person document.

Answer:
Margaret said it is OK to have the URL in the Person document since we don't publish the URLs.

BZDATETIME::2010-07-06 15:26:01
BZCOMMENTOR::Bob Kline
BZCOMMENT::6

Shall I go ahead and send the schema to cancer.gov?

BZDATETIME::2010-07-12 15:03:21
BZCOMMENTOR::Bob Kline
BZCOMMENT::7

(In reply to comment #6)
> Shall I go ahead and send the schema to cancer.gov?

It was decided at this past Thursday's status meeting that we will go back and re-work the schema for the GP application form, breaking down the elements into enough granularity that a new Person document can be created automatically (or, if CIAT identifies an existing Person document, merging GP information into that document). The mailers will not be affected by this decision (CIAT will continue the practice of modifying the documents by handing, using the display of changes made in response to the mailer).

This new requirement will present the same difficulties we ran into with the conversion of the legacy gen_prof records into Person documents: we need to decide how the software will decide when to create a new contact block in the existing Person document, and when to flag a contact block which is already present as the block which is to be used as the GP mailer contact information, a GP practice location, or both. For the conversion process we used the approach of having CIAT prepare a mapping spreadsheet. That approach wouldn't work in this situation. In a very few cases, the information provided for a contact or practice location will exactly match a block in the target Person document, but that won't happen for most location blocks. One possible way around this would be something like the following:

1. CIAT provides a CDR ID for an existing Person document
2. the review interface then provides a list of all of the location
blocks in the Person document and all of the location blocks
in the application document
3. the reviewer identifies which location blocks in the Person
document are to be used with which location blocks in the GP
information

Not sure if it's going to be worth the expense of implementing such a complex interface for the number of GP applications we'll get which match existing Person documents.

Feedback, please.

BZDATETIME::2010-07-13 09:16:26
BZCOMMENTOR::Bob Kline
BZCOMMENT::8

Here's another solution. If CIAT indicates (on the review page for a new GP application) that we don't already have a Person document for the GP, the software creates one and populates it with the information we have from the form. If on the other hand CIAT does identify an existing Person document, the software inserts and populates a new GeneticsProfessionalDetails block, but CIAT is responsible for performing the rest of the modifications to the Person document (including the locations) based on the form information displayed by the software. We'll need to sit down at some point and design this review software (a separate task from this one, which deals with the services we're implementing for cancer.gov).

I assume everyone realizes that the decision to have the additional granularity needed to enable the review software to create new Person documents programmatically will mean significantly more extensive revision work on the existing form by cancer.gov, making it more difficult to get it through the queue. I suppose we could offer to help them with the implementation.

BZDATETIME::2010-07-27 08:54:23
BZCOMMENTOR::Bob Kline
BZCOMMENT::9

(In reply to comment #8)

> Here's another solution. If CIAT indicates (on the review page for a new GP
> application) that we don't already have a Person document for the GP, the
> software creates one and populates it with the information we have from the
> form. If on the other hand CIAT does identify an existing Person document, the
> software inserts and populates a new GeneticsProfessionalDetails block, but
> CIAT is responsible for performing the rest of the modifications to the Person
> document (including the locations) based on the form information displayed by
> the software.

If I recall correctly, the decision taken before I left for vacation was to adopt the solution described immediately above. If that's not right, please speak up. I will proceed in the meantime with revisions to the schema for the document Cancer.gov will submit to our second service, as well as expansion of the first service to provide the additional lookup values they'll need (for example, state/province/country combinations).

BZDATETIME::2010-07-27 08:58:15
BZCOMMENTOR::Margaret Beckwith
BZCOMMENT::10

Yes, that is my recollection of what we decided.

BZDATETIME::2010-08-24 07:47:14
BZCOMMENTOR::Bob Kline
BZCOMMENT::11

This task has been pushed back in the queue.

BZDATETIME::2011-08-30 11:24:58
BZCOMMENTOR::Margaret Beckwith
BZCOMMENT::12

I am bringing this issue back from the dead so we can resume discussions about it. I will need to get it into the Cancer.gov queue if we decide to proceed with it and I want to make sure I understand what we are asking for.

BZDATETIME::2012-01-05 12:08:41
BZCOMMENTOR::Margaret Beckwith
BZCOMMENT::13

Moving this back to cryopreserved state until cancer.gov is ready for it in the second half of 2012.

Added Erika as a watcher so she can coordinate scheduling of this task with the WCMS schedule (note that the target time frame mentioned in the previous comment passed a while ago).

Erika: any chance this will get into the WCMS queue in the foreseeable future? Or should we put this issue back in the deep freeze?

I had the wrong Erika (chengep) as watcher when I posted the previous comment:

Erika: any chance this will get into the WCMS queue in the foreseeable future? Or should we put this issue back in the deep freeze?