Minimum Required Terms Sample Clauses

Minimum Required Terms. Your Customer Agreements will, at a minimum, contain terms protective of Microsoft as follows: (1) terms that are at least as protective of Microsoft's intellectual property rights as the terms contained in Section 3(b)(3) and 3(b)(4) above; (2) terms that disclaim, to the extent permitted by applicable law, all warranties by Microsoft and any liability by Microsoft for any damages, whether direct, indirect, or consequential, arising from the use of the Software Services; and (3) terms stating that product support for the Software Services are provided by you or a third party on your behalf and are not provided by Microsoft.

Minimum Required Terms. Conditions (MRTCs) Draft 2‌ A. Fees Under the Transparency section of Draft 2 of the MRTCs, ONC indicates that QHINs will have to make fee schedules available to the RCE. In the Cooperation and Non- Discrimination section of Draft 2 of the MRTCs, ONC lays out additional information about permissible fees:

Minimum Required Terms. The minimum terms required for each Processor or Sub-processor written agreement are set out in Article 24(5)(b), as follows:

Minimum Required Terms. Conditions (MRTC) While the definitions of participants and participant members provide further clarity on intended roles, we are concerned these may be too restrictive. Our concerns include: o There may be multiple levels of participant and participant members, not just two; o Certain HIT Developers may never be Participants or Participant Members as they may only be supporting providers who are the actual Participants or Participant Members such as in eHealth Exchange or many HIEs; o Responsibilities of “actors” may be distributed differently than ONC proposes; o Technology infrastructures may be more decentralized/federated or more centralized. o There needs to be clarity of the embrace for meeting participants where they are and to encourage increased adoption of capable HIT over time, especially providers in market segments grossly underrepresented in trusted health exchange historically. Given those variations and our experience connecting clients across those diverse environments, we suggest ONC not focus on definitions with prescriptive/implied responsibilities to specific roles, but rather that within the QHIN governance, responsibilities, and technical infrastructures address specific participation requirements of the QHIN as whole, where the QHIN determines what kind of entity supports what requirement to collectively operate as a QHIN. We appreciate the wider variety of HINs that can qualify to be a QHIN, recognizing the variety of networks and formats that can make for a successful trusted exchange framework without a substantial first big step to become a QHIN. We also urge ONC to allow for QHINs to play distinct purposes as to purposes of exchange based on their function and scope where possible. We are very concerned with the impression left by the wording on intent of the MRTC that the proposed language, once finalized between the RCE and ONC, is expected to be included “as-is”, thus effectively replacing any existing agreement language that current trusted exchange frameworks have in place (such as Cerner participating in the CommonWell Health Alliance, which in turn connects with other networks within the Carequality framework, and other like arrangements). Change to current agreements, just for the sake of adoption of such prescriptive language, could re-open evaluation of participation by many current members of existing networks, cause stakeholder re-education, induce unnecessary re-alignment, and create re-work without substantial va...