Feedback Request: The authors are asking for feedback on the design approach for representing specific systems (e.g., specific cancer staging systems and performance scales). For example, currently, there are two abstract profiles for Cancer Stage and Cancer Risk Assessment, with 8 additional profiles for specific staging systems and risk assessments that use the abstract profiles as the parent. The advantage of these tailored profiles help ensure more consistent communication of this data by providing detailed guidance on the FHIR representation of the data from these assessments. However, this specificity comes at the expense of the lack of scability of the appraoch, since a vast proliferation of profiles would be required to represent all cancer stage systems and risk assessments currently in use. An alternate option could be to keep the abstract Cancer Stage and Cancer Risk Assessment profiles, remove the specific stage system and risk assessment profiles, but add narrative and examples that explain how common staging systems and risk assessments should be represented using the abstract Cancer Stage and Cancer Risk Assessment profiles. We welcome your feedback

Response:

By putting the 'house rules' in the Narrative, with examples,  you run the real risk of errors introduced by not being able to link the Code and ValueSet correctly.  If there were only 10s of organizations populating these profiles,  you might be able to get away with strict development standards and connectathons to guarantee the quality of the data.  But I don't think that is realistic.

I would want to know how much the authors of mCODE have looked into a new form of  Slicing:  https://build.fhir.org/profiling.html

If you were going to take the hit to update the Narrative and Examples every time a new Cancer Staging Profile was added,  you may as well add in the slice as well:

Note:  Slicing works on lists, and there is only one code per Observation, so you can't slice directly on Observation.code. 

(See attached picture)

So could you set up a profile called 'Cancer Staging CodeableConcept',  that contains all the Cancer Staging Slices, either as Observation[Generic Cancer Stage].hasMember.[Neuroblastoma INRGSS Stage Slice,  Neoroblastoma INSS Stage Slice, etc].  This would allow us to constrain the Code and Value Set by slice,  which would allow validation that the code and ValueSet match up. 

You could also do the same on Observation.Component,  but that seems a little weird.    I definitely would want the FHIR Architecture group to weigh in.  They might even propose a new element within the Observation Profile.