Health Care Survey Reporting Use Case
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 Health Care Survey Process Abstract Model
- 7 Use Case User Stories and Diagrams
- 7.1 Preconditions
- 7.2 User Stories
- 7.3 Postconditions
- 7.4 Alternate Flow
- 8 Data Requirements
- 9 Policy Considerations
- 10 Non-Technical Considerations
- 11 Appendices
Description
The purpose of the Health Care Survey use case is to identify the hospital (emergency department and inpatient care) and ambulatory care data that will be extracted from EHRs and/or clinical data repositories via FHIR APIs and sent to a system hosted at the federal level. This use case will help define how EHR data can be used in automated data collection, thereby reducing burden for the healthcare provider and EHR with the goal of increasing the submission of timely, quality health care data to the National Center for Health Statistics (NCHS).
Problem Statement
The current ambulatory (manual medical record abstraction) and hospital (claims) data collection method is burdensome for providers, lacks clinical richness, and is inefficient for NCHS.
Goals of the Use Case
Increase the response rate of sampled hospitals and ambulatory health care providers to the National Hospital Care Survey (NHCS) and the National Ambulatory Medical Care Survey (NAMCS)
Increase the volume, quality, completeness, and timeliness of data submitted to the NHCS and NAMCS
Reduce the burden, including cost, associated with survey participation for hospitals, ambulatory health care providers, and data source vendors
Reduce NCHS’s costs associated with recruiting hospital and ambulatory health care providers, and the processing of NHCS and NAMCS data
Develop a complete use case that can be supported by the MedMorph Reference Architecture for the reporting of health care survey data from health care providers and systems to NCHS
Scope of the Use Case
In-Scope
Collect standardized data based on eligibility criteria from NAMCS[1] and NHCS[2] in the hospital and ambulatory care settings
Define under what circumstances a data source system must create and transmit a report to the NCHS data store
Identify the data elements to be retrieved from the data source to produce the report
Collect partial provider-level and all available patient-level data for NAMCS
Collect partial hospital/facility-level and all available patient-level data for NHCS
Out-of-Scope
Assessment of the data quality of the content extracted from the data source
Data captured outside the data source 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. (Provider participation in the National Health Care Surveys is by invitation by NCHS based on being selected as part of the nationally representative samples of providers. Consent for participation in each National Health Care Survey is obtained during the manual recruitment process.)
Adult day services centers, residential care communities, nursing homes, home health agencies, and hospice
The National Hospital Ambulatory Medical Care Survey (NHAMCS) is designed to collect data on the utilization and provision of ambulatory care services in hospital emergency and outpatient departments and ambulatory surgery locations. While this IG could be used for NHAMCS data collection, at the present time NCHS is not intending to do so
Use Case Actors
Data Source: A system (e.g., EHR, clinical data repository) used in care delivery for patients which captures and stores data about patients and makes the information available instantly and securely to authorized users. While a data source does contain the medical and treatment histories of patients, a data source 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 data source 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 data source in this use case is a FHIR Enabled EHR.
Health Data Exchange App (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 NCHS 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 the EHR specified processes. The EHR specified processes are followed to enable the Backend Services App to use the EHR's FHIR APIs to access data. The hospital or ambulatory organization is the one who is responsible for choosing and maintaining the HDEA.
National Center for Health Statistics (NCHS) Data Store: A FHIR server or service that receives and stores the health care survey data.
Health Care Survey Process Abstract Model
Figure 1 below is the high-level model that illustrates the actors, activity, and systems involved in Health Care Survey workflow.
Figure 1: Health Care Survey Abstract Model
The FHIR Enabled Data Source sends subscription notifications to the HDEA when there has been activity in topics to which the app subscribes. The HDEA then queries the Data Source for survey data and the Data Source returns the appropriate FHIR resources. The HDEA receives and validates the resources. The resources are compiled into a FHIR bundle and sent to the NCHS Data Store.
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 needs to be in place before executing the use case flow.
The preconditions for the healthcare survey reporting use case include:
Use Case Trigger: A patient encounter has happened, and the provider has signed off on the encounter
The data source, provider, and receiving systems expose HL7 FHIR APIs
Pertinent data elements are captured discretely in the data source
Public Health uses allowed by HIPAA and other statutory authorities have been defined and implemented
Provisioning workflows have been established. The provisioning workflow includes activities that publish the various metadata artifacts required to make data source 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
NCHS is authorized to collect hospital and other healthcare entities data under the authority of section 306 of the Public Health Service Act (42 United States Code 242k)
Participant has volunteered to participate in a National Health Care Survey (including data agreements if applicable)
Physician:
was sampled by NCHS and voluntarily recruited
has a partner who was sampled last year, underwent system testing and validation, and moved onto production submission of data
has already completed the provider level data collection for the survey year (however, this will not preclude confirmative and supplementary data collection of provider-level data from the FHIR Provider resource, as well as potentially other FHIR resources that can provide provider-level data during the patient-level data collection)
User Stories
User Story 1 – Ambulatory Setting
Background: The National Ambulatory Medical Care Survey (NAMCS) is based on a sample of patient visits to non-federally employed office-based physicians (primary care or specialist) who are primarily engaged in direct patient care. Starting in 2006, a separate sample of visits to community health centers (CHC) was added; in 2021, the former CHC sample of NAMCS was redesigned and launched as the health center (HC) component. NAMCS collects an encounter-based set of demographic and clinical data generally available in a medical record for any type of visit.
Workflow: Upon completion of an encounter, the physician or licensed clinician, using the EHR, completes and closes the clinical encounter (“sign off”). This “sign off” triggers the Health Data Exchange App (HDEA), MedMorph’s backend services app, to evaluate the completed encounter. The completed encounter evaluation by the HDEA includes validating that the provider associated with the encounter is a “sampled” NAMCS provider and the encounter occurred within a specified timeframe. If the encounter meets the criteria, and after a lag period to allow for lab results to post when applicable, the HDEA requests a set of FHIR resources representing patient-level and select provider-level data of the encounter from the Data Source. The obtained resources are validated (e.g., conformant to the appropriate FHIR profiles) and transmitted to NCHS where they are received, acknowledged, and loaded into the NCHS Data Store.
The table below illustrates each actor, role, activity, input, and output of each step of the Health Care Survey Ambulatory workflow.
Table 1: HCS Ambulatory Setting Workflow
Step | Actor | Role | Activity | Input(s) | Output(s) |
|---|---|---|---|---|---|
1 | Data Source | Notifier | Notify the HDEA that a trigger event has occurred | Trigger codes | Notification message (e.g., “completed encounter” event) for a topic |
2 | HDEA | Evaluator | Evaluate notification message against criteria | Notification message content | Continuation decision based on available information |
3 | HDEA | Data Extractor | Query the Data Source for provider information | Query decision | FHIR query |
4 | Data Source | Query Responder | Return provider data | FHIR query | FHIR Provider Resource |
5 | HDEA | Evaluator | Evaluate provider information, notification message | FHIR Provider Resource, Notification message | Submittal decision based on available information |
6 | HDEA | Data Extractor | Query the Data Source for survey data | Notification message, timing, and other criteria | FHIR query |
7 | Data Source | Query Responder | Return survey data | FHIR query | FHIR resources |
8 | HDEA | Data Receiver | Receive FHIR resources and validate FHIR bundle | FHIR resources | FHIR validated Bundle |
9 | HDEA | Data Sender | Send validated FHIR bundle to NCHS Data Store | FHIR validated Bundle | FHIR validated Bundle |
10 | NCHS Data Store | Data Receiver | Receive and validate FHIR bundle | FHIR bundle | Validated FHIR bundle |
User Story 1 – Ambulatory Setting Activity Diagram
Figure 2 below illustrates the flow of events and information between the actors for the Health Care Survey Ambulatory workflow.
Figure 2: HCS Ambulatory User Story Activity Diagram
User Story 1 – Ambulatory Setting Sequence Diagram
Figure 3 below represents the interactions between actors in the sequential order that they occur in the Health Care Survey Ambulatory workflow.
Figure 3: HCS Ambulatory User Story Sequence Diagram
User Story 2 – Hospital Setting
Background: The National Hospital Care Survey (NHCS) is an electronic data collection, gathering Uniform Bill (UB) 04 administrative claims data or electronic health record data from sampled hospitals. NHCS is designed to provide reliable and timely nationally representative healthcare utilization data for hospital-based settings. NHCS collects all inpatient discharges, and Emergency Department (ED) encounters from sampled hospitals for a survey period of one year. NHCS’ sample is drawn from all non-federal US hospitals with a bed size > 6.
Workflow: Upon completion of an inpatient or ED encounter, the physician or licensed clinician completes and closes the clinical encounter (“sign off”). This “sign off” triggers the HDEA to evaluate the completed encounter against the NHCS criteria. If the encounter meets the survey criteria, and after a lag period to allow for lab results to post when applicable, the HDEA requests a set of FHIR resources representing patient-level and select provider-level data of the encounter from the Data Source. Once obtained and validated, these resources are transmitted to NCHS where they are received, acknowledged, validated, and loaded into the NCHS Data Store.
The table below illustrates each actor, role, activity, input, and output of each step of the Health Care Survey Hospital Setting workflow.
Table 2: HCS Hospital Setting Workflow
Step | Actor | Role | Activity | Input(s) | Output(s) |
1 | Data Source | Notifier | Notify the HDEA that a trigger event has occurred been met | Data or workflow trigger | Notification message (e.g., “completed encounter” event as a topic) |
2 | HDEA | Evaluator | Evaluates notification message against criteria | Notification message content | Continuation decision based on available information |
3 | HDEA | Data Extractor | Query the Data Source System for survey data | Notification message, timing, and other criteria | FHIR query |
4 | Data Source | Query Responder | Return survey data | FHIR query | FHIR resources |
5 | HDEA | Data Receiver | Receive FHIR resources and validate FHIR bundle | FHIR resources | FHIR validated bundle |
6 | HDEA | Data Sender | Send validated FHIR bundle to NCHS Data Store | FHIR validated bundle | FHIR validated bundle |
7 | NCHS Data Store | Data Receiver | Receive and validate FHIR bundle | FHIR bundle | Validated FHIR bundle |
User Story 2 – Hospital Setting Activity Diagram
Figure 4 below illustrates the flow of events and information between the actors for the Health Care Survey Hospital Setting workflow.
Figure 4: HCS Hospital Setting User Story Activity Diagram
User Story 2 – Hospital Setting Sequence Diagram
Figure 5 below represents the interactions between actors in the sequential order that they occur in the Health Care Survey Hospital Setting workflow.
Figure 5: HCS Hospital Setting User Story Sequence Diagram
Postconditions
A completed survey resides in the National Center for Health Statistics Data Store.
Alternate Flow
None
Data Requirements
The table below includes the data requirements for the Health Care Survey use case based on the abstract model and use case flows.
Click here for a detailed Excel version of the data requirements that includes mock data.
Table 3. Health Care Survey Data Elements
Health Care Surveys Data Element | Definition (unless otherwise Noted, this is the FHIR Resource definition) | USCDI V1 Data Class | USCDI V1 Data Element | US Core Profile or FHIR Base Resource | FHIR Resource.element | Flag** | Setting | Value Set (when applicable) | Value Set Example(s)*** | ||
ED | IP | OP | |||||||||
Patient Information | |||||||||||
Patient given name | Given name. (Given names (not always 'first'). Includes middle names). | Patient Demographics | First Name | US Core Patient Profile | Patient.name.given | M | x | x | x | N/A | N/A |
Patient family name | The part of a name that links to the genealogy. In some cultures (e.g. Eritrea) the family name of a son is the first name of his father. | Patient Demographics | Last Name | US Core Patient Profile | Patient.name.family | M | x | x | x | N/A | N/A |
Patient previous name | NOTE: Patient's previous name. (optional) | Patient Demographics | Previous name | US Core Patient Profile | Patient.name | M | x | x | x | N/A | N/A |
Patient name suffix | Part of the name that is acquired as a title due to academic, legal, employment or nobility status, etc. and that appears at the end of the name. | Patient Demographics | Suffix | US Core Patient Profile | Patient.name.suffix | 0 | x | x | x | N/A | N/A |
Patient birth sex | Codes for assigning sex at birth as specified by the Office of the National Coordinator for Health IT (ONC) | Patient Demographics | Birth Sex | US Core Patient Profile | Patient.extension:us-core-birthsex | M | x | x | x | Unknown | |
Patient date of birth | The date of birth for the individual. | Patient Demographics | Date of Birth | US Core Patient Profile | Patient.birthDate | S | x | x | x | N/A | N/A |
Patient race | Concepts classifying the person into a named category of humans sharing common history, traits, geographical origin or nationality. The race codes used to represent these concepts are based upon the CDC Race and Ethnicity Code Set Version 1.0 which includes over 900 concepts for representing race and ethnicity of which 921 reference race. The race concepts are grouped by and pre-mapped to the 5 OMB race categories: American Indian or Alaska Native; Asian; Black or African American; Native Hawaiian or Other Pacific Islander; White. | Patient Demographics | Race | US Core Patient Profile | Patient.extension:us-core-race | S | x | x | x | https://www.hl7.org/fhir/us/core/ValueSet-omb-race-category.html ; https://www.hl7.org/fhir/us/core/ValueSet-detailed-race.html |
|
Patient ethnicity | Concepts classifying the person into a named category of humans sharing common history, traits, geographical origin or nationality. The ethnicity codes used to represent these concepts are based upon the CDC ethnicity and Ethnicity Code Set Version 1.0 which includes over 900 concepts for representing race and ethnicity of which 43 reference ethnicity. The ethnicity concepts are grouped by and pre-mapped to the 2 OMB ethnicity categories: - Hispanic or Latino - Not Hispanic or Latino. | Patient Demographics | Ethnicity | US Core Patient Profile | Patient.extension:us-core-ethnicity | S | x | x | x | https://www.hl7.org/fhir/us/core/ValueSet-omb-ethnicity-category.html ; |
|
Patient preferred language | A language which may be used to communicate with the patient about his or her health. | Patient Demographics | Preferred Language | US Core Patient Profile | Patient.communication | S | x | ||||