changes in this version

[nizarbs2508]

• Gender: do not display translations.
• INS registration number: only display the label if there is an INS (several OIDs possible for INS).
• Secure e-mail address: delete "secure". At the bottom, the wording is "secure e-mail" to be replaced by "E-mail address"
• Replaced document: set the label according to the typeCode: : "Reference document" and for this value, display the id of the reference document : "Replaced Document"
• Author: the author is not always a person (HP or patient), it can be a device (see Minimal structuring). In this case, the display does not seem to work well (no "Author" label and no device name).
• Empty line under author to delete.

For all the elements of the header, the modification is made at the top and at the bottom of the displayed document.

At the top of the document:

• Patient's name: add the use between square brackets to differentiate the types of surnames and first names
• Date of birth: add a space before "years"
• "Sex:" add a space between the age and the wording "Sex"
• Author: review the display order suffix, prefix, first name, last name (with a space between each)

At the bottom of the document:

• Patient's name: add the use between square brackets to differentiate the types of surnames and first names
• “Performer –”: remove the dash
• Performer: the name, first name, prefix and suffix seem to be displayed in the order of the CDA because we see that it is different between the 1st and the 2nd performer. They should be displayed in the order suffix, prefix, first name, last name (with a space between each)
• Performer: replace “of” in front of the organization with parentheses
• "translation" to be translated as "precision"

Responsible Party and admitting physician:

• same rule on the display order suffix, prefix, first name, last name (with a space between each)
• same rule on organization in parentheses.

Author :

• same rule on the display order suffix, prefix, first name, last name (with a space between each)
• same rule on organization in parentheses.

Participant:

• functionCode: we put:

Commentaire sur le Dr MEDIONI -> if nullFlavor="NA", it puts "no applicable value" => ok if nullFlavor alone to indicate the label of the nullFlavor -> if nullFlavor + originalText => put only the text (and not "no applicable value") -> same rule on the display order suffix, prefix, first name, last name (with a space between each) + put a line break if functioncode before dataEnterer - same rule on the display order suffix, prefix, first name, last name (with a space between each) - same rule on organization in parentheses. Informant: Address - same rule on the display order suffix, prefix, first name, last name (with a space between each) - display and on the same line - put a line break after use="H" "home", use="WP" "work", etc… - put a line break after each telecom informationRecipient - same rule on the display order suffix, prefix, first name, last name (with a space between each) - display and on the same line Authenticator and legalAuthenticator: - same rule on the display order suffix, prefix, first name, last name (with a space between each) - display and on the same line. + add checks on all array for header and footer elements in case the element is empty

[mjszczep]

Hi Nizar--unfortunately, this commit is a bit hard to read through because of the number of extraneous changes moving line breaks and whitespace around. Is it possible to keep those the same in areas you're not actually modifying?

It's also unclear to me what the goal of some of these changes are. To pick just one example, the behavior of the show-identifiant template seems like a design change that would probably warrant its own discussion; do we need both show-identifiant and show-id-set? Or maybe we should pick one set of consistent behavior (either show ID OIDs or don't) and apply it everywhere. And if in some use cases we want to show ID OIDs everywhere and in others we don't--say, because of differing regulatory requirements--then that might be a good case for a new stylesheet parameter.

Topics like that would also be easier to discuss if your branch were split up into multiple smaller commits, each with its own separate change. That would make it easier to focus on them one at a time and figure out how best to merge them.

If you'd also rather just maintain your own fork on its own, that's fine too, of course! But if we do want to merge these changes into the HL7-released version of the stylesheet, I think we need to at least get rid of the extraneous formatting changes and ideally split it into smaller commits in order to move further along.

If you'd prefer, we can also talk about this on one of the Structured Documents conference calls, every Thursday at 10 AM US Eastern time. Talking on GitHub works too, but it's an option if you feel like a call would help things move faster!

[mjszczep]

Hi Nizar--are there still any changes you think should be merged into HL7's version of the stylesheet (and so released to everybody)? Or are all the changes in your fork specific to your use case at this point? If it's the latter, I figure we can just close this PR.