Central Cancer Registry Reporting Use Case
- Jamie Parker
- Becky Angeles
Table of Contents
- 1 Table of Contents
- 2 Description
- 3 Goals of the Use Case
- 4 Scope of the Use Case
- 4.1 In-Scope
- 4.2 Out-of-Scope
- 5 Use Case Actors
- 6 Central Cancer Registry Reporting Process Abstract Model
- 7 Use Case User Stories and Diagrams
- 8 Data Requirements
- 9 Policy Considerations
- 10 Technical Capabilities for Implementation of the Use Case
- 11 Appendices
Description
The purpose of the use case is to transmit cancer case information to state central cancer registries. The intent is to provide access to data not currently available, or available through non-standard and/or manual methods; it will not replace hospital registry reporting methods that are working well. The cancer use case will help assess how to address the gaps in workflow and triggers, and the ability to leverage MedMorph RA IG along with other existing HL7 FHIR® Implementation Guides to address the public health information needs.
Problem Statement
Cancer is a mandatory reportable disease; every state has public health law/regulation requiring information to be reported to a central cancer registry about all cancers diagnosed or treated within that state. Central cancer registries are population-based cancer registries that collect data on all cancer diagnosed in residents in a defined geographic area. The main sources of information include information from treatment facilities (e.g., hospitals, clinics/physician offices), diagnostic services (e.g., pathology laboratories) and vital statistics (e.g., death certificates). Central cancer registries have an emphasis on epidemiology and public health to determine patterns among various populations, monitor cancer trends over time, guide planning and evaluation of cancer control efforts, help prioritize health resource allocations and to advance clinical, epidemiologic and health services research 1. Even with reporting requirements, cancer surveillance is complex given the heterogeneous nature of the disease, numerous diagnostic and prognostic factors, and multiple medical encounters that produce data from a variety of non-harmonized data sources.
Challenges include:
Inability to identify which patient diagnoses and encounters require reporting
A lack of data in discrete fields (e.g., narrative blob text fields, PDF documents)
Issues with data flow
Delays in data availability
Managing proper timing of creating and transmitting reports
A lack of standardized systems for cancer data collection and reporting (in some cases)
These challenges make it difficult for registries to synthesize information in a timely and actionable way. Automation of cancer case registry reporting will reduce the burden of manual or other non-standardized data collection processes that currently exist.
Goals of the Use Case
The goal of this use case is to automate the capture of cancer cases and cancer treatment information not reported by other sources and provide incidence data faster for research and public health. It will leverage the Making Electronic Data More Available for Research and Public Health (MedMorph) Reference Architecture (RA) IG and other existing FHIR® infrastructure to transmit cancer case information primarily from ambulatory care practices to central cancer registries. This Use case will not replace hospital registry reporting methods which are working well. Additionally, this use case aims to identify data standards that allow for the collection and transmission of these data electronically from EHRs automatically rather than relying on labor-intensive manual processes and duplications of effort.
Scope of the Use Case
In-Scope
Collect standardized data on all types of reportable cancers diagnosed and/or treated
Define under what circumstances an EHR system must create and transmit a cancer report to the central cancer registry
Identify the data elements to be retrieved from the EHR to produce the cancer report
Use NAACCR Volume II data dictionary for standardized data collection
Include data collection along the longitudinal spectrum (Diagnosis -> Staging -> Initial Treatment -> Death)
Out-of-Scope
Validation of the EHR data
Data captured outside the EHR and communicated directly to registries
Changes to existing provider workflow or existing data entry
Policies of the clinical care setting to collect consent for data sharing
Integrating claims data into the trigger event to send a report to the cancer registries
Use Case Actors
Electronic Health Record (EHR): A system used in care delivery for patients and captures and stores data about patients and makes the information available instantly and securely to authorized users. While an EHR does contain the medical and treatment histories of patients, an EHR system is built to go beyond standard clinical data collected in a provider’s provision of care location and can be inclusive of a broader view of a patient’s care. EHRs are a vital part of health IT and can:
Contain a patient’s medical history, diagnoses, medications, treatment plans, immunization dates, allergies, radiology images, and laboratory and test results
Allow access to evidence-based tools that providers can use to make decisions about a patient’s care
Automate and streamline provider workflow
A FHIR Enabled Data Source exposes FHIR APIs for other systems to interact with the EHR and exchange data. FHIR APIs provide well-defined mechanisms to read and write data. The FHIR APIs are protected by an Authorization Server which authenticates and authorizes users or systems prior to accessing the data. The EHR in this use case is a FHIR Enabled EHR.
Health Data Exchange (HDEA) (MedMorph’s backend services app): A system that resides within the clinical care setting and performs the reporting functions to public health and/or research registries. The system uses the information supplied by the metadata repository to determine when reporting needs to be done, what data needs to be reported, how the data needs to be reported, and to whom the data should be reported. The term “Backend Service” is used to refer to the fact that the system does not require user intervention to perform reporting. The term “App” is used to indicate that it is similar to a SMART on FHIR App which can be distributed to clinical care via EHR vendor specified processes. The EHR vendor specified processes are followed to enable the Backend Services App to use the EHR's FHIR APIs to access data. The healthcare organization is the one who is responsible for choosing and maintaining the Backend Services App within the organization.
Central Cancer Registry: A data repository that receives and stores cancer case information. Data Repositories are actively managed and are used to receive data, store data, and perform analysis as appropriate. These data repositories could be operated or accessed by PHA (or their designated organizations), research organizations with appropriate authorities and policies.
Central Cancer Registry Reporting Process Abstract Model
Figure 1 below is the Abstract Model that illustrates the actors, activity, and systems involved in the Central Cancer Registry Reporting Use Case workflow.
Figure 1: Central Cancer Registry Reporting Process Abstract Model
Use Case User Stories and Diagrams
Preconditions
Preconditions describe the state of the system, from a technical perspective, that must be true before an operation, process, activity, or task can be executed. Preconditions are what need to be in place before executing the use case flow.
The preconditions for the cancer registry reporting use case include:
Use Case Trigger: A cancer diagnosis has been recorded in the EHR
EHR and central cancer registry systems support HL7 FHIR APIs
Pertinent data elements are captured discretely in the EHR
Public Health uses allowed by HIPAA and other statutory authorities have been defined and implemented
Provisioning workflows have been established. The workflow includes activities that publish the various metadata artifacts required to make EHR data available to public health and/or research. These activities include publishing value sets, trigger codes, reporting timing parameters, survey instruments, structures for reporting, etc. These artifacts are used subsequently in data collection and reporting workflows.
User Stories
User Story Cancer Diagnosis and Treatment - Reporting based on Specific Criteria
A patient visits her primary care provider (PCP) because of a lump in her breast. The provider orders a mammogram and then a biopsy that is sent to the pathology laboratory for testing. The laboratory analyzes the biopsy specimen which indicates the patient has breast cancer. The pathology report is sent to the provider who ordered the biopsy. On January 20, 2022, the provider confirms the diagnosis of breast cancer. This information is integrated into the patient’s EHR. The patient is informed of her test results. The PCP clinic’s electronic reporting system determines that the patient has been diagnosed with a cancer that meets the criteria for reporting to the central cancer registry, as defined by the national standard Cancer Reportability List. These lists and other reportability criteria are contained in the Health Data Exchange App (HDEA), MedMorph’s backend services app. The HDEA handles all the trigger events for exchanging a patient’s EHR information across systems and is notified when the encounter is closed. The HDEA creates a standard report with the required data elements and sends it to the central cancer registry in the state where the patient resides, as required by state law. On February 2, 2022, the PCP orders a further workup and clinically stages the patient’s cancer. This information is also included in the patient’s EHR. The HDEA recognizes that this initial staging information does not meet the criteria for reporting because the information has been added within six months of the initial report transmitted to the central cancer registry (i.e., the initial report was sent January 20, 2022, and the staging information was done February 2, 2022). Thus, the staging information is in the EHR, but does not yet trigger the HDEA to report or exchange this information.
The patient has surgery on February 9, 2022, and the PCP refers her to a medical oncologist in the same clinic for further treatment. The medical oncologist sends the patient to the radiation therapy department to initiate radiation therapy as part of the first course of treatment for her breast cancer. Radiation therapy is given through September 29, 2022 and is documented in the EHR as the reason for the encounter/visit. The HDEA is notified of this update by the patient’s EHR and determines that the patient was seen for treatment of a cancer that meets the criteria for reporting to the central cancer registry and is more than six months after the initial diagnosis was transmitted to the central cancer registry. Thus, the HDEA creates a standard report with the required data elements and securely sends it to the central cancer registry in the state where the patient resides, as required by state law.
After radiation was completed on September 29, 2022, the medical oncologist initiates the chemotherapy regimen on October 10, 2022, as part of the first course of treatment for her breast cancer. The chemotherapy drugs are infused, and the chemotherapy treatment is documented in the EHR as the reason for the encounter/visit. The HDEA determines that the patient was seen for treatment of a cancer that meets the criteria for reporting to the central cancer registry; however, it does not meet the criteria for transmitting to the central registry because it has been added to the EHR between 6 months and 12 months of the initial diagnosis and transmission of a cancer report.
After 12 months from the initial diagnosis and transmission of a cancer report to the central cancer registry, the HDEA generates and sends a standard report with essential data elements to the central cancer registry in the state where the patient resides. At every subsequent 12 months after the initial diagnosis and transmission of a cancer report to the central cancer registry, the HDEA generates and sends a standard report with essential data elements to the central cancer registry in the state where the patient resides, until the patient is recorded as deceased or there have been no updates to the patient’s EHR record. These timed exchanges of a patient’s EHR information are triggered by criteria set up in the HDEA and run seamlessly in the background without human intervention, which eases mandatory reporting requirements.
Cancer Diagnosis and Treatment Main Flow
The table below illustrates each actor, role, activity, input, and output of each step of the Cancer Diagnosis and Treatment user story.
Step | Actor | Role | Activity | Input(s) | Output(s) |
1 | EHR System | Notifier | Notify the HDEA that criteria have been met | Trigger code | Notification message |
2 | HDEA | Evaluator | Evaluate notification message against criteria | Notification message content | Continuation decision based on available information |
3 | HDEA | Data Extractor | Query the EHR for cancer data | Notification message | FHIR query |
4 | EHR System | Query Responder | Return cancer data | FHIR query | FHIR resources |
5 | HDEA | Decision Logic Evaluator | Evaluate if a report needs to be sent | FHIR resources | FHIR resources |
6 | HDEA | Data Receiver | Receive FHIR resources and validate FHIR bundle | FHIR resources | FHIR validated bundle |
7 | HDEA | Data Sender | Send validated FHIR bundle to Central Cancer Registry | FHIR validated bundle | FHIR validated bundle |
8 | Central Cancer Registry | Data Receiver | Receive and validate FHIR bundle | FHIR bundle | Validated FHIR bundle |
9 | Repeat Steps 1-8 for any category notification that meets the reporting criteria as needed |
| |||
Table 1: Cancer Diagnosis and Treatment Flow
Cancer Diagnosis and Treatment Activity Diagram
Figure 2 below illustrates the flow of events and information between the actors for the Cancer Diagnosis and Treatment workflow.
Figure 2: Cancer Diagnosis and Treatment Activity Diagram
Cancer Diagnosis and Treatment Sequence Diagram
Figure 3 below represents the interactions between actors in the sequential order that they occur in the Cancer Diagnosis Treatment workflow.
Alternate Flow – Reporting Every Encounter
Cancer - Reporting Every Encounter Alternate Flow
The Cancer Diagnosis and Treatment – Reporting Every Encounter user story remains the same as the Cancer Diagnosis and Treatment user story except instead of identifying a category of criteria that triggers a report, the “all reports” criteria are set.
The table below illustrates each actor, role, activity, input, and output of each step of the Alternate Cancer Diagnosis and Treatment Reporting Every Encounter user story
Step | Actor | Role | Activity | Input(s) | Output(s) |
1 | EHR System | Notifier | Notify the HDEA that criteria have been met | Trigger code | Notification message |
2 | HDEA | Evaluator | Evaluates notification message against criteria | Notification message content | Submittal decision based on available information |
3 | HDEA | Data Extractor | Query the EHR for cancer data | Notification message | FHIR query |
4 | EHR System | Query Responder | Return cancer data | FHIR query | FHIR resources |
5 | HDEA | Data Receiver | Receive and validate FHIR resources | FHIR resources | FHIR validated bundle |
6 | HDEA | Data Sender | Send validated FHIR bundle to Central Cancer Registry | FHIR validated bundle | FHIR validated bundle |
7 | Central Cancer Registry | Data Receiver | Receive and validate FHIR bundle | FHIR bundle | Validated FHIR bundle |
8 | Repeat Steps 1-7 for all reports |
| |||
Table 2: Cancer - Reporting Every Encounter Alternate Flow
Cancer - Reporting Every Encounter Activity Diagram
Figure 4 below illustrates the flow of events and information between the actors for the Cancer Diagnosis and Treatment - Reporting Every Encounter workflow.
Figure 4: Cancer - Reporting Every Encounter Activity Diagram
Cancer - Reporting Every Encounter Sequence Diagram
Figure 5 below represents the interactions between actors in the sequential order that they occur in the Cancer Diagnosis and Treatment – Reporting Every Encounter workflow.
Figure 5: Cancer - Reporting Every Encounter Sequence Diagram
Postconditions
The submitted cancer report resides in the central cancer registry.
Data Requirements
Cancer Data Elements: Note that these are pulled from NAACCR Version 21 Data Standards and Data Dictionary.
The table below illustrates the data element, definition, sample values or codes, USCDI, and USCDI element name for cancer reporting.
Click here for a detailed MS Excel version of the table below which includes mapping to US Core, USCDI, mCODE, and electronic Case Reporting (eCR).
NAACCR Data Item # | NAACCR Data Item Name | Use Case Data Element Name | Definition | USCDI V1 Data Class | USCDI V1 Data Element | US Core Profile / FHIR Resource | US Core / FHIR element | Sample Value | Sample Value Display Name | Code System OID | Code System Name | Value Set OID |
2110 | Date Case Report Exported | Date Report Generated | effectiveTime (Date Document was Generated) |
|
|
|
|
|
|
|
|
|
|
| ? | CDA Element: setId |
|
|
|
|
|
|
|
|
|
|
| Version Number | CDA Element: Version Number |
|
|
|
| 1 |
|
|
|
|
2508 | EHR Vendor Name | EHR Vendor Name | The name of the software vendor for the EHR that created the report | Provenance |
| us-core-provenance | us-core-provenance.agent:ProvenanceTransmitter.who(Device).manufacturer WHERE Provenance.agent:ProvenanceTransmitter.type=composer | Epic |
|
|
|
|
2508 | EHR Software Name | EHR Software Name | The name of the software that created the report | Provenance |
| us-core-provenance | us-core-provenance.agent:ProvenanceTransmitter.who(Device).deviceName WHERE Provenance.agent:ProvenanceTransmitter.type=composer | Beacon |
|
|
|
|
2508 | EHR Software Version | EHR Software Version | The version number of the software that created the report | Provenance |
| us-core-provenance | us-core-provenance.agent:ProvenanceTransmitter.who(Device).version WHERE Provenance.agent:ProvenanceTransmitter.type=composer | V 1.4 |
|
|
|
|
Patient Information | ||||||||||||
2330 | Name--Last | Patient Last Name | Last name of the patient. | Patient Demographics | Last Name | us-core-patient | us-core-patient.name.family | Shepherd |
|
|
|
|
2240 | Name--First | Patient First Name | First name of the patient. | Patient Demographics | First Name | us-core-patient | Patient.name.given | Meredith |
|
|
|
|
2250 | Name--Middle | Patient Middle Name | Middle name or, if middle name is unavailable, middle initial of the patient. | Patient Demographics | Middle Name | us-core-patient | Patient.name.given | Lynn |
|
|
|
|
2390 2280 | Name--Birth Surname Name--Alias | Patient Name Use | Identifies the purpose for this name | Patient Demographics | Previous Name |
|
|
|
|
|
|
|
2270 | Name--Suffix | Patient Suffix | Title that follows a patient's last name, such as a generation order or credential status (e.g., "MD," "Jr."). | Patient Demographics | Suffix | us-core-patient | Patient.name.suffix |
|
|
|
|
|
2350 2355 | Addr Current--No & Street Addr Current--Supplementl | Patient Street Address | The number and street address or the rural mailing address of the patient’s current usual residence. This can be used to generate a follow-up inquiry and must correspond to other fields in the current address. If the patient has multiple tumors, the current address should be the same. | Patient Demographics | Current Address | us-core-patient | Patient.address.line | 111 Main Street |
|
|
|
|
1810 | Addr Current--City | Patient Address City | Name of city of the patient’s current usual residence. If the patient has multiple tumors, the current city of residence should be the same for all tumors. | Patient Demographics | Current Address | us-core-patient | Patient.address.city | Seattle |
| 2.16.840.1.113883.6.245 | U.S. Board on Geographic Names (USGS - GNIS) | 2.16.840.1.114222.4.11.973 |
1820 | Addr Current--State | Patient Address State | USPS abbreviation for the state, territory, commonwealth, U.S. possession, or CanadaPost abbreviation for the Canadian province/territory of the patient’s current usual residence. If the patient has multiple tumors, the current state of residence should be the same for all tumors. | Patient Demographics | Current Address | us-core-patient | Patient.address.state | WA |
| 2.16.840.1.113883.6.92 | FIPS 5-2 (State) | 2.16.840.1.113883.3.88.12.80.1 |
1830 | Addr Current—Postal Code | Patient Address Zip Code | Postal code for the address of the patient’s current usual residence. If the patient has multiple tumors, the postal codes should be the same. For U.S. residents, use either the 5-digit or the extended 9-digit ZIP code. Blanks follow the 5-digit code. For Canadian residents, use the 6-character alphanumeric postal code. Blanks follow the 6-character code. When available, enter postal code for other countries. | Patient Demographics | Current Address | us-core-patient | Patient.address.postalCode | 98101 |
| 2.16.840.1.113883.6.231 | USPostalCodes | 2.16.840.1.113883.3.88.12.80.2 |
1832 | Addr Current--Country | Patient Address Country | Country code for the address of patient’s current usual residence. If the patient has multiple tumors, the current country of residence should be the same for all tumors. | Patient Demographics | Current Address | us-core-patient |
Patient.address.country | US |
| 2.16.840.1.113883.3.88.12.80.63 | Country | 2.16.840.1.113883.3.88.12.80.63 |
| Note: Doesn't map directly, but very important in determining current address vs. address at diagnosis | Patient Address Start Date | Address start date | Patient Demographics | Current Address or Previous Address? | us-core-patient | Patient.address.period | June 23, 2005 |
|
|
|
|
| Note: Doesn't map directly, but very important in determining current address vs. address at diagnosis | Patient Address End Date | address end date | Patient Demographics | Current Address or Previous Address? | us-core-patient | Patient.address.period | nullFlavor="NA" |
|
|
|
|
2360 | Telephone | Patient Phone Number | Current telephone number with area code for the patient. Number is entered without dashes. Includes codes (in addition to valid telephone number). | Patient Demographics | Phone Number | us-core-patient | Patient.telecom.value | (206)555-1313 |
|
|
|
|
220 | Sex | Patient Gender | Administrative Gender - the gender that the patient is considered to have for administration and record keeping purposes. |
|
| us-core-patient | Patient.gender | F | Female | 2.16.840.1.113883.5.1 | AdministrativeGender | 2.16.840.1.113883.1.11.1 |
240 | Date of Birth | Patient date of birth | Date of birth of the patient. | Patient Demographics | Date of Birth | us-core-patient | Patient.birthDate | February 20, 1960 |
|
|
|
|
2300 | Medical Record Number | Patient medical record number | Records medical record number used by the facility to identify the patient. |
|
| us-core-patient | Patient.identifier.value | 979746186 |
|
|
|
|
| Patient identifier type | Patient Identifier System | Establishes the namespace for the value - that is, a URL that describes a set values that are unique. |
|
| us-core-patient | Patient.identifier.system | MR |
|
|
|
|
2320 | Social Security Number | Patient Social Security Number | Records patient’s social security number. The number is entered without dashes and without any letter suffix. This is not always identical to the Medicare claim number. |
|
| us-core-patient | Patient.identifier.value | 333-44-5555 |
|
|
|
|
| Patient identifier type | Patient Identifier System | Establishes the namespace for the value - that is, a URL that describes a set values that are unique. |
|
| us-core-patient | Patient.identifier.system=http://hl7.org/fhir/sid/us-ssn |
|
|
|
|
|
2315 | Medicare Beneficiary Identifier | Patient Medicare Beneficiary number | Congress passed the Medicare Access and CHIP Reauthorization ACT to remove Social Security Number (SSN) from Medicare ID card and replace the existing Medicare Health Insurance Claim Numbers with a Medicare Beneficiary Identifier (MBI). The MBI will be a randomly generated identifier that will not include a SSN or any personal identifiable information. |
|
| us-core-patient | Patient.identifier.value |
|
|
|
|
|
| Patient identifier type | Patient Identifier System | Establishes the namespace for the value - that is, a URL that describes a set values that are unique. |
|
| us-core-patient | Patient.identifier.system=http://hl7.org/fhir/sid/us-mbi | SB |
|
|
|
|
160 | Race 1 | Patient first reported race | A person's self-identification with one or more social groups. | Patient Demographics | Race | us-core-patient | Patient.us-core-race.extension:ombCategory AND/OR Patient.us-core-race.extension:detailed | 2054-5 | Black or African American | 2.16.840.1.113883.6.238 | Race & Ethnicity - CDC | 2.16.840.1.113883.1.11.14914 |
190 | Spanish/Hispanic Origin | Patient Ethnicity | A person of Cuban, Mexican, Puerto Rican, South or Central American, or other Spanish culture or origin regardless of race | Patient Demographics | Ethnicity | us-core-patient | Patient.us-core-ethnicity.extension:ombCategory AND/OR Patient.us-core-ethnicity.extension:detailed | 2186-5 | Not Hispanic or Latino | 2.16.840.1.113883.6.238 | Race & Ethnicity - CDC | 2.16.840.1.114222.4.11.837 |
252 | Birthplace--State | Patient State of Birth | USPS abbreviation for the state, territory or U.S. possession. |
|
| Patient | FHIR Extension: birthPlace.address.state | PA |
| 2.16.840.1.113883.6.92 | FIPS 5-2 (State) | 2.16.840.1.113883.3.88.12.80.1 |
254 | Birthplace--Country | Patient Country of Birth | The country in which the patient was born. |
|
| Patient | FHIR Extension: birthPlace.address.country | US |
| 2.16.840.1.113883.3.88.12.80.63 | Country | 2.16.840.1.113883.3.88.12.80.63 |
150 | Marital Status at DX | Patient Marital Status | Code for the patient’s marital status. (removed the NAACCR requirement that it's status at time of diagnosis) |
|
| us-core-patient | Patient.maritalStatus | M | Married | 2.16.840.1.113883.5.2 | MaritalStatus | 2.16.840.1.113883.1.11.12212 |
1760 | Vital Status | Vital Status | Vital status (dead or alive) of the patient as of the date entered in Date of Last Contact [1750]. If the patient has multiple tumors, vital status should be the same for all tumors. |
|
| us-core-patient | Patient.deceasedBoolean | false |
|
|
|
|
1750 | Date of Last Contact | Date of Death | Date of last contact with the patient, or date of death. If the patient has multiple tumors, Date of Last Contact should be the same for all tumors. |
|
| us-core-patient | Patient.deceasedDateTime |
|
|
|
|
|
2475 | NPI--Physician--Follow-Up | Primary Care Physician NPI | The NPI (National Provider Identifier) code for the physician currently responsible for the patient's medical care. |
|
| us-core-patient | Patient.generalPractitioner(US Core).identifier:NPI |
|
|
|
|
|
545 | NPI--Reporting Facility | Reporting Facility NPI | The NPI (National Provider Identifier) code for the facility submitting the data in the record. |
|
| us-core-patient | us-core-patient.managingOrganization(US CoreOrganization).identifier:NPI Provenance.agent.who.US Core Practitioner Profile. AND Provenance.agent.type=author or transmitter? |
|
|
|
|
|
Encounter Information | ||||||||||||
| Note: Doesn't map directly, but important for context for other elements | Encounter period | The start and end times of the encounter. |
|
| US Core Encounter Profile | Encounter.period |
|
|
|
|
|
|
| Classification of Pt, Encounter | inpatient | outpatient | ambulatory | emergency +. |
|
| US Core Encounter Profile | Encounter.class |
|
|
|
|
|
|
| Encounter subject | The patient or group present at the encounter. |
|
| US Core Encounter Profile | Encounter.subject |
|
|
|
|
|
|
| Encounter Identifier | Identifier(s) by which this encounter is known. |
|
| US Core Encounter Profile | Encounter.identifier.value |
|
|
|
|
|
|
| Encounter participant type | Role of participant in encounter. |
|
| US Core Encounter Profile | Encounter.participant.type |
|
|
|
|
|
|
| Primary participant responsible for encounter | Encounter principal performer of service. |
|
| US Core Encounter Profile | Encounter.participant.type=PPRF |
|
|
|
|
|
|
| Participant overseeing the encounter | Participant overseeing the encounter |
|
| US Core Encounter Profile | Encounter.participant.type=ATND |
|
|
|
|
|
|
| Encounter participant individual | Persons involved in the encounter other than the patient. Reference(US Core Practitioner Profile) |
|
| US Core Encounter Profile | Encounter.participant.individual |
|
|
|
|
|
|
| Encounter primary performer NPI | NPI of encounter principal performer. |
|
| US Core Encounter Profile | Encounter.participant.individual.Practitioner.identifier:NPI |
|
|
|
|
|
|
| Encounter primary performer name | Name of encounter principal performer. |
|
| US Core Encounter Profile |
|
|
|
|
| |
|
| Encounter location address | The location where the encounter takes place. |
|
| US Core Encounter Profile | Encounter.location.location.address |
|
|
|
|
|
|
| Encounter location NPI | The NPI Number for the facility where the encounter takes place |
|
|
|
|
|
|
|
|
|
630 | Primary Payer at DX | Primary payer type | The type of coverage: social program, medical plan, accident coverage (workers compensation, auto), group health or payment by an individual or organization. |
|
| US Core Encounter Profile | Encounter.account.coverage.type |
| BC Managed Care or equivalent |
|
|
|
580 | Date of First Contact | Date of Patient First Visit | Date of the patient's first visit with the reporting provider |
|
| us-core-encounter | period.start |
|
|
|
|
|
|
| Encounter Diagnosis | Enounter diagnosis. |
|
| us-core-encounter | diagnosis |
|
|
|
|
|
|
| Encounter Service Provider | The organization (facility) responsible for this encounter |
|
| us-core-encounter | serviceProvider |
|
|
|
|
|
|
| Encounter Reason Code | Coded reason the encounter takes place |
|
| us-core-encounter | reasonCode |
|
|
|
|
|
|
| Encounter Reason Reference | Reason the encounter takes place (reference) |
|
| us-core-encounter | reasonReference |
|
|
|
|
|
Provider Information | ||||||||||||
|
| Practitioner Name | The full name of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.name.text | Alex Karev, MD |
|
|
|
|
|
| Practitioner Last Name | The last name of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.name.family | Karev |
|
|
|
|
|
| Practitioner First Name | The first name of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.name.given | Alex |
|
|
|
|
|
| Practitioner Address | The address of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.address |
|
|
|
|
|
|
| Practitioner Street Address | The street address of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.address.line | 999 Ellis Way |
|
|
|
|
|
| Practitioner Address City | The city of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.address.city | Seattle |
| 2.16.840.1.113883.6.245 | U.S. Board on Geographic Names (USGS - GNIS) | 2.16.840.1.114222.4.11.973 |
|
| Practitioner Address State | the State of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.address.state | WA |
| 2.16.840.1.113883.6.92 | FIPS 5-2 (State) | 2.16.840.1.113883.3.88.12.80.1 |
|
| Practitioner Address Postal Code | The postal code of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.address.postalCode | 98101 |
| 2.16.840.1.113883.6.231 | USPostalCodes | 2.16.840.1.113883.3.88.12.80.2 |
|
| Practitioner Address Country | The country of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.address.country | US |
| 2.16.840.1.113883.3.88.12.80.63 | Country | 2.16.840.1.113883.3.88.12.80.63 |
|
| Practitioner Email Address | The email of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members | Provenance and/or Care Team Members? | us-core-practitioner | us-core-practitioner.telecom.ContactPoint.value WHERE system=email |
|
|
|
| |
|
| Practitioner Telephone Number | The telephone number of the physician playing a specific role for the patient during diagnosis and/or treatment for this cancer. | Care Team Members |
| us-core-practitioner | us-core-practitioner.telecom.ContactPoint.value WHERE system=phone | (206) 555-3921 |
|
|
|
|
|
| Provider Role | The role of the provider, which would apply to each of the individual provider types (above) | Care Team Members |
| us-ph-practitionerrole | us-ph-practitionerrole.specialty |
|
|
|
|
|
2495 | NPI--Physician 3 | Practitioner Specialty NPI | The NPI (National Provider Identifier) code for another physician (e.g., managing provider, radiation oncologist, medical oncologist) involved in the care of the patient. | Care Team Members |
| us-core-practitioner | Practitioner.identifier:NPI |
|
|
|
|
|
Primary Cancer Condition | ||||||||||||
1770 | Cancer Status | Cancer Condition Clinical Status | The clinical status of the condition. | Problems | Problems | us-core-condition | us-core-condition.clinicalStatus | active |
|
|
|
|
390 | Date of Diagnosis | Cancer (Primary) Date of Diagnosis | Date of initial diagnosis by a recognized medical practitioner | Problems | Problems | us-core-condition | us-core-condition.onsetDateTime | January 26, 2018 |
|
|
|
|
| Doesn't map to a SINGLE item | Cancer (Primary) Diagnosis Code | Code for the cancer diagnosis being reported | Problems | Problems | us-core-condition | us-core-condition.code | 408643008 | Infiltrating duct carcinoma of breast (disorder) | 2.16.840.1.113883.6.96 | SNOMED CT | Needs to be developed |
| Doesn't map to a SINGLE item | Cancer Diagnosis Code | Code for the cancer diagnosis being reported |
|
|
|
| C50.411 | Malignant neoplasm of upper-outer quadrant of right female breast | 2.16.840.1.113883.6.90 | ICD-10-CM | Have list of values in emarc; will need to publish as value set |
522 523 | Histologic Type ICD-O-3 Behavior Code ICD-O-3 | Cancer (Primary) Histology/Behavior | The histologic type and behavior (morphology) of the tumor | Problems | Problems |
|
| 8500/3 OR 8500 | Infiltrating duct carcinoma, NOS | 2.16.840.1.113883.6.43.1 | ICD-O-3 | Is there a way for us to create a VS to restrict these to only the Morphology codes? |
| Histologic Type ICD-O-3 Behavior Code ICD-O-3 | Cancer (Primary) Histology/Behavior | The histologic type and behavior (morphology) of the tumor | Problems | Problems |
|
| 82711006 | Infiltrating duct carcinoma | 2.16.840.1.113883.6.96 | SNOMED CT | 2.16.840.1.114222.4.11.7256 |
490 | Diagnostic Confirmation ICD-O-3 | Cancer (Primary) Evidence Type (Diagnostic Confirmation) | Code for the best method of diagnostic confirmation of the cancer being reported at any time in the patient’s history. | Problems | Problems |
|
| 1 | Positive histology | 2.16.840.1.113883.3.520.3.3 | NAACCR Diagnostic Confirmation | 2.16.840.1.113883.3.520.4.3 |
400 | Primary Site | Cancer (Primary) Primary Site | Code for the primary site of the tumor being reported | Problems | Problems |
|
| C50.4 | Upper-outer quadrant of breast | 2.16.840.1.113883.6.43.1 | ICD-O-3 | Is there a way for us to create a VS to restrict these to only the Topography codes? |
| Primary Site | Cancer (Primary) Primary Site |
|
|
| us-core-condition | us-core-conditionbodySite | 110496004 | Upper outer quadrant of right breast | 2.16.840.1.113883.6.96 | SNOMED CT | 2.16.840.1.113883.3.88.12.3221.8.9 |
410 | Laterality | Cancer (Primary) Laterality | The side of a paired organ, or the side of the body on which the reportable tumor originated | Problems |
|
|
| 24028007 | Right (qualifier value) | 2.16.840.1.113883.6.96 | SNOMED CT | 2.16.840.1.113883.3.520.4.22 |
Secondary Cancer Condition | ||||||||||||
|
| Cancer (Secondary) Date of Diagnosis | The date of onset of metastases |
|
|
|
|
|
|
|
|
|
|
| Cancer (Secondary) Diagnosis Code | Code for the cancer that has spread (metastasized) from the place where it first started to another part of the body |
|
|
|
|
|
|
|
|
|
|
| Cancer (Secondary) Histology/Behavior | The histologic type and behavior (morphology) of the metastatic tumor |
|
|
|
|
|
|
|
|
|
|
| Cancer (Secondary) Histology/Behavior | The histologic type and behavior (morphology) of the metastatic tumor |
|
|
|
|
|
|
|
|
|
|
| Cancer (Secondary) Primary Site | Code for the metastatic site of the tumor being reported |
|
|
|
|
|
|
|
|
|
|
| Cancer (Secondary) Primary Site | Code for the metastatic site of the tumor being reported |
|
|
|
|
|
|
|
|
|
|
| Cancer (Secondary) Laterality | The side of a paired organ, or the side of the body on which the reportable metastatic tumor originated |
|
|
|
|
|
|
|
|
|
Cancer Stage Group | ||||||||||||
|
| Cancer Stage Group Code | Indication of whether the stage group, T, N, M is clinical or pathological. |
|
|
|
|
|
|
|
|
|
| No mapping, but can be used to determine stage at diagnosis | Cancer Date TNM Clinical Stage Assigned | Date/time TNM clinical stage information was assigned | Problems |
|
|
| February 11, 2018 |
|
|
|
|
1060 | TNM Edition Number | Cancer TNM Stage Edition/Version Number | The edition of the AJCC manual used to stage the cancer | Problems |
|
|
|
|
|
|
|
|
1004 1014 | AJCC TNM Clin Stage Group AJCC TNM Path Stage Group | Cancer TNM Clinical Stage Group | Detailed site-specific codes for the clinical stage group as defined by AJCC | Problems |
|
|
| IIIA OR 3A |
| 2.16.840.1.113883.3.520.3.18 | TNM 8. Edition | 2.16.840.1.113883.3.520.4.30 |
1001 1011 | AJCC TNM Clin T AJCC TNM Path T | Cancer TNM Tumor | Detailed site-specific codes for the tumor (T) as defined by AJCC | Problems |
|
|
| cT2 or c2 |
| 2.16.840.1.113883.3.520.3.18 | TNM 8. Edition | 2.16.840.1.113883.3.520.4.32 |
1002 1012 | AJCC TNM Clin N AJCC TNM Path N | Cancer TNM Nodes | Detailed site-specific codes for the nodes (N) as defined by AJCC | Problems |
|
|
| cN2 OR c2 |
| 2.16.840.1.113883.3.520.3.18 | TNM 8. Edition | 2.16.840.1.113883.3.520.4.33 |
1003 1013 | AJCC TNM Clin M AJCC TNM Path M | Cancer TNM Clinical Metastases | Detailed site-specific codes for the metastases (M) as defined by AJCC | Problems |
|
|
| cM0 OR c0 |
| 2.16.840.1.113883.3.520.3.18 | TNM 8. Edition | 2.16.840.1.113883.3.520.4.34 |
Problems | ||||||||||||
3780, 3782, 3784, 3786, 3788, 3790, 3792, 3794, 3796, 3798 | Secondary Diagnosis 1-10 | Patient Problem Code | Records the patient’s preexisting medical conditions, factors influencing health status, and/or complications for the treatment of this cancer. | Problems | Problems | us-core-condition | us-core-condition.code | 44054006 | Diabetes mellitus type 2 | 2.16.840.1.113883.6.96 | SNOMED CT | 2.16.840.1.113883.3.88.12.3221.7.4 |
3780, 3782, 3784, 3786, 3788, 3790, 3792, 3794, 3796, 3798 | Secondary Diagnosis 1-10 | Patient Problem Code |
|
|
| us-core-condition | us-core-condition.code | E11.9 | Type 2 diabetes mellitus without complications | 2.16.840.1.113883.6.90 | ICD-10-CM |
|
|
| Problem Clinical Status | The clinical status of the condition. |
|
|
|
|
|
|
|
|
|
|
| Problem Verification Status | The verification status to support the clinical status of the condition. |
|
|
|
|
|
|
|
|
|
|
| Problem Category | A category assigned to the condition. |
|
|
|
|
|
|
|
|
|
|
| Problem Subject | Indicates the patient or group who the condition record is associated with. |
|
|
|
|
|
|
|
|
|
Lab Results | ||||||||||||
|
| Laboratory Test/Panel Code | The test (or panel of tests) that was performed relevant to the cancer diagnosis . A LOINC SHALL be used if the concept is present in LOINC. | Laboratory | Tests | us-core-observation-lab | us-core-observation-lab.code | 10480-2 | Estrogen+Progesterone receptor Ag [Presence] in Tissue by Immune stain | 2.16.840.1.113883.6.1 | LOINC | Value set to be developed to restrict to cancer-related (or can we do a "blacklist" approach--which tests are NOT wanted) |
|
| Laboratory Test Result Status | The status of the result value |
|
| us-core-observation-lab | us-core-observation-lab.status | completed |
| 2.16.840.1.113883.5.14 | ActStatus | 2.16.840.1.113883.11.20.9.39 |
|
| Laboratory Test Performed Date | Date test was performed | Laboratory |
| us-core-observation-lab | us-core-observation-lab.effective[x] | January 26, 2018 |
|
|
|
|
|
| Laboratory Result Value | The Laboratory result value. | Laboratory | Values/Results | us-core-observation-lab | us-core-observation-lab.valueQuantity.value | Positive |
| 2.16.840.1.113883.6.96 | SNOMED CT |
|
|
| Laboratory Result Units of Measure | Units of measure for the laboratory result value. | Laboratory | Values/Results | us-core-observation-lab | us-core-observation-lab.valueQuantity.unit |
|
| 2.16.840.1.113883.6.8 | UCUM | 2.16.840.1.113883.1.11.12839 |
Procedures | ||||||||||||
1290 | RX Summ--Surg Prim Site | Procedure Code | Procedure to the primary site performed as part of the first course of treatment. | Procedures | Procedures | us-core-procedure | us-core-procedure.code | 442963006 | Percutaneous needle biopsy of breast using ultrasound guidance | 2.16.840.1.113883.6.96 | SNOMED CT | Is there a value set for procedures? If not, should/can we create one? |
1290 | RX Summ--Surg Prim Site | Procedure Code |
| Procedures | Procedures | us-core-procedure | us-core-procedure.code | 19083 | Biopsy, breast, with placement of breast localization device(s) (e.g., clip, metallic pellet), when performed, and imaging of the biopsy specimen, when performed, percutaneous; first lesion, including ultrasound guidance | 2.16.840.1.113883.6.12 | CPT-4 | We can't publish a CPT value set. |
1290 | RX Summ--Surg Prim Site | Procedure Code |
| Procedures | Procedures | us-core-procedure | us-core-procedure.code | 0HBT3ZX | Excision of Right Breast, Percutaneous Approach, Diagnostic | 2.16.840.1.113883.6.4 | ICD10 PCS | See item in TFS for value set |
1200 | RX Date Surg | Procedure Performed Date | Date/time of the procedure to the primary site performed as part of the first course of treatment. | Procedures |
| us-core-procedure | us-core-procedure.performedDateTime | January 26, 2018 |
|
|
|
|
|
| Procedure Performed Facility | Facility (NPI/Name) where the procedure was performed |
|
| us-core-procedure | us-core-procedure.performer.actor.Organization.identifier |
|
|
|
|
|
|
| Procedure Reason Code | The coded reason why the procedure was performed. This may be a coded entity of some type, or may simply be present as text. |
|
| us-core-procedure | us-core-procedure.reasonReference.Condition us-core-procedure.reasonCode |
|
|
|
|
|
Radiation | ||||||||||||
1506 | Phase 1 Radiation Treatment Modality | Radiation Code | Identifies the radiation modality administered during the first phase of radiation treatment delivered as part of the first course of treatment | Procedures | Procedures | us-core-procedure | us-core-procedure.code | 77412 | Radiation treatment delivery, ≥ 1 MeV; complex | 2.16.840.1.113883.6.14 | HCPCS | 2.16.840.1.113883.3.520.4.23; but we can't publish the CPT codes in this value set. |
1506 | Phase 1 Radiation Treatment Modality | Radiation Code |
| Procedures | Procedures | us-core-procedure | us-core-procedure.code | 448385000 | Megavoltage radiation therapy using photons | 2.16.840.1.113883.6.96 | SNOMED CT | 2.16.840.1.113883.3.520.4.23 |
1506 | Phase 1 Radiation Treatment Modality | Radiation Code |
| Procedures | Procedures | us-core-procedure | us-core-procedure.code | DM011ZZ | Beam Radiation of Right Breast using Photons 1 - 10 MeV | 2.16.840.1.113883.6.4 | ICD10 PCS | 2.16.840.1.113883.3.520.4.23 |
1210 | RX Date Radiation | Radiation Administered Start Date | Date on which radiation therapy began at any facility that is part of the first course of treatment. | Procedures? |
| us-core-procedure | us-core-procedure.performedDateTime | 09/14/2018 |
|
|
|
|
|
| Radiation Reason Code | The coded reason why the procedure was performed. This may be a coded entity of some type, or may simply be present as text. |
|
| us-core-procedure | us-core-procedure.reasonReference.Condition? |
|
|
|
|
|
|
| Radiation Reason Reference | The justification of why the procedure was performed. |
|
|
|
|
|
|
|
|
|
|
| Radiation Intent | The purpose of a procedure. |
|
|
|
|
|
|
|
|
|
1531 | Radiation Treatment Discontinued Early | Radiation Termination Reason | A code explaining the unplanned or premature termination, or normal completion, of a plan of treatment, course of medication, or research study. |
|
|
|
|
|
|
|
|
|
Prescribed Medication Information | ||||||||||||
1220 | RX Date Chemo | Date medication prescribed | Date medication was prescribed | Medications |
| us-core-medicationrequest | us-core-medicationrequest.authoredOn |
|
|
|
|
|
1390 | RX Summ--Chemo | Medication prescribed code | Code (with associated name) for the medication that was prescribed | Medications | Medications | us-core-medicationrequest | us-core-medicationrequest.medicationCodeableConcept | 1720960 | 26.3 ML gemcitabine 38 MG/ML Injection | 2.16.840.1.113883.6.88 | RxNorm | 2.16.840.1.113762.1.4.1010.4 |
|
| Medication Prescribed Reason Code | The reason or the indication for ordering or not ordering the medication. |
|
| us-core-medicationrequest | us-core-medicationrequest.reasonCode AND |
|
|
|
|
|
|
| Medication Prescribed Reason Reference | Condition or observation that supports why the medication was ordered. |
|
|
|
|
|
|
|
|
|
|
| Medication Prescribed Reason Reference | Condition or observation that supports why the medication was ordered. |
|
|
|
|
|
|
|
|
|
Administered Medication Information | ||||||||||||
| RX Date Chemo | Date medication administered | A specific date/time or interval of time during which the medication administration took place. |
|
| MedicationAdministration | MedicationAdministration.effectiveDateTime |
|
|
|
|
|
| RX Summ--Chemo | Medication administered code | Identifies the code (with associated name) for the medication that was administered. |
|
| MedicationAdministration | MedicationAdministration.medication[x] |
|
|
|
|
|
|
| Medication Administered Reason Code | A code indicating why the medication was given. |
|
| MedicationAdministration | MedicationAdministration.reasonCode |
|
|
|
|
|
|
| Medication Administered Reason Reference | Condition or observation that supports why the medication was administered. |
|
| MedicationAdministration | MedicationAdministration.reasonReference.Condition |
|
|
|
|
|
|
| Medication Administered Reason Reference | Condition or observation that supports why the medication was administered. |
|
|
|
|
|
|
|
|
|
Employment History | ||||||||||||
272 | Census Ind Code 2010 CDC | Patient Industry Code | Code for the patient's usual industry, using U.S. Census Bureau codes and NIOSH non-paid worker codes |
|
| odh-UsualWork | coding:industryONETSOCDetailODH | 6570 | Motion pictures and video industries | 2.16.840.1.114222.4.5.315 | Industry CDC Census 2010 Industry NAICS Detail (ODH) | 2.16.840.1.114222.4.11.7187 |
|
| Patient Occupation Period | Date patient's occupation code was recorded |
|
| odh-UsualWork | component:odh-UsualOccupationDuration.valueQuantity | April 1985-present |
|
|
|
|
282 | Census Occ Code 2010 CDC | Patient Occupation Code | Code for the patient's usual occupation, using U.S. Census Bureau codes and NIOSH non-paid worker codes |
|
| odh-UsualWork | coding:occupationONETSOCDetailODH | 2700 | Actors | 2.16.840.1.114222.4.5.314 | Occupation CDC Census 2010 Occupation ONETSOC Detail (ODH) | 2.16.840.1.114222.4.11.7186 |
Smoking Status | ||||||||||||
|
| Patient Smoking Status | Current smoking status | Smoking Status | Smoking Status | US Core Smoking Status Observation Profile | Observation.valueCodeableConcept.code | 8517006 | Former smoker | 2.16.840.1.113883.6.96 | SNOMED CT | 2.16.840.1.113883.11.20.9.38 |
|
| Patient Smoking Status Date | Date patient's smoking status was recorded |
|
| US Core Smoking Status Observation Profile | Observation.effective[x] | <date of the encounter> |
|
|
|
|
Vital Signs | ||||||||||||
|
| Patient Height Code | Patient Height code | Vital Signs | Body height | us-core-body-height | us-core-body-height.code.coding.code | 8302-2 | Height | 2.16.840.1.113883.6.1 | LOINC | 2.16.840.1.113883.3.88.12.80.62 |
|
| Patient Height Recorded Date | Date patient's height was recorded |
|
| us-core-body-height | us-core-body-height.effectiveDateTime | <date of the encounter> |
|
|
|
|
|
| Patient Height Value | Patient Height value | Vital Signs | Body height | us-core-body-height | us-core-body-height.valueQuantity.value | 162.5 |
|
|
|
|
|
| Patient Height Units | Patient Height units | Vital Signs | Body height | us-core-body-height | us-core-body-height.valueQuantity.unit | cm |
| 2.16.840.1.113883.6.8 | UCUM | 2.16.840.1.113883.1.11.12839 |
|
| Patient Weight Code | Patient Weight code | Vital Signs | Body weight | us-core-body-weight | us-core-body-weight.code.coding.code | 3141-9 or 29463-7 | Weight Measured or Weight | 2.16.840.1.113883.6.1 | LOINC | 2.16.840.1.113883.3.88.12.80.62 |
|
| Patient Weight Recorded Date | Date patient's weight was recorded |
|
| us-core-body-weight | us-core-body-weight.effectiveDateTime | <date of the encounter> |
|
|
|
|
|
| Patient Weight Value | Patient Weight value | Vital Signs | Body weight | us-core-body-weight | us-core-body-weight.valueQuantity.value | 72.5 |
|
|
|
|
|
| Patient Weight Units | Patient Weight units | Vital Signs | Body weight | us-core-body-weight | us-core-body-weight.valueQuantity.unit | kg |
| 2.16.840.1.113883.6.8 | UCUM | 2.16.840.1.113883.1.11.12839 |
Clinical Notes/Text Fields | ||||||||||||
| TBD | Progress Note Content | A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety. | Clinical Notes | Progress Note | us-core-documentreference | us-core-documentreference.text |
|
|
|
|
|
Table 3: Cancer Reporting Data Elements
Policy Considerations
Policy considerations for the use case to be implemented in the real-world include:
MedMorph will use existing frameworks (e.g., FHIR APIs) for the exchange of data.
When there is a third party, a data use or business use/associate agreement may be needed (e.g., Association of Public Health Laboratories (APHL)).
Public Health Agencies (PHAs) may have state-specific restrictions on collecting protected classes of data (e.g., AIDS status, mental health status, Substance Use Disorder/Opioid Use Disorder (SUD/OUD)).
If the patient gives consent for sharing of AIDs, mental health, etc. data the burden would be on the sending system.
For research use cases, there must be consent before the data is sent.
For jurisdictional restrictions on data that can not be collected, the MedMorph Reference Architecture will make provisions for defining actions (e.g., redaction, filtering, removal, validation) before submission. The actions could be triggered based on the content of specific data elements.
The MedMorph Reference Architecture will do an additional validation check on the data before the data leaves the healthcare organization. This is important in cases of a healthcare organization reporting to multiple jurisdictions.
What if more data is sent that what is requested?
Registries may have restrictions on collecting certain information. For example, cancer registries collect comorbidity information, but some of them are restricted from collecting information about AIDS or mental health conditions as a comorbidity
This should be handled by policy and processes around the data received.
The data generator should be clear on what data is being requested and the data provided should only be the data requested.
The Reference Architecture IG will ask for feedback during the ballot process on if the MedMorph Reference Architecture should define an acknowledgment mechanism for notifications when additional data is received.
Technical Capabilities for Implementation of the Use Case
For the use case to be implemented successfully, the following technical capabilities must be considered:
EHRs and or tracking systems must be onboarded
The use, IT/data governance, and or versioning of FHIR between trading entities
Consent models for data exchange:
For public health purposes, existing authorities are sufficient, and no consent is required.
For research use cases:
Institutional Review Boards (IRB) approvals, intended purpose, and consent for the intended purpose is included
Other areas to investigate:
https://www.hl7.org/fhir/consent.html (e.g., FHIR ResearchSubject and ResearchStudy resources and their relationship to the Consent resource)
Patient-level data, Limited Data Set (LDS), Deidentified data sets, and relationships to consent
Data that is stored outside the EHR (e.g., Prescription Drug Monitoring Program (PDMP) data) may not be available
Activities that are not associated with a clinical order or clinical visit (e.g., drive-up COVID test, STD test, adult immunization at the pharmacy) may not be available
The reference architecture defines trigger events and timing offsets in relationship to trigger events, and actions to be performed based on trigger events to account for data lag vs. real-time (especially for research use cases)
Provenance should be supported as defined by USCDI and applied to all data classes being reported
State laws and standards can preempt/modify/exclude data that could occur in a content (use case) specific IG
Appendices
Related Use Cases and Links
North American Association of Central Cancer Registries (NAACCR): https://www.naaccr.org/
NAACCR Data Standards and Data Dictionary: https://www.naaccr.org/data-standards-data-dictionary/
References to Appropriate Documentation
Terms and Definitions
Central Cancer Registry[3]: an information system designed for the collection, storage, and management of data on persons with cancer. Registries play a critical role in cancer surveillance, which tells us where we are in the efforts to reduce the cancer burden. Surveillance data may also serve as a foundation for cancer research and are used to plan and evaluate cancer prevention and control interventions.
Electronic Health Record (EHR)[4]: a real-time, patient-centered record that makes information available instantly and securely to authorized users. While an EHR contains the medical and treatment histories of patients, an EHR system is built to go beyond standard clinical data collected in a provider’s provision of care location and can be inclusive of a broader view of a patient’s care. EHRs are a vital part of health IT and can:
Contain a patient’s medical history, diagnoses, medications, treatment plans, immunization dates, allergies, radiology images, and laboratory and test results
Allow access to evidence-based tools that providers can use to make decisions about a patient’s care
Automate and streamline provider workflow
Use Case: Document used to capture user (actor) point of view while describing functional requirements of the system. They describe the step by step process a user goes through to complete that goal using a software system. A Use Case is a description of the ways an end-user wants to "use" a system. Use Cases capture ways the user and system can interact that result in the user achieving the goal. (adapted from https://www.visual-paradigm.com/)
User Story: A User Story is a note that captures what a user does or needs to do as part of his/her work. Each User Story consists of a short description written from user's point of view, with natural language. (adapted from https://www.visual-paradigm.com/)
[1] Menck, H., Gress, D. and Griffin, A., 2011. Cancer Registry Management Principles and Practices for Hospitals and Central Registries. 3rd ed. Dubuque, IA: Kendall Hunt. ISBN: 978-0-7575-6900-5
[2] Adapted from https://www.healthit.gov/faq/what-electronic-health-record-ehr
[3] Adapted from: What is a Cancer Registry?
[4] Adapted from: https://www.healthit.gov/faq/what-electronic-health-record-ehr