TUTORIAL #06 Theory and Practice of Outbreak Detection

1. TUTORIAL #06 Theory and Practice of Outbreak Detection AMIA Annual MeetingSaturday, November 8, 2003 8:00 - 4:30 pm

2. IV. Implementation • Architecture • Healthcare collaborative network • Data standards • CDC’s implementation guides • Break • Software • Mini panel on futuristic use case (All)

3. Prototypical Syndromic SurveillanceData Flows Continuous Daily Emergency Department Categorize Into Syndromes Daily Totals Totals Higher Than Expected? Continuous Alert Chief Complaint and Patient Demographics In HL7 messages Review Trends Historical Models Updated monthly Valid Alert? Initiate Response

4. All are Data Producing Facilities (DPFs) Surveillance Reporting Context Doctor’s Office, Emergency Room, Hospital, etc. Health Departments Chief Compliant Information Patient Encounters Order Information Test Orders Test Orders ADT Data Lab Results Lab Results Test Results Laboratory Order Information Outpatient Tests Test Orders Reference Laboratory Specimens Received Test Results

5. DPF System Upgrades • DPFs support numerous different information systems enabled with different levels of output capabilities • Architecture recognizes that DPFs do not currently have the capability of sending fully standardized transactions. Systems upgrades to provide this capability are likely to be implemented over an extended time period • DPFs are not currently funded to implement an electronic public health reporting capability • Factors affecting the ability of a DPF to upgrade or replace legacy information system include: • Vendors have left the business, or no longer support older version systems • Vendors may not have (or choose to allocate) resources • Vendor charges and hardware costs for upgrades are not budgeted in DPF • DPFs are unable/unwilling to upgrade to latest product versions (at least 20-30% of DPFs are on non-current versions)

6. IT System Diversity No Single ISV application dominates in the top 100 provider networks (ranging in size from a few hospitals to over 100 hospitals) Rip-and-replace to standardize ISV systems in provider networks will be very expensive, driving demand for cross-platform standards-based integration

7. Conceptual Architecture All are Data Producing Facilities (DPFs) RIS Pharmacy Emergency Department Chief Complaint LIS ADT Clinical Documentation Public Health Information System Collation, transformation and routing processes PH Compliant HL7 Messages Web page Data entry HIS & other systems Veterinary / Zoo Labs Reference Labs Web page Data entry

8. Code translation Code translation Code translations Architecture Detail Transformation Functions DPF Feeder Systems Functions Required to convert DPF Feeder System output to PH Compliant HL7 messages. These functions may be performed in the Public Health Department, DPF or an Intermediary Transformation Functions Public Health Information System PH compliant HL7 messages Format converter Public Health Information System Routing PH compliant HL7 messages Collation De-identification (of “non-reportable” findings) Public Health Information System PH compliant HL7 messages Text handling Filter

9. Transformation Functions • Different functions may be • on the same or different physical computers, or • in the same or separate software modules, or • performed in a different order than represented in the “detail” slide. • Functions may take place in the data producing facility, at an intermediary, or in the public health department • In most cases, these functions can be technically accomplished in any of these locations • State/local conditions, regulatory and privacy (e.g., HIPAA) requirements will be factors in determining which is chosen. • The choice of where these functions are carried out should not obscure responsibility for the data

10. Format Converter • This function is to convert the message from a proprietary or poorly compliant standard format to the public health compliant HL7 message format • Input wide diversity of message formats • HL7 2.x proprietary implementations • ASCII flat files • Database files (e.g., Access, Cache, Oracle) • Output Public Health compliant HL7 messages • Does NOT include semantic transformations • These converters are likely to be one of the more costly and maintenance-intensive of the transformation functions. • An interface engine may be able to accomplish this format conversion

11. Collation • This function will collate multiple messages or message content with database content • Combination of messages from multiple sources • Matching of patient identifiers • Message matching to integrate demographic data with clinical data • Collation and integration of data from multiple DPF systems (LIS, HIS, billing, MPI, etc.) • e.g., add demographic data from ADT data to laboratory data • Important to note that this implies storing this data since it will arrive asynchronously • Collation/integration of accession information from ordering laboratory with results from reference laboratory.

12. Text Handling • This function is to translate textual strings into the appropriate coded values. • Splitting “lumped” transactions into components (e.g., text string listing Salmonella, Shigella, and Campylobacter) • The first time a new unique text string is detected: • A human coder will determine how it is to be transformed • A database manager will incorporate that transformation rule into the function • Henceforth, any instance of that precise text string is automatically transformed to the appropriate code(s). • Transformation of titer results into standard format • e.g., 1:16, 1/16, 16:1 all translate to 16

13. Text Handling -- Negation • The example is laboratory specific, there are also non-laboratory examples such as ‘rule out diagnosis’. • Significant findings are represented as negative statements. • E.g., “No salmonella isolated” • In essence, this functions as an organism-specific culture. • This is NOT the same as “no organisms found” • The text handling function must handle negation • LOINC has defined codes for organisms, which can be used as follows: • LOINC code for organism name – e.g., Salmonella species. • Coded value “none found”

14. Code Translation • This function will translate coded fields from proprietary vocabularies to public health compliant vocabularies. • Translation of internal lab, hospital, physician’s office codes into standard codes such as LOINC for result identifiers and HL7 tables for selected fields. • Transformation of titer results into standard format • e.g., 1:16, 1/16, 16:1 all translate to 16

15. Code Translation - Tables • The Code Translation function is dependent upon translation tables that must be built and maintained. • This task can be expensive and may require expert subject knowledge. • Translation table may be built/maintained by: • Data producing facility staff person • Public health staff person • Third party specialist or intermediary • There are many tables with different levels of volatility (frequency of change) and specialty (expertise required to maintain) • Multiple Code Translation functions may be required to support the different types of translation table • Transformation table should reside at the point of responsibility for maintenance: • In the data producing facility • Public health department • Intermediary

16. Code Translation – cont. Who should maintain the Code Translation Table?

17. Filter • This function filters the messages so that only transactions appropriate for public health are processed • Check for selected orders by order code • Check for selected results by result code • Check for selected results by result value • Check for selected coded chief complaint • Must occur after Format Converter, Text Handling and Code Translation functions so that standard format and codes can be used in the filter.

18. De-identification • This function includes the removal of identifying information from the messages according to public health requirements. • Rationale for this function is that it is likely to be needed in some jurisdictions for selected data or reporting types. • De-identification would not be applied to data covered by state regulations requiring reporting in an identifiable format. • The application of de-identification would be determined by the local jurisdiction.

19. Routing • This function includes the routing of messages to the appropriate public health department • Routing based on decision rules • Which public health jurisdiction needs to get this report? • Fields required for message routing (e.g. patient zip code) must be present in the message • Major issue for • larger laboratories (e.g., Quest) • DPF close to state borders • Clinical laboratory in Memphis • Washington DC metro area

20. Function Sequencing • The sequence in which the functions are performed can vary and is impacted by several factors • Logical requirement • One function may be dependent upon the output of another function • Efficiency preference • The sequence provides a simpler, easier to maintain or less costly solution • Performing System Which system is performing the function (DPF, Intermediary or Health Department) The following slide shows a possible sequence

21. Code translation Code translation Code translations Possible Functional Sequence Transformation Functions DPF Feeder Systems Functions Required to convert DPF Feeder System output to PH Compliant HL7 messages. These functions may be performed in the Public Health Department, DPF or an Intermediary Public Health Information System De-identification (of “non-reportable” findings) PH compliant HL7 messages Format converter Public Health Information System Routing PH compliant HL7 messages Collation Public Health Information System PH compliant HL7 messages Text handling Filter Web page Data entry

22. Possible Functional Sequence

23. Code translation Code translation Code translations Kansas City Model – Intermediary DPF Feeder Systems Cerner Data Operations Format conversion (output flat file) Routing Web site for each PH Org Public Health Information System VPN De-identified info (Orders) Encrypt VPN Public Health Information System Decrypt info for notifiable results Collation Summarization Analytic Public Health Information System Text handling Filter

24. Code translation Code translation Code translations Regenstrief/Indiana Model DPF Feeder Systems Encrypted DB transfer Regenstrief Institute County Health Dept Real-time HL7 Dedicated Network/VPN Collation Format converter Routing State Department of Health Summarization Analytic Filter INPC Databases Text handling Real-time HL7

25. RODS Model DPF Feeder Systems RODS County Health Dept Real-time HL7 Summarization Analytic Alerts Collation Dedicated Network/VPN State Department of Health Text handling De-identified Info Format Converter HSRC

26. Code translation Code translation Code translations HCN Model DPF Feeder Systems Integration Broker FDA Real-time HL7 E-mail Filter VPN Routing Alerts CMS Summarization Analytic Text handling Collation CDC Real-time HL7 Format Converter De-identified Info Gateway

28. Standards • Data model • RIM • Message Standards • HL7 (chief complaint, orders, results, alerts) • X12 • NCPDP • Data Standards • Free text (NLP) • ICD-9  ICD-10 (Frontlines of Medicine) • LOINC • NDC  RxNorm • CPT-4 • SNOMED • Data sets • DEEDS • Identifiers

29. HL7 Major Structures • Message - contains segments • - Segments (like database records) - contain fields • Required or optional • May repeat • Fields - like database fields/attributes • Variable length • Required or optional • May repeat • Standard data type • All represented in ASCII strings

30. Example HL7 Segment PID PID|1||||JONES^RICHARD^ROBERT||19910607|M … Field delimiter Sub-field delimiter Patient birth date Patient Name Patient gender

31. Abnormal flag LOINC code OBX for serum Troponin-I and a CK MB OBX Observation ID Observation value Normal range Units OBX|1|NM|10839-9^TROPONIN-I^LN||5|ng/ml|0-1.3|H||H|F|19980309… Date OBX|2|NM|13969-2^CK MB-MASS^LN||24|ug/L|0-6|N||H|F|19980309 Identifies coding system as LOINC Says patient had a serum troponin value of 5 ng/mL, and a serum CK MB value of 24 ug/L.

32. Zip code Visit date and time Free-text chief complaint Sample HL7 ADT Message MSH|^~\&||xxx||RODS|200202241715||ADT^A04|2002022XXXXXXXX|P|2.3<CR> PID|||||||^020|M|||^^^^84204|||||<CR> PV1||E|||||||||||||||||98765432||||||||||||||||||||||||200202151830||<CR> DG1||||SORE THROAT,COUGH<CR> IN1||||||||||||||||||||||||||||||||||||||||||||^^^^84056<CR> <ETX>

33. Code standards - LOINC • Database of 26,000 variables (synonyms, cross mappings) • Six part formal name • LOINC code with check digit • Mapping/browsing program (RELMA) • All available at no cost for research or commercial purposes • Available on internet: http://regenstrief.org

34. Implementation Guidelines http://www.cdc.gov/phin/messaging