OpenHMIS Registration API Design

Owned by Wesley Brown
Last updated: Jun 06, 2012 by Former user (Deleted)Version comment
3 min read

Note: This is a work-in-progress page and will change frequently along with the discussions about the registration api.  Dumb ideas and designs are not just possible but likely.

High-Level Features

General

  • Expose registration events

  • Support some type workflow

    • Could be very simple (redirect to a url or add persistent list item) or integrate with a more complex workflow engine

  • Integrate with an appointment scheduling module

  • Manage programs, relations, and allergies from within the registration screens (this does not seem like core functionality)

  •  

  • Dynamic design of the available fields  in the registration form selecting from person attributes

  • Configure the precision on the calculated age to show (years, months, days)

  • Print patient slip after registration

    • Dynamic design of the print layout

  • Manage user Categories

  • Manage user Categories

    • Create new categories

    • Define category Type 

    • Define incompatibilities amongst categories and patient restrictions Create new categories Define category Type  Define category compatibilities and restrictions

Search

  • Auto-complete searching

  • In-place search results (no postback)

  • Custom search algorithms

  • Find patient by identifier

    • Bar code

    • Fingerprint

    • Retina

    • etc

  •  

  • Advance Search Option that filters patients by 

    • gender

    • Age +- Range

    • Last Visit

    • Relative Name

    • Telephone Number

Patient Creation

  • When creating, perform more exhaustive search using all available data

  • Works with idgen module for patient ids

UI

  • Provide full-screen registration view that hides the rest of OpenMRS

  • Custom registration UI for registration clerks

  • Designe a screen-size layout to avoid scroll while registering a patient

API Design

General

RegistrationService

A service which provides access to add, edit, and remove patients. Exposes events for each operation.

Search

PatientSearchBase

Base class for all searches to find patients

PatientSearchStrategyBase

Base class for all patient search strategies, supports optional static initialization

Searches for patient by their attributes using some strategy

A specific attribute searching strategy

Searches for a patient using some external identifier (barcode, finger-print, etc)

A specific identifier search strategy.  Initialization could be used to build an in-memory cache of the all identifiers to handle situations where the database cannot be used to perform the type of search required.

Patient Identifier Management

We should manage the process behind associating an identifier (fingerprint, bar code, etc) with a patient as this can be a complicated multi-stage process.

The data for a single patient identifier.  The structure of the data is managed by the system which creates the identity.  For example, if a fingerprint is being used, a PatientIdentifier subclass would be created which would be used by the interface code with the fingerprint scanner when the identifier is created as well as the PatientIdentifierSearchStrategy for fingerprints.  Support for encryption should be supported, though care should be taken as this may significantly impact performance of searches.  Patients can, and likely will, have multiple identifiers.  When possible, database indexes should be used to increase search performance, this implies that different tables may be used based on whether the identifier should be indexed as including identifiers that should not be indexed needlessly increases the size while reducing the efficiency of the index.

A service which provides access to add, edit, and remove patient identifiers.  This service will be exposed as a web service via the Webservices.rest module.  This service will also expose events so that PatientIdentifierSearchStrategy's can be notified of identifier operations.