Stream: python
Topic: Pop up session
Harold Solbrig (Jun 10 2019 at 20:39):
I've reserved a Python popup session at 11:05 Wed in McKinley
Harold Solbrig (Jun 10 2019 at 20:39):
One of the topics will be a very short show 'n tell of the PyCharm IDE and how it uses type hints.
Harold Solbrig (Jun 10 2019 at 20:42):
Also discuss our (JHU's) proposal for including a bit more robust data types.
Pascal Pfiffner (Jun 11 2019 at 17:13):
Cool, thanks!
Harold Solbrig (Jun 11 2019 at 17:14):
Putting together a prototype for the datatypes that I can show tomorrow -- should help with some design decisions
Seth Russell (Jun 12 2019 at 20:31):
Related to our discussions today about it being hard to find clientfhir when searching: I did a search and found these 3 python libraries on pypi and github. Seems that the fhirclient python library has more features than these.
* https://github.com/teffalump/health_fhir
* https://github.com/beda-software/fhir-py
* https://github.com/Arborian/fhirstorm
Was anyone at the session that has used these libraries? Or maintain them/know the maintainer? I think it might be a good idea to invite them to join forces so we can get things done quicker.
Brian Kolowitz (Jun 12 2019 at 21:22):
are the slides available somewhere?
Seth Russell (Jun 12 2019 at 21:45):
@Harold Solbrig said that he check on making them available. Hopefully they can be on the conference site with standard presentations.
Harold Solbrig (Jun 12 2019 at 21:46):
I'll get them on the website in the next day or so -- want to clean it up a little first...;
Ward Weistra (Jun 12 2019 at 22:04):
@Vadim Laletin seems to have worked on fhirpy.
@Igor Sirkovich @Gopikrishnan Chandrasekharan @Ilya Beda @nicola (RIO/SS) @Bell Eapen have starred one of the other mentioned clients.
@Geoff Low seemed interested on Twitter.
Interested in joining work with us on https://github.com/smart-on-fhir/client-py instead? (Sorry for duplicate messages, or if you were already at the pop-up session just now :slight_smile: )
Ilya Beda (Jun 13 2019 at 05:56):
Hi @Ward Weistra thank you for mentioning.
We started https://github.com/beda-software/fhir-py for two reasons.
1. There is no python FHIR client that supports asyncio yet. We are working right now on it. We use it in a closed source project, but it will be open-sourced soon.
2. Current implementation materializes each FHIR resources as classes. It uses code generations to be up to date. So instead of developing a python library for FHIR, you have to develop a code generator tool instead.
We decided that FHIR library should work with dictionaries rather than with classes. We are using JSON schemas to validate FHIR resources. So to add support for new an FHIR release you don't need to regenerate a library source code, you just need to add JSON schema for a new FHIR release. Asyncio adapter is in on the way.
If you find these ideas reasonable, contributions are welcome.
Seth Russell (Jun 13 2019 at 17:55):
@Ilya Beda Thanks for providing some details on your FHIR library's unique features and direction compared to the SMART Python client. I think depending on use case a dictionary based approach might be easier to use.
After reviewing your github documentation and a quick look into the code, I have a couple of questions:
* What resources does your library support?
* What version of FHIR does your library support?
Eric Haas (Jun 13 2019 at 18:17):
@Ilya Beda are you using json schema in python. I could not find a handy library to use them?
Grahame Grieve (Jun 15 2019 at 01:12):
@Ilya Beda the main reference implementations support both approaches (generated classes, and metadata driven classes). There are use cases for both, and also lots of shared code for both - so suggest that there should be one python library that supports both approaches
Eric Haas (Jun 16 2019 at 21:29):
I don't know what the difference of a generated classes, and metadata driven classes in Python is and moreover in what situations one would be better that the other. Can somebody explain.
Grahame Grieve (Jun 16 2019 at 22:07):
the main reference implementations support 2 different models:
-
a set of generated classes. In this model, a python native class is generated that expresses the semantics of the resources defined in the specification, and matching parsers / serialisers are provided/generated
-
a single class that represents an element with a definition, and that has a reference to that definition - mostly provided by a StructureDefinition (though alternate sources are possible)
Grahame Grieve (Jun 16 2019 at 22:07):
the first is easier to use, and faster, and simpler
Grahame Grieve (Jun 16 2019 at 22:08):
the second is really useful because you can load resources from any version, including versions you haven't met yet, or resources that are not yet defined. Of course, that doesn't mean that you actually understand them
Grahame Grieve (Jun 16 2019 at 22:08):
so the second approach is generally found in FHIR tools rather than FHIR applications - but there's no hard requirement that makes this true
Vadim Laletin (Jun 17 2019 at 06:25):
Ilya Beda Thanks for providing some details on your FHIR library's unique features and direction compared to the SMART Python client. I think depending on use case a dictionary based approach might be easier to use.
After reviewing your github documentation and a quick look into the code, I have a couple of questions:
* What resources does your library support?
* What version of FHIR does your library support?
In addition to @Ilya Beda's answer, we also use another approach for query string generation in search. We use Django's style (https://docs.djangoproject.com/en/2.2/topics/db/queries/) which can be familiar for Django users.
Our library supports all resources because there are no restrictions due to dict-based approach.
We support all versions of FHIR including 4.0.0. We use their schemas for validation. You can find a list of supported versions here https://github.com/beda-software/fhir-py/tree/master/fhirpy/schemas. We use pickle format to store the root attributes of each resource to make root-field validation.
But we have some ideas to not to use schemas at all and apply validation using $validate endpoint (https://www.hl7.org/fhir/resource-operation-validate.html). As a result, we'll be able to work with any FHIR server with any version/extensions/profiles.
Last updated: Apr 12 2022 at 19:14 UTC
