Hey guys,
My name is Marc, I’m a Product Manager at Withings, working on our APIs that allow developers to fetch Health Data measured by the variety of connected devices we provide. We are currently in the process of transforming our Health Data APIs into FHIR APIs.
I had the chance to assist FHIR DevDays a few weeks ago and being there answered a lot of questions I had, however there are still some missing pieces for me to be sure we’re on the right track.
The FHIR resources that we will be providing are Observation, Patient and Device.
Today we already have millions of observations in our databases, stored in various proprietary formats and different types of databases optimised for the data type (high frequency data vs low frequency data).
To transform our data from our proprietary format to FHIR, we will use HAPI and map our data on the generated php data model classes.
Profiling
I’m currently starting to create our IG, and this brings tons of questions :
- When to choose to create your own profile vs trying to find one that fits ? Right now I think a good practice would be to derive one of the vital-signs profiles for Withings Observations, and use existing profiles for some of them when they exist (for instance us-core-blood-pressure for blood pressure)? But I’m still wondering which profile to choose, as for instance the French government has defined one and so did the US government.
- How to be sure that the webservices will be conform to our declared profiles? It seems to me that creating an IG is a very declarative process but it doesn’t constrain our webservices to return Resources that match our profile. Even if we test thoroughly our API before launch, after that regressions might happen?
- I’m planning to use fsh and sushi to create our profiles and IG, then publish it using IG publisher, is that a correct approach?
Performance
The fact that our observation data are stored in different formats and databases mean that they were not built to be requested at the same time. We currently have multiple webservices that will be merged into a single FHIR Observation webservice.
4) As requesting different types of data (for instance by doing a search on both high frequency and low frequency data) will result in poor performances from our server, should we constrain the types of data that can be returned at the same time in our implementation guide (for instance, adding a rule with the sets of loinc codes that can be requested in a single search)?
5) Do you know of efficient ways to page results when data are coming from different types of databases?
Versionning and iterating
We’re trying to release a first version of the API as soon as possible, even if incomplete in order to get feedbacks from our partners and the community. However, we know things are going to change, maybe on the way we model data or even our IG.
6) What would you say is a best practise for iterating on a FHIR API that is alpha/beta. I guess it’s a problem all APIs face but FHIR adds IGs and Profiles to the equation.
Anyways, sorry for the long post, any help would be greatly appreciated 