Primary takeways

• Chasm between content ontologies and message exchange formats
• The importance of requirements in conceiving reusable software solutions
• The value of dual-representation (GRDDL)
• The Computer-based Patient Record (CPR) Requirements
• Secure (or Semi-closed) Semantic Web Architecture
  • Trust and rules might not be sufficient for security in closed CMS
• Use of foundational ontologies

Backdrop

• The Computer-Based Patient Record: An Essential Technology for Health Care.
  • ISBN: 0309055326
• Cleveland Clinic's Cardiovascular Information Registry
• 3 year project to completely reconstituted as an XML & RDF repository
  • 200,000 patients
  • 100+ publications per year
  • 15-20 new cases collected per day
• Details..
  • Controlled data entry (XForms)
  • Semantic data warehouse model within the institution
  • Migrated a (very large) legacy relational model to a patient record ontology
  • Security model: ACL associated with Named Documents / Graphs
  • High-volume content management
  • Data export for statistical analysis
  • Use of open source tools and open standards (XSLT,XML,RDF,OWL,N3,SKOS,XSD)

The problem: content ontology proliferation

• SNOMED, Open Galen, UMLS, OBR, FMA, biozen ..
• High proliferation, little commonality
• Not (neccessarily) suited for uniform & concrete serialization (data collection)
  • More a fault of their representation formats than the vocabularies
  • The (often understated) impedance mismatch between KR and document syntax
• Mostly oriented around biomedical reality not healthcare information

The problem: use of message formats for KR

• HL7 Reference Information Model (RIM)
• Not biologically (or clinically) comprehensive
• Ontologically inconsistent
  • The primary goal is data exchange not KR

Wide spectrum of representation requirements

• Two extremes in a wide spectrum of medical record requirements
• Uniform message exchange versus knowledge representation
• XML and RDF have become mutually exclusive solutions for representation

A software engineering analogy

• What are the symptoms of poor requirements gathering in the software development cycle?

Suggested Solutions

• Dual web representation (XML,GRDDL,RDF,OWL)
• Web architecture (standards-based)
• CPR requirements
• Foundational content modeling

Dual Representation (GRDDL)

• GRDDL: Emerging technology for automated extraction of RDF from XML
• Crucial for medical record representation and content management
• Encourages fast adoption and reuse of single-purpose vocabularies
• ESL analogy
• Cheap technology:
  • Presentation (XSLT, XHTML)
  • Form-based data entry (XForms)
  • Uniform, unambigous interpretation (RDF,RDFS,OWL)

GRDDL best practices for vocabularies

• Associate an XML to RDF transform for extracting RDF from established XML vocabularies
  • XSLT is the more common language for writing such transforms
• Develop a concrete XML syntax for your stand-alone RDF vocabulary
• Consider a GRDDL transformation for extracting CPR descriptions from HL7 documents / messages

Computer-based Patient Record: what is it?

• Old, but very relevant, specific set of requirements by Institute of Medicine
• Expresses the same concerns about lack of clear definition / requirements
• 15 years and counting...
• Emphasizes:
  • The need to support Problem-oriented Patient Record (POPR) standards
  • The need to facilitate decision support
• Can be met with semantic web architecture, document processing, GRDDL, and rich web backplane

Meeting CPR functional requirements

• Uniform, extensible record content (dual representation)
• Record format (open vocabulary standards)
• System performance (RDF-DBMS and Content Management Systems - CMS)
• Linkages (web architecture)
• Intelligence (logical reasoning and decision support - DL, DLP, ACPP models)
• Reporting Capabilities (Document processing - XSLT, XHTML, PDF, tabular exports - CSV)
• Security (ACL, Named Document / Graph, Content Managements Systems - CMS)
• Multi-views (seperation of content / presentation / interpretation XML, GRDDL & XSLT)
• Accessiblity (browser-based standards - CSS, XHTML, XSLT, XForms, SVG, etc ...)

Architecture, representation, and content models

Meeting CPR content modeling requirements

• Alignment with POPR standard
• Longitudinal, life-long content (time-orientation OWL time)
• Provenance and source (DC)
• Provider Identification and participation (FOAF?)
• Patient Identification (FOAF,vCard,..)
• Controlled vocabularies and thesauri classifications (SKOS)
• Uniform (core) information and process model
  • (HL7 RIM OWL? - acts, entities, roles, causation, participation)
• Use of interoperable, foundational ontologies

Diagram of content models for CPR

Going forward

• Establish a group to steward best practices?
• An interest group note?
• POPR concepts are minimal and well established
  • Develop a core ontology for POPR concepts?
• Align POPR vocabulary with:
  • HL7 RIM (OWL?)
  • OpenEHR?
  • ACPP
  • OWL-time
  • Foundational ontologies (DOLCE, OBR, SNOMED, UMLS)
• Write namespace transformations for extracting POPR RDF from HL7 RIM documents

Acknowledgements

• http://www.nap.edu/catalog/5306.html - Online book
• http://doi.ieeecomputersociety.org/10.1109/TAI.2002.1180795 - Ontologies for Knowledge Representation in a Computer-Based Patient Record
• http://www.w3.org/TR/grddl/ - Gleaning Resource Descriptions from Dialects of Languages
• http://www.w3.org/TR/webarch/ - Architecture of the World Wide Web, Volume One
• http://www.w3.org/MarkUp/Forms/2006/backplane/ - Rich Web Application Backplane
• http://www.w3.org/DesignIssues/LinkedData.html - Linked Data
• http://ontology.buffalo.edu/bio/OBR.pdf - A Strategy for Improving and Integrating Biomedical Ontologies