Follow-Up from 5/5 ELR WG Call: Seeking Feedback for Development of a National ELR Flat File

Question 1:
My choice is Option 2.  This would be the simpler for the sender to create and the simpler for the recipient to parse.

Question 2:
My choice is neither exactly option 1 nor exactly option 2.
All of the fields that the HL7 IG defines as Usage R or RE should have a counterpart in the CSV, with Usage rules equivalent to the IG. There should be an optional field for SSN. For the fields other than EPI questions that defines the set of elements; no need to define a set of "common data elements all members agree on" or a superset.
I have no objection to including the EPI questions those so long as that does not cause any delay in finalizing the CSV spec.  The EPI questions should all be optional.  As far as I am concerned a superset of those is fine so long as there aren't so many that it would cause confusion/delay for the senders to develop their CSV exports.

I would like a column for patient middle name.
I suggest the column name corresponding to SPM-4 should be Specimen Type, not Specimen Source.

Walter Kemper
 ELR Coordinator, NC EDSS Project
On behalf of State of NC DHHS Division of Public Health
 Email: Walter.Kemper@dhhs.nc.gov
(919) 426-3468 (mobile) 

Q1 Option 2 - agree with Mark and Walter.

Q2 - Agree with both in the following ways.
CSV needs to be universal, focused on collection of lab report data elements first, and epi second.
Use of standard code sets in csv would be great, but I think getting the data for the universal common elements is key first. Otherwise these labs should send us HL7. So I'm with Mark more on this one.

I'm with you. I picked Option 2 for both questions.

Q1. Option 2. Agree with Mark & Walter on this. We've had some recent experience implementing a CSV template and simpler is definitely a must. Even simple can be a challenge.

Q2. Option 2. Focus on the lab result itself is most important. Additional collection of information will happen on positives anyway.

Q. 3. done.

Ideally, it would be in the best interest of all jurisdictions (really all parties involved) if AIMS could be the receiver of all of the large pharmaceutical files.  It would minimize effort nationally and provide a single point where modifications, if necessary need to be made, as opposed to replicating this work at all of the jurisdictions. 

Validation is definitely an important step before data hits the jurisdiction systems or integration engines.  Creating validation for new types of data files can be very time-consuming for key staff at the jurisdiction level and is a real problem in the midst of all of the data requests occurring related to COVID-19.

Hello, 

Thanks for all your work on this. 
Responses from TN: 
Question 1 - Option 2 is preferrable
Question 2 - I like the suggestion on the call to have two options (one with critical, core data elements and one with additional 'optional/like to have' data elements)

Critical fields: 
Test name 
Test code/LOINC 
Result (i.e., reactive, non-reactive, indeterminate, or numeric value)
Accession number
Specimen collection date
Date/time of testing
Patient first name
Patient last name
Patient date of birth
Patient sex
Patient race
Patient phone number
Patient street address
Patient street address 2
Patient city
Patient state
Patient zip
Ordering facility/client name
Ordering provider name
Ordering provider/facility street address 
Ordering provider/facility street address 2
Ordering provider/facility city
Ordering provider/facility state
Ordering provider/facility zip
Ordering provider/facilty phone number
Performing laboratory name - used for sending/reporting facility
Performing laboratory CLIA - used for sending/reporting facility

Optional: 
Specimen type
Other patient identifier (SSN, MRN, etc.)

Thanks, 

Randi