Canonical References to Prior/Non-Tip Resource Versions

[Paul Jones]

We would like to leverage, as part of a custom profile architecture, fhir versioned canonical references to underlying resources.  For example, the xml for a required versioned value set binding might look this:

"binding": {
   "strength": "required",
   "description": ".... valueset of codes describing anatomical locations for taking the temperature.",
   "valueSet": "https://<host>/fhir/ValueSet/body-temperature-location-code|1.2"
}

We want strict versioning to permit deployment of updates (new versions, some of which might be breaking) to resources already accessed by fhir clients without causing disruption.

It seems that, for profiles deployed as installed resources (not binary), back versions do not resolve because of limitations in the search apparatus (the spidx tables have content for only current/tip resource versions).

However, it experimentally we discovered that the npm package model/tables appear to preserve packaged binary resource versions durably, and that with a little bit of cajoling can be used to close the gap.

Am looking for some feedback on this topic: 

• Is this characterization (of hapi back version referenceability) correct?
• Is the npm package model a recommended source of truth for prior versions of resources?
• Are there other recommended design alternatives?

Thanks for any input you can provide,

Paul Jones

[James Agnew]

I believe on recent HAPI FHIR releases you should be able to achieve this using regular resource storage as well (ie not just using NPM). The trick is that you can't mix the concepts of resource version (e.g. ValueSet.meta.versionId) and business version (e.g. ValueSet.version).

If you want to allow both business versions to be active and available for validation, each business version needs to be a distinct resource with a different ID. So both versions may well have a resource version of "1" but both are searchable.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/85892519-8120-4da2-96cd-1f2a15f4bb24n%40googlegroups.com.

[Paul Jones]

ok, thx for responding.

Do you not agree, though, that resource properties having canonical datatypes should support version suffixes (per the spec)?  

It seems like you are recommending that we simply do not do it (i.e., versioning), but rather post each as a separate resource.  It seems like we lose something that way.

[James Agnew]

> Do you not agree, though, that resource properties having canonical datatypes should support version suffixes (per the spec)? 

I agree 100% - But the version suffix refers to the business version and not the resource version.

In FHIR, it's not possible to use the search API to discover previous "FHIR versions" of resources. That's just how the spec states that it should work.. So if you want to have the canonical URLs be discoverable in a FHIR repository, you have to use separate resources.

This doesn't mean that it would be a bad idea to make it work the way you're describing. But that would be work that hasn't happened, so that way doesn't work today.

Cheers,

James

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/99e08dbb-ffd0-4cd1-934a-642773349f0bn%40googlegroups.com.

[Paul Jones]

OK, thanks for explaining.

I have a working POC that supports back version references to profile-related resources (for validation purposes) that are deployed as npm packages (since that model in hapi is version-complete).

Was hoping that HAPI would move in that direction as well.

On Aug 9, 2022, at 5:25 PM, James Agnew <james...@gmail.com> wrote:



[Paul Jones]

With help from a colleague - Chuck Summers - I now understand your points above and their bases in the FHIR spec.  

However, I noticed (w/ version 6.0.1, and preceding?) that the jpa validation support for StructureDefinition does not include the version search parameter.

I had to apply this patch to get it working:

diff --git a/src/main/java/ca/uhn/fhir/jpa/dao/JpaPersistedResourceValidationSupport.java b/src/main/java/ca/uhn/fhir/jpa/dao/JpaPersistedResourceValidationSupport.java
index 8e8d25f..017994d 100644
--- a/src/main/java/ca/uhn/fhir/jpa/dao/JpaPersistedResourceValidationSupport.java
+++ b/src/main/java/ca/uhn/fhir/jpa/dao/JpaPersistedResourceValidationSupport.java
@@ -244,7 +244,14 @@ public class JpaPersistedResourceValidationSupport implements IValidationSupport
                                }
                                SearchParameterMap params = new SearchParameterMap();
                                params.setLoadSynchronousUpTo(1);
-                               params.add(StructureDefinition.SP_URL, new UriParam(theUri));
+
+                               int versionSeparator = theUri.lastIndexOf('|');
+                               if (versionSeparator != -1) {
+                                       params.add(StructureDefinition.SP_VERSION, new TokenParam(theUri.substring(versionSeparator + 1)));
+                                       params.add(StructureDefinition.SP_URL, new UriParam(theUri.substring(0, versionSeparator)));
+                               } else {
+                                       params.add(StructureDefinition.SP_URL, new UriParam(theUri));
+                               }
                                search = myDaoRegistry.getResourceDao("StructureDefinition").search(params);
                                break;
                        }

Does this make sense?