Added support for external standard ICS tables and actor groupings.

[PaulMartinsen]

📑 Description

This PR adds two features:

1. support including ICS tables from external standards and indicate where SDPi requirements support requirements from those external standards,
2. markup and include required actor groupings in profile artefacts.

External standards

• after including requirements from an external standard using, for example, load-standard::IEEE-P11073-10700-2022.json[id=10700,cite="ref_ieee_11073_10700_2022"],
• requirements from the standard can be referenced with, for example, RefRequirement:RR1162[standard-id=10700, comment="log time-service unreachable"],
• this reference will be automatically collected when made from within the [RELATED] block of an SDPi requirement,
• and used when an ICS table is generated from the external standard using, for example, sdpi_ics_table::[sdpi_req_group="SDC Participant",standard-id=10700].

An example table is shown below, where support from SDPi requirements for requirements in the 11073-10700 standard are indicated with links and comments to the relevant SDPi requirement:

Note

• Please check the SDPi requirements shown in the table as supporting RR1162 from 10700 are appropriate; they make sense to me, but this is not my area of expertise.
• RefRequirement to external standards is only picked up in the [RELATED] block for requirements. However, there may be other places to show support in SDPi for requirements from external standards. RefRequirements can be used anywhere in the text to reference support for external standards already. Once we see what we want to reference, these can be added to the generated ICS tables for external standards too.

Actor groupings

Adding actor groupings to an actor definition exposes the required actor groupings to the exported artefacts to support aggregation of requirements through inheritance relationships by external tooling. Groupings may be fixed, for example:

[#vol1_clause_sdpi_p_somds_connector,role="actor actor-alias",actor-id="somds_connector",actor-grouping=somds_participant,oid-arcs=.29]
===== SOMDS Connector

or depend on profile actor options, for example:

[#vol1_clause_sdpi_p_somds_fhir_gateway,role="actor actor-alias",actor-id="somds_fhir_gateway",oid-arcs=.33]
[actor-grouping="somds_consumer[sdpi-p-gateway-direction-export],somds_provider[sdpi-p-gateway-direction-import]"]
===== SOMDS FHIR Gateway

The actor groups from the asciidoc markup are included in the actor information exported to the profiles.json artefact:

☑ 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

[ToddCooper]

@PaulMartinsen - If I remember right, we still had some open issues to resolve for this PR before I do a review / merge ... yes? Or is it ready for me to do a detailed review and if it all looks right, is OK?

[PaulMartinsen]

This one is ready for a detailed review @ToddCooper . Before merging, we should be comfortable, as mentioned in the PR summary, that the (example) SDPi requirements supporting requirements from 10700 ICS are sensible.

[ToddCooper]

@PaulMartinsen - I was finally able to take a look at this PR ... sorry it has taken so long!
As you can see, some conflicts need to be resolved in the merge checks.
This looks pretty good, but honestly, it has been so long since we talked through the details, that I forget, for example, where the ICS- identifiers come from, what the RR/TR/DR represent, and even the "m" vs. "r" ... and is there a "c" somewhere?!
That said, it might be good to go ahead and get this ready to merge ASAP as a stake in the ground, and we can evolve it from there. We are looking at a ballot in late March / early April, and having this as informative content for review would be a good thing!

[PaulMartinsen]

Hi @ToddCooper , I sorted out the conflicts in the merge checks.

The identifiers come from the source standards I believe. So we're taking the ICS- values from either 10700 or 10701. Same with the RR/TR/DR symbols. I think TR = technical requirement. I'm not sure about the others. ChatGPT says, (putting @d-gregorczyk out of a job ;-) ):

m and r also come from the standards ICS tables. The 3rd one's p. I guess we inherit these from when cost trumped clarity. Perhaps worth having a key in each standard section?

Important

I think its worth checking that that small number of requirements I tagged providing support make sense before merging if you get a chance. It is only the 10 in the screenshot above (R1532 etc) supporting RR1162 from 10700.

Beyond that, I'll take a another look over the PR and make sure I didn't miss anything. I'm not sure if I added any documentation for these new features yet. Either this week or early next well in time to stake the ground.

[PaulMartinsen]

Documentation for the new feature is in the cookbook file @ToddCooper , so this one is good to go from my side.

[ToddCooper]

@PaulMartinsen - just confirming ... this is ready for my FINAL review and if all is good, merge ... right?

[PaulMartinsen]

@ToddCooper , yep