Details
-
Change Request
-
Resolution: Persuasive
-
Medium
-
US Minimal Common Oncology Data Elements (mCODE) (FHIR)
-
1.0.0 [deprecated]
-
Clinical Interoperability Council
-
TNM Clinical Stage Group [deprecated]
-
-
Russ Leftwich / May Terry: 5-0-1
-
Enhancement
-
Non-compatible
Description
When testing compliance with mCODE, we might find resources that fail to comply to any mCODE profile. Does this mean that the system fails to comply with mCODE?
Presumably any EHR contains three types of resources:
- Resources that are explicitly in the scope of mCODE and therefore, if they fail validation testing, it implies non-compliance with mCODE. An example is an observation with code LOINC 21908-9, Clinical Stage Group.
- Resources that are clearly outside the scope of mCODE and are not expected to comply with mCODE profiles. An example is a VisionPrescription resource.
- Resources that may be connected to mCODE might be intended to be mCODE compliant. An example is a Condition resource that might be intended to be an mCODE ComorbidCondition, PrimaryCancerCondition, or SecondaryCancerCondition resource, or maybe not.
Perhaps one option to disambiguate the third category is to have the server system declare whether an instance is intended to be mCODE compliant by including some declaration in the instance itself. This could be accomplished by putting the name of an mCODE profile in meta.profile. This is not currently required by mCODE.
I would like to see a thoughtful discussion of this problem and development of clear conformance criteria.