SubscriptionTopic support

[nathanloyer]

Hey all,

I was trying to write some custom tests for the SubscriptionTopic resource, and it seems like it is not supported. I was digging into the fhir_models gem since it seems like that is the source of the supported resource types. I do not see SubscriptionTopic listed in there, so I'm guessing that gem doesn't support the R4B version of the fhir spec.

Can we get inferno updated to support these resources? Is there another way I can tell the fhir client in the inferno framework to support new/custom resource types?

I can work around the issue by using the http_client instead of the fhir_client, but it would be nice to have official support for this.

Thanks.

[Jammjammjamm]

We'll investigate what it takes to update the fhir_models gem to support R4B. The models are generated, so if we're lucky, adding the updated definitions and regenerating the library will take little effort. For a major update like this, though, it's very possible that it will require more effort.

[nathanloyer]

Is there a way for me to add custom resource types into the test framework so I can still use the fhir_read and fhir_search methods in the tests that we write? We also have a couple of resource types that we have invented on our own and not published anywhere which we are using for internal APIs that I wanted to test using inferno. So in that case I would hand craft a data model module and want to register it with the test framework so I can use fhir_search to test it.

If there is a way to do that, then I could do the same thing with SubscriptionTopic instead of asking yall to support R4B.

[Jammjammjamm]

So the necessary change would be in fhir_models rather than fhir_client. The bulk of the code for the individual models is generated, so they look like this.

The quickest possible way to hack this in would be to create files with definitions for SubscriptionTopic, etc. that look just like the model I linked above. Then put a require_relative 'path/to/new/model' somewhere where it will be loaded prior to being used (like at the top of the first file that uses the new model).

The more complicated version which may end up being less work (or may not work at all, depending on the scope of the changes in R4B) would involve something like this:

• clone the fhir_models repo and put it in vendor/fhir_models
• if you're using docker, update the Dockerfile to add the vendor folder before RUN bundle install
• replace the R4 definitions in vendor/fhir_models/lib/fhir_models/definitions with their R4B versions
• from vendor/fhir_models, run bundle install && bundle exec fhir:generate to generate models from the R4B definitions
• in your root Gemfile, add gem 'fhir_models', path: 'vendor/fhir_models'
• run bundle install and you should now be using the version of fhir_models you just created which includes R4B resources

[nathanloyer]

You know... before opening this issue I had created my own data model file for the resource type that extended FHIR::Model, but I didn't figure out that I had to require it from my test code. I figured it would be able to find it automatically somehow. So close :D

Looks like the next hurdle is that the assertion method I wanted to use is trying to send the resource to the validator and I think it's failing because the validator doesn't know about the resource type. I can keep debugging that or just do some custom assertions. At least I can use the fhir_search method now.

Here is the current error in case you are curios:

 E, [2023-09-21T20:02:00.365079 #1] ERROR -- : /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/dsl/fhir_validation.rb:233:in `find_validator': No 'default' validator found (Inferno::Exceptions::ValidatorNotFoundException)
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/dsl/fhir_validation.rb:222:in `find_validator'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/dsl/fhir_validation.rb:222:in `find_validator'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/dsl/fhir_validation.rb:41:in `find_validator'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/dsl/fhir_validation.rb:35:in `resource_is_valid?'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/dsl/assertions.rb:121:in `block in assert_valid_bundle_entries'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/dsl/assertions.rb:116:in `reject'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/dsl/assertions.rb:116:in `assert_valid_bundle_entries'
     from /opt/inferno/lib/athenahealth_test_kit/subscriptions_group.rb:54:in `block (2 levels) in <class:SubscriptionsGroup>'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:77:in `instance_eval'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:77:in `run_test'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:51:in `run'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:128:in `block in run_group'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:127:in `each'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:127:in `run_group'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:53:in `run'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:128:in `block in run_group'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:127:in `each'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:127:in `run_group'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:53:in `run'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/test_runner.rb:40:in `start'
     from /usr/local/bundle/gems/inferno_core-0.4.18/lib/inferno/jobs/execute_test_run.rb:10:in `perform'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:202:in `execute_job'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/middleware/chain.rb:172:in `invoke'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:169:in `block in process'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/job_retry.rb:113:in `local'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:263:in `stats'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/job_logger.rb:13:in `call'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/job_retry.rb:80:in `global'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:124:in `block in dispatch'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/job_logger.rb:39:in `prepare'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:123:in `dispatch'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:168:in `process'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:78:in `process_one'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/processor.rb:68:in `run'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/component.rb:8:in `watchdog'
     from /usr/local/bundle/gems/sidekiq-6.5.9/lib/sidekiq/component.rb:17:in `block in safe_thread'

Thanks for the help.

Is this approach documented in the framework docs? If it isn't then I'd be happy with the resolution of this ticket being just to update the docs there to tell people how they can do this.

[nathanloyer]

Actually on that stacktrace, after looking some more I think my hunch was right. I was really just looking for the test to iterate through the entries and check that each contained resource was of type SubscriptionTopic. I don't really need it to run complete validations. I can just iterate through them on my own.