Thanks for all the suggestions and references. As I understand it, Fluxstream is a data aggregator, but NOT a data normalizer. So if you say have sleep data from a fitband and from say a Zeo, they are not related together ... they are just separate data and you have to figure out how they relate.
i2b2 and Open mHealth establish a normalized set of data attributes, and in particular in Open mHealth's case, data extracted from measuring devices and data input manually get normalized into a common set of attribute/value pairs ... so said example of sleep data from two different sources would get stored in the database as identical data "side-by-side". i2b2 has an ontology for its data, while Open mHealth is pretty "flat".
Then there are all the developments that Apple's HealthKit is opening up on the iOS side of things, with its own rather flat ontology.
But those draw also from references to several national patient medical ontologies. Plus the ones that patbuen just mentioned. So really, there are TOO MANY ontologies to choose from for normalizing measurements and observations of the human condition.
So, I've decided to go simpler. My root data structure will be a completely flat set of normalized attributes and values without any requirement for an ontology. I can draw data from any ontology (aka from any of Open mHealth, i2b2, Fluxstream, Healthkit, Fitbit, Zeo, Jawbone, electronic scales, manual data entry ... whatever), and it all gets stored "atomically". So I can import from anything, and it gets normalized so say "body-weight" from any source (manual or measuring device) is always stored as "body-weight".
Information that was imported together under some notion of an ontology (for example a "body-weight" and a "body-fat-%" measurement from an advanced scale, or for example systolic and diastolic blood pressure measurements including meta data about which device was used and what posture the person had) is marked as related for only those specific measurements. So my dataset does not demand any pre-established ontology of related or hierarchical or categorized attributes within a measurement. Its just accepts what is given, stores it atomically, and links together only attributes and meta-data that were gathered together. So each measurement can come from a different ontology; that original ontology can be re-created, or a different ontology can be composed from the "atomic data".
Exporting into a framework like Open mHealth or i2b2 or Fluxstream or HealthKit just means the atomic data will be "bundled" into whatever ontology that framework chooses to impose. And similarly, exporting into a local analytic tool like Excel or SPSS, the end-user can create their own ontology to organize the "atomic data" any way they wish.
In effect, my solution is pretty close to Open mHealth's approach, as they are pretty "atomic" as well. But they are missing ALOT of attributes since I need nutritional attributes (for food/drink eaten), exercise/activity attributes that are pretty specific (for say run/hike/bike app imports and for exercise tracker app imports), sleep attributes (something I know alot about since I wrote an App for the Zeo Mobile headbands), demographic attributes. Open mHealth is mostly right now focused only on Vitals attributes.
So I've created a master root of attributes, and I'm drawing them from Open mHealth, i2b2, bioportal.bioontology.org, HealthKit. Thus I'm ensuring as much as possible that I can pull data into an "atomic normalized" set of attributes, and push data back in whatever ontologies are required.
Open mHealth's schema's are in one sense a bit "chubby" (not well suited for an App-sized database) but on the other hand quite narrow in completeness and lack of internationalization support. I'm starting from the outset for the App and all its root definitions to be internationally localized in terms of language, so I'm not using their schema's directly. But I could create literally 100's of schema's for them in an automated manner for the attributes they are missing.
I've learned alot in a very short while about the state of the national patient databases and their pretty uniform ontology standards versus the App-level health data ontology standards that are fractured. Thanks for all the citations (and those citations in many cases point to other national-level citations).
Back to writing code.