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 physician’s 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 physician’s 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 patient’s 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: • Patient’s 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 • XML+XSLT  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/