inferno-framework / inferno-core Goto Github PK

we are Ambulatory, so we dont have Encounter.hospitalization
Encounter.hospitalization.dischargeDisposition
data elements in our EHR. But as per Uscore and Inferno these are SHALL support elements. As we dont have in our EHR, shall we avoid this data elements or we need to mandatory have these elements to pass the test.

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.

I just updated to 0.3.5 and discovered that it's now requiring that you attach a body to the request. I only got it to work if I set the body to '{}' for an empty JSON object. The documentation for the API here indicates there are no body parameters

https://inferno-framework.github.io/inferno-core/api-docs/#/Test%20Session/post_test_sessions

You should be able to replicate by starting up any inferno server based on 0.3.5 and make the following request.

> curl 'http://localhost/api/test_sessions?test_suite_id=g10_certification&preset_id=testing' -XPOST
{"errors":"859: unexpected token at ''"}

Whereas this one is the workaround to get it working again

> curl 'http://localhost/api/test_sessions?test_suite_id=g10_certification&preset_id=testing' -XPOST -d '{}'

I would prefer for this body requirement to be removed again as it used to be. This change broke automated inferno testing which we kick off periodically.

In some of the tests, I would assume it is choosing a specific item to pull because of data in a previous item pulled.

IE, for the organization test, if it is pulling "Organization/27", if I am wondering "why did it choose that one?", there are so many other things prior, it is hard to determine where the Inferno test might have seen "Organization/27" before. If these type of tests where it is being called because of a previous reference could state where that reference was, that would be helpful.

ONC recently removed a test from Tab 6 of the g.10 test suite. Following this change, the input json file we had historically used contained inputs that Inferno no longer recognized. When trying to run the tests, our POST to https://inferno.healthit.gov/suites/api/test_runs was met with a 500 and the following response: {"errors":"undefined method 'warning' for #\u003cLogger:0x0000561690c6b180\u003e\nDid you mean? warn"}.

I believe this is coming from this line of code.

We updated our json to remove the no longer used inputs and are now seeing tests pass normally so this is non-blocking/non-urgent on our end, just wanted to report this little bug since I imagine others may run into it following the recent change as well.

In the Single Patient API test sequence, the access token is automatically defaulted in, and it isn't editable. However, it isn't clear which access token is being used. If you run the test kit in order, there are three access tokens floating around:

1. The token from the Standalone Patient App sequence
2. The token from the Limited Access App sequence
3. The token from the EHR Practitioner App sequence

I've haven't really figured out exactly which one gets used, and if it depends on what order the tests were run. But I think it would be nice if you just gave the user a drop-down list with the list of tokens, and which preceding sequence was used to acquire the token .

We are currently validating "8 DiagnosticReport for Laboratory Results Reporting Tests" US core 4.0.0 profile and are unable to understand the expectation for 1 particular test case 8.09.

Our Sample response
"resource": { "resourceType": "DiagnosticReport", "id": "34000177", "meta": { "versionId": "1", "lastUpdated": "2022-04-12T13:43:33Z" }, "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Diagnostic Report</b></p><p><b>Document Category</b>: Laboratory</p><p><b>Status</b>: Final</p><p><b>Effective Date</b>: Apr 10, 2022 5:00 A.M. CDT</p></div>" }, "contained": [ { "resourceType": "Observation", "id": "34000179", "status": "final", "code": { "coding": [ { "system": "http://loinc.org", "code": "664-3", "userSelected": true } ] }, "valueString": "Gram stain report results.", "derivedFrom": [ { "reference": "Observation/MIC-CE-34000177", "display": "DIAGNOSTIC_REPORT" } ] } ], "identifier": [ { "system": "https://fhir.cerner.com/ceuuid", "value": "CEfda49233-ccfa-4ed4-afbc-9f5082c2bf0c-34000177-2022041208433400" }, { "system": "https://www.hospital.com", "value": "MicroExtOrderID001" } ], "status": "final", "category": [ { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "LAB", "display": "Laboratory", "userSelected": true } ], "text": "Laboratory" }, { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "MB", "display": "Microbiology", "userSelected": true } ], "text": "Microbiology" } ], "code": { "coding": [ { "system": "http://loinc.org", "code": "600-7", "userSelected": true } ] }, "subject": { "reference": "Patient/655923" }, "encounter": { "reference": "Encounter/3116065" }, "effectiveDateTime": "2022-04-10T10:00:00Z", "issued": "2022-04-10T11:45:24Z", "performer": [ { "extension": [ { "valueCodeableConcept": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "code": "LA", "display": "legal authenticator" } ], "text": "legal authenticator" }, "url": "http://hl7.org/fhir/StructureDefinition/event-performerFunction" } ], "reference": "Practitioner/2809948" }, { "extension": [ { "valueCodeableConcept": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "code": "LA", "display": "legal authenticator" } ], "text": "legal authenticator" }, "url": "http://hl7.org/fhir/StructureDefinition/event-performerFunction" } ], "reference": "Practitioner/589723" } ], "resultsInterpreter": [ { "reference": "Practitioner/2809948" }, { "reference": "Organization/589723" } ], "result": [ { "reference": "#34000179", "display": "Gram Stain" } ] }

For this we are getting the error
Error text: DiagnosticReport.result[0]: Unable to find a match for profile #34000179 among choices: http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-lab

Could anyone please provide more details as to what additional things we are supposed to populate in "Contained" field ?

Inferno2.0 is validating resources against the latest profile versions even when a profile version is specified in fhir resources.

So a resource with the following meta will still get validated against latest profile version and not the one specified...
"meta": { "profile": [ "http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device|3.1.1" ] },

When we run the following curl request against our hosted validator we get the error below...
curl --location --request POST 'https://...inferno-core-validator-api/validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device|3.1.1' \ --header 'Content-Type: application/json' \ --data-raw '{ "id": "9879", "meta": { "profile": [ "http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device|3.1.1" ] }, "extension": [ { "url": "https://fhir.athena.io/StructureDefinition/ah-practice", "valueReference": { "reference": "Organization/234234" } }, { "url": "https://fhir.athena.io/StructureDefinition/ah-chart-sharing-group", "valueReference": { "reference": "Organization/234234324" } } ], "udiCarrier": [ { "deviceIdentifier": "00827002008776", "jurisdiction": "http://hl7.org/fhir/NamingSystem/fda-udi", "carrierHRF": "(01)00827002008776" } ], "status": "entered-in-error", "type": { "text": "Peripheral vascular guidewire, manual" }, "patient": { "reference": "Patient/6757" }, "resourceType": "Device" }'

The following error is given by inferno when a valid resource is provided in results...
us-core-9: 'For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.' Rule 'For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.' Failed

We utilize redirects to manage multiple connections through a single gateway. For example:
https://www.medentfhirtest.com/fhir/R4/savcw237/.well-known/smart-configuration
redirects to
https://www.medentfhirtest.com/fhir/R4/.well-known/smart-configuration/index.php?medent_practice_id=savcw237

This worked for the previous Inferno test suites, but is now returning a 302 on the very first test.

Will redirects like this be supported or do we need to reconfigure our connections?

Thanks!
Savannah Dearing

In each sequence you have nice big green checkmarks for passes:

But in the TOC view, you just have little dots:

However, it doesn't look like the dot color lines up with the "sum" or the tests.

See this test session:
https://inferno-dev.healthit.gov/onc-certification-g10-test-kit/test_sessions/94395c64-b6e2-4a22-b8f5-c0285b2e85dd#g10_certification-g10_smart_standalone_patient_app-smart_standalone_launch

All the tests in the Standalone Patient App sequence passed, but the TOC summary shows fail:

Also, making the TOC pass/fail indicator more of a checkmark / x icon instead of just a colored dot would be nice. I'm red/green color blind :).

Hey all,

While working through updating to the latest versions this week, I encountered an issue where the error message I received made it very difficult to determine the root cause of the issue. We have a few preset test configurations that we've been using for a while now to run the inferno test suite every day. When trying to create a new session from the APIs using our presets after upgrading, I started getting this error message:

> curl -XPOST 'http://localhost/api/test_sessions?test_suite_id=g10_certification&preset_id=my-preset-id'
{"errors":"undefined method `[]' for nil:NilClass\n\n          type: suite_inputs[input[:name].to_sym][:type]\n                                                 ^^^^^^^"}

The application logs at least point me to the location in code that has the issue, but it's still not very helpful as I'm not an expert in this source code:

inferno-athenahealth-inferno-1            | I, [2023-03-06T20:51:53.333166 #13]  INFO -- : POST http://localhost/api/test_sessions?test_suite_id=g10_certification&preset_id=my-preset-id
inferno-athenahealth-inferno-1            | E, [2023-03-06T20:51:55.382919 #13] ERROR -- : /usr/local/bundle/gems/inferno_core-0.4.11/lib/inferno/utils/preset_processor.rb:30:in `input_for_options': undefined method `[]' for nil:NilClass (NoMethodError)
inferno-athenahealth-inferno-1            |
inferno-athenahealth-inferno-1            |           type: suite_inputs[input[:name].to_sym][:type]
inferno-athenahealth-inferno-1            |                                                  ^^^^^^^
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/inferno_core-0.4.11/lib/inferno/utils/preset_processor.rb:21:in `block in processed_inputs'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/inferno_core-0.4.11/lib/inferno/utils/preset_processor.rb:21:in `map'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/inferno_core-0.4.11/lib/inferno/utils/preset_processor.rb:21:in `processed_inputs'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/inferno_core-0.4.11/lib/inferno/repositories/test_sessions.rb:49:in `apply_preset'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/inferno_core-0.4.11/lib/inferno/apps/web/controllers/test_sessions/create.rb:17:in `handle'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/hanami-controller-2.0.0.beta1/lib/hanami/action.rb:338:in `block in call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/hanami-controller-2.0.0.beta1/lib/hanami/action.rb:325:in `catch'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/hanami-controller-2.0.0.beta1/lib/hanami/action.rb:325:in `call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/inferno_core-0.4.11/lib/inferno/apps/web/controllers/controller.rb:6:in `call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/hanami-router-2.0.0/lib/hanami/router.rb:108:in `call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/hanami-router-2.0.0/lib/hanami/middleware/body_parser.rb:43:in `call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/rack-2.2.6.3/lib/rack/builder.rb:244:in `call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/inferno_core-0.4.11/lib/inferno/utils/middleware/request_logger.rb:24:in `call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/rack-2.2.6.3/lib/rack/static.rb:161:in `call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/puma-5.6.5/lib/puma/configuration.rb:252:in `call'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/puma-5.6.5/lib/puma/request.rb:77:in `block in handle_request'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/puma-5.6.5/lib/puma/thread_pool.rb:340:in `with_force_shutdown'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/puma-5.6.5/lib/puma/request.rb:76:in `handle_request'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/puma-5.6.5/lib/puma/server.rb:443:in `process_client'
inferno-athenahealth-inferno-1            |     from /usr/local/bundle/gems/puma-5.6.5/lib/puma/thread_pool.rb:147:in `block in spawn_thread'
inferno-athenahealth-inferno-1            |
inferno-athenahealth-inferno-1            | I, [2023-03-06T20:51:55.383416 #13]  INFO -- : 500 in 2050.255484 ms
inferno-athenahealth-inferno-1            | I, [2023-03-06T20:51:55.383512 #13]  INFO -- : {"errors":"undefined method `[]' for nil:NilClass\n\n          type: suite_inputs[input[:name].to_sym...

After digging into the source code and playing around with my presets, I came to the conclusion that one of my preset input parameters was misconfigured. I eventually determined it was because I had an input in my preset that was no longer a valid input name. "limited_requested_scopes" was the input in question.

I understand that the input requirements are going to change over time, but I think in this situation at least having more useful error messages would be extremely helpful. It looks to me like you have all the data available to return a message along the lines of "The input parameter 'limited_requested_scopes' is not a valid input for this test suite". That would have taken my debugging down from several hours to a couple of minutes.

This link for the "star" button goes to the wrong place

It took me to here:

https://github.com/inferno_community/inferno-core/

Could you sort the presets in the dropdown in the UI?

Currently it seems to just be sorting them in some random order that I cannot figure out. My theory is that it's the order that they were loaded. I think sorting them alphabetically by the title would be sufficient. Alternatively you could provide an order field for us to manually set in the preset JSON, but I think alphabetic is better than manually setting the order.

Hey all,

I just updated to version 0.4.10 and noticed the /api/test_runs/{test_run_id}/results API now returns a 404.

It seems like there is a possible replacement by calling /api/test_runs/{test_run_id} with the query parameter of include_results=true

If the change was intentional, then you should remove it from your swagger API docs, because it still claims the endpoint should exist.

As my team was trying to debug some issues with our resources failing, we found that inferno was claiming that fhir validator found the resource to be invalid. However, the details of the resource were not available to us because the requests to the FHIR Validator API service were not persisted.

This is the issue we were trying to debug: #154

Persisting these requests would give us additional detail about which resource was failing. It was very difficult to find the root cause of this issue without this feature.