diff --git a/source/playbook/design_principles.html.erb b/source/playbook/design_principles.html.erb
index 6d73232..8f75088 100644
--- a/source/playbook/design_principles.html.erb
+++ b/source/playbook/design_principles.html.erb
@@ -13,49 +13,48 @@ theme: playbook
Design Principles
- Below are principles that have guided the <%= link_to("CodeX HL7 FHIR Accelerator Community","https://confluence.hl7.org/display/COD/CodeX+Home") %> and in the design, planning, development, testing, adoption, and value of FHIR-based data standards, including <%= link_to("mCODE","https://confluence.hl7.org/display/COD/mCODE") %>. These principles guide and are elaborated upon in the <%= link_to("Playbook Tracks", "index.html#organization") %> and <%= link_to("Case Studies", "/casestudies/index.html") %>. If additional specialties follow these principles, the resulting standards are more likely to be developed efficiently, to be compatible across specialties as part of each patient's life-time health, to be adopted in practice, and to provide value for patients and all stakeholders.
+ Below are principles that have guided the <%= link_to("CodeX HL7 FHIR Accelerator","https://confluence.hl7.org/display/COD/CodeX+Home") %> through the design, planning, development, testing, and adoption of FHIR-based data standards. These principles guide and are elaborated upon in the <%= link_to("Playbook Tracks", "index.html#organization") %> and <%= link_to("Case Studies", "/casestudies/index.html") %>. If specialty communities follow these principles, the resultant standards can be developed more efficiently, will be more compatible with other aspects of the patient's health records, have better adoption, and improve healthcare experiences for all.
- - A dedicated and diverse <%= link_to("community", "community.html") %> is essential to the design and execution of a health data standards project.
+
- A dedicated and diverse <%= link_to("community", "community.html") %> is essential.
- - Each use case needs committed representation from all stakeholders needed to drive the use case (e.g., patients, providers, health systems, Gov’t agencies, vendors, payers, and others).
+ - Each use case needs representation from all stakeholders (e.g., patients, providers, health systems, Gov’t agencies, vendors, payers, and others).
- - Compelling <%= link_to("use cases", "use_cases_planning.html") %> are the foundation upon which solutions are designed and driven.
+
- Compelling <%= link_to("use cases", "use_cases_planning.html") %> are the foundation for solutions.
- - Define each use case as a project that addresses a single, important, narrowly focused problem.
- - Build a use case plan that is end-to-end - including the scope, resources, data requirements, and a pragmatic strategy for how standards will be adopted and provide value in the real world.
- - Prioritize use cases that address salient challenges. However, start with simpler (not simple) use cases that have commitment from all the community members needed to succeed.
- - Prioritize use cases that improve collection and sharing of quality, core, standardized data related to patient care and outcomes should be the top priority.
+ - Each use case should address a single, important, narrowly-focused problem.
+ - Plan with the end in mind. Comprehensive plans include the scope, resources, data requirements, and a pragmatic strategy for how standards will be adopted and provide real-world value.
+ - Prioritize critical community challenges. However, start with simpler use cases that have a commitment from the community.
+ - Use cases that improve collection and sharing of data related to patient care and outcomes should be the top priority.
- <%= link_to("Clinical information requirements", "standards.html#clinical_requirements") %> are a first priority for each use case.
- - Build consensus within a diverse team of clinical experts on the minimal data requirements needed to address core use case requirements.
- - Define clinical requirements as discrete observations and actions (e.g., patient birth date = 11/04/1989 vs. patient is 34 years old).
- - If previous work in the space exists, seek to work with the other initiatives and adapt their work rather than re-do.
+ - Build consensus within a diverse team of clinical experts on the minimal data requirements needed to address the use case.
+ - Clinical requirements should be discrete observations and actions (e.g., patient birth date = 11/04/1989 vs. patient is 34 years old).
+ - Seek to collaborate with the other initiatives and adapt their work rather than re-do.
- - How clinical requirements are represented in <%= link_to("FHIR Implementation Guides (IG)", "standards.html#fhir_ig_development") %> influence their useability, and their interoperability across specialties.
+
- A use case's <%= link_to("FHIR Implementation Guide (IG)", "standards.html#fhir_ig_development") %> influences its useability, interoperability, and thus value to adopters.
- - Develop first a single, core IG that represents the minimal clinical requirements for small set of use cases concepts common within the specialty. This core IG can be improved upon as use cases are executed and supplemented within related IGs when data requirements are important for just a small subset of the community.
- - Leverage government-backed interoperability standards whenever possible, e.g., United States Core Data for Interoperability (USCDI), Fast Healthcare Interoperability Resources (FHIR), US Core FHIR Implementation Guide for core patient data, and others.
- - Leverage the available tools (see the <%= link_to("Resources page", "/resources/index.html") %>) for modeling and IG development, to produce higher-quality FHIR IGs that are more coherent across specialties, use cases, and projects.
- - Leverage global code systems and terminology standards (e.g., LOINC, SNOMED CT, CPT, and other systems).
- - Standardize work through an open, royalty-free health standards development organization, preferably Health Level Seven (HL7).
+ - Develop first a single, core IG that represents the minimal clinical requirements for small set of use cases. This core IG can be expanded upon as use cases are executed and supplemented by related IGs when data requirements are important for just a small subset of the community.
+ - Leverage government-backed interoperability standards (United States Core Data for Interoperability (USCDI) and US Core FHIR Implementation Guide) and global code systems and terminology standards (LOINC, SNOMED CT, CPT, etc.).
+ - Leverage the available tools (see the <%= link_to("Resources page", "/resources/index.html") %>) to produce high-quality FHIR IGs that are coherent across specialties, use cases, and projects.
+ - Publish work through an open, royalty-free health standards organization, preferably Health Level Seven (HL7).
- - Build use cases within a vision of a coherent lifetime <%= link_to("Standard Health Record", "/resources/tech-standards.html#fhir_additional_considerations") %> for every patient.
+
- Build use cases within a vision of a comprehensive lifetime <%= link_to("Standard Health Record", "/resources/tech-standards.html#fhir_additional_considerations") %> for every patient.
- - Enable standardized data to become the basis for every patient's health record and standard of care.
-
- Empower patients to be engaged with and have control of their health data.
- - Collect patient data once (generally around the encounter) and reuse it for future patient encounters and multiple use cases.
- - Enable consistent representation of health data concepts that could be used across specialties, subspecialties, and use cases.
+ - Enable standardized data to become the foundation for every patient's health records and care.
+
- Empower patients to engaged and control their health data.
+ - Collect data once and reuse it for future needs and other use cases.
+ - Enable consistent representation of health data that can be used across specialties, subspecialties, and use cases.