Fixed formatting and added recommended changes

- updated files to be more uniform

adr/002-java.md

@@ -4,7 +4,8 @@ Date: 2022-10-21
 
 ## Decision
 
-We will use Java 17 for the main trusted intermediary code.
+We will use Java 17 for the main intermediary code.
+
 This doesn't preclude us from using other languages for other services or applications.
 
 ## Status
@@ -13,27 +14,30 @@ Accepted.
 
 ## Context
 
-We decided to use a JVM based language because it has many third-party healthcare libraries and frameworks.
+We decided to use a Java Virtual Machine- (JVM) based language because it has many third-party healthcare libraries and frameworks that are pertinent to the project. 
 
 We decided on Java over Kotlin, Scala, and Groovy because more people know Java.
 
 ## Impact
 
 ### Positive
 
-- Has robust libraries, like HAPI FHIR, which provide comprehensive support for creating, parsing, and validating FHIR resources.
-- Libraries are well-maintained and widely used in the healthcare industry.
-- Ability to handle large-scale, multi-threaded applications makes it suitable for processing large volumes of FHIR data in real-time, which is crucial in healthcare settings.
-- Java's security features, such as encryption and secure authentication mechanisms, help in building HIPAA-compliant FHIR applications.
+- **Robust and Well-Maintained Libraries:** has robust libraries, like HAPI FHIR, which provide comprehensive support for creating, parsing, and validating FHIR resources. Libraries are well-maintained and widely used in the healthcare industry
+
+
+- **Powerful Data Processing:** ability to handle large-scale, multithreaded applications makes it suitable for processing large volumes of FHIR data in real-time, which is crucial in healthcare settings
+
+
+- **Compliant Security Features:** Java's security features, such as encryption and secure authentication mechanisms, help in building HIPAA-compliant FHIR applications.
 
 ### Negative
 
-- Code tends to be more verbose leading to longer development times and more boilerplate code.
-- Code tends to be more verbose which can lead to longer development times and more boilerplate code.
+- **Verbose Code:** Code tends to be more verbose leading to longer development times and more boilerplate code.
+
 
 ### Risks
 
-- Limited functional programming capabilities can make it harder to express certain data transformation logic that is common in FHIR processing, compared to languages with stronger functional programming support.
+- **Limited Functional Expression:** Limited functional programming capabilities can make it harder to express certain data transformation logic that is common in FHIR processing, compared to languages with stronger functional programming support.
 
 ### Related Issues
 

adr/003-gradle.md

@@ -4,37 +4,49 @@ Date: 2022-10-24
 
 ## Decision
 
-We will use the [Gradle build tool](https://gradle.org) for the main trusted intermediary code.
+We will use the [Gradle build tool](https://gradle.org) for the main intermediary code.
 
 ## Status
 
 Accepted.
 
 ## Context
 
-[Maven](https://maven.apache.org) is the other big option available to us.  Gradle was chosen over Maven because
-- it uses Groovy, an actual programming language, to configure the projects instead of XML, which has a rigidly defined schema.
-  This allows for better expressibility in how one configures their project.
+Other build tools were considered; [Maven](https://maven.apache.org) is the other big option available to us.  Gradle was chosen over Maven because
+- Gradle uses Groovy, an actual programming language, to configure the projects instead of XML (Extensible Markup Language), which has a rigidly defined schema.
+
+
+- Gradle allows for diversity in configuration of the project.
+
+
 - Gradle is faster with its job execution.
 
 
 ## Impact
 
 ### Positive
 
-- Advanced dependency management capabilities help streamline the integration of FHIR libraries, such as HAPI FHIR, and other required dependencies.
-- Highly customizable build scripts allow for fine-tuned configuration
-- Reduced build times
-- Integrates well with continuous integration and continuous deployment (CI/CD) pipelines, enabling automated testing
+- **Advanced Dependency Management** capabilities help streamline the integration of FHIR libraries, such as HAPI FHIR, and other required dependencies
+
+
+- **Highly Customizable Scripts:** Highly customizable build scripts allow for fine-tuned configuration.
+
+
+- **Reduced build times**
+
+
+- **CI/CD Automation:** integrates well with continuous integration and continuous deployment (CI/CD) pipelines, enabling automated testing
 
 ### Negative
 
-- Flexibility can lead to complex and verbose build scripts; Managing these scripts can become cumbersome
-- Custom configurations may not be fully compatible with certain versions of Java or FHIR libraries
+- **Cumbersome Build Scripts:** Flexibility can lead to complex and verbose build scripts; Managing these scripts can become cumbersome.
+
+
+- **Configuration Incompatibility:** Custom configurations may not be fully compatible with certain versions of Java or FHIR libraries.
 
 ### Risks
 
-- Possible slow build times due to scripts and project size
+- **Possible Slow Build Times** due to scripts and project size
 
 ## Related Issues
 

adr/004-groovy-spock.md

@@ -4,19 +4,22 @@ Date: 2022-10-24
 
 ## Decision
 
-We will use the [Groovy programming language](http://groovy-lang.org) with the
-[Spock testing framework](https://spockframework.org) for our unit and end-to-end testing.
+We will use the [Groovy programming language](http://groovy-lang.org) with the [Spock testing framework](https://spockframework.org) for our unit and end-to-end testing.
 
 ## Status
 
 Accepted.
 
 ## Context
 
-Spock is a testing framework similar to [JUnit](https://junit.org/junit5/).  Some benefits of Spock include...
+Spock is a testing framework similar to [JUnit](https://junit.org/junit5/).  Some benefits of Spock include: 
+
 - Encourages BDD-style given/when/then testing.
+
 - Mocking is _super_ easy.  No need for a separate dependency like [Mockito](https://site.mockito.org).
+
 - Expressive assertion failures.  No need for a separate dependency like [Google Truth](https://truth.dev).
+
 - Adds a layer of flexibility and expressiveness to testing that you don't get with JUnit.
 
 Spock requires we use Groovy, another JVM-based language.
@@ -25,18 +28,25 @@ Spock requires we use Groovy, another JVM-based language.
 
 ### Positive
 
-- Expressive and readable tests
-- Supports data-driven testing which is useful for testing FHIR resources across a variety of scenarios with different data sets
-- Integrates well with Java
+- **Expressive and readable tests**
+
+
+- **Data-driven Testing:** supports data-driven testing which is useful for testing FHIR resources across a variety of scenarios with different data sets
+
+
+- **Integrates well with Java**
 
 ### Negative
 
-- Limited IDE support
+- **Limited IDE Support:** writing and debugging tests can become cumbersome 
 
 ### Risks
 
-- Tests can run slow
-- Dependency management difficulties
+- **Slower Test Execution:** Tests can potentially run slower compared to simpler JUnit tests, especially for larger test suites. 
+
+
+- **Dependency Management:** Managing Groovy dependencies alongside Java libraries may introduce complexity or compatibility issues in certain build environments.
+
 
 ## Related Issues
 

adr/006-domain-plugin.md

@@ -4,41 +4,45 @@ Date: 2022-10-24
 
 ## Decision
 
-A plugin paradigm (plugin-based architecture) will be used for the different business domains of the trusted intermediary.  This improves
-modularity, separates concerns, and allows for flexibility in the future if it makes sense to extract this domain
-into a separate JAR, Gradle project, or even repository.
+A plugin paradigm (plugin-based architecture) will be used for the different business domains of the intermediary. This improves modularity, separates concerns, and allows for flexibility in the future if it makes sense to extract this domain into a separate JAR, Gradle project, or even repository.
 
 ## Status
 
 Accepted.
 
 ## Context
 
-The trusted intermediary useful for just one business domain.  There are multiple areas in healthcare where
-a trusted intermediary could be beneficial.  To that end, a plugin paradigm is used to register domain(s) with the
-larger trusted intermediary application.  This also allows the domain to develop and operate regardless how the
-trusted intermediary operates.  E.g. Is the trusted intermediary in a Jetty Java container hosted on a VM or is it
-hosted in Azure Functions?
+The intermediary currently serves a single business domain, but it has the potential to support multiple domains in healthcare where a intermediary is beneficial. To accommodate this, we will adopt a plugin-based architecture that allows new domains to be registered with the intermediary. This approach enables each domain to be developed and operated independently of the intermediary’s core system.
+
+This independence also applies to the intermediary’s deployment environment, whether the intermediary is running in a Jetty Java container on a VM, or hosted within Azure Functions, the plugin paradigm ensures that domain logic remains unaffected and adaptable to various operational contexts.
 
 ## Impact
 
 ### Positive
 
-Encapsulation of domain-specific logic: Ensuring isolation of concerns; Core application logic remains unaffected
-Reusability: Plugins can be reused reducing duplication
-Flexibility: Domains can evolve independently and potentially be extracted into separate projects.
-Targeted testing: Focused unit and integration testing
+- **Encapsulation of domain-specific logic** ensuring isolation of concerns; Core application logic remains unaffected.
+
+
+- **Reusability:** Plugins can be reused reducing duplication.
+
+
+- **Flexibility:** Domains can evolve independently and potentially be extracted into separate projects.
+
+
+- **Targeted Testing:** focused unit and integration testing
 
 
 ### Negative 
 
-- Increased complexity: Managing multiple plugins can increase architectural complexity over time, especially with the addition of features.
-- Dependency management challenges: Ensuring compatibility across multiple version can become cumbersome
+- **Increased Complexity:** Managing multiple plugins can increase architectural complexity over time, especially with the addition of features.
+
+- **Dependency Management Challenges:** Ensuring compatibility across multiple versions can become cumbersome.
 
 
 ### Risks
-- Maintenance burden: Possible increased maintenance burden which can require more rigorous testing
-- Fragmentation: Increased possibility for inconsistencies across the system due to varying approaches
+- **Maintenance Burden:** possible increased maintenance burden which can require more rigorous testing
+
+- **Fragmentation Risk:** increased possibility for inconsistencies across the system due to varying approaches
 
 ## Related Issues