Support & FAQs
Production Support: BioSense Platform Service Desk
Sites may submit support requests to the BioSense Platform Service Desk when transitioning from one phase of the onboarding cycle to the next, as well as when questions arise or support is needed.
The BioSense Platform Service Desk provides a central repository for all support requests, including management of facilities, technical problems related to message transmission, and ad hoc requests such as accessing the BioSense Platform.
Once a site enters the Operate Phase, a primary point of contact should register for access to the BioSense Platform Service Desk. To register, go to http://support.syndromicsurveillance.org.
Once registered, sites will be able to submit support requests, monitor progress on open requests, and review closed requests. Additional training on using the BioSense Platform Service Desk is available at https://vimeo.com/118708825.
Frequently Requested Asked Questions
This section provides answers to questions commonly asked during BioSense Platform onboarding. While not exhaustive, these Frequently Asked Questions (FAQs) are a starting point for sites before submitting a support request. The FAQs are categorized by topic:
- PHIN Messaging Guide for Syndromic Surveillance
- Differences in Site and PHIN Requirements
- Content Guidance and HL7 Specifications for Key Data Elements
- Message Transport, Frequency, and Acknowledgements
PHIN Messaging Guide for Syndromic Surveillance
What is the relationship between the Final Recommendation: The Core Processes & EHR Requirements of Public Health Syndromic Surveillance (PHSS) document released by the ISDS and the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings released by CDC?
The purpose of the International Society for Disease Surveillance (ISDS) document is "…to define the core of public health syndromic surveillance practice and the electronic health record (EHR) data requirements widely needed to support the core." CDC’s PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings provides technical specifications and implementation guidance to support the exchange of core syndromic surveillance data from healthcare to public health in accordance with the ISDS document.
Should a data type section be added to the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings?
The guide includes a section that shows what data types are supported. Some complex data types are expanded in various sections of the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings. For information about these data types, please see HL7 standards, Version 2.5.1, Chapter 2A.
What data sources are supported by the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings?
The guide supports emergency department, urgent care, inpatient and ambulatory care data sources. As eligible health professionals and hospitals adopt, implement, and upgrade their electronic health records (EHR) systems through the Centers for Medicare and Medicaid Services (CMS) EHR incentive programs (Meaningful Use programs), public health agencies have the opportunity to routinely receive health data from settings other than emergency departments and urgent care centers. Given the factors and complex relationships that affect EHR data quality, a collaborative approach that includes public health, healthcare, and EHR technology developers is the best way to determine how EHR data can be meaningfully used for surveillance. When considering ambulatory care, extreme caution should be taken. It is wise to start with the limited number of large practices and get experience with the different characteristics and volume of data.
Is ADT the correct message type for PHIN Messaging Guide for Syndromic Surveillance, or is Observation Result/Patient Referral Message (ORU/REF) being considered?
The business processes defined by the ISDS workgroup are based on point-to-point data exchange of Admit Discharge Transfer (ADT) messages between healthcare facilities and public health departments. Therefore, ADT is the correct message type based on the use case for addressing the core data elements. Applicability of candidate HL7 messages in other data exchange scenarios has yet to be determined and may vary by public health site and data exchange partner.
The decision to use ADT message constructs instead of the ORU message construct was reviewed and approved by ISDS, the Public Health Data Standards Consortium (PHDSC), and other CDC partners. Compared to ORU structure, the ADT structure provides more flexibility for message exchange by health information systems that capture data from emergency department (ED) and urgent care (UC) patient visits before sending those data to a public health authority. Although Health Information Systems (HIS) transmit ADT messages as part of normal operation and configuration, these HIS generally lack the ability to transmit observation-related data through ORU messages. HIS typically receive such messages.
Should important but optional measures such as laboratory orders and results be added to the PHIN Messaging Guide for Syndromic Surveillance?
Laboratory orders and results are discussed in the guide’s Extended Data Elements section, Table 4.2.2, data element 37, Laboratory Results data set.
For laboratory results, system users can reference the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm), available on the HL7 website. The guide can be found on the HL7 website by accessing https://www.hl7.org/store/index.cfm.
How will the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings be updated in the future?
CDC will issue new versions of this guide as necessary to modify the syndromic surveillance business standards and data requirements. CDC will collaborate with the International Society for Disease Surveillance (ISDS) and the community by adding its input along with public comments, feedback from state and local public health agencies and vendors, and input from public health partner organizations.
Differences in Site and PHIN Requirements
My state requires triage notes for each patient visit and a clinical impression of the diagnosis for syndromic surveillance. However, the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings states that triage notes and clinical impression data elements are optional. Can my site require that these data elements be added?Sites may require specific data elements. And when necessary, sites may add data elements, modify data element usage, or constrain message elements to support specific local requirements, laws, and regulations.
If the public health site is authorized to collect the medical record number, should it be a required field?
PID-3, Patient Identifier List, which populates medical record number, is required in the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings. System users should check with their local site administrator to determine if receiving the medical record number in this field is necessary.
Note: The Patient ID (PID) sent to the receiver should not be the facility medical record number. Instead, the PID should be unique for locating the original medical record number.
Is PID-7, Date of Birth, month, and year required? How should it be handled if the patient age (or age unit) cannot be obtained for the OBX segment since both are required?
PID-7, Date of Birth, is an optional field in HL7 and the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings. The data type is TS (YYYYMMDD), which allows a minimum population of just the year (YYYY).
Sites may require a level of specificity beyond populating the year. On the other hand, Age and Age Units are both required (Usage = R) and sent in the OBX segment. The value of "Unknown" has been added to the value set to allow for instances where the patient age unit may not be obtained. The Age field sent in (OBX-5) can contain zero (0), whereas the Age Unit field (OBX-6) can be populated with the value of "Unknown." However, Age is a critical element to epidemiology and syndromic surveillance. Every effort should be made to populate appropriate age and age units, or if that is not possible and it is locally allowable, then reporting the DOB is acceptable.
Content Guidance and HL7 Specifications for Key Data Elements
What is the preferred way to send a chief complaint?
Where possible, send a Chief Complaint in an OBX segment, and populate the Observation Value as free text, expressed in a patient’s own words. Coded values are secondary and only sought in addition to free text or if free text is unavailable. By using the "coded with exceptions (CWE)," you allow for the possibility of coding systems and free text. If these data flow through an intermediary or third party, the intermediary or third party must keep the original text (CWE-9) of the transmission. Implementers should check with their local site administrator for their version of an adopted coding system.
Note: If an electronic health record (EHR) system provides only drop-down choices for chief complaint values and does not allow free text, it is important to concatenate the text of the selected drop-down choices into one text field. If the vendor is open to comment, please express your disappointment at the loss of the patient’s words and advocate to input the information into their system.
Admit Reason may be used for patients admitted to the hospital in an ED setting. Is this different from Chief Complaint?
Admit Reason and Chief Compliant are not always the same. Chief Complaint is expected to be the patient’s own words in free text and provides a level of granularity beyond that of Admit Reason. Admit Reason is a short description of the provider’s reason for admitting the patient. Though Admit Reason can include free text in PV2-3.2, it often uses ICD-9 (International Classification of Diseases) codes or SNOMED (Systematized Nomenclature of Medicine) codes, whereas Chief Complaint, located in an OBX, often uses free text. For this reason, whenever possible, capturing both is preferred.
Note: Ideally, Chief Complaint should be a rich text description in the patient’s own words relating the patient’s complaint upon arrival. Coded values for Chief Complaint are far less useful.
If a sender does not have a value for a data element with a usage type of "RE" and the data element is sent in an OBX segment, is it necessary to include an OBX segment for that data element with an empty OBX-5 field?
"RE" indicates a field that is required but may remain empty when the initial message is generated. Although omitting an empty OBX segment with an empty OBX-5 field is acceptable, you must send an update message including OBX segment when the information becomes available and you update the data value. "RE" is NOT optional.
Can multiple addresses be sent in a single message? PID-11, Patient Address, shows only one repeat, which ISDS considers the "Current address.
PID-11, Patient Address, expects to receive only the patient primary (current) address information. However, note that we do not want the full patient address—only the patient zip, county, city, and country.
The time stamp fields for PID-29, Patient Death Date and Time, and PV1-45, Discharge Date/Time, show the minimum acceptable precision to the nearest minute. Is it acceptable to send the date only?
PID-29, Patient Death Date and Time, and PV1-45, Discharge Date/Time, are not required fields—but it is desirable to be precise by sending all available data. However, sending only the date is allowed.
Can Patient Age be sent in years, or does it need to be a separate OBX for years and months, or possibly days?
As per the PHIN Messaging Guide for Syndromic Surveillance, "… for age to be de-identified, age must be rounded to an integer. For a patient’s age greater than or equal to (>=) 2 years old, report in whole years. Unit value should be Year. For patients younger than ( <) 2 years old, report age in integer months. Do not report days or weeks."
For further information, please see PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings.
How do I remove patient identification in PID-5 (Patient Name)?
To de-identify data, insert "~^^^^^^S" in PID-5, illustrating that the information is removed. However, you should send the patient ID and other low-level information that does not identify the patient.
For "MSH-4, Sending Facility," and "EVN-7, Event Facility," what values are expected?
"MSH-4, Sending Facility" is a unique identifier for the facility that sends the message. "EVN-7, Event Facility" identifies the facility where the event occurred. The message should contain both "MSH4, Sending Facility" as the sending facility and "EVN-7, Event Facility," where the patient was treated.
Note: Changes to the BioSense Platform processing that will add the functionality required to analyze data by the Event Facility ID (EVN-7) are expected to take effect in 2016.
What IDs should public health expect or request for MSH-4, Sending Facility? Do facilities use National Provider Identifiers (NPIs) or list individual physicians?
The International Society for Disease Surveillance (ISDS) recommends the use of NPIs, a unique identification number for covered healthcare providers. The use of NPIs should be discussed during the implementation process because local sites may differ on their use of identifiers for this field.
Please refer to item 1 in Minimum Data Elements table 4.2.1 for further information or to the Centers for Medicare and Medicaid Services NPI information at http://www.cms.gov/NationalProvIdentStand/.
Should race and race category be defined according to HL7 specifications?
The International Society for Disease Surveillance (ISDS) recommends consistency across meaningful use public health reporting by using the CDC value set Race Category. This is the same value set used in the HL7 Version 2.5.1: Implementation Guide for Immunization Messaging and HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health.
Message Transport, Frequency, and Acknowledgements
Can a single batch contain different types of syndromic surveillance messages?
Yes, batches may contain all admit, discharge, and transfer (ADT) message types for syndromic surveillance. Examples follow:
- ADT^A01 Admit/Visit Notification
- ADT^A04 Register a Patient
- ADT^A08 Update Patient Information
- ADT^A03 Discharge/End Visit
Are receivers required to acknowledge all syndromic surveillance messages?
The PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings specifies what the acknowledgment messages should contain, but the sender and receiver must decide whether to acknowledge a specific data exchange.
How often should I send syndromic surveillance messages?
A business rule has been added to the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings v2.0 that states data for syndromic surveillance must be timely. On page 23, this is defined as "Therefore, data must be submitted at least within 24 hours of the date and time of the patient’s initial encounter. Any subsequent updates to a patient’s record must also be submitted within 24 hours of the information (transaction) being added to the patient record. Real time data transmission, or very frequent batch data transmission, is preferred. If batch transmission mode is utilized, batches must be transmitted at least once every 6 hours."