diff --git a/asciidoc/images/vol1-diagram-sdpi-req-types-model.svg b/asciidoc/images/vol1-diagram-sdpi-req-types-model.svg
index 1edae44..96d9ada 100644
--- a/asciidoc/images/vol1-diagram-sdpi-req-types-model.svg
+++ b/asciidoc/images/vol1-diagram-sdpi-req-types-model.svg
@@ -1,18 +1,20 @@
diff --git a/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc b/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc
index 165f2c5..aeacea9 100644
--- a/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc
+++ b/asciidoc/volume1/tf1-ch-a-requirements-interoperability.adoc
@@ -190,15 +190,16 @@ It should be further noted that though conformity testing aspects are beyond thi
[#vol1_clause_sdpi_requirements_core_model]
==== SDPi Requirements Core Model
-To formally integrate requirements in to this specification, the following requirements model provides the starting point:
+To formally integrate requirements in to this specification, the following model details the core types of requirements that will be defined:
[#vol1_figure_appendix_a_sdpi_requirements_core_model]
-.SDPi Requirements - Core Model
+.SDPi Requirement Categories - Core Model
image::../images/vol1-diagram-sdpi-req-types-model.svg[align=center]
-This model identifies a set of requirement "types" that are formalized in the specification.
-Each type is a source of requirements that are explicitly identified and formalized with appropriate metadata.
+This model identifies the set of requirement "types" that are utilized in the specification.
+
+Each type defines a unique class of requirements that build upon a foundational specification that may be specialized with additional metata to better capture the unique source and role of each specification.
[%autowidth]
[cols="^1,4,^1,^1"]
@@ -218,7 +219,12 @@ Each type is a source of requirements that are explicitly identified and formali
| Usage
| Requirement utilized in a specific use context that provides for its satisfaction.
| sdpi_requirement_usage
-|
+|
+
+| IHE Profile
+| Each IHE profile specification has a set of requirements that must be captured. For example, Actor X in Profile Y requires support for Transaction A + B + C.
+| sdpi_requirement_ihe_profile
+|
| Use Case Feature
| A functional "feature" requirement based on clinical use case scenarios.
@@ -231,12 +237,12 @@ Each type is a source of requirements that are explicitly identified and formali
|
| SES
-|
+| Non-technical requirements related to Safety, Effectiveness, and Security are captured in these blocks. These are especially relevant to mapping ISO/IEEE 11073-1070x Participant Key Purposes standard requirements to elements within the SDPi specification.
| sdpi_requirement_ses
| See SES Section <>
| Tech Feature
-|
+| Technology focused requirements result from the use of a particular implementation approach. For example, use of TLS 1.3 may also result in the need to address related technical capabilities.
| sdpi_requirement_tech_feature
|
|===
diff --git a/sources/vol1-diagram-sdpi-req-types-model.pptx b/sources/vol1-diagram-sdpi-req-types-model.pptx
index 2e9a0e1..e45fe7c 100644
Binary files a/sources/vol1-diagram-sdpi-req-types-model.pptx and b/sources/vol1-diagram-sdpi-req-types-model.pptx differ