CDR Tickets

BZDATETIME::2012-03-07 15:20:07
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

Would this information be available to Cancer.gov and the licensees or is this intended for Cancer.gov only?

BZDATETIME::2012-03-07 16:33:52
BZCOMMENTOR::Margaret Beckwith
BZCOMMENT::2

Just to Cancer.gov. Also, we need to make sure that we somehow give them the association of Board member to a specific Board, and who the Editor-in-Chief of the Board is.

BZDATETIME::2012-03-08 14:22:44
BZCOMMENTOR::Margaret Beckwith
BZCOMMENT::3

Notes from meeting. Please feel free to correct if I got something wrong.
1. In the dtd, we will provide cancer.gov with a new document type called Board doc.
2. This will include a list of all of the Board members for a particular Board, Affiliation Name and Place for each of them, text that goes at the top of the page, and information about who is Editor-in-Chief.
3. We will compile all of the information for them in the vendor filter.

BZDATETIME::2012-03-08 16:15:20
BZCOMMENTOR::Volker Englisch
BZCOMMENT::4

There are several things that need to happen for this issue:

• Changing the DTD for Cancer.gov

• Modifying the publishing document to select the Board Org documents

• Creating the vendor filters to create the BoardMembership documents (one
  file for each board listing the current members)

• Updating the vendor filter post-process to exclude the documents from
  the licensee output.

I will add additional Bugzilla issue for the above items when needed.

Can we go ahead with the work or are we waiting for Cancer.gov to give the green light first?

BZDATETIME::2012-03-27 17:30:28
BZCOMMENTOR::Volker Englisch
BZCOMMENT::5

We (Bob and myself) had a short meeting with Blair and Lauren regarding this issue and we came up with a basic idea for the elements that are needed to support this new "document type" for each of the boards:
PDQBoard
BoardName*
BoardDescription*
BoardUrl*
BoardMembers*
BoardMember&+
PersonalNameInfo*
BoardRole&
ContactInfo&

I've created a filter to build this data structure but I'm having some questions:

• the PDQBoardMemberInfo document lists the Affiliations block containing
  the AffiliationName and AffiliationPlace.
  Should this information be used as the ContactInfo or do we pick up the
  ContactInfo from the Person document based on the PersonContactID?

• other than the GivenName, MiddleInitial, SurName and ProfessionalSuffix
  information is there anything else that needs to be included in the
  PersonalNameInfo block?

BZDATETIME::2012-03-28 12:27:41
BZCOMMENTOR::Margaret Beckwith
BZCOMMENT::6

The information we show on Cancer.gov is exactly the information we include int he Affiliation Name/Place elements in the CDR. That is part of the reason that we structured them that way. We shouldn't have to take any contact information from the Person record.

I think the info you have listed for the name is fine. There may be cases where the Board Member doesn't want their name listed the way it is in the Person record, and we will have to figure that out. Since the names on the Board Rosters come from the Person records, I think most of them should be fine.

BZDATETIME::2012-03-28 12:35:07
BZCOMMENTOR::Volker Englisch
BZCOMMENT::7

(In reply to comment #6)
> I think the info you have listed for the name is fine. There may be cases
> where the Board Member doesn't want their name listed the way it is in the
> Person record, and we will have to figure that out.

We could possibly create an optional SpecialBoardMemberName element/block that would overwrite the information from the Person document if it exists?

BZDATETIME::2012-03-28 13:02:28
BZCOMMENTOR::Volker Englisch
BZCOMMENT::8

Bob, given Margaret's comment #6 regarding the contact info for a board member I'd suggest to specify in the DTD
BoardMember&+
PersonNameInfo*
BoardRole&
Affiliations& <<<<< The schema allows multiple
Affiliation <<<<< affiliations

rather than
BoardMember&+
PersonNameInfo*
BoardRole&
ContactInfo&
The ContactInfo to me suggests Street, City, ZIP, etc.
Also, I suggested in my previous comment an additional (optional) SpecialBoardMemberName element/block for the cases when the board member does not want the information from the Person document displayed but rather list a different name (or list the name differently).
What do you think?

BZDATETIME::2012-03-28 14:24:42
BZCOMMENTOR::Bob Kline
BZCOMMENT::9

(In reply to comment #8)

> I'd suggest to specify in the DTD
> BoardMember&+
> PersonNameInfo*
> BoardRole&
> Affiliations& <<<<< The schema allows multiple
> Affiliation <<<<< affiliations

Sure.

> The ContactInfo to me suggests Street, City, ZIP, etc.

Well, the page does have postal address information in it, so your affiliation block will need to carry that. I assume you've done the research to confirm that the address information on the current web page matches address information accompanying the affiliations rather than directly linked to the person, independent of any organization. If that's not true, then you'll need to go back to the ContactInfo approach, and either have the Affiliation element(s) incorporated into that block, or have them outside of (and preceding) the ContactInfo block.

> Also, I suggested in my previous comment an additional (optional)
> SpecialBoardMemberName element/block for the cases when the board member does
> not want the information from the Person document displayed but rather list a
> different name (or list the name differently).
> What do you think?

Yes, but that would be in our schemas and data, not in the DTD. By the time the document gets to the DTD, we'll have swapped in any overriding information from the SpecialBoardMemberInfo block.

BZDATETIME::2012-03-28 14:34:03
BZCOMMENTOR::Margaret Beckwith
BZCOMMENT::10

All the Web page has on it is this:

Franco M. Muggia, M.D., Editor-in-Chief
New York University Medical Center [Affiliation Name]
New York, NY [Affiliation Place]

so that is all the location information we need to send to Cancer.gov. Maybe I am misunderstanding...

In terms of the name, I think having a "Display Name" for those few cases where the person wants their name to show differently than what is in the Person record is a good idea.

BZDATETIME::2012-03-28 15:14:17
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

(In reply to comment #9)
> Yes, but that would be in our schemas and data, not in the DTD.

That means that the SurName, the only mandatory element of the PersonNameInformation block, will hold a display name like 'Madonna' for 'Madonna Louise Ciccone', right?

BZDATETIME::2012-03-28 15:30:10
BZCOMMENTOR::Bob Kline
BZCOMMENT::12

(In reply to comment #11)
> (In reply to comment #9)
> > Yes, but that would be in our schemas and data, not in the DTD.
>
> That means that the SurName, the only mandatory element of the
> PersonNameInformation block, will hold a display name like 'Madonna' for
> 'Madonna Louise Ciccone', right?

Why don't we make it simple for them and assemble a MemberNameDisplay element and a MemberSortKey element?

BZDATETIME::2012-03-30 13:42:18
BZCOMMENTOR::Volker Englisch
BZCOMMENT::13

(In reply to comment #12)
> Why don't we make it simple for them and assemble a MemberNameDisplay element
> and a MemberSortKey element?

I'm guessing since we're already making it simple for Cancer.gov we should also include the professional titles in the display string. Our DTD would then look like this:
PDQBoard
BoardName*
BoardDescription*
BoardUrl*
BoardMembers*
BoardMember+
MemberDisplayString*
MemberSortKey
BoardRole&
Affiliations&
Affiliation
AffiliationName&+
AffiliationPlace*

BZDATETIME::2012-03-30 17:42:02
BZCOMMENTOR::Robin Juthe
BZCOMMENT::14

(In reply to comment #12)
> Why don't we make it simple for them and assemble a MemberNameDisplay element
> and a MemberSortKey element?

We decided in yesterday's status meeting to add two new elements to the Board Member Information document:

Member Display First Name
Member Display Surname

This division will be used to generate the sorted list of Board members (by surname with the exception of the Editor-In-Chief).

BZDATETIME::2012-04-24 09:46:18
BZCOMMENTOR::Margaret Beckwith
BZCOMMENT::15

Lowering priority since this didn't make it into Release 6.5. It will go into 6.6.

Some of the work for this issue has already been completed but other parts may have been lost due to the CBIIT move.
The DTD has already been updated and is available (on DEV) under
d:\cdr\licensee\pdqCG.dtdR10404

A filter has already been prepared but was never versioned. The stub is stored on PROD as CDR729825 with the filter title "Denormalization Filter: PDQBoard Add Board Member".
I found a version of this filter under my home directory
D:\home\venglisch\CDR\Filters\CDR0000729825.xml

Rather than creating a new BoardMembership document type Bryan is asking to create instead a General Document type that would allow other content to be pushed to Gatekeeper. This approach would eliminate the WCMS team to spend a lot of work to work on Gatekeeper for the automated update of just 6 documents.
This issue will need to be discussed further.

We want to remove this task from the current release. Bryan's requirement to come up with a "general document" document type will need to be discussed in more detail.

~bryanp: This request is ancient (pre-dates CBIIT's takeover of our hosting). Should we just close this ticket?

~bryanp: Closing ticket. It can be re-opened if necessary.