1 / 11

Open Source EHR Re-factoring Services December 2011 Update

Open Source EHR Re-factoring Services December 2011 Update. Afsin Ustundag. Preliminary Deliverables. List of application layer modules Already in the OSEHRA Architecture document Number of applications: 168 Identification of interfaces required and list of common services

asha
Download Presentation

Open Source EHR Re-factoring Services December 2011 Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Open Source EHR Re-factoring ServicesDecember 2011 Update Afsin Ustundag

  2. Preliminary Deliverables • List of application layer modules • Already in the OSEHRA Architecture document • Number of applications: 168 • Identification of interfaces required and list of common services • Start from XINDEX results • More detail by code investigation, automation • Similar project ongoing within OSEHRA?

  3. Refactoring Deliverables • Refactored Module Software Source Codes • Module of our choice • Scheduling is suggested • No new functionality added • Mainly reorganization of existing code to make it more modular and accessible • Making the code compliant with OSEHRA guidelines • Open source community to be engaged and participate

  4. Delivered – Package Interfaces • Automated Package to Package Interfaces • Routine to routine only. • Package routines are identified from namespaces. • Uses XINDEX variant. • Interfaces are specified as tags in routines • Formal parameters. • Inputs and outputs. • Globals (top level). • Indirection and Xecute statements. • Read and Write statements.

  5. Delivered – Package Interfaces • Example Interface from Problem List Package GETLIST^GMPLHS CALLING PACKAGES : HEALTH SUMMARY,ORDER ENTRY/RESULTS REPORTING FORMAL: GMPDFN,STATUS INPUT: DUZ*,GMPDFN,GMPLVIEW*,IO,ION,IOST,IOT,ORWINDEV,SCS* STATUS,U OUTPUT: %,C,DI,DIL,DIQ0,DIQ1,DIQ2,DRS*,GMPLIST*,GMPTOTAL,I,J SCS*,X,Y GLBS: ^%ZOSF,^AUPNPROB,^DD,^DI,^DIC,^GMPL,^TMP,^VA READ: 0 WRITE: 1 PKG GLBS: ^%ZOSF,^AUPNPROB,^DIC,^GMPL,^TMP,^VA PKG EXEC: 1 PKG IND: 0

  6. Delivered – Package Choice • Choice of a preliminary package • We chose Problem List. • A package that does not have too many dependencies. • A package that does not have too few dependencies. • A clinical package. • Has a menu based UI and GUI (CPRS).

  7. Future Work - Dependencies • Routine interfaces are not the only dependencies • VistA file ownership. • Global ownership. • GUI RPCs. • Data as Code (Faux Routines). • Needs identification and automation • Interfaces • Needs to be fully validated. • Namespace identification should be automated.

  8. Future Work - Testing • Understand OSEHRA resources and procedures. • Understand VA resources and procedures. • Automated tests? • Test plans? • Test data? • MUnit? • Determine and implement testing strategy. • Requires understanding the functionality of Problem List package from user point of view. • Test data? • VA eHealth University?

  9. Future Work - Refactoring • Identify and separate presentation layer • Can we implement a simple Problem List GUI? • Needs more understanding of the code. • Most read/writes are in common services? • Do we move it to application layer? • Needs more understanding of CPRS. • Any business logic in CPRS? • No Problem List RPC entries in ^XWB(8994? • Problem List is manipulated through Order Entry package? • Initialization and authentication? • Need to look at Medical Domain Web Services (MDWS)

  10. Future Work - Refactoring • Identify and separate business logic • Part of it is identifying presentation layer. • Move direct data access to lower levels (FileMan). • Move direct global lookup. • Move Xecute statements. • Limit indirection . • Replace direct update calls to other packages with simple generic listeners? • Define API’s between packages if not there.

  11. Future Work - Refactoring • Contribute XINDEX based utility • Additional functionality already added for deliverables. • Needs to be improved for dependencies. • Improve as a tool to gather information about the codebase and globals. • Looking at it as a automated refactoring tool. • New all local variables. • Add formal parameters. • Replace old style tag/goto based loops. • Identify dead code.

More Related