View source for 201801 Automated Profiling From Domain Models


[[Category:201801_FHIR_Connectathon_Track_Proposals|Jan 2018 Proposals]]
=Track Name=
Automated Profiling From Domain Models
==Submitting WG/Project/Implementer Group==
<!-- Who is asking for this track? -->
Clinical Interoperability Council, Cancer Interoperability Group

==Justification==
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
There is a practical gap between documenting the clinical content in a healthcare domain via a domain analysis model, and the ability to deliver a corresponding FHIR implementation. While it is possible with existing manual tools to create individual FHIR Profiles in small numbers, clinical domains may require large numbers of profiles. There are over 100 clinical specialties and many more sub-specialties, and 50,000 human diseases that may require profiling in some fashion. Moreover, profiling a single healthcare domain independent from all others will create silos of information. The goal is to use the same FHIR profiles for wound assessment and wound care whether in nursing, geriatric medicine, podiatry, diabetes, or emergency care. The inevitable conclusion is that much more efficient and coordinated methods of profile development are required.

This track will test and compare multiple methodologies for creating FHIR profiles that make it possible to convert a domain analysis model (a so-called logical model) into a set of FHIR profiles in a relatively simple, efficient manner. For this Connectathon, the focus will be on modeling breast cancer staging. Focusing on one domain will allow for comparison of the modeling efforts more easily. However, if you have a different domain you wish to model, and have a complete workflow for going from input to FHIR profiles, you are also welcome to join this track. This track will also attempt to make some hypotheses about what constitutes a "good profile".

NOTE: This Connectathon track is agnostic to the approaches to logical modeling and FHIR Profiling. It is being supported by the MITRE Standard Health Record team, but any and all methods of modeling and profiling are welcomed and encouraged.

==Known Approaches to Capturing FHIR profiles==

{| class="wikitable"
! Who
! Logical Model Capture
! Logical Model Representation
! Mapping Language
|-
| style="font-weight: bold;" | FHIR
| Excel Spreadsheets
| Structure Definition
| FHIR Mapping Language
|-
| style="font-weight: bold;" | MITRE (Open Source)
| Clinical Information Modeling and Profiling Language (CIMPL)
| Clinical Information Model COmputable Representation (CIMCORE)
| CIMPL
|-
| style="font-weight: bold;" | FHIM
| Any UML development tool
| XMI
| Open Health Tools Model Driven Message Interoperability (MDMI)
|-
| style="font-weight: bold;" | CIMI
| MagicDraw and ADL Workbench
| Archetype Description Language (ADL) and Basic MetaModel (BMM)
| FHIR Mapping Language
|}

==Proposed Track Lead==
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
Mark Kramer, mkramer@mitre.org<br>
Michael O'Keefe, mokeefe@mitre.org<br>
See [[Connectathon_Track_Lead_Responsibilities]]

==Expected participants==
Participants that we have reached out to, or who have expressed interest in the connectathon topic:
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
* Clinical Interoperability Council (CIC)
* Clinical Information Modeling Initiative (CIMI)
* Federal Health Architecture (FHA) and Federal Health Information Model (FHIM)
* Model-Driven Health Tools (MDHT)
* College of American Pathologists (CAP)
* Wayne Kubic (HL7 CTO)
* Integrating the Healthcare Enterprise (IHE)
* HL7 Cancer Interoperability Group

==Profiling Problem Description==

The goal is to create FHIR profiles representing a simplified version of breast cancer staging. This section contains a high-level description of breast cancer staging. It is not intended to be 100% clinically accurate or complete. The following five data structures are in scope for the Connectathon:

# TNM Staging Elements
# ER Status and subelements
# PR Status and subelements
# HER2 Status and subelements
# Tumor Grade and subelements

The challenge can be viewed in two steps: 1) formalize the domain description as an information model, and 2) produce profiles from that description.

===Background===

The treatment of breast cancer is driven by several factors influencing the prognosis of each patient. The process of aggregating these factors is called '''staging'''. Staging is ultimately represented by a single overall score (0, IA, IB, IIA, IIB, IIIA, IIIB, IIIC, or IV), but many macroscopic, microscopic, and biologic factors go into staging. ''Note that the goal of the current exercise is not to calculate the overall stage, nor validate consistency among the staging categories, but only to define FHIR profiles to contain staging information.''

The American Joint Commission on Cancer 8th Edition Staging Manual (AJCC-8) defines the elements used in staging breast cancer. These include the traditional TNM staging components (anatomic staging), as well as other factors that are known to influence the prognosis of breast cancer patients, including: tumor grade, hormone receptor status (progesterone and estrogen), as well as human epidermal growth factor 2 (HER 2) status.

=== Staging Elements===

There are three staging components:

* T (tumor): defines categories for the primary tumor based on the tumor size.
* N (regional nodes): defines categories for lymph node involvement in the cancer, based on the status of lymph nodes in proximity to the breast.
* M (distant metastases): defines categories for presence or absence of distant metastases.

Each component has a value, referred to as a “category,” whose allowable values are given below.

Staging can be done at several points over the patient’s course of care:
* '''Clinical (c)''' refers to staging done before tissue samples have been obtained from the tumor. The T, N and M  components are prefixed with “c” to denote clinical staging (e.g., cT, cN).
* '''Pathologic (p)''' refers applies to staging in patients who had surgery as their initial course of treatment. It includes all data used for clinical staging, data from surgical exploration and resection, and results of pathological examination (gross and microscopic) of the primary carcinoma, regional lymph nodes and metastatic sites. The T, N, and M components are used with the “p” prefix to denote pathologic staging (e.g., pT, pN)
* '''Post-neoadjuvant (y)''' refers to staging done after the patient has completed therapy such as chemotherapy, radiation, or hormone therapy. The T and N  components are prefixed with “y” denote post-treatment staging without or with surgery (e.g., ycT or ypT).

Conceptually the staging data structure might look something like this:
<pre>
StageGroup [1..1]: either 0, IA, IB, IIA, IIB, IIIA, IIIB, IIIC, or IV
StageTiming: either clinical (c), pathologic (post-surgical) (p), post-neoadjuvant clinical (yc), or post-neoadjuvant pathologic(yp)
T [1..1]: either TX, Tis (DCIS), Tis (Paget), T1, T1mi, T1a, T1b, T1c, T2, T3, T4, T4a, T4b, T4c, or T4d
N* [1..1]: either cNX, cN0, cN1, cN2, cN2a, cN2b, cN3, cN3a, cN3b, cN3c (for clinical staging) 
or pNX, pN0, pN1, pN1mi, pN1a, pn1b, pN1c, pN2, pN2a, pN2b, pN3 (for pathologic staging)
M [1..1]: either M0 or M1
*For post-neoadjuvant staging, the N categories are preceded by “y” (e.g. ycNX, ypN1)
</pre>

===Estrogen receptor (ER) status===
Estrogen receptor alpha is the predominant estrogen receptor expressed in breast tissue and is overexpressed in around 50% of breast carcinomas. The determination of ER status depends on several observations:
*Nuclear positivity: the percentage of cells that test (stain) positive
*Average staining intensity
*Primary antibody reacting with the ER receptor

A data structure for ER status conceptually could look like this:
<pre>
EstrogenReceptorStatus [1..1]: either positive, indeterminate, or negative
NuclearPositivity [0..1]: percentage
AverageStainingIntensity [0..1]: either None/Negative (0), Weak (1), Moderate (2), or Strong (3)
PrimaryAntibody [0..1]: either SP1, 6F11, or 1D5
</pre>

===Progesterone receptor (PR) status===
Progesterone receptor (PR) is expressed in 65% of breast carcinomas. Oncologists use PR status and related details to inform their treatment decision. The determination of PR status depends on several observations:
*Nuclear positivity: the percentage of cells that test (stain) positive
*Average staining intensity
*Primary antibody reacting with the PR receptor

Conceptually, a data structure for PR status could look like this:
<pre>
ProgesteroneReceptorStatus [1..1]: either positive, indeterminate, or negative
NuclearPositivity [0..1]: percentage
AverageStainingIntensity [0..1]: either None/Negative (0), Weak (1), Moderate (2), or Strong (3)
PrimaryAntibody [0..1]: either IE2, 636, 16, SP2, 1A6, 1294, or 312)
</pre>

===Human epidermal growth factor 2 (HER2) status===
Human epidermal growth factor receptor 2 (HER2) status can impact the prognosis of breast cancer patients. The determination of HER2 status can be achieved through immunohistochemistry (IHC) or ''in situ'' hybridization (ISH). Each method results in a different set of observations used to determine HER2 receptor status:
* HER2 by IHC:
** Score: 0, 1+, 2+, or 3+. A score of 0 or 1+ translates to a negative HER2 status; a score of 2+ is considered equivocal, and a score of 3+ is considered positive;
** Percentage of cells with complete staining: 0-100%;
* HER2 by single-probe ISH:
** Average number of HER2 signals per cell
* HER2 by dual-probe ISH:
** Average number of HER2 signals per cell
** Average number of CEP17 signals per cell
** HER2/CEP17 ratio: ratio of HER2 signals per cell over CEP17 signals per cell

A data structure for HER2 status conceptually could look like:

<pre>
HER2ReceptorStatus [1..1]: either positive, negative, equivocal, or indeterminate
Method [0..1]: either ICH, ISH single probe, or ISH dual probe
HER2byIHC [0..1]:
    Score [1..1]: either 0, 1+, 2+, or 3+
    CompleteStaining [0..1]: percentage
HER2byISH [0..1]:
    AverageHER2SignalsPerCell [1..1]: decimal
    AverageCEP17SignalsPerCell [0..1]: decimal
    HER2CEP17Ratio [0..1]: decimal
</pre>

===Tumor Grade===
All invasive breast carcinomas should be assigned a histologic grade. The College of American Pathologists (CAP) stipulates the Nottingham combined histologic grade should be used. The grade is determined by assessing morphologic features (tubule formation, nuclear pleomorphism, and mitotic count), and assigning a score of 1 to 3 to each feature. The combined score of the three categories is then divided into categories to produce the overall histologic grade. 

Possible data structure for histologic grade:
<pre>
HistologicGrade: either grade cannot be assessed (GX), low combined histologic grade (G1), intermediate combined histologic grade (G2), or high combined histologic grade (G3)
TubuleFormation [0..1]: either 1, 2, or 3
NuclearPleomorphism [0..1]: either 1, 2, or 3
MitoticCount [0..1]: either 1, 2, or 3
</pre>

==Roles==

===Profile Creator===
The Profile Creator will come to the Connectathon with an unstructrued (e.g. non-FHIR) analysis model of a particular medical domain (cardiology, cancer, radiology, etc.) developed by or in conjunction with a domain subject matter expert. They will also arrive at the Connectathon with (paper or FHIR) patients that exercise the model.

During the Connectathon, the Profile Creator will translate these paper models into the modeling language, whether the creator is using SHR or otherwise, from which FHIR profiles can be generated.

The Profile Creator will then upload these profiles to a FHIR server, either a publicly-available one controlled by the Creator, or one of the ones listed on [[FHIR_Connectathon_17#Test_servers | the Connectathon page]]

====Profiling domain complexity====
In order to make it easier for newcomers to profiling/modeling to join this track, there will be 3 different levels of domain complexity within the area of breast cancer.

* '''Easy''': Cancer Staging
** Cancer staging assigns a grade to a tumor based on size, location, and metastasis status
* '''Harder''': Cancer progression
** Modeling the progression of cancer through diagnosis and treatment, including side-effects like chemotherapy toxicity
* '''Bonus''': Additional modeling, such as:
** Patient genetics
** Tumor receptor status
** Pathology

====Resources for Profile Creators====
* https://lightmyfhir.org/2017/09/10/fhir-profiling-made-easy/
* https://github.com/standardhealth/shr_spec
* http://standardhealthrecord.org/

===Profile Server===
The Profile Server is the actual FHIR server that accepts the FHIR profiles. The Profile Creator will then generate and upload FHIR patients that conform to the generated FHIR Profiles to the Profile Server.

http://clinfhir.com/ is an option for building patients to upload to the Profile Server, as it allows for building linked resources that conform to profiles.

===Patient Endpoint (optional)===
The Patient Endpoint is a FHIR client that requests the FHIR patients from the Profile Server, and validates their adherence to the FHIR profiles generated by the Profile Creator. This may be done in a manual or automated fashion.

==Scenarios==
<!-- What will be the actions performed by participants? -->

===Develop Clinical Domain Model===
:Action: Profile Creator creates a logical representation (SHR or otherwise) of their clinical model
:Precondition: Profile creator must have developed an unstructured clinical model prior to the connectathon
:Success Criteria: tooling successfully processes clinical model into FHIR profiles
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->

===Upload model to FHIR server===
:Action: Profile Creator uploads FHIR profiles to a FHIR server
:Precondition: Profile creator must have developed the logical model and generated FHIR profiles from it
:Success Criteria: FHIR profiles successfully upload to the server
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->

===Create Resources conforming to the Domain Model in FHIR Server===
:Action: Profile Creator builds patients/other FHIR resources that exercise the domain model being built
:Precondition: Profile creator should have example patients to build from/clinical knowledge to build resources
:Success Criteria: Patients and associated resources are successfully uploaded to the FHIR server
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->

===Validate Domain Model Resources against FHIR Profiles===
:Action: Profile Server or Patient Endpoint request and validate the Domain Model resources against FHIR profiles
:Precondition: 
:Success Criteria: Patient Endpoint or Profile Server successfully validate valid resources (and reject invalid resources)
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->