One of the things that I've been looking at recently is personal health data stored in consumer apps and wearable devices. Most of the details here amount to a FHIR Observation of some sort, with a code to describe the data element (and a value as a code, or quantity, or perhaps even a waveform). We know that codes are computer friendly, but they aren't people friendly (and software developers ARE people, regardless of what others might tell you).
So, when everything is an observation, it gets messy for software developers who want nice, easy to remember mnemonics and JSON stuff that is focused right where they are focused. Things that FHIR can capture and store, but maybe FHIR isn't actually the right place for those working in this space.
PCHA and Continua have some specifications in this space too, but again, NOT easy for developers to use, because once again, too much focus on the terminology, and not on what the developer is trying to do.
We need to find a way to move terminology out of the way. Open mHealth looks like it's at a better place for this space, but folks who've invested heavily in FHIR and other standards don't agree. But wait, what if those developers aren't my audience? What then?
It all depends on your field of view. And mine, as usual, is many and varied.
-- Keith
openMHealth is useful because it ducks the complexity of terminology and profiles. openMHealth won't scale the way FHIR does because it ducks terminology and profiles. I think the right arrangement is for openMHealth to be mapped to FHIR well enough to support a bi-directional transform, so that you can use one as a facade to the other (depending on your use case which way round it would be)
ReplyDelete