Add BICEPS Content Actor Groupings to SDPi-P Required Actor Groupings Table (TF-1:10.3)

[Copilot]

📑 Description

TF-1:10.3 SDPi-P Required Actor Groupings only covered transactional (gateway) actors, omitting the required groupings for the BICEPS Content Creator and BICEPS Content Consumer content profile actors.

Changes

• asciidoc/volume1/tf1-ch-10-sdpi-p.adoc — Added two rows to vol1_table_sdpi_p_required_actor_groupings:
  • BICEPS Content Creator → unconditionally grouped with SOMDS Provider
  • BICEPS Content Consumer → unconditionally grouped with SOMDS Consumer
  • Added Note 1 clarifying that these groupings apply to all content modules in Table 1:10.1-2 (SDPi-P — Actors and Content Modules), precluding the need for per-content-module rows

☑ Mandatory Tasks

The following aspects have been respected by the pull request assignee and at least one reviewer:

• Changelog update (necessity checked and entry added or not added respectively)
  • Pull Request Assignee
  • Reviewer

[JavierEspina]

@ToddCooper , does this (currently DRAFT) PR correctly address #476? (mostly drafted by my pal "Copilot"!). See workflow runs for rendered result.

[ToddCooper]

@ToddCooper , does this (currently DRAFT) PR correctly address #476? (mostly drafted by my pal "Copilot"!). See workflow runs for rendered result.

@JavierEspina - Having reviewed the issue + your update, I think the answer is "Yes"! However, you might consider one more thing (see attached template + current RAD TF Vol 1 documents).
IHE_Suppl_Template_Rev10-6_2022-01-17.docx
IHE_RAD_TF_Vol1.pdf

If you look at the table on template line 580 + the current RAD TF-1 example around line 7205 (which shows that the template is still "current)"), we could add the right most column and then put the Note 1 in that column for both content actors. BUT it may be sufficient as is!

The crux of the issue is where to formally bind content to AIPO's and this is where I believe that happens.

Let me know your determination as to ... sufficiency!

[JavierEspina]

@ToddCooper , does this (currently DRAFT) PR correctly address #476? (mostly drafted by my pal "Copilot"!). See workflow runs for rendered result.

@JavierEspina - Having reviewed the issue + your update, I think the answer is "Yes"! However, you might consider one more thing (see attached template + current RAD TF Vol 1 documents). IHE_Suppl_Template_Rev10-6_2022-01-17.docx IHE_RAD_TF_Vol1.pdf

If you look at the table on template line 580 + the current RAD TF-1 example around line 7205 (which shows that the template is still "current)"), we could add the right most column and then put the Note 1 in that column for both content actors. BUT it may be sufficient as is!

The crux of the issue is where to formally bind content to AIPO's and this is where I believe that happens.

Let me know your determination as to ... sufficiency!

Thanks, Todd. After reading that template carefully (for the first time), I have validated that it is the current one. I also checked the RAD TF-1 example. I don't think we need to add an extra column. What RAD chose from the template is "alternative 1" while we went for "alternative 2". I don't see benefits in one over the other...and much less so in making up a hybrid of alternatives. That said I noticed a few things that I have just changed in a further commit:

• Following the template instruction to list ALL profile actor, even when they do not have required groupings (NOTE: I skipped 2 abstract actors plus the Discovery Proxy. The latter could be seen as requiring grouping with bot Provider and Consumer...but that gets kind of recursive / way to complex...)
• Title row should read "Reference" and not "TF Reference"
• Added "Required" per template instruction when there are no grouping conditions

[JavierEspina]

@ToddCooper , does this (currently DRAFT) PR correctly address #476? (mostly drafted by my pal "Copilot"!). See workflow runs for rendered result.

@JavierEspina - Having reviewed the issue + your update, I think the answer is "Yes"! However, you might consider one more thing (see attached template + current RAD TF Vol 1 documents). IHE_Suppl_Template_Rev10-6_2022-01-17.docx IHE_RAD_TF_Vol1.pdf
If you look at the table on template line 580 + the current RAD TF-1 example around line 7205 (which shows that the template is still "current)"), we could add the right most column and then put the Note 1 in that column for both content actors. BUT it may be sufficient as is!
The crux of the issue is where to formally bind content to AIPO's and this is where I believe that happens.
Let me know your determination as to ... sufficiency!

Thanks, Todd. After reading that template carefully (for the first time), I have validated that it is the current one. I also checked the RAD TF-1 example. I don't think we need to add an extra column. What RAD chose from the template is "alternative 1" while we went for "alternative 2". I don't see benefits in one over the other...and much less so in making up a hybrid of alternatives. That said I noticed a few things that I have just changed in a further commit:

• Following the template instruction to list ALL profile actor, even when they do not have required groupings (NOTE: I skipped 2 abstract actors plus the Discovery Proxy. The latter could be seen as requiring grouping with bot Provider and Consumer...but that gets kind of recursive / way to complex...)
• Title row should read "Reference" and not "TF Reference"
• Added "Required" per template instruction when there are no grouping conditions

@ToddCooper, if you agree with above...:
1- I would transition the PR from Draft to In Review
2- I would create a new issue to make the same kind of changes for the rest of SDPi profiles

[ToddCooper]

I have reviewed all changes and approve this pull request.

[ToddCooper]

@JavierEspina - To speed things up, I went ahead and submitted the review. I assume that you can simply change the status and merge. WA me if not. Also, go ahead and create the issue for normalization of the other profiles / actors. Regarding Alternative 1 & 2, I thought that they said "Use Alternative 1 when ..." and then when to use Alternative 2. That said, I really don't care. The main part is to get it defined in such a way that we can replicate it in Gazelle and do the testing.