standardhealth/fsh-mcode

fsh-mcode's Issues

Eliminate identifier slicing on GenomicVariant, TumorMarker

AccessionIdentifier, FillerIdentifierNumber, PlacerOrderNumber

Ref #50

Should component[DNARangesExamined] be a Range?

This refers to the GenomicRegionStudied profile, the component DNARangeExamined is a Range. The Range data type has a low and high element, whose type is SimpleQuantity. Is a SImpleQuality really suitable for a DNARange lower or upper bound?

ReasonCode and ReasonReference in CancerSurgicalProcedure

Both ReasonCode and ReasonReference are optional for CancerRelatedSurgicalProcedure, yet is one of these elements that determines the cancer-related nature of the procedure. From the profile's description:

The scope of this profile has been narrowed to cancer-related procedures by constraining the ReasonReference and ReasonCode to cancer conditions.

These these elements be marked as MS, at the very least, and we should consider an invariant/guidance indicating one of the fields must be populated.

GenomicRegionStudied, UnitsOfLengthVS, and USCore SUSHI 0.6.1 compilation errors

SUSHI 0.6.1 improved and found the following fsh syntax related grammar errors:

• error: extraneous input 'GeneStudied' expecting {<EOF>, KW_ALIAS, KW_PROFILE, KW_EXTENSION, KW_INSTANCE, KW_INVARIANT, KW_VALUESET, KW_CODESYSTEM}

• error: Alias USCoreRace cannot be redefined to http://hl7.org/fhir/us/core/StructureDefinition/us-core-race; it is already defined as http://hl7.org/fhir/us/core/ValueSet/omb-race-category.

• error: extraneous input 'UCUM#mm' expecting {<EOF>, KW_ALIAS, KW_PROFILE, KW_EXTENSION, KW_INSTANCE, KW_INVARIANT, KW_VALUESET, KW_CODESYSTEM}

IG Pub seems to object to the name of our IG

ImplementationGuide/fhir.us.mcode
ig-0: Name should be usable as an identifier for the module by machine processing applications such as code generation [name.matches('A-Z{0,254}')]
It appears the regex doesn't allow periods, but does allow underscores.

Remove RadiationDose complex extension from CancerRelatedRadiationProcedure

Ref #50

TNM Categories should be Must Support in Stage Group hasMember

I think we wanted to do this but we were blocked by CIMPL limitations. These should definitely be MS.

Is EvidenceType staying or going?

We need a decision on whether the EvidenceType extension will be included in mCODE 1.0. It is not a must-support element in CancerDiseaseStatus, and as such, it is unusual in mCODE. It's the only case of introducing an extension that is not MS. However, CodeX needs this element. It could be part of the iCAREdata IG.

If EvidenceType is cut, then CancerDiseaseStatusEvidenceTypeVS should be eliminated as well.

Change one code in ConditionStatusTrendVS

[Carmela]: Suggest removing * SCT#260415000 "Not detected (qualifier)" and adding 281900007 |No abnormality detected (finding). This would be much more consistent with other values in the set, and also closer to the target meaning of "no evidence of disease".

Remove StatementDateTime extension CancerRelatedRadiationProcedure and CancerRelatedSurgicalProcedure

Ref #50

Adopt ID convention "mcode-profile-or-extension-name"

Other IGs seems to be using a convention for profile ids that follows the pattern "ig-profile-or-extension-name". For mcode, it would be like "mcode-cancer-patient". We should follow this convention and do so before 1.0 release.

CancerRelatedRadiationProcedure is missing total Grays delivered & Gray/fraction

Reported by Halina Labikova (Varian)
Fractions in Radiation Therapy, for example. I was poking around mCODE RT Profile, and it doesn't make too much sense to me to just capture the RT modality w/o total grays delivered or gy per fraction. (http://build.fhir.org/ig/HL7/fhir-mCODE-ig/StructureDefinition-CancerRelatedRadiationProcedure.html)

Recheck definitions for Clinical and Pathological Staging

Make sure they accurately reflect Clin vs. Path.

FHIR examples are not appearing in the Examples tab within each profile page

Screenshot below:

YesNoUnknownVS is not used in mCODE and should be removed

Title says it all.

Make Karnofsky Value Set reference LOINC

KarnofskyPerformanceStatusVS is a copy of LOINC list LL4986-7. We did last year this because of IG Pub limitations. I wonder if it is time to change it to a reference to the LOINC answer set. The use of LOINC answer lists in FHIR is explained here: https://www.hl7.org/fhir/loinc.html#alist

Add Must Supports to CancerRelatedMedicationStatement

We used to inherit MS flags from US Core, but US Core 3.1 no longer has a MedicationStatement profile, so we are inheriting directly from FHIR MedicationStatement. Two important MS that are missing: effective[x] -- the start and stop time of the medication, the medication[x] -- the medication itself.

mCODECancerGeneticVariantExample02 Missing?

It looks like the balloted IG had an example for "Genetic Variant - single somatic mutation" called mCODECancerGeneticVariantExample02 and described as "extends the contents of the Genomic Report example showing whether a test for a specific mutation for BRCA1 was present."

This example is missing from the PreRel #2 draft. I commented out the link in examples.md, so if it is added, the link should be re-instated. IG json should also be updated in that case.

mcode-termination-reason extension not marked as MS in CancerRelatedRadiationProcedure

I think this is a bug. The extension should be marked as MS in all the profiles it's used in, since it is an mCODE element. In CancerRelatedMedicationStatement the extension is marked as MS.

Replace generic attribute short descriptions and definitions

The definition and short description of elements throughout the IG are the inherited from either FHIR or US Core. They don't describe the elements in the context of mCODE.

CancerGenomicsReport.result slices have incorrect references to US Core Observation

Screenshot below:

It appears that the generated CancerGenomicsReport StructureDefinition has incorrectly populated the Reference:

        "path": "DiagnosticReport.result",
        "sliceName": "CancerGeneticVariant",
        "short": "Observations",
        "definition": "[Observations](http://hl7.org/fhir/R4/observation.html)  that are part of this diagnostic report.",
        "comment": "Observations can contain observations.",
        "requirements": "Need to support individual results, or  groups of results, where the result grouping is arbitrary, but meaningful.",
        "alias": [
          "Data",
          "Atomic Value",
          "Result",
          "Atomic result",
          "Data",
          "Test",
          "Analyte",
          "Battery",
          "Organizer"
        ],
        "min": 0,
        "max": "1",
        "base": {
          "path": "DiagnosticReport.result",
          "min": 0,
          "max": "*"
        },
        "type": [
          {
            "code": "Reference",
            "targetProfile": [
              "http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-lab"
            ]
          }
        ],

targetProfile should be http://hl7.org/fhir/us/mcode/StructureDefinition/CancerGeneticVariant

Change ^status to #active on all Profiles and Extensions

Ugh. Chris might be changing the default status of all StructureDefinitions to #draft in the next version of SUSHI. We want our SDs to be #active, across the board.
FYI, here are the definitions of the codes #active, #draft, #unknown: http://hl7.org/fhir/R4/valueset-publication-status.html

Remove RelationToLandmark and AnatomicalOrientation extensions on BodySite

Remove extensions on BodySite (many profiles): unless these are specifically aligned with Clinical Genomics for GeneticSpecimen, none of the mCODE profiles go beyond specifying a value set for bodySite. There were ballot comments against extending bodySite.

NOTE: Leave laterality as-is because it addresses a ballot comment, and it is important MS element.

Ref #50

Laterality value set change

From Wendy Blumenthal:

FHIR-24511
We don’t agree with the use of CIMI’s value set in that it mixes the concept code types and we believe two of the values come from the wrong concept types. We believe laterality is a qualifier of body site rather than a structure in its own right.

For that reason, we feel the better SNOMEDCT Concept code for:

• Right is 24028007 (qualifier) rather than CIMI's 85421007 (structure of right half of the body)
• Left is 7771000 (qualifier) rather than CIMI's 311560008 (structure of left half of the body)

CIMI’s values for the following codes match the values we use in our value set and come from the qualifier concept type:

• Right and Left 51440002 (qualifier)
• Midline (qualifier)

Unilateral 66459002 (qualifier) is a needed value for cancer registries; its meaning is “Only one side involved, right or left origin, unspecified”. We would prefer that this value is added, but can live with it if the decision is to leave it out.

We are okay with the decision to leave “not applicable” out of the value set

Cannot bind to code systems

There were several places where we were attempting to bind to a code system, instead of a value set, for example, this line:
component[GenomicDNAChange].valueCodeableConcept from HGVS
and this:
* component[GeneStudied].valueCodeableConcept from HGNC

Be careful because neither of these are value sets. They are both code systems.

TNM Clinical and Pathological staging Observation.focus should be MS, possibly required

Currently, the Observation.focus attribute bound to PrimaryCancerCondition is optional and not must-support.
This needs to be at least MS, and potentially a required attribute since staging has no meaning without its association to a primary cancer condition. Moreover, it is possible for one to have multiple primary cancers and without enforcing this, one doesn't know which cancer the stage is related to.

New batch of QA errors need to be addressed

The new IG Pub has issued a boatload of new warnings and errors.

Laterality separate required element

From Wendy Blumenthal:

FHIR-24510 https://jira.hl7.org/browse/FHIR-24510

We would like some more clarification on the response. It says “should” but the spec says “must be supported”, so we’re not clear if this is a required element or not. For cancer registries, this is an absolutely required data element; they cannot determine the number of cancers a patient has without knowing the laterality of the tumor. Without this information, the registry cannot provide accurate incidence rates.

mCODE extensions are missing examples

Identified by Lloyd McKenzie during the FMG mCODE Publication Review:
Warnings that the following extensions are missing examples:

• mcode-termination-reason
• mcode-laterality
• mcode-histology-morphology-behavior

Fixes are to represent these in at least one mCODE instance which has this in their profile.

Removing non-cancer content leftover from CIMPL

[Rute]:
Principles for the translation from CIMPL to FSH:

1. Port elements explicitly required in mCODE scope and default to community-accepted content otherwise (e.g. base resource/US Core profile)
2. Porting tailored to target FHIR version and alignment scoped to mCODE-specific content (e.g. don’t backport R4 elements to DSTU2 as extensions if not MS mCODE elements)

Here are my findings and recommendations:
• Remove StatementDateTime extension CancerRelatedRadiationProcedure and CancerRelatedSurgicalProcedure: it’s a leftover from OBF. I believe we can fit this under the “removal” of non-standard extensions ballot comment.
• Remove extensions on BodySite (many profiles): unless these are specifically aligned with Clinical Genomics for GeneticSpecimen, none of the mCODE profiles go beyond specifying a value set for bodySite. There were ballot comments against extending bodySite.
• Remove RadiationDose complex extension from CancerRelatedRadiationProcedure: it was modeled in oncocore but it never surfaced as a requirement for mCODE and it’s not part of the data dictionary (note that in the current IG it is marked as MS, but I don’t believe the mCODE governance bodies ever discussed adding radiation dose as an element). This change would fit under Lloyd’s comment on not creating an extension for radiation dose.
• Consider eliminating identifier slicing on GenomicVariant, TumorMarker: leftover CIMI-ism?

Add Vital and Lab back into DD

[from Bob Miller] Put Height, Weight, Blood Pressure, CMP and CBC back into the DD. In the Profile column, name the external profile.

Expand SNOMED histology/morphology value set

From Wendy Blumenthal:

FHIR-24509. https://jira.hl7.org/browse/FHIR-24509

There is one other code with descendants that is critical for registries to include, so we would like it to be added….: In situ melanocytic morphology (morphologic abnormality) [253035009]. It will not be a descendent of Carcinoma in situ

Subject in Cancer Related Radiation Procedure pointing to US Core Patient

Should the subject point to CancerPatient instead or was this discrepancy intended? If intended, it's unclear when to use the CancerPatient profile vs. US Core Patient.

Request new LOINC codes for "disease status" and "cancer disease status"

Requested by Susan Matney re: CancerDiseaseStatus.
The current LOINC code used is in "response to treatment" which differs from our CancerDiseaseStatus profile which is an assessment to the overall patient status and not specifically in response to treatment".

GeneticTestMethodVS constraint missing from TumorMarker profile.

Missed porting this over from CIMPL.

Proofread and if necessary correct the mCODE Diagram

just a reminder to do this task -- with all our changes, we should be careful the diagram is accurate.

Whitespace warning from IG Pub

StructureDefinition/CancerGeneticVariant: StructureDefinition.snapshot.element[43].mapping[3].map warning value should not start or finish with whitespace

StructureDefinition/GenomicRegionStudied: StructureDefinition.snapshot.element[16].mapping[3].map | warning | value should not start or finish with whitespace

Update data dictionary

Data dictionary needs to be updated with changes made

Front matter files and images missing after IG Publisher upgrade

SAX-parsing errors on all mCODE images and binary files (XLS, Word Doc) after running IG Publisher FHIR IG Publisher Version 1.0.61-SNAPSHOT. The mCODE front matter images are then missing.

ReasonReference pointing to CancerConditionParent

In CancerRelatedSurgicalProcedure and CancerRelatedRadiationProcedure, the ReasonReference element is pointing to CancerConditionParent.

In the IG, this profile is described as an abstract class (should it even be there?). Why not point directly to PrimaryCancerCondition and SecondaryCancerCondition as choices?

CancerPatient lacks a description

Description is absent from FSH source.

Inconsistent guidance on representing AJCC version 8

Our staging examples specify AJCC version 8 as follows:
* method = MTH#C146985 "AJCC Cancer Staging Manual 8th Edition"
However, our documentation states: "Because SNOMED CT does not currently have a code representing AJCC Version 8, specify the exact text 'AJCC Version 8' in the text sub-field of the code structure, and omit the code."
We need to have consistency between the guidance and the examples.

CancerHistologicGradeVS is not used and should be removed from mCODE

The title says it all. It is appearing on the ValueSet page.

GeneticTestVS is not used in mCODE and should be removed

Associate extensions with resource(s)

The extensions defined in mCODE should be associated with a context -- the element or resource they can extend. It's good form to say where the extension can be used. Not sure if this is something we need to do before 1.0...

Add \build\input-cache\org.hl7.fhir.publisher.jar to .gitignore

Cancer Related Radiation/Surgical Procedure are not on the example page

GeneticVariant components are not constrained

Document that metadata elements are not included in DD

To be specific, the metadata elements suppressed from 1.0 DD are:
• Reference to the patient or subject
• Time of the event and/or time of record creation
• Encounter, if required by US Core
• Workflow status for observations, conditions, and procedures
• Any fixed codes that identify the type of measurement or observation
• The practitioner or organization for observations and conditions, except where this information is specifically important to interpretion the result (only in GenomicsReport)

Implementation page is out of date

Several things on the implementation page are out of date. The Body Site description still refers to multiple extensions when we had landmark-related extension. Several other things (vitals, labs) need to be updated to reflect 1.0, as well. The entire page needs to be carefully looked at.
Includes checking all versions and all supporting documentation.