Active Semantic Electronic Medical Records

1
Active Semantic Electronic Medical Records

• Chapter 6

2
Introduction

• Most cumbersome aspect of healthcare is the
  extensive documentation that is legally required
  for each patient.
• 30 of physicians assistant is spent on this.
• Medical practices are investing heavily in
  Electronic Medical Records (EMR)
• This chapter discusses the design of an EMR that
  utilizes semantic web/web services.
• It is based on collaboration between physicians,
  Athens (GA) Heart Center, LSDIS Lab at UGA.
• Utilizes active semantic documents (ASDs)
  developed at LSDIS lab.

3
News

• Google is getting in health care Google health
  Cleveland Clinic announcing a joint venture for
  what? For managing health records of patients
• W3C is heavily involved healthcare area.

4
Active semantic documents

• ASDs get their semantic feature by automatic
  annotation of documents with respect to one or
  more ontologies.
• The documents are now active
• They are termed active since they support
• automatic and dynamic validation
• decision making on the content of the document
• apply contextually relevant rules to components
  of the documents
• accomplished by executing rules on semantic
  annotations and relationships that span across
  ontologies.

5
Active Semantic Electronic Medical Record (ASEMR)

• ASEMR is an application of ASDs in healthcare
  which aims to
• Reduce medical errors
• Improve physician efficiency
• Improve patient safety and satisfaction in
  medical practice
• Improve quality of billing records leading to
  better payment
• Make it easier to capture and analyze health
  outcome measures
• Specification of rules along with ontologies play
  a key role.

6
ASEMR Rules

• Rules include prevention of drug interaction
• Ensuring the procedure performed has supporting
  diagnoses
• ASEMR
• semantic and lexical annotations can be displayed
  in a browser,
• show results of rule execution,
• provide ability to modify semantic and lexical
  entities in a constrained manner, say, according
  to existing lexicons
• offer suggestions when rules are broken or
  exceptions made
• Currently in use by Athens GA Heart Center (AHC)
• This is an add on Panacea electronic end-to-end
  medical records and management system

7
ASMER Approach

• Development of ontologies in healthcare
  (cardiology) domain
• Development of an annotation tool that utilizes
  the developed ontologies for annotation of
  patient records
• Development of decision support algorithms that
  support rule and ontology based
  checking/validation and evaluation.

8
Motivating Scenario and Benefits

• Physicians face many challenges
• Patient care
• Clinical care pathways
• Medical billing insurance pays for care
• Any error in a number or reporting may result in
  refusal to pay
• Preferred drug recommendations formularies
• Auditable oversight
• Abide by government regulations

9
Knowledge and Rules representations

• ASMER employs a combination of OWL ontologies
  with RDQL rules
• Three ontologies
• Practice ontology
• medical practice, facility, physician, assistant,
  and nurse
• Parts of the existing databases were used to
  populate this ontology
• Drug ontology
• Drugs, classes of drugs, drug interactions, drug
  allergies, formularies
• License content (Gold Standard Media) equivalent
  to physicians drug reference was the primary
  source for populating this ontology
• See Fig. 6.1

10
ASMER Ontologies (contd.)

• Diagnosis/procedure ontology
• Medical conditions, treatments, diagnosis
  (ICD-9), and procedures (CPT)
• Licensed SNOMED (Systemized Nomenclature of
  Medical-clinical terms)
• Key enhancements involved linking this ontology
  to the drug ontology.
• Customizability for each area involved assigning
  code to practices and diagnosis

11
Rules supported by ASEMR

• Drug interaction check
• Drug formulary check (whether the drug is covered
  by the insurance company, if not, provide
  alternatives)
• Drug dosage range check
• Drug-allergy interaction check
• ICD-9 (International Classification of Diseases)
  annotations choice for physicians to validate and
  choose the best possible code for treatment
  choice
• Preferred drug recommendation based on drug and
  patient insurance information
• Rules allow for more flexibility, enhanced
  reasoning power and extensibility
• Rules allow for addition of knowledge
  declaratively for ex adding a relation
  cancel_the_effect to ontology and addition of
  rule indicating the drugs affected by this rule
  extends the decision making capacity.

12
Application Scenario 1 Front end

• ASEMR is installed at 8 beta sites.
• Active semantic documents
• ASEMR both expedites and enhances the patient
  documentation process.
• Enables physicians office to complete
  documentation while the patient is still in the
  office
• Lets analyze a sample ASD (Fig.6.2)

13
Analyzing an ASD

• Document is annotated with ICD, other technical
  terms automatically
• Medications after visit section
• Level 3 (l3) interaction warning on one of the
  drugs
• Mouse over on it will pop up details
• Warning F (yellow) indicates that drug is not
  covered under the patients insurance
• Warning A (green) warns that the patient is
  allergic to this drug
• Simply clicking on the drug prints a prescription
• Explore the drug to get more details about the
  drug (see an example in Fig. 6.3)

14
ASEMR Scenario 2 Semantic Encounter Sheet

• See fig.6-4
• When a physician decides on a diagnosis and plan
  for treatment, he/she will have to justify it by
  specifying code for the reasons.
• This can be automatically done.
• Semantic encounter sheet
• as the user selects orders (ex EKG), the next
  column populates the screen with diagnostic code
  which support medical necessity.
• The doctor is required to validate this choice
  and the ontology enables him/her to easily
  consider alternatives.

15
Implementation details

• The Panacea database holds all information about
  the patient
• Patients visits, past and present problems,
  diagnoses, treatment, doctors seen, insurance
  information, text description of the visit.
• Data entry creates a well structures XML document
• Document is annotated using annotation module
• After the annotation, rules module applies rules
  to the annotations rules are written in RDQL
• Information is exposed using WS and REST based
  messages
• XMLXSLT ? HTML exposed to the client

16
ASEMR Architecture
REST WS calls
Active Semantic Document Javascript C
REST WS call
Lexical annotations
Semantic annotations
Tomcat
DrugWS
PracWS
ICD9WS
Client Web Browser
xml
XSL
Panacea Database
RDQL
XML
Static ontology holder/Jena
Jena api
DRUG
Practice
ICD-9
Owl_files
17
Deployment and Evaluation

• AHC is the main site of deployment
• About 80 patients per day in a 4 hours time frame
• 2 physicians, 2-4 mid-level providers, 8 nurses,
  4 nuclear/echo technicians, relies on
  Panacea/ASEMR web-bases paperless operation for
  all functions except billing.
• Everything done realtime, where as after visit
  time was used in earlier approaches.

18
Results

• Patient volume increased See fig.6-6 as seen
  from appointments
• Charts completed before deployment of ASMER and
  after deployment See fig.6-7, 6-8
• Increase in patient satisfaction
• Increase in income to the organization
• Improved patient care

19
Future Directions

• ASEMR approach can be extended to provide
  decision support on a deeper level.
• Can discover obscure relationship between
  symptoms, patient details, and treatments.
• Semantics alerts can be injected into the system
  about trials etc.
• Higher degree of integration into billing system.

20
Demos

• http//www.openclinical.org
• ASMER demo http//lsdis.cs.uga.edu/projects/asdoc
  
• Google Microsoft healthcare giants?
• W3C http//www.w3.org/2005/04/swls/