Support obs.interpretation and obs.status, aligned with FHIR

Background

Currently if you want to store whether an obs's value is normal or abnormal, you need to put that obs in an obs group with another obs indicating its abnormality. This is awkward to work with, and hard to query against.

FHIR supports an "interpretation" field on its observation resource that lets you indicate this as part of the obs itself: http://www.hl7.org/fhir/observation-definitions.html#Observation.interpretation

While we're adding one column to the obs table (and maybe causing large implementations to need to take manual upgrade steps), let's also add a second "status" column: https://www.hl7.org/fhir/observation-definitions.html#Observation.status

Proposal

• Add a (short) varchar `obs.interpretation` column.
  • This field is optional, but constrained by the API to certain values (not constrained in the DB)
  • maybe we will allow all values defined by FHIR at http://www.hl7.org/fhir/valueset-observation-interpretation.html
  • maybe we will limit to the subset proposed by jteich at https://docs.google.com/document/d/1nIA6PqI45-WgAZ6Cfu9CHPK6BVdbt3gw6fenj1Vuq00/edit
• Add a (short) varchar `obs.status` column.
  • This field is required, and constrained to the values "preliminary", "final", "amended"
  • The default value should be "final" (this should apply to existing obs, in a migration. also the API should default to final when creating new obs, for backwards-compatibility)

Extra Credit

Ideally, when the user edits an obs whose status is final (and the system voids-and-creates-new) the new obs should have status = amended.

Out of Scope

For now we will not support obs.status of "registered" or "cancelled", because this would imply we need to allow obs with null values, and this would be a huge change for client code.