Update Quick Start guide based upon feedback (#387)

* spelling fix - add dash to "non secured" 

Fixes #297

* consistent tense in quickstart guide

specifically the enumerated list of steps and corresponding headers of the Building an EHR service section of the document

* Update quickstart.md

Change header from "Building an EHR Service" to "Integrating CDS Services into an EHR"

* SMART app is optional 

Fixes #294

Author: isaacvetter

docs/quickstart.md

@@ -6,13 +6,13 @@ A CDS Hooks scenario typically includes two main actors: an EHR and a CDS Servic
 ![patient-view Hook Overview](images/patient-view-hook-launch_spec.png)
 
 ## Building a CDS Service
-A CDS Service is an external service that responds to EHR requests through cards. There are several steps to setting up a CDS Service: 
+A CDS Service is an external service that responds to EHR requests through cards. A card can optionally link to a SMART app. There are several steps to setting up a CDS Service: 
 
 1. Create an endpoint for discovery
 2. Develop a service
 3. Test the service with the [sandbox](http://sandbox.cds-hooks.org/)
-4. Create a SMART app (or [borrow one](https://apps.smarthealthit.org/apps/pricing/open-source))
-5. Test the service and SMART app with an EHR
+4. If applicable, create a SMART app (or [borrow one](https://apps.smarthealthit.org/apps/pricing/open-source))
+5. Test the service (and, if applicable, SMART app) with an EHR
 
 This tutorial recommends implementing the CDS Hooks [security model](specification/1.0/#security-and-safety) after successful open access testing.
 
@@ -80,20 +80,20 @@ Delete the existing hooks, and then do a quick add with a reference to your CDS
 
 After testing with the sandbox, you are ready to connect with an EHR service.
 
-## Building an EHR Service
+## Integrating CDS Services into an EHR
 Build out following sections:
 
-1. Calls discovery endpoint 
+1. Call discovery endpoint 
 2. Invoke service on patient-view 
-3. Support for FHIR resources on request (context or pre-fetch)
-4. Exposed non-secured FHIR server
+3. Support FHIR resource on CDS requests (context or pre-fetch)
+4. Expose non-secured FHIR server for testing
 5. Render card
 6. Launch SMART app 
-7. Tested with external CDS Service
+7. Test with external CDS Service
 
 This tutorial recommends implementing the CDS Hooks [security model](specification/1.0/#security-and-safety) after successful open access testing.
 
-### Calls discovery endpoint 
+### Call discovery endpoint 
 The CDS discovery endpoint provides the list of services a CDS provider supports, and the hooks a service should be invoked on. An EHR may configure their system to support a set of hooks at a certain location in their users work flow, or build a dynamic capability to interact with a CDS Service provider within a work flow. For the best end-user experience, this guide recommends a business analyst configure which hooks an EHR will support. 
 
 Below is an example work flow where a business analyst accesses this list of available services by calling 
@@ -109,7 +109,7 @@ This image captures a business analyst reviewing services from one CDS provider.
 ### Invoke service on patient-view hook
 The `patient-view` hook is invoked when a patient chart is opened. It's one of the most basic since the logic doesn't have any prior workflow dependencies. The service called on the `patient-view` hook could be dependent on patient characteristics, for example: sex, problems in problems list, active medications, etc. The current version of the CDS Hooks specification allows the EHR to decide which characteristics to consider. 
 
-### Support for FHIR resources on request or prefetch
+### Support FHIR resource on CDS requests (context or pre-fetch)
 Often a CDS Service will require additional information from the EHR to perform the decision support logic, or determine the appropriate SMART app to return. Prefetch provides the EHR the capability to pass a resource when invoking a service. For example, with a patient resource included a service could do a geography search for potential environmental risk factors. Below is an example request invoked on patient-view with a patient included: 
 
 ```json
@@ -140,8 +140,8 @@ In some cases, additional information beyond what is included in the prefetch ma
 
 It is recommended FHIR servers implement, and CDS Services follow, locale specific implementation guides. In the US, the recommended implementation guides to follow are the [Argonaut Data Query Guide (DSTU2)](http://www.fhir.org/guides/argonaut/r2/) or [HL7 US Core (STU3)](http://hl7.org/fhir/us/core/index.html). Each profile page within these implementation guides includes queries FHIR servers are required to support. 
 
-### Exposed non-secured FHIR server
-A non secured FHIR server is important to support testing with a CDS Service. When the EHR moves a hook to production the system is expected to follow the guidelines in the [security](specification/1.0/#security-and-safety) requirements.
+### Expose non-secured FHIR server for testing
+A non-secured FHIR server is important to support testing with a CDS Service. When the EHR moves a hook to production the system is expected to follow the guidelines in the [security](specification/1.0/#security-and-safety) requirements.
 
 ### Render card
 The CDS Service will provide a response in the form a of a 'card'. Your EHR needs to be able to display the card.
@@ -174,7 +174,7 @@ Example card rendered: ![Card with SMART App link](images/Bilirubin_SMART_App_Ca
 
 For some CDS Services the end step will just display the card. For the patient-view hook discussed here, we are focused on launching a SMART app. The CDS Hooks guide places no additional constraints for launching a SMART app beyond those from [SMART on FHIR](http://docs.smarthealthit.org/authorization/). 
 
-## Test with an external CDS Service
+## Test with external CDS Service
 
 No development is complete without testing with a CDS Service provider. Find a member in the [community](community) and test away.