cancer_pathology_data_sharing_test_kit 0.9.0

data/lib/cancer_pathology_data_sharing_test_kit/docs/data_access_suite_description.md

@@ -0,0 +1,83 @@
+## Overview
+
+The Cancer Pathology Data Sharing (CPDS) Data Access Test Suite verifies the ability of
+clinical systems to make [US Core](http://hl7.org/fhir/us/core/STU5.0.1/)
+data accessible to other systems per the
+STU 1.0.1 version of the HL7® FHIR® [Cancer Pathology Data Sharing IG](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/).
+
+## Scope
+
+The CPDS IG requires that both [Laboratory Information System (LIS)](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-pathology-lab-information-system.html)
+and [Electronic Health Record (EHR)](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html) 
+systems support "searching and retrieval of resources using US Core APIs". This test suite
+verifies that a system exposes the full list of US Core v5 APIs and profiles.
+
+Other capabilities that the CPDS IG requires of these systems are currently out of scope
+for this test suite, including
+- EHR requirements around ServiceRequest creation.
+- LIS requirements around DiagnosticReport creation.
+
+## Test Methodology
+
+Inferno will simulate a FHIR client using the search and read API required by the
+[Laboratory Information System (LIS)](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-pathology-lab-information-system.html)
+and [Electronic Health Record (EHR)](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html) CapabilityStatements.
+Through a combination of tester input and details returned by the searches it makes, Inferno will
+attempt to search for and read resources conforming to each profile. This includes
+- Testing required search parameter combinations and verifying that the results returned are appropriate.
+- For each must support element, observing an instance with that element populated.
+- For each must support reference element, verifying that a populated reference can be resolved.
+
+## Running the tests 
+
+### Quick Start
+
+The minimal amount of information Inferno needs to run these tests includes the following inputs:
+- **FHIR Endpoint**: URL of the system's FHIR endpoint.
+- **OAuth Credentials / Access Token** (optional): If needed, a token that Inferno will include in the `Authorization`
+  HTTP header in the form `Bearer <input value>` on each request it makes to the system under test
+- **Patient IDs**: Comma separated list of patient IDs. Inferno will use these when building searches.
+
+### Demonstration
+
+If you would like to try out the tests using the [Inferno Reference Server](https://inferno.healthit.gov/reference-server) 
+([code](https://github.com/inferno-framework/inferno-reference-server)) as the system under test,
+use the "Inferno Reference Server" preset.
+
+## Current Limitations
+
+### Report generation and data access differences
+
+The CPDS STU 1.0.1 IG contains mismatches between the profiles made available through
+the [EHR Data Access API](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html)
+and those that need to be included in [cancer pathology reports](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html),
+both in terms of:
+- **The number of profiles**: The [EHR Capability Statement](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html)
+requires support for US Core STU 5 APIs which can return instances conforming to up to [45 profiles](https://www.hl7.org/fhir/us/core/STU5/profiles-and-extensions.html) while the [Pathology Cancer Exchange Bundle profile](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html)
+requires explicit support for only 6 profiles. Strictly speaking, the US Core IG does not require implementing systems to support APIs that
+return all US Core profiles. However, the CPDS IG does not provide explicit guidance on which resource types and profiles to support
+either in the Capability Statement or through the scope of entries to include in the report Bundle (see the **Extra Bundle entries**
+limitation on the report generation suite for details).
+- **Which profiles**: The [Pathology Cancer Exchange Bundle profile](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html)
+requires entry conformance to specific profiles for which there are no APIs defined in the CPDS [EHR Capability Statement](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html)
+or the referenced [US Core Server CapabilityStatement](https://www.hl7.org/fhir/us/core/STU5/CapabilityStatement-us-core-server.html).
+For example, the report requires [US Pathology Specimen profile](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-specimen.html)
+but the [EHR Capability Statement](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html)
+does not require support for a Specimen resource API directly the referenced version of US Core ([STU 5](https://www.hl7.org/fhir/us/core/STU5/profiles-and-extensions.html))
+does not define a profile or API for the Specimen resource type. Additionally, for resource types for which US Core does define APIs, e.g.,
+[DiagnosticReport](https://hl7.org/fhir/us/core/STU5.0.1/StructureDefinition-us-core-diagnosticreport-note.html),
+CPDS doesn't explicitly indicate the need for EHRs to support the CPDS-specific profile in their APIs,
+e.g., for [US Pathology DiagnosticReport](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-diagnostic-report.html).
+
+Currently this report generation suite and the data access suite test the requirements indicated in the
+IG, including API support for all US Core Profiles, despite the mismatch and their potential to cause
+interoperability issues or extra implementation burden. Future versions of this test suite may update this
+approach based on community feedback and IG updates.
+
+### Limited authentication and authorization options
+
+This test suite currently provides only one option for testers to adjust the requests that Inferno makes
+so that the system under test can identify Inferno as the requestor. If the **Access Token** input is populated, 
+the provided value will be placed in the HTTP `Authorization` header with the prefix `Bearer `.
+Support for Inferno to obtain bearer tokens using SMART on FHIR workflows or other auth schemes may be added
+in the future based on community feedback.

data/lib/cancer_pathology_data_sharing_test_kit/docs/report_generation_suite_description.md

@@ -0,0 +1,118 @@
+## Overview
+The Cancer Pathology Data Sharing Report Generation Test Suite verifies the conformance of clinical systems,
+including laboratory information systems (LISs) & electronic health records (EHRs) to the report generation
+requirements in the STU 1.0.1 version of the HL7® FHIR® 
+[Cancer Pathology Data Sharing (CPDS) IG](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/).
+
+## Scope
+This test suite focuses on the report creation portion of a system's role in submitting pathology reports to
+central cancer registries. Specifically, these tests verify that a system can produce a set of comformant
+and complete [Pathology Cancer Exchange Bundle(s)](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html). 
+
+The IG defines other capabilities of clinical systems that are currently out of scope for this suite, including:
+- The gathering of report content from other systems, if necessary.
+- The transmission of reports to registries.
+- The exchange of data between LIS and EHR systems, including service requests and diagnostic reports.
+
+## Test Methodology
+
+To verify that the system under test can produce conformant and complete cancer pathology reports, Inferno asks
+the tester to provide as input a set of [Pathology Cancer Exchange Bundles](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html)
+generated from the system under test. Inferno will check that each Bundle and the must support entry types
+are conformant to the required profile. Additionally, to verify completeness the tests check for a populated example of each
+must support element designated must support Bundle entry types as well as the profiles required for those entries.
+
+## Running the tests 
+
+### Quick Start
+
+The minimal amount of information Inferno needs to run these tests includes the following inputs:
+- **Cancer Reports**: A comma-Separated list of one or more FHIR Pathology Cancer Exchange Bundles
+  in JSON format generated by the system under test.
+
+Testers will need to generate one or more reports using the system they are testing, paste them into
+the input in Inferno and run the tests. Inferno will evaluate the reports and provide test results.
+
+### Demonstration
+
+If you would like to try out the tests using example data from the CPDS IG, use the "Demo Report"
+preset, which contains the [US Pathology Exchange bundle example](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/Bundle-us-pathology-exchange-bundle-example.json.html)
+with the [Service Request - Cancer Pathology example](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/ServiceRequest-cancer-path-example.json.html) added to it so as to cover all required entry types. The demo report should pass all the tests.
+
+## Current Limitations
+
+### Report generation and data access differences
+
+The CPDS STU 1.0.1 IG contains mismatches between the profiles made available through
+the [EHR Data Access API](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html)
+and those that need to be included in [cancer pathology reports](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html),
+both in terms of:
+- **The number of profiles**: The [EHR Capability Statement](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html)
+requires support for US Core STU 5 APIs which can return instances conforming to up to [45 profiles](https://www.hl7.org/fhir/us/core/STU5/profiles-and-extensions.html) while the [Pathology Cancer Exchange Bundle profile](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html)
+requires explicit support for only 6 profiles. Strictly speaking, the US Core IG does not require implementing systems to support APIs that
+return all US Core profiles. However, the CPDS IG does not provide explicit guidance on which resource types and profiles to support
+either in the Capability Statement or through the scope of entries to include in the report Bundle (see the **Extra Bundle entries**
+limitation on the report generation suite for details).
+- **Which profiles**: The [Pathology Cancer Exchange Bundle profile](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html)
+requires entry conformance to specific profiles for which there are no APIs defined in the CPDS [EHR Capability Statement](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html)
+or the referenced [US Core Server CapabilityStatement](https://www.hl7.org/fhir/us/core/STU5/CapabilityStatement-us-core-server.html).
+For example, the report requires [US Pathology Specimen profile](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-specimen.html)
+but the [EHR Capability Statement](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/CapabilityStatement-central-cancer-registry-reporting-ehr-pathology.html)
+does not require support for a Specimen resource API directly the referenced version of US Core ([STU 5](https://www.hl7.org/fhir/us/core/STU5/profiles-and-extensions.html))
+does not define a profile or API for the Specimen resource type. Additionally, for resource types for which US Core does define APIs, e.g.,
+[DiagnosticReport](https://hl7.org/fhir/us/core/STU5.0.1/StructureDefinition-us-core-diagnosticreport-note.html),
+CPDS doesn't explicitly indicate the need for EHRs to support the CPDS-specific profile in their APIs,
+e.g., for [US Pathology DiagnosticReport](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-diagnostic-report.html).
+
+Currently this report generation suite and the data access suite test the requirements indicated in the
+IG, including API support for all US Core Profiles, despite the mismatch and their potential to cause
+interoperability issues or extra implementation burden. Future versions of this test suite may update this
+approach based on community feedback and IG updates.
+
+### Bundle slicing
+
+The [Pathology Cancer Exchange Bundle profile](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html)
+describes the required contents in terms of slices on `Bundle.entry` using specific profiles
+as [the discriminator](https://build.fhir.org/profiling.html#discriminator). This means, for example,
+that a Bundle with two Patient entries would be valid as long as only one of those Patients
+did not conform to the [US Core Patient profile](http://hl7.org/fhir/us/core/STU5.0.1/StructureDefinition-us-core-patient.html)
+specified in the patient slice. That interpretation does not align with other forms of these reports,
+such as [NAACCR Volume V](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/background.html#fhir-profiles-to-capture-naaccr-volume-v)
+which would require exactly one patient.
+
+These tests check [Pathology Cancer Exchange Bundles](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html) as if the slicing were discriminated by
+resource type, meaning that any Patient entries are part of the Patient slice. Since the Patient slice
+has a cardinality of exactly 1, a Bundle with multiple Patient entries would be invalid regardless of
+which profiles they conform to. Future versions of this test suite may update this approach based on
+community feedback and IG updates.
+
+### Extra Bundle entries
+
+This test suite currently only checks for the presence of instances of the six resource types indicated in the
+[Pathology Cancer Exchange Bundle(s)](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html) and their conformance to the indicated profiles.
+The tests do not check that
+- Instances recursively referenced from these instances are also present in the Bundle.
+- Recursively referenced instances that are present in the Bundle conform to the profile(s) required
+  by the referencing element(s).
+- All must support elements for recursively referenced profiles are demonstrated.
+
+For example the [US Core Encounter profile](https://hl7.org/fhir/us/core/STU5.0.1/StructureDefinition-us-core-encounter.html)
+is referenced from a must support `entry` element slice in the [Pathology Cancer Exchange Bundle(s)](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/StructureDefinition-us-pathology-exchange-bundle.html)
+and the [US Core Encounter profile](https://hl7.org/fhir/us/core/STU5.0.1/StructureDefinition-us-core-encounter.html)
+requires support for the [US Core Practitioner profile](https://hl7.org/fhir/us/core/STU5.0.1/StructureDefinition-us-core-practitioner.html)
+on the `participant.individual` element. This test suite does not currently test that in a
+Bundle where `participant.individual` is demonstrated referencing a Practitioner that the referenced
+instance is also present in the Bundle and that it conforms to the [US Core Practitioner profile](https://hl7.org/fhir/us/core/STU5.0.1/StructureDefinition-us-core-practitioner.html). 
+Must support elements for the [US Core Practitioner profile](https://hl7.org/fhir/us/core/STU5.0.1/StructureDefinition-us-core-practitioner.html)
+also do not need to be demonstrated currently.
+
+The CPDS IG does not explicitly require that the above requirements are met, but they are likely
+to be necessary or at least helpful in practical applications of report exchange. Future versions
+of this test suite may update this approach based on community feedback and IG updates.
+
+### No API-based Submission
+
+The CPDS IG refers to the MedMorph framework for submission which uses FHIR Messaging. Currently, this test suite
+does not support submission of reports using this standards-based approach and instead requires manual provision of
+the reports using Inferno inputs. Future versions may include support for FHIR Messaging or other approaches
+to submission.

data/lib/cancer_pathology_data_sharing_test_kit/fhir_resource_navigation.rb

@@ -0,0 +1,174 @@
+require_relative 'primitive_type'
+
+module CancerPathologyDataSharingTestKit
+  module FHIRResourceNavigation
+    DAR_EXTENSION_URL = 'http://hl7.org/fhir/StructureDefinition/data-absent-reason'.freeze
+    PRIMITIVE_DATA_TYPES = FHIR::PRIMITIVES.keys
+
+    def resolve_path(elements, path)
+      elements = Array.wrap(elements)
+      return elements if path.blank?
+
+      paths = path.split(/(?<!hl7)\./)
+      segment = paths.first
+      remaining_path = paths.drop(1).join('.')
+
+      elements.flat_map do |element|
+        child = get_next_value(element, segment)
+        resolve_path(child, remaining_path)
+      end.compact
+    end
+
+    def find_a_value_at(element, path, include_dar: false, &block) # rubocop:disable Metrics/CyclomaticComplexity
+      return nil if element.nil?
+
+      elements = Array.wrap(element)
+      if path.empty?
+        unless include_dar
+          elements = elements.reject do |el|
+            el.respond_to?(:extension) && el.extension.any? { |ext| ext.url == DAR_EXTENSION_URL }
+          end
+        end
+
+        return elements.find(&block) if block_given?
+
+        return elements.first
+      end
+
+      path_segments = path.split(/(?<!hl7)\./)
+
+      segment = path_segments
+        .shift
+        .delete_suffix('[x]')
+        .gsub(/^class$/, 'local_class')
+        .gsub(/^method$/, 'local_method')
+        .gsub('[x]:', ':')
+        .to_sym
+      no_elements_present =
+        elements.none? do |element| # rubocop:disable Lint/ShadowingOuterLocalVariable
+          child = get_next_value(element, segment)
+          child.present? || child == false
+        end
+      return nil if no_elements_present
+
+      remaining_path = path_segments.join('.')
+      elements.each do |element| # rubocop:disable Lint/ShadowingOuterLocalVariable
+        child = get_next_value(element, segment)
+        element_found =
+          if block_given?
+            find_a_value_at(child, remaining_path, include_dar: include_dar, &block)
+          else
+            find_a_value_at(child, remaining_path, include_dar: include_dar)
+          end
+        return element_found if element_found.present? || element_found == false
+      end
+
+      nil
+    end
+
+    def get_next_value(element, property)
+      extension_url = property[/(?<=where\(url=').*(?='\))/]
+      if extension_url.present?
+        element.url == extension_url ? element : nil
+      elsif property.to_s.include?(':') && !property.to_s.include?('url')
+        find_slice_via_discriminator(element, property)
+
+      else
+        value = element.send(property)
+        primitive_value = get_primitive_type_value(element, property, value)
+        primitive_value.present? ? primitive_value : value
+      end
+    rescue NoMethodError
+      nil
+    end
+
+    def get_primitive_type_value(element, property, value)
+      source_value = element.source_hash["_#{property}"]
+
+      return nil unless source_value.present?
+
+      primitive_value = CancerPathologyDataSharingTestKit::PrimitiveType.new(source_value)
+      primitive_value.value = value
+      primitive_value
+    end
+
+    def find_slice_via_discriminator(element, property) # rubocop:disable Metrics/CyclomaticComplexity
+      element_name = property.to_s.split(':')[0].gsub(/^class$/, 'local_class').gsub(/^method$/, 'local_method')
+      slice_name = property.to_s.split(':')[1].gsub(/^class$/, 'local_class').gsub(/^method$/, 'local_method')
+      if metadata.present?
+        slice_by_name = metadata.must_supports[:slices].find { |slice| slice[:slice_name] == slice_name }
+        discriminator = slice_by_name[:discriminator]
+        slices = Array.wrap(element.send(element_name))
+        slices.find do |slice|
+          case discriminator[:type]
+          when 'patternCodeableConcept'
+            slice_value = discriminator[:path].present? ? slice.send(discriminator[:path].to_s)&.coding : slice.coding
+            slice_value&.any? { |coding| coding.code == discriminator[:code] && coding.system == discriminator[:system] }
+          when 'patternCoding'
+            slice_value = discriminator[:path].present? ? slice.send(discriminator[:path]) : slice
+            slice_value&.code == discriminator[:code] && slice_value&.system == discriminator[:system]
+          when 'patternIdentifier'
+            slice.identifier.system == discriminator[:system]
+          when 'value'
+            values = discriminator[:values].map { |value| value.merge(path: value[:path].split('.')) }
+            verify_slice_by_values(slice, values)
+          when 'type'
+            case discriminator[:code]
+            when 'Date'
+              begin
+                Date.parse(slice)
+              rescue ArgumentError # rubocop:disable Metrics/BlockNesting
+                false
+              end
+            when 'DateTime'
+              begin
+                DateTime.parse(slice)
+              rescue ArgumentError # rubocop:disable Metrics/BlockNesting
+                false
+              end
+            when 'String'
+              slice.is_a? String
+            else
+              if slice.is_a? FHIR::Bundle::Entry # rubocop:disable Metrics/BlockNesting
+                slice.resource.resourceType == discriminator[:code]
+              else
+                slice.is_a? FHIR.const_get(discriminator[:code])
+              end
+            end
+          when 'requiredBinding'
+            discriminator[:path].present? ? slice.send(discriminator[:path].to_s).coding : slice.coding
+            slice_value { |coding| discriminator[:values].include?(coding.code) }
+          end
+        end
+      else # rubocop:disable Style/EmptyElse
+        # TODO: Error handling for if this file doesn't have access to metadata for some reason (begin/rescue with StandardError?)
+      end
+    end
+
+    def verify_slice_by_values(element, value_definitions) # rubocop:disable Metrics/CyclomaticComplexity
+      path_prefixes = value_definitions.map { |value_definition| value_definition[:path].first }.uniq
+      path_prefixes.all? do |path_prefix|
+        value_definitions_for_path =
+          value_definitions
+            .select { |value_definition| value_definition[:path].first == path_prefix }
+            .each { |value_definition| value_definition[:path].shift }
+        find_a_value_at(element, path_prefix) do |el_found|
+          child_element_value_definitions, current_element_value_definitions =
+            value_definitions_for_path.partition { |value_definition| value_definition[:path].present? }
+
+          current_element_values_match =
+            current_element_value_definitions
+              .all? { |value_definition| value_definition[:value] == el_found }
+
+          child_element_values_match =
+            if child_element_value_definitions.present?
+              verify_slice_by_values(el_found, child_element_value_definitions)
+            else
+              true
+            end
+          current_element_values_match && child_element_values_match
+        end
+      end
+    end
+  end
+end

data/lib/cancer_pathology_data_sharing_test_kit/group_metadata.rb

@@ -0,0 +1,82 @@
+module CancerPathologyDataSharingTestKit
+  class GroupMetadata
+    ATTRIBUTES = [
+      :name,
+      :class_name,
+      :version,
+      :reformatted_version,
+      :resource,
+      :profile_url,
+      :profile_name,
+      :profile_version,
+      :title,
+      :short_description,
+      :is_delayed,
+      :interactions,
+      :operations,
+      :searches,
+      :search_definitions,
+      :include_params,
+      :revincludes,
+      :required_concepts,
+      :must_supports,
+      :mandatory_elements,
+      :bindings,
+      :references,
+      :tests,
+      :id,
+      :file_name,
+      :delayed_references
+    ].freeze
+
+    ATTRIBUTES.each { |name| attr_accessor name }
+
+    def initialize(metadata)
+      metadata.each do |key, value|
+        raise "Unknown attribute #{key}" unless ATTRIBUTES.include? key
+
+        instance_variable_set(:"@#{key}", value)
+      end
+    end
+
+    def exclude_search_tests?
+      delayed? && !searchable_delayed_resource?
+    end
+
+    def add_test(id:, file_name:)
+      self.tests ||= []
+      test_metadata = {
+        id: id,
+        file_name: file_name
+      }
+      self.tests << test_metadata
+    end
+
+    def add_granular_scope_test(id:, file_name:)
+      self.granular_scope_tests ||= []
+
+      self.granular_scope_tests << {
+        id:,
+        file_name:
+      }
+    end
+
+    def to_hash
+      ATTRIBUTES.each_with_object({}) { |key, hash| hash[key] = send(key) unless send(key).nil? }
+    end
+
+    def add_delayed_references(delayed_profiles, ig_resources)
+      self.delayed_references =
+        references
+          .select { |reference| (reference[:profiles] & delayed_profiles).present? }
+          .map do |reference|
+            profile_urls = (reference[:profiles] & delayed_profiles)
+            delayed_resources = profile_urls.map { |url| ig_resources.resource_for_profile(url) }
+            {
+              path: reference[:path].gsub("#{resource}.", ''),
+              resources: delayed_resources
+            }
+          end
+    end
+  end
+end

data/lib/cancer_pathology_data_sharing_test_kit/igs/README.md

@@ -0,0 +1,21 @@
+# Note on this IGs folder
+
+There are three reasons why it would be necessary to put an IG package.tgz in this folder. If none of these apply, you do not need to put any files here, or can consider removing any existing files to make it clear they are unused.
+
+## 1. Generated Test Suites
+Some test kits use a "generator" to automatically generate the contents of a test suite for an IG. The IG files are required every time the test suites need to be regenerated. Examples of test kits that use this approach are the US Core Test Kit and CARIN IG for Blue Button® Test Kit.
+
+
+## 2. Non-published IG
+If your IG, or the specific version of the IG you want to test against, is not published, then the validator service needs to load the IG from file in order to be able to validate resources with it. The IG must be referenced in the `fhir_resource_validator` block in the test suite definition by filename, ie:
+
+```ruby
+      fhir_resource_validator do
+        igs 'igs/filename.tgz'
+
+        ...
+      end
+```
+
+## 3. Inferno Validator UI
+The Inferno Validator UI is configured to auto-load any IGs present in the igs folder and include them in all validations. In general, the Inferno team is currently leaving IGs in this folder even if not otherwise necessary to make it easy to re-enable the validator UI.

data/lib/cancer_pathology_data_sharing_test_kit/metadata.rb

@@ -0,0 +1,75 @@
+require_relative 'version'
+
+module CancerPathologyDataSharingTestKit
+  class Metadata < Inferno::TestKit
+    id :cancer_pathology_data_sharing_test_kit
+    title 'Cancer Pathology Data Sharing IG Test Kit'
+    description <<~DESCRIPTION
+
+      The Cancer Pathology Data Sharing (CPDS) Test Kit is a testing tool for Health IT systems
+      seeking to meet the requirements of the STU 1.0.0 version of the HL7® FHIR®
+      [Cancer Pathology Data Sharing IG](https://hl7.org/fhir/us/cancer-reporting/STU1.0.1/).
+
+      <!-- break -->
+
+      This test kit currently contains suites that verify the conformance of systems playing the following roles:
+      - **Report Generation**: Verifies that the Health IT system can generate
+        conformant and complete cancer pathology reports to send to a cancer registry.
+      - **Data Access**: Verifies that the Health IT system can respond to queries
+        for the data needed to create a cancer pathology report.
+
+      ## Getting Started
+
+      To run CPDS tests, select the suite corresponding to the functionality you wish to test
+      and click ‘Create Test Session’.
+
+      ## Status
+
+      These tests are a **DRAFT** intended to allow CPDS IG implementers to
+      perform preliminary checks of their implementations against the IG's requirements and provide feedback
+      on the tests. Future versions of these tests may validate other requirements and may change how these
+      are tested.
+
+      ## Known Limitations
+
+      This test kit does not currently include test suites for all actors and all capabilities defined by the CPDS IG.
+      Out of scope areas of the IG include the Cancer Registry actor and details related to the use of the
+      [MedMorph framework](https://hl7.org/fhir/us/medmorph/STU1/) by all actors to coordinate reporting triggering,
+      report content, and report delivery requirements.
+
+      The existing Report Generation and Data Access suites focus on report content and do not currently
+      test most details of the report exchange workflow. The following areas are not tested:
+      - Data Access requirements around authentication and authorization.
+      - Report Generation requirements around the gathering of report contents from clinical systems and the
+        delivery of completed reports using FHIR APIs.
+
+      For additional details on suite-specific limitations, see the suite documention in the running tests or the
+      corresponding content in the source repository ([Data Access suite limitations](https://github.com/inferno-framework/cancer-pathology-data-sharing-test-kit/blob/main/lib/cancer_pathology_data_sharing_test_kit/docs/data_access_suite_description.md#current-limitations),
+      [Report Generation suite limitations](https://github.com/inferno-framework/cancer-pathology-data-sharing-test-kit/blob/main/lib/cancer_pathology_data_sharing_test_kit/docs/report_generation_suite_description.md#current-limitations))
+
+      ## Repository and Resources
+
+      The Cancer Pathology Data Sharing Test Kit can be [downloaded](https://github.com/inferno-framework/cancer-pathology-data-sharing-test-kit/releases)
+      from its [GitHub repository](https://github.com/inferno-framework/cancer-pathology-data-sharing-test-kit).
+
+      ## Providing Feedback and Reporting Issues
+
+      We welcome feedback on the tests, including but not limited to the following areas:
+      - Validation logic, such as potential bugs, lax checks, and unexpected failures.
+      - Requirements coverage, such as requirements that have been missed, tests that necessitate features that the
+        IG does not require, or other issues with the interpretation of the IG’s requirements.
+      - User experience, such as confusing or missing information in the test UI.
+
+      Please report any issues with this set of tests in the [issues section](https://github.com/inferno-framework/cancer-pathology-data-sharing-test-kit/issues)
+      of the repository.
+
+    DESCRIPTION
+    suite_ids [:cpds_report_generation, :cpds_data_access]
+    tags []
+    last_updated LAST_UPDATED
+    version VERSION
+    maturity 'Low'
+    authors ['MITRE Inferno Team']
+    repo 'https://github.com/inferno-framework/cancer-pathology-data-sharing-test-kit/'
+  end
+end