kitwaremedical/fhir-sandbox

Tools for building a prepopulated fhir server

fhir-sandbox's Issues

module_name not needed

https://github.com/KitwareMedical/lungair-fhir-server/blob/45430e36168f646179d31f3b6f4f38d43403bc77/example/README.md?plain=1#L167

module_name is not needed in the above line, correct?
@stephencrowell can you confirm?

typo in example data source

fhir-sandbox/example/example_data_source.py

Line 9 in 239fb71

def get_indentifier_value(self):

Typo; this is causing it to not override the parent function

add synthetic data source options

from @andinet :

Synthea is a synthetic EHR data generator

https://github.com/synthetichealth/synthea

It can export data in HL7 FHIR format.

Here is the original paper that talks about the simulator
https://academic.oup.com/jamia/article/25/3/230/4098271

---

more comments by me:

Synthea does not create a fhir server for you, but rather can write json to your disk that looks exactly like what you'd get if you looked up patient data that was served via the FHIR protocol (see here). It's as though you had a FHIR server with the data in it, queried the server to get some json representations of the FHIR resources, and then saved that text json to disk. So the tool we are creating still has value added beyond what Synthea does, because our tool sets up a containerized server for you. However, our tool is less ambitious than Synthea in that we are (currently) only supporting Patients and Observations (compare to the giant list of FHIR resources seen here again).

So in conclusion I do believe it will be valuable, perhaps later, to incorporate synthea as one form of data generation that our tool can use.

include mimic citation

add an appropriate citation of mimic-III dataset into this repository

remove temporary testing line that got in

https://github.com/KitwareMedical/lungair-fhir-server/blob/45acfeecdff5824494414b05d0ba48fac1ec31be/data_sources/mimic3.py#L170

streamline adding new data sources

Messing with our argparse should not be necessary for a user of our API who wants to add a custom data source.
In fact it's best if they don't have to touch populate_fhir_server.py at all.

Options:

• make it possible to somehow "register" the new data source once it's created, so that it becomes an option when running populate_fhir_server.py.
• make populate_fhir_server.py take an argument that somehow points to the custom classes

For a custom data source it would be nice to be able to tell users "create your data source definition like this and then feed it into our tool", rather than saying "fork this project and make these changes."

abstract out the mimic-specific data generation

improve random data generation

The basic random data option could be made a lot more useful with a pretty small amount of effort:

• generating data in a sensible way for each observation, sampling normal distributions with sensible means, etc
• having a random patient class with some randomizable parameters that determine the distribution that will be sampled to generate observations for that patient.

do not use dynamic importing for customization

The way we currently import custom data sources is not great.

We should really make fhir-sandbox a proper python package that provides populate_fhir_server as a script, and we should approach the problem of adding a custom data source in a more proper way, treating fhir-sandbox as an extensible API.

One example of an issue this method of customization causes is that the module containing the custom data source cannot do relative imports. There is a fix suggested here but there are so many other issues that crop up that we should really rethink the current design.

In another project we addressed packaging and customization properly, so we can follow that as a model.

fix readme link

"A more in-depth explanation with examples can be found here."

link broken

streamline adding new observation types

Need to think about how to approach this.

One thing I am noticing is the way information is grouped in UNIT_CODES, LOINC_CODES, and DISPLAY_STRINGS, for example. Right now if I wanted to add a new observation type I'd have to go touch each of those and add my entry. It would be better if things were grouped such that the changes I need to make are more localized.

Even better if we can come up with a way to add custom observation types without touching the main code.
Similarly to #6, it would be ideal if users can use our tool directly rather than having to fork it if they want to add their own observation type. We need to think about how we can design it this way.

improve readme

• intro blurb of what this is
• getting, configuring, and running the docker image
• basic usage (use our premade data sources)
• custom data source
  • what abstract classes to provide implementation for
  • minimal example
• custom observation type
  • point to the right place
• what if user wants other FHIR resources besides patient, observation? just point out that this is a limitation and point to fhir docs

rename project

Rename this project and this repo to something not LungAIR specific.

Purpose of this project is to populate sandbox fhir servers with custom data. Nothing to do with LungAIR.
What is a good name that captures this objective?

add mimic-iv on fhir data source

https://physionet.org/content/mimic-iv-fhir-demo/2.0/

Contains the data from 100 patients taken from MIMIC-IV, but organized in a FHIR-like format.
It's FHIR-like data exported to json files that you can download -- then it'd be up to us to serve the json as if one is reading a real FHIR server.
Would definitely be a good data source option to add to our fhir-sandbox software if we had time/interest later.