1. Medical Record Abstract Workshop Nov 16, 2001

2. Why are we here? VMDB success requires “harmony” Sophisticated veterinary medical records need a capable nomenclature. Capable nomenclatures need capable medical records systems. (Our) medical records system developers are not learning about or working with SNOMED. The RIGHT way to use SNOMED in Veterinary Medical Records systems does not exist (and Virginia-Maryland is not withholding information).

3. Current status… SNOMED is completing the database merger with Clinical Terms Version 3. The database merger is a huge challenge. There will be MUCH more “non-non-human” content available. The relationships and definitions are in flux. The hierarchies are undergoing revision.

4. Current status… SNOMED is still negotiating a license agreement with the federal government. IF successfully concluded: Free access to SNOMED content for anyone who is required to report data to federal government. No one directly involved represents veterinary interests. NCI / NIH / CDC do seem to appreciate the necessity of veterinary content.

5. Current status… We have not had access to the database for almost this whole year. No adding Veterinary Concepts No repairing Veterinary Definitions We do have the software and Dr. Livesay has been getting practical experience with the process. (Won’t take long once we “get permission”).

6. SNOMED changes… RT 1.0 RT 1.1 CT 1.0

7. SNOMED changes… Merger = content acquisition Additional Concepts (non-merger) Minor part of the process Intermediate hierarchy SNOMED recognizes that its hierarchies need work. Approach is top down, however (SNOMED- RT). Lower level hierarchies are part of merger. Relationship types added to categories Methods for definition creation are changing.

8. Definitions… Pre-coordinated Concepts with pre-made “computed” definitions. Post-coordinated Concepts built at the time of data entry in the medical records system.

9. SNOMED won’t… include a concept for every thing you might think to say. Especially categories with lots of modifiers (fractures, poisonings, etc.) Especially procedures with lots of detail. We will probably find that post-coordination is a must.

10. SNOMED won’t… Remove concepts that already have more detail than they REALLY intend to support. SNOMED ‘seems’ to support kinds of content that SNOMED actually thinks should be post-coordinated.

11. SNOMED won’t sanction… adding context to the definitional concept X is a “final diagnosis” X is a “presumptive diagnosis” X is a “rule out” X is a “problem” This is a decision that MUST be made for each medical records system. It is not consistent with the HL7/VMDB message that has been proposed.

12. History… Coding systems were purpose built. ICD-9 - Standardized for government health statistics (especially death certificates). CPT – Standardized for medicare billing submission.

13. History… Coding systems of the past were designed to reduce demands on computer systems. Single code – minimized storage space, transmission overhead Single purpose gave them an implied semantic context ICD-O (causes of death) ICD-9 (diagnoses for billing, statistics) CPT (procedures for billing)

14. History… SNOMED has NOT been developed (de novo) as a data entry vocabulary for medical records SNOP Data entry for pathology – single purpose SNOMED International Direct acquisition of concepts from other vocabularies (ICD-9, CPT, NANDA, etc.) – multi-purpose

15. History… Uneven hierarchies, inconsistent approaches (within SNOMED) Findings and SOME associated etiologies (toxicology) Findings and SOME notions of duration Findings and SOME notions of topography SNOMED is not a perfect guide to its own use.

16. Challenges… Limitations of veterinary medical records systems Concept (meaning) drift SNOMED version control History tables, referrals

17. Medical record system capabilities… Pre-coordinated concepts only You are only able to store concepts that exist in SNOMED without modification. Simplifies medical record system design Limits expressiveness Post-coordination You can add details to SNOMED concepts that don’t exist in the nomenclature Imposes medical record system requirements Imposes rules on phrase construction

18. Medical record system capabilities Record system MUST store a connection between the primary concept, the nature of the modification and the modifier. Objectattributevalue (triples) Defined conceptrelationshipmodifier Femurhas lateralityleft Pneumoniahas severitysevere Richness of semantic structure Independent storage of final diagnosis, problem lists, presenting complaint?

19. Concept meaning “drift” Procedure (group) = Radiology Radiography Radiography + fluoroscopy Radiography + fluoroscopy + scintigraphy Radiography + fluoroscopy + scintigraphy + ultrasound + CT + MRI + PET It may always have meant “Any technique done in the radiology department”. = Diagnostic imaging…

20. Goal… Store meaningful abstracts of medical records for retrieval and analysis. Final diagnoses Procedures Presenting complaints Problem lists

21. Retrieval of… Records for a particular clinician Records for a particular hospital Records contributed to national data repository These MIGHT all require different coding approaches.

22. Retrieval approaches… Using the “IS_A” hierarchy Search SNOMED for ALL children of a particular concept. All is_a “disease of the cardiovascular system” The list of children serves as the value restriction list for a query of the medical record system. All records where the diagnosis = something in the list (retrieved from SNOMED)

23. Retrieval approaches… Using the definitions… All concepts with a particular set of relationship (attribute) value pairs All “procedures” where “has_action” = “injection” AND “administered_substance” = “doxirubicin” are part of the definition. The list of children serves as the value restriction list for a query of the medical record system. All records where the procedure = something in the list (retrieved from SNOMED)

24. Retrieval approaches… Require that the medical record system interact with the SNOMED database. Require that the abstracts we create follow the rules SNOMED imposes on concept definitions.

25. Tough goal… Balance pre-coordination with post- coordination while… … insuring computational equivalence (a post- coordinated concept can be coded both ways, but both must have all the same parts) … avoiding redundancy (we shouldn’t add morphologies and topographies that are already part of the definition through inheritance).

26. Shaft of tibia (topography)T2 Tibia (topography)T1 T2 M1 M2M3 M4 D1 D2D3 D4 D5 D1+T2+M2+M3Open Comminuted Fx of Shaft of TibiaD6 …Fracture of BoneD1 D5+M3Open Comminuted Fx of Shaft of TibiaD6 D3+M4Open Comminuted Fx of Shaft of TibiaD6 D4+T2+M3Open Comminuted Fx of Shaft of TibiaD6 D3+M2+M3Open Comminuted Fx of Shaft of TibiaD6 Open Comminuted Fx of Shaft of Tibia Open Fx Shaft of Tibia Open Fx Tibia Fx Shaft of Tibia Fx Tibia D2+T2+M2+M3D6 D2+T2+M2D5 D2+M2D4 D2+T2D3 D1+T1D2 Open, comminuted Fx (M2 + M3)M4 Comminuted FxM3 Open FxM2 FractureM1 D1 Open comminuted Fx of Shaft of Tibia D0+…+T1+T2+M2+M3Open Comminuted Fx of Shaft of TibiaD6 D0