15

We are currently in the process of evaluating FHIR for use as part of our medical record infrastructure. For the EHR data (Allergies, Visits, Rx, etc..) the HL7 FHIR seems to have an appropriate mapping.

However, lots of data that we deal with is related to personal Fitness - think Fitbit or Apple HealthKit:

  • Active exercise (aerobic or workout): quantity, energy, heart-rate
  • Routine activities such as daily steps or water consumption
  • Sleep patterns/quality (odd case of inter-lapping states within the same timespan)
  • Other user-provided: emotional rating, eating activity, women's health, UV

While there is the Observation resource, this still seems best fit (!) for the EHR domain. In particular, the user fitness data is not collected during a visit and is not human-verified.

The goal is to find a "standardized FIHR way" to model this sort of data.

  • Use an Observation (?) with Extensions? Profiles? Domain-specific rules?

    FHIR allows extraordinary flexibility, but each extension/profile may increase the cost of being able to exchange the resource directly later.

    An explanation on the appropriate use of an FHIR resource - including when to Extend, use Profiles/tags, or encode differentiation via Coded values - would be useful.

  • Define a new/custom Resource type?

    FHIR DSTU2 does not define a way to define a new Resource type. Wanting to do so may indicate that the role of resources - logical concept vs. an implementation interface? - is not understood.

  • Don't use FHIR at all? Don't use FHIR except on summary interchanges?

    It could also be the case that FHIR is not suitable for our messaging format. But would it be any "worse" to go FIHRa <-> FIHRb than x <-> FIHRc when dealing with external interoperability?

The FHIR Registry did not seem to contain any User-Fitness specific Observation Profiles and none of the Proposed Resources seem to add appropriate resource-refinements.

At the end of the day, it would be nice to be able to claim to be able to - with minimal or no translation, ie. in a "standard manner" - be able to exchange User Fitness data as an FHIR stream.

Innat
  • 16,113
  • 6
  • 53
  • 101
user2864740
  • 60,010
  • 15
  • 145
  • 220
  • Is there something in the documentation of Observation that leads you to believe that it either needs to be collected during a visit or human-verified? It might also be helpful if you submitted a change request seeking explicit inclusion of some of these activities as well as examples in the specification to make it more obvious that this is an intended use of Observation. – Lloyd McKenzie Mar 06 '16 at 15:17
  • @LloydMcKenzie I'm not sold that a change to an Observation (or adding a new Resource) meets the [FHIR ethos](http://wiki.hl7.org/index.php?title=FHIR_Guide_to_Designing_Resources) - looking for a good answer one way or another. Observations have an [Observation Status](https://www.hl7.org/fhir/valueset-observation-status.html) where "Final" seems to mandate human-approval. Also, [the specification](https://www.hl7.org/fhir/observation.html) did not provide an example to indicate general fitness data was a primary use case; the examples are clinical in nature. – user2864740 Mar 07 '16 at 08:51
  • 1
    I've raised tracker http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&feedback=Successfully+added+%5B%239675%5D&tracker_id=677 to address the status issue. There will be a variety of observations where no human review will be involved. I'd encourage you to raise a tracker proposing additional examples in this space. – Lloyd McKenzie Mar 07 '16 at 16:03

1 Answers1

13

Certainly the intent is to use Observation, and there's lots of projects already doing this.

There's no need for extensions, it's just a straight forward use. Note that this: " In particular the user fitness data is not collected during a visit and is not human-verified" doesn't matter. There's lots of EHR data of dubious provenance...

You just need to use the right codes, and bingo, it all works. I've provided a bit more detail to the answer here: http://www.healthintersections.com.au/?p=2487

Grahame Grieve
  • 3,538
  • 3
  • 15
  • 17
  • Thanks for the response. Those make a good bit of sense for single-value entries. However, aggregates are still problematic, for example: 1) sleep patterns (for which there can be multiple overlapping segments of "type"); 2a) exercises / workouts (for which there can be different 'segments' containing correlated samples); 2b) pulse as a single observation or part of an exercise; 3) diet and woman's health (which contains compound/correlated data). – user2864740 Mar 07 '16 at 08:41
  • Even Weight+BMI+Waist might be considered a single aggregate; it's much less defined that merely a Systolic/Diastolic pair. Being able to find published implicit/explicit "profiles" (and the rules that such define) would be ideal. – user2864740 Mar 07 '16 at 08:47
  • 1
    Observation supports creation of aggregates. This can be seen in blood panels, scores like apgar and genomic observations. But agree it would be good to have an example or two from the personal measurement space. I'd encourage you to submit a change proposal to add some. (And if you want to provide some sample data to use, that would be great too :)) – Lloyd McKenzie Mar 07 '16 at 16:10
  • Thanks for the answer. We're have some out composite Observations for exercises with different LOINC-codified components (is this using it as an "observation bag?") slated - it definitely can handle lots of the immediate cases. Data seems all too hard to come by, and much of it stuff that it would still be *nice* to get that's been elusively outside the models. – user2864740 Mar 10 '16 at 06:42