Skip to content

Latest commit

 

History

History
229 lines (183 loc) · 6.76 KB

DESIGN.rdoc

File metadata and controls

229 lines (183 loc) · 6.76 KB
Raw

Laika Design and Architecture ↑

The classes covered in this document are grouped into four sections. Application-specific code is the scaffolding and business logic that holds Laika together. Test and test type code manages EHR testing state and related data. Patient code is responsible for reading, updating, processing and generating C32 from patient data. Validation code does the heavy lifting that constitutes Laika’s core functionality.

Application-specific Code ↑

Models ↑

{ErrorMailer}

error notification email handler

{Setting}

run-time application configuration setting

{SystemMessage}

news post

{User}

application user

{UserNotifier}

password reset notification

{UserObserver}

user callbacks (sends notification)

Controllers ↑

The Dashboard tab is implemented by {TestPlansController#index} and the Library tab is implemented by {PatientsController#index}.

{AccountController}

login, logout and registration

{ApplicationController}

application-wide controller functionality

{NewsController}

display and post news items

{SettingsController}

manage run-time configuration

{UsersController}

list and update users

{VendorsController}

add and update vendors

Support Code ↑

  • {SortOrder}

  • {PatientFormBuilder}

Tests and Test Types ↑

Remember that we’re talking about the EHR testing performed by Laika, not the automated test suite used to check for regressions in Laika itself. The test types are all sub-classes of {TestPlan}. The list of test plan types is enumerated in config/initializers/load_test_plan_types.rb.

Test Types ↑

The state of an individual test plan is represented by a sub-class of {TestPlan}:

  • {C32DisplayAndFilePlan}

  • {C62InspectionPlan}

  • {GenerateAndFormatPlan}

  • {NhinDisplayAndFilePlan}

  • {PdqQueryPlan}

  • {PixFeedPlan}

  • {PixQueryPlan}

  • {XdsProvideAndRegisterPlan}

  • {XdsQueryAndRetrievePlan}

Models ↑

{MessageLog}

references an external table, used for ???

{AtnaAudit}

references an external table, used for viewing ATNA logs

{ClinicalDocument}

document attachment

{ContentError}

validation error

{Proctor}

test proctor

{Vendor}

categorize tests by an arbitrary string

Library Code ↑

{XdsRecordUtility}

directly access records in an XDS database

{XDSUtils}

use xds-facade to query documents in an XDS database

Controllers ↑

{TestPlansController}

test plan operations, includes several test-specific actions

{XdsPatientsController}

XDS utility operations

Patients ↑

A {Patient} instance represents a single patient’s medical history. Most of the models in Laika are part of this structure and represent different sections or subsections of patient data. Patient and its subordinate types are based on the C32 document standard: wiki.hitsp.org/docs/C32/C32-1.html

Patient Data Models ↑

The following models are used to construct a complete patient record. Each one represents a section or subsection of patient data.

{Address}

patient address

{AdvanceDirective}

advance directive data

{Allergy}

patient allergy information

{Comment}

section comment (not currently used)

{Condition}

patient condition information

{Encounter}

doctor visit

{Immunization}

patient immunization

{InformationSource}

patient info source

{InsuranceProvider}

patient insurance provider

{InsuranceProviderGuarantor}

… and guarantor info

{InsuranceProviderPatient}

… and patient info

{InsuranceProviderSubscriber}

… and subscriber info

{Language}

spoken or written language

{MedicalEquipment}

medical device, e.g. pacemaker

{Medication}

prescribed medication

{PatientIdentifier}

patient affinity domain identifiers

{PersonName}

full name

{Procedure}

medical procedure

{Provider}

doctor or hospital

{RegistrationInformation}

general patient and contact info

{Result}

medical test results (child of {AbstractResult})

{Support}

supporting contacts

{Telecom}

phone contacts

{VitalSign}

patient vitals (child of {AbstractResult})

Patient Support ↑

  • {Commentable}

  • {HasC32ComponentExtension}

  • {InsuranceProviderChild}

  • {PatientChild}

  • {PersonLike}

Lookup Data Models ↑

These models represent lookup data needed for the UI and validation.

  • {ActStatusCode}

  • {AdvanceDirectiveStatusCode}

  • {AdvanceDirectiveType}

  • {AllergyStatusCode}

  • {AllergyTypeCode}

  • {CodeSystem}

  • {ContactType}

  • {CoverageRoleType}

  • {EncounterLocationCode}

  • {EncounterType}

  • {Ethnicity}

  • {Gender}

  • {InsuranceType}

  • {IsoCountry}

  • {IsoLanguage}

  • {IsoState}

  • {LanguageAbilityMode}

  • {LoincLabCode}

  • {MaritalStatus}

  • {MedicationType}

  • {NoImmunizationReason}

  • {ProblemType}

  • {ProviderRole}

  • {ProviderType}

  • {Race}

  • {Relationship}

  • {Religion}

  • {ResultTypeCode}

  • {RoleClassRelationshipFormalType}

  • {SeverityTerm}

  • {SnowmedProblem}

  • {Vaccine}

  • {ZipCode}

Lookup Support ↑

  • {HasSelectOptionsExtension}

  • {RandomFinder}

Controllers ↑

Most of the controllers involved in updating patient data are descendants of either {PatientChildController} or {PatientChildrenController} depending on whether the patient has one or many of the given resource, respectively. {PatientsController} controls high-level patient operations and the Library view.

  • {AdvanceDirectivesController}

  • {AllergiesController}

  • {ConditionsController}

  • {EncountersController}

  • {ImmunizationsController}

  • {InformationSourcesController}

  • {InsuranceProviderGuarantorsController}

  • {InsuranceProviderPatientsController}

  • {InsuranceProviderSubscribersController}

  • {InsuranceProvidersController}

  • {LanguagesController}

  • {MedicalEquipmentsController}

  • {MedicationsController}

  • {PatientIdentifiersController}

  • {PregnanciesController}

  • {ProceduresController}

  • {ProvidersController}

  • {RegistrationInformationController}

  • {ResultsController}

  • {SupportsController}

  • {VitalSignsController}

Validation Code ↑

The {Validation} API is used to manage the validators for each document type. The validation code is configured in initializers/laika_validation.rb.

Validators ↑

{Validation}

top-level validation management API

{Validation::Validator}

validation for a single doc type

{Validators::C32Validation}

C32 content inspection

{Validators::Schema::Validator}

C32 schema validation

{Validators::Schematron}

C32 schematron validation

{Validators::Umls::UmlsValidator}

UMLS validation

{Validators::XdsMetadataValidator}

XDS metadata validation

C62 Support (incomplete) ↑

{Validators::C62::Reader}

access the payload of a C62 document

{Validators::C62::Validator}

C62 validation (incomplete)

UMLS Support ↑

  • {Validators::Umls::UmlsBase}

  • {Validators::Umls::UmlsCodeHierarchy}

  • {Validators::Umls::UmlsCodeSystem}

  • {Validators::Umls::UmlsConcept}

Schematron Support ↑

  • {Validators::Schematron::BaseValidator}

  • {Validators::Schematron::CompiledValidator}

  • {Validators::Schematron::UncompiledValidator}

  • {Validators::Schematron::XslProcessor}