Stream: implementers
Topic: FHIR Packages
Theoharis Nalmpantidis (May 22 2019 at 07:12):
Hello everyone.
I am new with FHIR and we have started an implementation with HAPI-FHIR server.
During the DevDays in the Netherlands there were information about FHIR Packages och versioning. The message was to version the Fhir packages.
My question is: Is there any recommended way to use the "Fhir package version" in rest-communicaton in a similar way as the fhirVersion?
Ex.
Accept: fhirVersion=4.0, packageVersion=1.0.0, application/json+fhir
Ewout Kramer (May 22 2019 at 08:52):
When would this REST traffic occur? Is this a Fhir client requesting the download of a package? Or is this a client requesting a conformance resource (say a StructureDefinition) for a certain version of FHIR for a certain version of a package from a server?
Michel Rutten (May 22 2019 at 09:47):
@Theoharis Nalmpantidis support for NPM packages in FHIR follows the (external) NPM specification. The FHIR spec itself does not specify how to search for and/or fetch an NPM package from an NPM server. Simplifier supports such functionality by means of a custom API endpoint that implements the NPM spec. The NPM spec defines how to deal with package versions.
Theoharis Nalmpantidis (May 22 2019 at 12:33):
Hi I dont mean the rest-communication to the NPM package, it is when consuming a FHIR resource that conforms to a specific profile.
Here is one example:
FhirContext ctx = FhirContext.forR4();
ctx.setDefaultTypeForProfile("http://natmedlist.se/fhir/StructureDefinition/nll-patient|1.0", EHMPatient.class);
IGenericClient client = ctx.newRestfulGenericClient("http://nll-fhir-server.192.168.234.5.nip.io/fhir-server/fhir");
client.registerInterceptor(new LoggingInterceptor(true));
Patient patient = client.read().resource(Patient.class).withId("82b3570c-8a51-464d-a53e-7fb55255063c").execute();
The logs.
main] INFO ca.uhn.fhir.rest.client.interceptor.LoggingInterceptor - Client request: GET http://nll-fhir-server.192.168.234.5.nip.io/fhir-server/fhir/metadata HTTP/1.1
[main] INFO ca.uhn.fhir.rest.client.interceptor.LoggingInterceptor - Client request headers:
Accept-Charset: utf-8
Accept: application/fhir+xml;q=1.0, application/fhir+json;q=1.0, application/xml+fhir;q=0.9, application/json+fhir;q=0.9
User-Agent: HAPI-FHIR/3.7.0 (FHIR Client; FHIR 4.0.0/R4; apache)
When I sniff the traffic is does not include which profile the client conforms to, is there any way to tell the FHIR-server to create a Resource according a specific profile based on FHIR package?
Theoharis Nalmpantidis (May 22 2019 at 12:49):
I forgot to add this is necessary when supporting multiple versions of a specific profile under the same endpoint.
Ex. http://[base]/fhir-server/fhir/Patient
Theoharis Nalmpantidis (May 22 2019 at 13:13):
When would this REST traffic occur? Is this a Fhir client requesting the download of a package? Or is this a client requesting a conformance resource (say a StructureDefinition) for a certain version of FHIR for a certain version of a package from a server?
It is the last conformance resource for a certain version of FHIR for a certain version of a package.
Ewout Kramer (May 22 2019 at 13:17):
@Theoharis Nalmpantidis, although I am not familiar with HAPI, in general an instance of FHIR data (like a Patient) could state such claims in its meta data, specifically Patient.meta.profile. This is not necessary, however, and you can use FHIR validation (using the $validate operation) to validate any instance against any chosen profile. However, we have not yet defined how you'd tell the server where to look for such a profile. It is assumed a server has one "current" profile with a given canonical - especially if you use a canonical with a version | in it. Normally, servers would have loaded the content of a given package into their databases, and so be able to find that profile. If (in the case you are suggesting) a server could have the contents of multiple packages with multiple versions of the given profile, then presumably the version becomes the discriminator. If not, there's currently no way of telling the server which package you want to take the profile from. It would probably be a parameter to $validate but its too early to say anything definite.
Theoharis Nalmpantidis (May 22 2019 at 13:29):
Ok Thanks @Ewout Kramer
That was the kind of answer i was looking for.
Would it be a bad idea to implement a packageVersion Accept http-header as the fhirVersion according to standard to support which profile to use?
I was thinking about GET calls when using _include and _revinclude when both resources conform to specific profiles (with version).
Ex. GET http://[base]/MedicationRequest?_include=Patient
Ewout Kramer (May 22 2019 at 14:21):
It's not a crazy idea to pilot - but that wouldn't mean it's part of FHIR yet, so you'd have to watch out to tell your clients that it is a private extension to the standard....
Theoharis Nalmpantidis (May 22 2019 at 15:01):
Thanks for the answer :)
Michel Rutten (May 22 2019 at 15:45):
FYI R4 introduces the notion of version-specific canonical url references of the form "http://...|1.0" (separated by a vertical bar). This is the preferred way of referencing a specific version of a profile.
A resource instance could include a version-specific profile reference in the meta.profile element. This would allow a server to validate against that specific profile version, without having to introduce an additional HTTP header.
Theoharis Nalmpantidis (May 22 2019 at 16:29):
Yes but it does not solve the fact that for instance Patient profile v.1.0 is included in the same package as MedicationRequest profile v.1.0. I looked at version-specific canonical url and yes it only solves versioning for a single Profile based on a conformance resource.
Grahame Grieve (May 22 2019 at 19:56):
I
Grahame Grieve (May 22 2019 at 19:56):
I'm not actually following the issue here. Why does the client need to know about packaging on the server?
Theoharis Nalmpantidis (May 22 2019 at 23:01):
Hi @Grahame Grieve
We are at this stage designing profiles (version=1) that conform to specific FHIR Resources like Patient, MedicationRequest and MedicationDispense.
All the profiles are going to be packaged according to standard NPM Packages.
We are mapping FHIR resources to an internal datamodel before storing in DB which means that resource data could conform to a specific profiles different versions. The data stored in DB is version agnostic.
Lets say that in 1-2 years from now that we have to profile the next major version of a resource (cause of legislation), during that time we will support 2 versions at the same time, our clients will have 6 months -1 year to adapt to the latest version. That means that we need some kind of mechanism to know which version our clients support or is it a better approach to launch a separate FHIR-Server instance for the new package version?
Lloyd McKenzie (May 22 2019 at 23:33):
You can simply declare the profile versions within your instances using the 'meta' element and avoid the need to require your clients to do anything 'custom'
Theoharis Nalmpantidis (May 23 2019 at 05:17):
Could u please explain more? How would the server know which Profile version the client supports in a GET operation?
Lloyd McKenzie (May 23 2019 at 05:31):
The CapabilityStatement allows a server to declare what profiles (and versions) it supports (as well as what resources and operations it supports)
Theoharis Nalmpantidis (May 23 2019 at 07:06):
OK I understand
Vadim Peretokin (May 24 2019 at 09:10):
How would the server know which Profile version the client supports in a GET operation?
The server's CapabilityStatement would not answer that
Vadim Peretokin (May 24 2019 at 09:11):
It would be instead the client asking the server which profiles it supports
Lloyd McKenzie (May 24 2019 at 14:52):
The Server's CapabilityStatement allows the server to declare which profiles (including which versions of which profiles) it supports using the supportedProfile element
Theoharis Nalmpantidis (May 24 2019 at 15:46):
Yes but it does not answer solve which _profile to use when using a GET operation with _include and _revinclude. For instance request a MedicationRequest and including the Patient. How would that operation look like? [base]/MedicationRequest?identifier=id&_include=MedicationRequest:subject&_profile=http://fhir.example.com/mymedication|1.0,http://fhir.example.com/mypatient|1.0.
Any suggestions?
Lloyd McKenzie (May 24 2019 at 16:49):
The data pointed to by the MedicationRequest will comply with whatever profiles it complies with. If you're looking for data filtering based on profile, that's not something that FHIR supports.
Theoharis Nalmpantidis (May 24 2019 at 18:27):
It is not data filtrering we are looking for, the solution for us would be to temporary launch an unique instance of a FHIR server per FHIR package major-version. I plan to attend the FHIR dev days in Amsterdam in November and to further explain the need.
Grahame Grieve (May 24 2019 at 20:12):
How would that operation look like?
I don't understand the operation - are you saying to only return medication requests where the patient conforms to that profile?
Theoharis Nalmpantidis (May 24 2019 at 21:10):
I want a bundle response for a search operation where the medicationrequest is matched and the patient resource is included. How can the client define that the medicationrequest to conforms to profile A and patient to conforms to profile B?
Grahame Grieve (May 24 2019 at 21:11):
I don't know. How can the client define that something that already exists conforms to a set of rules when it requests to access it?
Theoharis Nalmpantidis (May 24 2019 at 21:30):
The set of rules are designed and implemented based on FHIR package version. The set of rules can vary. We were hoping on approving clients based on FHIR package version. We are planning to have 2 simultaneous versions active in production so that clients will have time to adapt to the latest version according the clients release plan.
Theoharis Nalmpantidis (May 24 2019 at 21:32):
The FHIR package version (semver ) is used as a contract
Grahame Grieve (May 24 2019 at 21:34):
ok so I went back and re-read the thread. From what you've said, I don't know why you aren't using the fhirVersion parameter on the mime type as documented at http://hl7.org/fhir/versioning.html
Theoharis Nalmpantidis (May 24 2019 at 21:36):
Ok we are using that but if the profiles version could have mandatory extensions
Grahame Grieve (May 24 2019 at 21:37):
the profiles version could have mandatory
I don't know what that means?
Theoharis Nalmpantidis (May 24 2019 at 21:38):
If I take a conformance resource and add a extension with a manadatory parameters
Theoharis Nalmpantidis (May 24 2019 at 21:39):
And I the next major version of the package version add another mandatory parameter
Grahame Grieve (May 24 2019 at 21:40):
so different versions of the client have different business rules applied to their interactions based on different client declared package versions?
Theoharis Nalmpantidis (May 24 2019 at 21:45):
Actually the business rules are located in the server not the client, for instance v1 medicationRequest profile has extension parameter A mandatory, but v2 medicationRequest profile has extension parameters A and B mandatory
Theoharis Nalmpantidis (May 24 2019 at 21:46):
And the FHIR data is transformed to a local db-model that can handle both profile version
Grahame Grieve (May 24 2019 at 21:46):
but in fact, B is not mandatory. Unless B is prohibited from reading content from v1
Theoharis Nalmpantidis (May 24 2019 at 21:47):
Sorry B is mandatory but prohibited from reading
Theoharis Nalmpantidis (May 24 2019 at 21:47):
forgot to write that.
Theoharis Nalmpantidis (May 24 2019 at 21:48):
Lets say B is mandatory because the new profile version is a major version
Grahame Grieve (May 24 2019 at 21:49):
woah. we're really in the advanced place now. if...
the new profile version is a major version
Then fhirVersion will suffice.
Theoharis Nalmpantidis (May 24 2019 at 21:50):
Yes I know the requirement could be the legislation in Sweden
Grahame Grieve (May 24 2019 at 21:52):
but really, that doesn't make any difference to your underlying use case. you still have different clients facing different rules. I think your choices are:
- track the client's business rules in the client registration (I assume that you have some registration framework)
- define your own business rules parameter to the mime type (not really conformant with the stated intent of mime type parameters)
- use Resource.implicitRules (my least favourite of these options)
btw I am in Stockholm the week after next if you want to face-to-face about this
Theoharis Nalmpantidis (May 24 2019 at 21:55):
Do you have the exact date maybe?
I was thinking about 2 scenarios either letting clients add a packageVersion similar to the fhirVersion or to it make easy and launch a FHIR-Server per FHIR-package major version.
Grahame Grieve (May 24 2019 at 22:02):
in terms of micro-service.... yes, that's the obvious thing to do (your second option) but that ties the resource identity to the version of the representation (see discussion on the link above). So people don't always like micro-services for something like this
Theoharis Nalmpantidis (May 24 2019 at 22:05):
I was meaning to launch a FHIR Server for the package not just a single conformance resource
Grahame Grieve (May 24 2019 at 22:05):
that's what I thought you meant
Theoharis Nalmpantidis (May 24 2019 at 22:06):
ok
Theoharis Nalmpantidis (May 24 2019 at 22:19):
Just one last question Grahame the link did you mean your previous post (with the options) or is it an actual link that I don't see in the chat log?
Grahame Grieve (May 24 2019 at 23:12):
http://hl7.org/fhir/versioning.html
Theoharis Nalmpantidis (May 25 2019 at 09:56):
Ok thanks
Last updated: Apr 12 2022 at 19:14 UTC
