search

CDCgov / data-exchange-hl7

Enterprise Data Exchange (DEX) is a new cloud-native centralized data ingestion, validation, and observation service scoped for common data types (HL7, FHIR, CDA, XML, CSV) sent to the CDC. It helps public health stakeholders who send data to the CDC while reducing the maintenance efforts, complexity, and duplication of ingestion points to CDC.
Apache License 2.0
10 stars 14 forks source link

Lab: Confirm that the lab template can be structurally validated using the PHIN Spec 3.0-3.1-3.2 #126

Closed lmcnabb closed 1 year ago

rmharrison commented 2 years ago

Decision: A

How should ELR segments be handled?

Option A: Structurally validate with PHINSPEC

~Option B (#179): Create a pseudo-MMGAT JSON (similar to #108 #136). No dice.~

rmharrison commented 2 years ago

@lmcnabb will find lab message. So @marcia-schulman can test the PHINSPEC validation.

marcia-schulman commented 1 year ago

Hepatitis production messages were provided to us for testing, along with a spreadsheet that describes (a) which messages use the Optional Lab Template and (b) what errors we should expect to see, i.e., what errors were generated for these messages in MVPS.

Upon testing a handful of these messages in the NIST GVT tool using our profile for PHIN Spec 3.1, I have found the following:

  1. The messages do not conform to some basic rules that are in the PHIN Spec, unrelated to the Optional Lab Template. For example, every message in the set contains an OBR that begins as follows: OBR|1|\"\"| Since OBR 2 is specified as RE (Required may be empty) and SOME VALUE has been entered in OBR 2, then the NIST validator is checking for the Required components of OBR 2 and throwing errors that these Required components are not present. If OBR 2 were completely empty, then no errors would be generated for OBR 2.

  2. None of the errors in the spreadsheet are being generated by the NIST validator. This is partly because the errors in the spreadsheet are almost exclusively content errors, not structural errors. It may be possible to add some of these content-type errors to the NIST validation for those segments that are not currently validated by the MMG validator (e.g., SPM) by adding back the HL7 value sets associated with those fields (e.g., SPM-4 Specimen Type -> HL70487).

In short, the NIST Validator is validating the structure of the segments but not the content. If we wish to add some content validation for lab-related segments, we will need to add another ticket to do that exploratory work.

mscaldas2012 commented 1 year ago

I'd say let's validate those content as part of the MMG-Validation!

marcia-schulman commented 1 year ago

Information regarding what validation errors/warnings are coming from MVPS for these messages can be found in this spreadsheet.