Merge pull request #446 from cds-hooks/issue/249-267-limitations

Remove limitations section as the content is duplicated further in the spec.

Author: kpshek

docs/specification/1.0.md

@@ -10,12 +10,6 @@ The CDS Hooks specification describes the RESTful APIs and interactions to integ
 ### Conformance Language
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119](https://tools.ietf.org/html/rfc2119).
 
-### Limitations
-This specification has the following limitations.
-
-* The specification provides options for providing a CDS Service access to the EHR's FHIR resources through use of either prefetch and/or a bearer access token to be presented to the FHIR Server.  Decisions regarding which approach to take, and details regarding how the choice is implemented, are left up to the EHR vendor/provider, as architectural considerations will come into play.
-* The specification acknowledges that each EHR vendor/provider will need to vet CDS Service providers and suggests that vendors/providers create a "white list" of providers deemed "safe" and/or a "black list" of providers deemed "unsafe."  Similarly, an EHR vendor/provider MAY assess the safety of active links embedded in CDS Hooks Cards returned to the EHR.  The specification does not suggest how such vetting is accomplished nor suggest factors to consider, as these judgments are dependent upon each EHR vendor's or provider's existing vetting processes and risk-management policy.
-
 ## Open API Specification
 
 An [Open API Specification](https://www.openapis.org/) (formally known as the Swagger Specification) interface of CDS Hooks is available. The open source Open API Specification defines a programming language-agnostic method to describe a RESTful API like CDS Hooks. The Open API Specification is used by many projects and is supported by CDS Hooks for the benefit of implementers.