Observations are usually defined in distinct manners, this includes, the method of collection of observation, what unit it is collected in, interpretations of the observation result and so on. Questionnaires rely on observation definitions to make its job easier, this also allows instances to have a central repository of their master data.
Using Observation Definitions in questionnaire ensures that standards are used when a particular observation is captured across questionnaires.
A single observation code can have multiple definitions.
Care will allow observation definitions to be made at an instance level and at a facility level. Observation Definitions once created cannot be destroyed, only moved into the entered-in-error status.
The MVP of this spec can be limited, more features can be added to this spec as needed to improve the data collection quality
The idea is that you can add observation definitions instead of questions in a questionnaire. ie instead of adding a question for blood pressure, you can specify two options for blood pressure, ie Blood pressure from Cuff based monitor or Blood pressure from a device. Each of these would have a separate reference set and possibly a different unit.
Care at this point will not support converting between units when displaying data. This is supported based on UCUM principles as everything is expressed in terms of a base unit. this feature can be added later on.
Observation definitions can be infinitely complex allowing for different interpretations based on the condition that the patient is in. These can be built as and when needed.
The spec for an observation definition is as follows, its loosely based on the FHIR Spec for the same
{
"id" : "<string>", // Internal identifier
"facility" : "<reference>" // Reference to facility if present, if not present, defenition is instance wide
"version" : "<string>", // Automatically assigned version number
"slug" : "<string>" // To maintain uniqueness in a given facility
"title" : "<string>", // Name for this ObservationDefinition (human friendly)
"status" : "<code>", // Options draft | active | retired | unknown
"description" : "<markdown>", // Natural language description of the ObservationDefinition
"derivedFromUri" : "<uri>", // Is this observation defenition created based on an external URI
"category" : "<code>", // Code for observation type
"code" : "<code>", // Code for observation, ie what is being observed
"permittedDataType" : "<code>", // From Questionnaire
"bodySite" : "<code>", // Body part to be observed
"method" : "<code>", // Method used to produce the observation
"permittedUnit" : "<code>", // Unit for quantitative results
"component" : [{ // Component results
"code" : "<code>", // What is being observed
"permittedDataType" : "<code>", // From Questionnaire
"permittedUnit" : "<code>", // I Unit for quantitative results
}]
}
The spec for observation definition is awfully close to a questionnaire itself. Components can help simplify how data is collected in a questionnaire, there is a very fine line in FHIR on how a questionnaire and Observation definition is treated, we have modified the spec to support ease of use, the data created by care remains translatable to FHIR at all times.
V2 to include https://build.fhir.org/observationdefinition-definitions.html#ObservationDefinition.qualifiedValue