Parts of this should probably be a comment, but apparently I don't rank high enough to do that.
FHIR is premised on the idea of exchanging specific "collections" of information that represent real-world business objects that have state and can reasonably be manipulated as part of a single unit of work. What you're describing doesn't seem to fit into that paradigm (though more information about the specifics of the use-case - e.g. what kinds of key/value pairs, how many are sent, how are they related - would be helpful). In theory the Observation resource can be treated as a simple name/value pair - Observation.name and Observation.value, but I'm not clear that's appropriate for your use-case