Stream: implementers
Topic: License
Sandra Mattes (Nov 11 2020 at 16:31):
Hi there! We are developing a digital health application (DiGA) in Germany. To comply to the government's requirements regarding interoperability, we are defining our own profile on top of the FHIR Observation ressource (as we need to use a different coding system than intended in the standard) and collect a selection of ressources in a transaction bundle. This definition must be submitted to the vesta gematik directory.
Is there anything we need to consider concerning IP and licensing for our definition when using the HL7 FHIR Standard as a base and defining the delta and a guideline on the data contained in the bundle?
Thanks in advance for the help!
Lloyd McKenzie (Nov 11 2020 at 16:40):
The license of FHIR puts all content other than the name and logo in the public domain. Details are here: https://www.hl7.org/fhir/license.html
Note that there are rules about what you can do and still be considered "FHIR conformant". However, changing the codes for Observation.code is fine - those are defined as 'example' bindings, which means you're free to use whatever you like. (Observation.status, Observation.interpretation, etc. have tighter requirements.)
Sandra Mattes (Nov 12 2020 at 08:46):
Thanks a lot for the info. :)
Sandra Mattes (Nov 12 2020 at 13:08):
One more question concerning the license. I have read in the German "Profildefinition" that defining a new "Profil" (profile) (I am not sure if this is just the German term for ressource, as the defined profiles are the ressources of the standard) underlies a voting process from FHIR. What we do is collecting our data in existing ressources, which are all unchanged except for the Observation Coding system.
Those ressources are collected in a transfer bundle. We want to define the cardinality of the Ressources for our bundle though, like we need exactly one Patient ressource per bundle, one Account Ressource, 0..* Appointments etc. in an implementation guide. Might there occur any problem there? I guess you could also define this bundle's contents as a new Profile for our use case instead, which then consists of the used ressources as its fields. This would require the hl7 voting process and underlies rules, as far as I understand...
René Spronk (Nov 12 2020 at 13:37):
Anybody can define any profile at any point in time, as long as that profile is a constraint on the core structures defined by the FHIR specification. The contents of the FHIR specification itself, and implementation guides defined by HL7 Germany, all subject to a balloting process. Other organizations or persons may follow their own processes, which need not be based on balloting etc.
Sandra Mattes (Nov 12 2020 at 13:47):
@René Spronk Great, thank you a lot!
Lloyd McKenzie (Nov 12 2020 at 14:14):
@Sandra Mattes Are you defining message bundles or transaction bundles or something else?
Sandra Mattes (Nov 12 2020 at 14:38):
@Lloyd McKenzie my first attempt was to define the contents of transaction bundle. But now I think more technically correct would be to define a profile.
Lloyd McKenzie (Nov 12 2020 at 15:17):
A profile constrains the scope of your instance(s). The data itself wouldn't be sent in a profile. Enforcing constraints on how many repetitions are allowed to be present in a transaction would be unusual, as the transaction endpoint is intended to handle a wide variety of use-cases. What are your reasons for imposing constraints on what resources are present (and how many of them)?
Sandra Mattes (Nov 12 2020 at 15:25):
Because just adding the data to the transaction bundle does not fully depict the data's semantics, for example that it must contain exactly one patient, or that it contains in any case 0..3 current Goals.
Sandra Mattes (Nov 12 2020 at 15:27):
The data transaction's goal is interoperability, therefore I think those semantics need to be represented in any way, be it a guide or for example a profile definition.
Last updated: Apr 12 2022 at 19:14 UTC
