{
  "resourceType": "StructureDefinition",
  "url": "http://example.org/fhir/StructureDefinition/SDCObservation",
  "name": "SDCObservation",
  "status": "draft",
  "fhirVersion": "4.0.0",
  "kind": "resource",
  "abstract": false,
  "type": "Observation",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Observation",
  "derivation": "constraint",
  "differential": {
    "element": [
      {
        "id": "Observation.identifier",
        "path": "Observation.identifier",
        "comment": "This should map to the identifier for the document reference it was derived from that contains an SDC form and appended with the QuestionID e.g. formID.formInstanceVersionURI.QuestionID."
      },
      {
        "id": "Observation.code",
        "path": "Observation.code",
        "comment": "Observation code should be defined based on the SDC QuestionID. \r\n\r\n*All* code-value and, if present, component.code-component.value pairs need to be taken into account to correctly understand the meaning of the observation."
      },
      {
        "id": "Observation.value[x]",
        "path": "Observation.value[x]",
        "comment": "The answer from the form should ideally be captured as a valueCodeableConcept including the AnswerID of the question and display value. There are use cases such as quantity, where other types may be appropriate.\r\n\r\nAn observation may have; 1)  a single value here, 2)  both a value and a set of related or component values,  or 3)  only a set of related or component values. If a value is present, the datatype for this element should be determined by Observation.code.  A CodeableConcept with just a text would be used instead of a string if the field was usually coded, or if the type associated with the Observation.code defines a coded value.  For additional guidance, see the [Notes section](observation.html#notes) below."
      },
      {
        "id": "Observation.bodySite",
        "path": "Observation.bodySite",
        "comment": "bodySite should be defined by the form's defined site.\r\n\r\nOnly used if not implicit in code found in Observation.code.  In many systems, this may be represented as a related observation instead of an inline component.   \n\nIf the use case requires BodySite to be handled as a separate resource (e.g. to identify and track separately) then use the standard extension[ bodySite](extension-bodysite.html)."
      },
      {
        "id": "Observation.hasMember",
        "path": "Observation.hasMember",
        "comment": "Observation has child questions and answers that are referenced via this element.\r\n\r\nWhen using this element, an observation will typically have either a value or a set of related resources, although both may be present in some cases.  For a discussion on the ways Observations can assembled in groups together, see [Notes](observation.html#obsgrouping) below.  Note that a system may calculate results from [QuestionnaireResponse](questionnaireresponse.html)  into a final score and represent the score as an Observation."
      },
      {
        "id": "Observation.derivedFrom",
        "path": "Observation.derivedFrom",
        "comment": "Observation has parent questions and answers that are referenced via this element\r\n\r\nAll the reference choices that are listed in this element can represent clinical observations and other measurements that may be the source for a derived value.  The most common reference will be another Observation.  For a discussion on the ways Observations can assembled in groups together, see [Notes](observation.html#obsgrouping) below."
      },
      {
        "id": "Observation.component",
        "path": "Observation.component",
        "comment": "Obvservations should contain component codes with the the answers. Multiple components must be used for multiple answers to a single question (e.g. a multiselect question)\r\n\r\nFor a discussion on the ways Observations can be assembled in groups together see [Notes](observation.html#notes) below."
      }
    ]
  }
}