Medical Record Abstract Workshop

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. • Object attribute value (triples) • Defined concept relationship modifier • Femur has laterality left • Pneumonia has severity severe • 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. Open comminuted Fx of Shaft of Tibia T1 T2 T1 Tibia (topography) T2 Shaft of tibia (topography) M1 Fracture M1 M2 Open Fx M3 Comminuted Fx M2 M3 M4 Open, comminuted Fx (M2 + M3) M4 D1 Fracture of Bone … D2 Fx Tibia D1+T1 D0 D3 Fx Shaft of Tibia D2+T2 D4 Open Fx Tibia D2+M2 D1 D5 Open Fx Shaft of Tibia D2+T2+M2 D6 Open Comminuted Fx of Shaft of Tibia D1+T2+M2+M3 D1 D6 Open Comminuted Fx of Shaft of Tibia D2+T2+M2+M3 D6 Open Comminuted Fx of Shaft of Tibia D3+M2+M3 D2 D3 D6 Open Comminuted Fx of Shaft of Tibia D4+T2+M3 D4 D6 Open Comminuted Fx of Shaft of Tibia D3+M4 D6 Open Comminuted Fx of Shaft of Tibia D5+M3 D5 D6 Open Comminuted Fx of Shaft of Tibia D0+…+T1+T2+M2+M3