Skip to end of metadata
Go to start of metadata

Warning:

Do not launch ANY of the links while your are in create or edit mode. There is a good chance all of your work will be gone.


Template Usage Information:

  1. Project Name and ID



Enter the name of the project here: Minimal Common Oncology Data Elements

Project ID: 1509

Complete this section for all “Direct to Normative” ballot projects and when a project proceeds from “Informative to Normative” or “STU to Normative”.

Forward PSS to the TSC (via tscpm@HL7.org); this triggers American National Standards Institute (ANSI) Project Initiation Notification (PINS) submission.

 

TSC Notification:  Informative/STU to Normative 

Date:  Submission date

 

- or -                     Direct to Normative (no STU) (includes reaffirmations)       

 

Identify ISO, IEC or ISO/IEC standard to be adopted in text box below

Enter info here if an ISO, IEC, or ISO/IEC Standard is to be adopted as an American National Standard; Enter the designation of the standard(s) to be adopted:

Includes text from ISO, IEC or ISO/IEC standard: Check here if this standard includes excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption.

Yes

 

No

X

Select the unit of measure used in the standard; if no measurements are in the standard, select N/A

 X

N/A

 

U.S.

Metric

 

Both

 

Investigative Project (aka PSS-Lite)

Date : 

Check this box when the project is investigative or exploratory in nature, which allows limited project scope definition. Sections 1-Project Name, 2-Sponsoring Group(s)/Project Team, 3a-Project Scope, 3b-Project Need, 3e-Project Objectives/Deliverables/Target Dates, 3i-Project Document Repository, 6b-[Realm, if known], and 6d-[applicable Approval Dates] are required for Investigative Project. Investigative Project specific instructions are highlighted in yellow. An investigative project must advance in two WGM cycles, requiring a full scope statement. Otherwise the project will be closed.

2. Sponsoring Group(s) / Project Team

2.a. Primary Sponsor/Work Group

Primary Sponsor/Work Group
(1 (And Only 1) Allowed)

Clinical Interoperability Council

2.b. Co-sponsor Work Group(s)

Co-sponsor Work Group(s):

(Enter co-sponsor approval dates in Section 6.d Project Approval Dates)

CIMI

Indicate the level of involvement that the co-sponsor will have for this project:
YES Request formal content review prior to ballot
YES Request periodic project updates. Specify periodMonthly
NO Other Involvement. Specify details here: 

2.c. Project Team

All names should have confirmed their role in the project prior to submission to the TSC.

Project facilitator (1Mandatory)

Mark Kramer

Other interested parties and their roles

ASCO (authors/reviewers), CancerLinQ (authors/reviewers), Clinical Information Interoperability Council (reviewer/sponsor), Cancer Interoperability Group (reviewers), HL7 Public Health WG (reviewers, period updates), Biden Cancer Initiative (adviser/convener), Brigham and Women's Hospital (potential implementer), Beth Israel Deaconess (potential implementer), Commonwell Health Alliance (adviser)

Multi-disciplinary project team (recommended)


     Modeling facilitator

May Terry

     Publishing facilitator

Laura Heerman Langford

     Vocabulary facilitator

Susan Matney, Rute Martins

     Domain expert rep

Wendy Rubinstein (ASCO/CancerLinQ)

     Business requirement analyst

Monica Bertagnolli (ASCO)

     Conformance facilitator (for IG projects)

Lloyd McKenzie

     Other facilitators (SOA, etc)




Implementers (2 Mandatory for STU projects)

FHIR Project Note: The implementer requirement will be handled by the “balloting” project.  Therefore work groups do not fill out the above section.  However, feel free to list implementers specific to your work group’s resources if you know of any.

1) Intermountain Healthcare

2) Partners Healthcare

3) CancerLinQ

3. Project Definition

3.a. Project Scope


Describe the project; include what is expected to be accomplished/delivered along with specified features and functions. Include whether the deliverable(s) are universal, realm specific or applicable to various realms. Be sure to spell out all acronyms as these are carried forward to the NIB (Notice of Intent to Ballot) for ballot announcements.

This project will develop a common set of standardized data elements relevant to many types of cancer. It is intended to facilitate collection of "real world data" from clinical encounters with higher uniformity and quality, independent of the provider or EHR vendor. Data structures accurately capturing patient characteristics, disease characteristics, treatments, and outcomes that matter to patients and clinicians would rapidly accelerate progress toward using current therapies optimally and potentially, new clinical guidelines. The resulting Minimal Common Oncology Data Elements (mCODE)-based data sets, with data from the clinical care settings, will not require extensive curation, and will be shareable with other mCODE-based data sets without reformatting. A core team of oncologists will guide the selection and prioritization of content, and the results (subject to HL7 approval) will be delivered as FHIR profiles in an Implementation Guide (IG). The results will be US Realm-specific, but the lessons learned, and many of the actual profiles, could have universal applicability. The intent is to base mCODE on a common base logical model determined and approved by CIMI.


3.b. Project Need


This information is required by ANSI for all ballots. Briefly explain the reason behind the need for this project. This may be related to legislative requirements, industry need, or similar justifications.
Tremendous progress could be made if oncology data gathered in clinical encounters could be captured in standard form. Currently, only 3-5% of cancer patients participate in randomized clinical trials (RCTs), and very little medical knowledge is gained from the other 95-97%. A significant part of the problem with real-world data is caused by the variability in the ways that EHRs capture clinical data, with much information going into clinical notes. Attempts to extract structured information clinical notes using natural language processing (NLP) have not been able to deliver high quality, computable data at scale. The only effective method of involves human data curation, which is expensive and unscalable. Although large repositories of cancer data already exist, the usefulness of this data is hindered by the variability and lack of structure in the data.

The interested parties, led by American Society of Clinical Oncologists (ASCO), believes the best starting point to begin to address this problem is to identify a small set of data elements that should be collected for all cancer cases, an effort they have named "mCODE", for Minimal Common Oncology Data Elements. Of course, mCODE will not be effective unless clinicians are willing to routinely apply it during patient care. Data collection is therefore an essential feature of mCODE use cases, for which the design goal is to minimize disruption of normal workflow and maximize incentives for adoption by the clinicians. MITRE and ASCO have teamed up to develop an mCODE-based Fast Healthcare Interoperability Resources (FHIR) implementation and Substitutable Medical Applications and Reusable Technologies (SMART)-on-FHIR application to extract mCODE data in computable formats. Intermountain Healthcare, as a participating CancerLinQ data repository and leader in quality cancer care, will operate test sites for capturing the required mCODE data and for utilizing the tailored reports during clinical care. The incentive driving initial mCODE adoption is its use in therapeutic decision-making and comparative effectiveness analysis, by providing cancer patients and oncologists with a cohort of (anonymized) similar patients, with their treatments an outcomes, in real-time. The ultimate goal is to use real world data to accelerate progress toward using current therapies optimally and potentially developing new clinical guidelines, particularly for patients currently underserved by RCTs, such as elderly and disadvantaged patients, patients with multiple co-morbidities, for rare tumors, and to assess outcomes in patients who receive multiple lines of treatment.


3.c. Security Risks


Will this project produce executable(s), for example, schemas, transforms, style sheets, executable program, etc.  If so the project must review and document security risks. Refer to the Cookbook for Security Considerations for additional guidance, including sample spreadsheets that may be used to conduct the security risk assessment. 


Yes

X

No


Unknown


3.d. External Drivers


Describe any external schedules or calendars which may not be known outside of the project team that are driving target dates for this project..

None


3.e. Project Objectives / Deliverables / Target Dates

Within each row, enter the explicit work product(s) / objective(s).  Indicate their target date at the right in WGM/Ballot Cycle format.  Include the project end date as the last objective (for standards projects, the end date will be the projected ANSI approval date). 

Target Date (in WGM or ballot cycle format, e.g. ‘2017 Sept WGM’ or ‘2017 Jan Ballot’)

Submit for STU Ballot (First Ballot Cycle)

2019 Sep Ballot

Complete STU Reconciliation

2020 Jan WGM

STU Published2020 Jan

Submit for Normative Ballot

2020 Sep Ballot

2022 Jan Ballot

Complete Normative Reconciliation

2021 Jan

2022 Jan


Submit Publication Request

2021 Jan

2022 Feb

Receive ANSI Approval

2021 April

2022 April

Project End Date (all objectives have been met)

Note:  For PSS-Lite/Investigative Project, End date must be no more than two WGM cycles, e.g. project initiated at January WGM must complete investigation by September WGM.

2021 April

2022 April


3.f.   Common Names / Keywords / Aliases


What common name does your group use to refer to the product(s) produced?  What alternative names, aliases and keywords does your group use to refer to the product(s) that will be produced?  Some examples: C-CDA, LRI, eDOS.  

mCODE (aka Minimal Common Oncology Data Elements)


3.g. Lineage


If your project creates a Post-Release 1 version; indicate the name of the prior product and if it is supplanting, replacing or coexisting with a previous release:

n/a

3.h. Project Dependencies


Enter any dependencies or the name & Project Insight ID of project(s) that this project is dependent upon to achieve its objectives:
 

Projects and their Project Insight IDs can be found via http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?ref=common


HL7 Clinical Genomics Domain Information Model(s) (Project ID 1050)


3.i.   HL7-Managed Project Document Repository Location


Projects must adhere to the TSC's guidelines (which were approved on 2016-04-04 and summarized in Appendix A).

A template to create a Project Page on the HL7 Wiki is available at: http://wiki.hl7.org/index.php?title=Template:Project_Page.

Enter the SPECIFIC URL of the HL7-MANAGED SITE where supporting project documents, deliverables, ballot reconciliation work and other project information will be kept
https://confluence.hl7.org/display/CIC/Minimal+Common+Oncology+Data+Elements (this page is proposed – has not been created yet)


3.j.   Backwards Compatibility


Are the items being produced by this project backward compatible?


Yes


No


Unknown

X

N/A

If you check 'Yes' please indicate the earliest prior release and/or version to which the compatibility applies:


For V3, are you using the current data types? 

(Refer to TSC position statement on new projects using R2B for more information on the current V3 data types)


Yes


No


Unknown

X

N/A



If you check no, please explain the reason:

If desired, enter additional information regarding Backwards Compatibility.


3.k. External Vocabularies


Will this project include/reference external vocabularies?

X

Yes


No


Unknown


N/A

If Yes, please enter the vocabularies: SNOMED CT, LOINC, RxNorm, HGNC (Hugo Genetics Nomeclature Committee), UCUM, GTR (Genetics Test Registry)


4. Products (check all that apply)



Arden Syntax


V2 Messages – Administrative


Clinical Information Modeling Initiative (CIMI)


V2 Messages - Clinical


Clinical Context Object Workgroup (CCOW)


V2 Messages - Departmental


Domain Analysis Model (DAM)


V2 Messages – Infrastructure


Electronic Health Record (EHR) Functional Profile


V3 Domain Information Model (DIM / DMIM)

x

FHIR Extensions


V3 Documents – Administrative (e.g. SPL)

x

FHIR Implementation Guide (enter FHIR product version below)


V3 Documents – Clinical (e.g. CDA)

x

FHIR Profiles (enter FHIR product version below)


V3 Documents - Knowledge


FHIR Resources


V3 Foundation – RIM


Guidance (e.g. Companion Guide, Cookbook, etc)


V3 Foundation – Vocab Domains & Value Sets

x

Logical Model


V3 Messages - Administrative


New/Modified/HL7 Policy/Procedure/Process


V3 Messages - Clinical


New Product Definition (please define below)


V3 Messages - Departmental


New Product Family (please define below)


V3 Messages - Infrastructure


Non Product Project - (Educ. Marketing, Elec. Services, etc.)


V3 Rules - GELLO


White Paper


V3 Services – Java Services (ITS Work Group)

x

Creating/Using a tool not listed in the HL7 Tool Inventory


V3 Services – Web Services (SOA)

If you checked New Product Definition or New Product Family, please define below:


For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

DSTU 2


5. Project Intent (check all that apply)




Create new standard



Supplement to a current standard


Revise current standard (see text box below)


x

Implementation Guide (IG) will be created/modified


Reaffirmation of a standard



Project is adopting/endorsing an externally developed IG:


New/Modified HL7 Policy/Procedure/Process



Specify external organization in Sec. 6 below;





Externally developed IG is to be (select one):


White Paper (select one):



Adopted  - OR -


Endorsed



Balloted Informative OR


Non-balloted WG White Paper



N/A  (Project not directly related to an HL7 Standard)











If revising a current standard, indicate the following:


-    Name of the standard being revised:n/a
-    Date it was published (or request for publication, or ANSI designation date)n/a
-    Rationale for revisionn/a
-    The relationship between the new standard and the current standard (is it designed to replace the current standard, a supplement to the current standard, etc.)n/a


5.a. Ballot Type (check all that apply)



Comment (aka Comment-Only)



Joint Ballot (with other SDOs)


Informative



N/A  (project won’t go through ballot)

x

STU to Normative     - OR -


Normative (no STU)











If necessary, add any additional ballot information here.  If artifacts will be jointly balloted with other SDOs, list the other groups.



5.b. Joint Copyright

Check this box if you will be pursuing a joint copyright.  Note that when this box is checked, a Joint Copyright Letter of Agreement must be submitted to the TSC in order for the PSS to receive TSC approval.

Joint Copyrighted Material will be produced?



Yes

x

No


6. Project Logistics

6.a. External Project Collaboration


Include SDOs or other external entities you are collaborating with, including government agencies as well as any industry outreach.  Indicate the nature and status of the Memorandum of Understanding (MOU) if applicable.

For projects that have some of their content already developed:

How much content for this project is already developed?


Was the content externally developed ? :

N

Is this a hosted (externally funded) project?  (not asking for amount, just whether or not it is funded)


Yes

X

No


6.b. Realm



Universal 

- OR -

 X

Realm Specific




Check here if this standard balloted or was previously approved as realm specific standard

U.S.

Enter “U.S.” or name of HL7 affiliate(s) here.  Provide explanation/justification of realm selection. For projects producing deliverables applicable to multiple realms, document those details here. 

For Investigative projects, indicate if the project is planned to be Realm Specific or Universal, if known. Work Groups are encouraged designating project a Universal project initially, and discover which Realms can contribute to the work effort during the discovery phase of the project. Note: This status is subject to change during the investigative process.



6.c. Stakeholders / Vendors / Providers

This section must be completed for projects containing items expected to be ANSI approved, as it is an ANSI requirement for all ballots

 

Stakeholders

 

Vendors

 

Providers

x

Clinical and Public Health Laboratories

  

Pharmaceutical

x

Clinical and Public Health Laboratories

  

Immunization Registries

 

EHR, PHR


Emergency Services

x

Quality Reporting Agencies

  

Equipment

 x 

Local and State Departments of Health

  

Regulatory Agency

 x 

Health Care IT

 x

Medical Imaging Service

x

Standards Development Organizations (SDOs)

 x

Clinical Decision Support Systems

 x

Healthcare Institutions (hospitals, long term care, home care, mental health)

 

Payors

x

Lab

  

Other (specify in text box below)

 

Other (specify in text box below)

x

HIS

 

N/A

x
 
 

Patients!!!!! (tongue)


Other (specify below)


 


Other:  Indicate other stakeholders, vendors or providers not listed above.










6.d. Project Approval Dates

Click here to go to HL7 Project Scope Statement Instructions#Appendix A for more information regarding this section.
Approvals are by simple majority vote of the approving body

Sponsoring Work Group Approval Date:

WG Approval Date

2019-02-15

Administrative review – in parallel with Work Group Approval

Co-Sponsor Group Approval Date


List each Co-Sponsor and their Approval Date

CIMI WG - 2019-01-24


Family Management Group Approval Date(s)

CIMI Projects: CIMI Management Group

CIMI MG Approval Date

N/A

CDA Projects: CDA Management Group

CDA MG Approval Date

N/A

FHIR Projects: FHIR Management Group

FMG Approval Date

2019-02-20

V2/Publishing Projects: V2 Management Group

V2 MG Approval Date

N/A

US Realm Projects: US Realm Steering Committee Approval
(Email WG approved PSS to: tscpm@HL7.org)

USRSC Approval Date

2019-02-26

Affiliate Specific Projects: Affiliate Approval Date

Affiliate Approval Date

N/A

Submit PSS to Steering Division after all of the above approvals are received

Steering Division (of Primary Sponsor WG) Approval Date:

SD Approval Date CCYY-MM-DD

2019-03-22

Last PBS Metrics Score:

 Green

 Yellow

 Red

PBS Metrics Reviewed? (required for SD Approval if not green)

 Yes

 No

ARB and Steering Division approval may be in parallel

Architectural Review Board Approval Date:

(required for externally developed content)

ARB Approval Date

TSC Approval

If applicable, TSC has received a Joint Copyright/Distribution Agreement (containing the verbiage outlined within the SOU),
signed by both parties.

Yes

No

 N/A


Technical Steering Committee Approval Date:
(Email SD WG approved PSS to: tscpm@HL7.org)

TSC Approval Date

2019-04-01