We appreciate NDH's inclusion of IHE profiling and work in the mCSD profile and Topologies whitepaper in the section on discovery of endpoints: 3.6 Discovery a HIE Endpoint via the NDH. Please make the following corrections: Please reference the IHE Topologies whitepaper ( https://profiles.ihe.net/ITI/papers/Topologies/index.html ), as it provides essential guidance for accomplishing this use case. Key sections: 4.2.2 Indicating Document Sharing Connectivity describes the meanings of the codes HIEInitiator and HIEResponder add clarification regardng meaing of HIEInitiator and HIEResponder 4.2.6 Directory Perspective  https://profiles.ihe.net/ITI/papers/Topologies/index.html#426-directory-perspective  walks through representing a multi-level network include relevant description from the white papers to clarify the topologies note 5.1.8 Document Access: Putting it all together shows an example with all the IHE profiling. include relevant description from the white papers to clarify the topologies noted The organizations 1.3.4 and 2.4.1 are not specific to Sutter, they represent the entire exchanges TEFCA and Carequality respectively. This is critical to the discovery approach; if interested in members of an HIE, start with the organization for that HIE and search for OrganizationAffiliations with the code HIEResponder. The full algorithm for discovering an endpoint is here:  https://profiles.ihe.net/ITI/papers/Topologies/index.html#4242-service-provider-endpoint-discovery-algorithm use carequality and tefca not Sutter in the diagram There is another part to this, which is discovering whether an organization is eligible to act as a client in an HIE. This is done with the code HIEInitiator. Please add this. There is another part to this, which is discovering when an organization is reachable electronically, but only indirectly, through the endpoint of a related organization. This is the case with numerous IHE profiles for federated SOAP APIs like XCPD and XCA, and is indicated with the code DocShare-federate, defined in IHE mCSD. Please add this. Note that with these methods for HIE Endpoint discovery, for HIEs that manage private PKIs (e.g. eHealth Exchange, Carequality, DirectTrust and TEFCA) there is no need for the Endpoint.trust-framework extension, so please make that clear in guidance. Organizations already have the public certificates through HIE onboarding; this is not something they discover at runtime. See this discussion:  https://chat.fhir.org/#narrow/stream/283066-united-states.2Fnational-directory/topic/Requirements.20for.20trust.20communities.2Fframeworks add explanation and examples There are numerous typos, e.g. "Endpoinhts", "prfiled", "Discovery a HIE Endpoint"   fix the typos