Talk:CDA for Healthcare Acquired Infectious Disease Reporting

How did I get here????

• • It seems that no pages link to this topic, and it isn't in any categories.
    • Are there other pages who used to link to this topic, but have been edited to link directly to the Mayo wiki?
    • Does the Mayo wiki contain all of the HAI documentation?

--KevinCoonanMD 21:24, 10 March 2011 (UTC)

---

Q+A on pilot materials

1. The question about "Post-Procedure? (Y/N)" is missing from the strawman, both as an entry and as a human-readable section.text.

CDC: This field will never be sent for BSI. It will be sent for SSI. If during the pilot the Post-procedure Yes/No value is present in a BSI CDA report, the NHSN import will ignore the value and enter No for this datum.

2. In CONF-15, I thought the LegalAuthenticator should be the Infection Control practitioner, and we should use the OID and extension supplied by CDC when they sign up for NHSN.

KH: The conformance-statements document should include the remark (from the strawman file) that legalAuthenticator may be an infection control practitioner or anyone assigned by the facility to this task. The strawman represents the legalAuthenticator id element as:

<id root="2.16.840.1.113883.3.117.1.1.5.1.1.2" extension="aLegalAuthenticatorID"/>

This has the form you note, i.e., @root + @extension. But please note that whether an organization constructs identifiers using only @root or using @root + @extension is not prescribed by CDA, and in general it would probably not be good practice to constrain organizations to using one form or another. Add to issues list

3. In CONF-16, it is not clear whether the Facility OID assigned by CDC should have an "extension" or not.

KH: General CDA guidance is to avoid routine/default use of @extension attribute, and the strawman represents the Facility ID as an OID with no @extension. An appropriate use of @extension may be the facility's local location ID (e.g., 9W) which is currently represented as location/addr/unitID but is under review. Add to issues list

4. Someone has added 2 required fields in CONF-65, which are not on the paper copy of the BSI form, and are not normally collected by Infection Control practitioners. They are the DATE and TIME of the "final reporting on an isolate." Can these requirements be loosened or removed for purposes of the pilot?

KH: These fields may be required by HL7 best practice; need to confirm. Given that the values are not available, will need an approach for the pilot. Add to issues list

5. CONF-66 ... does not really represent a question that appears on the paper copy of the BSI Form. Whether an organism is GNO, GPO or GO is directly calculable from the Pathogen code. If the CDC really wants this entry [vendors will need] a list of the gram-sensitivities...

KH: This component supports providing a visual rendering that separates the findings into GPO, GNO, and OO sections as on the BSI form. It was originally our understanding that this separation was desired, but it may not be. If not, this component can be removed from the conformance statements, strawman, and schematron rules. Add to issues list

6. We still do not have a strawman for the BSI Denominator data. Will this be available before the May 30 meeting in Atlanta?

KH: Will clarify with NHSN.

7. Rick: Perhaps represent the facility id as an extension attribute on the id element vs. just in the address.

Add to issues list.

8. ...currently the schematron rules require that at least one custom date field and one custom free text field to be included in the BSI XML file.... It seems to us that these custom fields should be optional, not required. Similarly, in the paper form, the Comments section is optional.... What if a user does not have any comments to submit?

KH: You are correct: the Custom Fields section and the Comments section should not be required. Corrected in May 30 update

9. In the paper form, if no pathogen is identified (e.g., in case of clinical sepsis), the page 2 on finding section is not required. However the schematron rules require a findings section with identified pathogen. What if no pathogen is identified as in the case of clinical sepsis?

KH: The conformance statements should state that a Findings section is required IF a pathogen has been identified. The requirement that a Findings section be present should be listed with the pilot constraints. Corrected in May 30 update

10. The schematron rules require that a discharge date is specified. What if a patient is currently still in hospital and not yet discharged?

CDC: Discharge date will not be required. Corrected in May 30 update

11. The schematron rules require a section on whether the BSI event contributes to patient death even if the patient is not dead. It seems to us that if the patient is not dead, whether BSI contributes to death is irrelevant and hence should not be a required section.

KH: The schematron rules are incorrectly stated. Corrected in May 30 update

12. If a patient has no middle name, should we omit the second <given> element completely, or should we include the element but with empty content?

KH: If no middle name, omit the second <given> element completely.

13. In the paper form, social security # is optional. For some patients in our database, we do not have their SSN. Currently the schematron rules issue a warning message if no SSN is specified. We assume that since this is only a warning message, we are OK with missing SSN data, correct?

KH: Yes, it is OK to have a warning message. Warnings result from SHOULD statements: in this case, the conformance statement states that the report SHOULD contain an SSN.

14. The bsi-num.xml file in the hai-update-v2.zip file that was sent out shortly before /the/ webinar does not have the <templateId root="2.16.840.1.113883.10.20.3/> required by CONF-3. However, the validator found no error.

KH: The conformance statements are out of sync. Only the following templateIds are needed:

<!-- Conformant to the BSI constraints of the HAI IG -->

<templateId root="2.16.840.1.113883.3.117.1.1.3.1" />

<!-- Pilot constraints and data constraints -->

<templateId root="2.16.840.1.113883.3.117.1.1.2"/>

Corrected in May 30 update

15. I noticed the transformation doesn't look for an entry that matches 2.16.840.1.113883.3.117.1.1.2.2.2. That entry should be legal per the cda.xsd, but I notice it's not mentioned in the Conformance Statements. If an entry is present in the xml file with that templateId, the transformation inserts a spurious "x" in the output. So the question is: Should we omit that entry, or will that entry be ignored by the transformation in the final version?

KH: The insertion of the spurious "x" is in effect a failure alert (since narrative block is required) that the populate-narrative transform for HAI/BSI does not recognize this templateId and so does not create a narrative block for the entry. In this particular case it's a correct failure: although that templateId is CDA-valid, the OID you used is under the pilot OID root but is not assigned: there are no conformance statements or schematron rules for it, and no XSLT template to create a narrative block for the entry.

16. CONF-78 in the conformance statements document states that the value of @code is x-ABX. In the May 15th webinar, I believe that the value of @code is changed to x-ABS. But today when I ran the validator, it actually expects the value of @code to be x-ABX. We used the populate-narrative.xsl to generate the narrative blocks. I need to change the reference of x-ABS to x-ABX in the populate-narrative.xsl file to have it correctly transform the narrative block for the findings section.

KH: The populate-narrative.xsl transform is in error: it should be checking for x-ABX as you state. Corrected in May 30 update

17. CONF-37: This requires each custom field to contain a free-text and a date entry. My understanding is that some of the custom fields are designated by NHSN to be Coded, Free Text, Numeric or Date Fields, but user gets to decide which, if any, they use. Folow-up: The Custom field blanks do occur in pairs, but my understanding is that the first blank is for the Field Label, and the second blank is for the Field Entry.

KH: The form shows paired spaces, one to write in and one for a date. Will need to confirm what entry types can be supplied here. Add to issues list

18. CONF-63: This requires the Findings section to contain between 1 and 3 pathogens. My understanding is that it is also possible to have zero pathogens identified. (that is, what if CONF-60 value = 'false' ) In this case, is the entire Findings component deleted?

KH: The conformance statements currently require a Findings section. This is incorrect - it is a pilot requirement, and should have appeared with the pilot constraints. If no pathogens are identified, the Findings section would not be present. A Findings section would be present (a) if LCBI, (b) if "pathogens identified" is yes. See also #9 above.

19. Use of the NHSN location codes. I believe this is still an open issue, and would favor the vendor only having to supply (a) The hospital's local location code, and (b) The NHSN location "type" (like SICU, MICU, SCA, etc.)

Also: Several business rules reference the NHSN location codes. Wouldn't these rules work just as well if they referred to location "types<" (like "Nursery, Post-Partum, L&D, etc.)?

CDC: The location type would not be sufficient for the location code submitted via CDA. The NHNS requires an exact matching to the location code.

20. I noticed CONF-73 calls for a value of "pathogen-ranking", but the populate-narrative.xsl is looking for a code of "Pathogen-ranking". Incorrect case will cause the matching to fail.

KH: The populate-narrative.xsl transform is incorrect. Corrected in May 30 update

21. The location-type code in my document was IN:ACUTE:WARD:M, which appears in the referenced table. It produces an error: Pilot Constraint: The NHSN Location Type code SHALL contain the string :CC:, indicating that the BSI record is for location type of ICU/Other(non-NICU or SCA). Are only the Critical Care locations valid? Or should the Validator accept any of the values in the NHSN Location-Type Codes table? Or am I missing something else?

KH: For the pilot only location-types of ICU/Other are in scope; see pilot constraint in CONF-86.