2659934 extend dragon copilot cli for radiology scenarios#220
2659934 extend dragon copilot cli for radiology scenarios#220BHANUPREDDY8126 wants to merge 21 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Adds initial Dragon Copilot for Radiology (DCR) support to the dragon-copilot-cli and introduces accompanying radiology manifest/schema artifacts, reference models, and sample payloads to support radiology extension scenarios.
Changes:
- Added a new
radiologycommand group to the CLI (init/generate/validate/package) plus DCR manifest schema validation. - Introduced a DCR extension manifest JSON schema, radiology templates, and interactive prompt flows.
- Added radiology OpenAPI/spec YAMLs, C# reference models, and sample request/response payloads.
Reviewed changes
Copilot reviewed 34 out of 35 changed files in this pull request and generated 11 comments.
Show a summary per file
| File | Description |
|---|---|
| tools/dragon-copilot-cli/src/shared/schema-validator.ts | Adds DCR schema loading and DCR manifest validation entrypoints to the shared validator. |
| tools/dragon-copilot-cli/src/schemas/dcr-extension-manifest-schema.json | New JSON Schema defining the DCR extension manifest contract (tools, auth, content-types, filtering criteria). |
| tools/dragon-copilot-cli/src/domains/radiology/types.ts | New TypeScript domain types for DCR manifests, templates, and CLI options. |
| tools/dragon-copilot-cli/src/domains/radiology/templates/index.ts | Adds radiology manifest templates exposed by radiology generate --template. |
| tools/dragon-copilot-cli/src/domains/radiology/shared/schema-validator.ts | Domain-local AJV schema validator for DCR manifests (schema + business rules). |
| tools/dragon-copilot-cli/src/domains/radiology/shared/prompts.ts | Radiology interactive prompts and input validation helpers. |
| tools/dragon-copilot-cli/src/domains/radiology/index.ts | Registers radiology CLI commands and wires to command implementations. |
| tools/dragon-copilot-cli/src/domains/radiology/commands/validate.ts | Implements dragon-copilot radiology validate for DCR manifests. |
| tools/dragon-copilot-cli/src/domains/radiology/commands/package.ts | Implements dragon-copilot radiology package zip packaging for DCR extensions. |
| tools/dragon-copilot-cli/src/domains/radiology/commands/init.ts | Implements dragon-copilot radiology init project/manifest scaffolding. |
| tools/dragon-copilot-cli/src/domains/radiology/commands/generate.ts | Implements dragon-copilot radiology generate (template + interactive tool addition). |
| tools/dragon-copilot-cli/src/commands/index.ts | Registers the new radiology command group in the unified CLI. |
| tools/dragon-copilot-cli/package.json | Updates CLI dependencies (AJV version range changed). |
| tools/dragon-copilot-cli/package-lock.json | Locks updated dependency resolution (AJV pinned). |
| tools/dragon-copilot-cli/extension.yaml | Adds a sample DCR manifest under the CLI tool directory. |
| radiology/src/requests/samples/Report-Minimal.json | Sample minimal radiology report payload. |
| radiology/src/requests/samples/QualityCheckResult-MixedBillingClinical.json | Sample mixed billing/clinical quality-check result payload. |
| radiology/src/requests/samples/PatientInformation-AllFields.json | Sample patient information payload. |
| radiology/src/models/Dragon.Copilot.Radiology.Models/Report.cs | C# reference model for the DCR report payload. |
| radiology/src/models/Dragon.Copilot.Radiology.Models/ReferenceResource.cs | C# reference model for recommendation reference resources. |
| radiology/src/models/Dragon.Copilot.Radiology.Models/Recommendation.cs | C# reference model for quality recommendations. |
| radiology/src/models/Dragon.Copilot.Radiology.Models/QualityCheckType.cs | C# enum for quality check types. |
| radiology/src/models/Dragon.Copilot.Radiology.Models/QualityCheckResult.cs | C# reference model for the quality-check result envelope. |
| radiology/src/models/Dragon.Copilot.Radiology.Models/Provenance.cs | C# reference model for recommendation provenance spans. |
| radiology/src/models/Dragon.Copilot.Radiology.Models/PatientInformation.cs | C# reference model for patient demographics payload. |
| radiology/src/models/Dragon.Copilot.Radiology.Models/BiologicalSex.cs | C# enum for patient biological sex. |
| radiology/dcr-dragon-extensibility-api.yaml | New OpenAPI contract for DCR extensions (/v1/process, envelopes, payload refs). |
| radiology/SessionData.yaml | Shared SessionData schema for DCR OpenAPI. |
| radiology/Report.yaml | YAML schema for the DCR report payload. |
| radiology/README.md | DCR manifest/spec overview and contract notes. |
| radiology/QualityCheckResult.yaml | YAML schema for DCR quality-check result payload. |
| radiology/PatientInformation.yaml | YAML schema for patient information payload. |
| physician/src/samples/DragonCopilot/Workflow/pythonSampleExtension/extension.yaml | Adjusts the physician Python sample manifest outputs. |
| extension.yaml | Adds a root-level sample DCR manifest. |
| Directory.Packages.props | Adjusts .NET package versions (Microsoft.Identity.Web downgrade). |
Files not reviewed (1)
- tools/dragon-copilot-cli/package-lock.json: Language not supported
| export interface DcrInputConfig { | ||
| minNumberOfPriors?: number; | ||
| maxNumberOfPriors?: number; | ||
| relevantBodyParts?: string[]; | ||
| relevantModalities?: string[]; |
There was a problem hiding this comment.
minNumberOfPriors/maxNumberOfPriors are defined as integer in the JSON schema, but the TypeScript types use number, which allows non-integer values. Align these TS types/validations with the schema to avoid users providing values that later fail schema validation.
|
@microsoft-github-policy-service agree company="Microsoft" |
…on_Copilot_CLI_for_Radiology_Scenarios
| # --------------------------------------------------------------------------- | ||
| # Request envelope | ||
| # --------------------------------------------------------------------------- | ||
| DragonStandardPayload: |
There was a problem hiding this comment.
This is a different definition of DragonStandardPayload than physicians. @mcdolejt for thoughts?
There was a problem hiding this comment.
I am not really sure if the DSP for radiology should be different for Rad. I don't think it should be. Clinical data is what it is. Meaning, it should have a type (observation.*, procedure, condition, allergy, etc...) to indicate what properties are relevant, a context to give the value meaning (The "question" or "field" which the data is representative of, and parent or children resources for relationships to other resources (allows for hierarchical data structures and mechanism to extend a resource). Those items alone are enough to cover the full spectum of clinical data across all specialties and regions. Sure there are some other properties like provenance, source, version, statuses, and other meta, for full compliance, but those are more for tracking than clinical meaning.
DSP and FHIR, are conceptually the same. FHIR was just focused on transactional of mostly higher level datapoints, where DSP is more focused on the clinical aspects of the data and is more flexible in terms of context definitions and relationships. In FHIR, for a condition, there are no properties beyond the "category" which allows for (encounter-condition, problem-list-item, or health-concern. There is no way to say that the condition is a CT finding of the Lung...Or the pre-operative diagnosis for an operation. Not as a discrete resource atleast. Sure, extensions could be always added, but we will always be chasing and required to be stable with a standard that we don't own...
There are my thoughts. Happy to discuss this further in a call as needed.
There was a problem hiding this comment.
Thank you for the comments.
I think that for an extension API, the contract benefits from being closer to the partner's domain rather than a shared abstraction. Radiology integrators tend to focus on studies, modalities, and structured findings — a wire format shaped that way keeps integration close to a serialization step, whereas a unified DSP would ask partners to translate into an abstraction whose cross-specialty payoff is less obvious given that partners today tend to be single-specialty.
So I think it would be better to share the plumbing (envelope, SessionData) and let the domain content diverge (input artifacts, clinical findings, recommendations).
I'm also happy to discuss this further.
1. renamed this file from dcr-dragon-extensibility-api.yaml to be radiology-extensibility-api.yaml 2 updated the readme file same pattern as physician
updated DragonStandardPayload also have a schema_version
updated ProcessResponse also have a schema_version
updated the "reportGeneration" capability to "qualityCheck"
removed "reportGeneration" capability to not supporting.
fixed icons
updated DragonRadiologyTool to DcrTool
updated $comment line
removed DragonInputConfig its not been used
removed extension.yaml its not been used updated the folder structure for samples
updated the packages
updated the packages
removed extension.yaml from cli folder
updated redme file
updated Missing "{" curly brace.
2659934 extend dragon copilot cli for radiology scenarios