Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • General design of Catalogs
    • See design summary document including lab compendium example
    • Profiling (currently in a spreadsheet  shared with the group mailing list) - version after the call
      View file
      name20191115_lab_catalogs_FHIR_design_post_call.xlsx
      height250
      • CatalogHeader: Composition ; for all kinds of catalogs
      • LaboratoryProcedureDefinition: PlanDefinition ; for lab compendium
      • TestOrPanelDefinition: ActivityDefinition ; for lab compendium
    • Additions checked:
      • Reflex testing has to be announced and specified in the catalog → Only handled in PlanDefinition (reflex and trigger). Dropped ActivityDefinition.intent 
        • Looking at slide 17 -18 of ppt: 
          • Expression element could use FHIRpath or other expression language that can describe the logic
          • Create overarching group with several sub-actions:
          • First part is the static part of the panel = static activityDefinition intent = original-order
          • Second subaction is kind = applicability with the expression of S. identified = meaning if Staph was identified – in the activityDefintion intent is then reflex, and then include ALL observationDefinitions attached to that reflex test
        • How to handle when reflex tests are also original orders?
          • Intent:
            • Original order
            • Reflex order
            • Filler-order – may be added by the filler lab, but not a part of a defined reflex algorithm
            • Does that mean that the system will have to have 2 activityDefinitions for the same test?
              • One for the reflex scenario
              • One for original order, when submitting an isolate for example
            • Maybe use the planDefinition ONLY to indicate reflex and not on the activityDefinition and not use the intent
          • How do you indicate a test is orderable?
            • Default in catalog is NOT orderable, if it is orderable – use context = LabOrderEntry and code task
            • The usageContext is a slice – should be 0..*
              • Can represent orderable test
              • Can represent population that the test is applicable for (e.g. for gender using the administrative-gender ValueSet)
              • usageContext terminology binding is extensible
      • Drop superset and "ivd-" prefix for PlanDefinition.type, and have to build definitions for test and panel (check if existing ones available)
      • Textual billing summary → Extension agreed. Gary to provide examples for the IG
        • Have extension for planDefinition called billingCode
        • Look at CMD segment used in eDOS – I guess we only need extension for the billing summary – which will be just text
      • Textual schedule summary → Extension agreed.
        • we already have estimated turnaround time in PlanDefinition, but often we need to indicate that tests are performed on specific days only
      • PlanDefinition scope describes use for representing "…order sets, protocols and …" – that should still fit – FMG advised to adopt this as well as CDS
        • We found all the replacements for all fields in catalogEntry in this resource, so we think its use is ok
      • Textual limitations summary → need more precision on this need, and examples → Gary?
  • Is there a place for clinical significance – in eDOS is was OM1-32 (interpretation) – is still in obsesrvationDefiniton
  • Managing and exchanging subsets of a lab compendium (Freida)
    • Search using PlanDefinition.topic criterion, which enables to represent as many categorizations as needed. You can obtain in a Bundle a subset of the catalog represented by the PlanDefinition resources corresponding to a particular topic value together with all the resources they reference.

...