The project will create fully modeled use cases across three distinct areas (e.g., hepatitis C virus [HCV], cancer, healthcare surveys) to inform the design of a scalable and extensible reference architecture to facilitate data exchange for both key patient-centered research questions and surveillance system requirements. This approach aims to minimize the burden on both the senders and receivers of data by providing a common method for obtaining data for research and public health for multiple conditions or uses, which will be documented in implementation guides.

Use Case Framework

The use case framework is a use case template with specific sections necessary to formalize a use case. This framework/template will be used across use cases.

Use Case Template

Past Meeting Materials

Cross-Cutting Considerations

The sections below indicate Policy and Non-Technical Considerations that are being discussed (draft) that may be common to the three use cases.

Policy Considerations (DRAFT)

The 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 Authorities (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.

Non-Technical Considerations (DRAFT)

The non-technical considerations for the use case to be implemented in the real-world include:

• Onboarding of EHRs and or tracking systems

• 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 (Look at ResearchSubject and ResearchStudy resources in FHIR and their relationship to Consent Resource)

      • Patient-level data, Limited Data Set (LDS), Deidentified data sets, and relationships to consent

      • https://www.healthit.gov/topic/leading-edge-acceleration-projects-leap-health-information-technology-health-it

• The activity network query space has not been reconciled with FHIR RESTFUL queries. How do queries on eHealth exchange, CommonWell map into authorities?

• Data that is stored outside the EHR (e.g., PDMP data, Hepatitis C wants drug use data) may not be available

• Any 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)

• Data lag vs. real-time (especially for research use cases) - the difference in time for use cases.

  • The Reference Architecture defines trigger events and timing offsets in relationship to trigger events, and actions to be performed based on trigger events.

• Data provenance (recognized authority - but how much do we trust the data from those systems outside of the EHR and the EHR ingests the data - and the detail of information and method of transmission (e.g., orally reported, substantiated with material or electronic)

  • The MedMorph Reference Architecture IG would recommend (or require in available) support for Provenance as defined by USCDI and apply to all data classes being reported.

• Registries will capture what they are required to capture by state laws and standards setters, but research use cases might want to capture complications, etc. related to cancer.

  • Acknowledgment that state laws and standards can preempt/modify/exclude data that could occur in a content (use case) specific IG.

Cancer-specific Non-Technical Considerations:

• Should we use specific histology/morphology codes, such as those used in pathology reports?

  • In the cancer specific IG, if possible, make this a SHOULD or MAY if possible. Use both SNOMED and ICD. ICD10 has a lot of cancer codes but they are not being used. NOTE: this is a change in workflow for physicians.

• Will we consider reporting guidelines (should we look at those guidelines as a non-technical consideration?), such as certain data content that should be reported under certain specific circumstances (e.g., based on cancer type, stage, treatment)?

  • There are required elements across multiple use cases that will be present in the RA IG. Use Case specific IGs will mark required elements as needed.

Parking Lot Items

Cancer

• Registries will capture what they are required to capture by state laws and standards setters, but research use cases might want to capture complications, etc. related to cancer. (this would get addressed in a research use case we can define data elements based on the use case and user story

Research and other queries that have a lag or are collecting data over a period of time:

• Duration of MedMorph query -. What is the longevity of the request? Should we have an expiration or renewal date? - (RA should support this)

Previous MedMorph Use Case Workgroups

Hepatitis C

Cancer

Healthcare Surveys

Related Use Cases