End Point’s CasePointer business acquired by Deloitte

2024-06-03T00:00:00+00:00

We are proud to announce that Deloitte has acquired the industry-leading public health disease surveillance business, CasePointer, from End Point Corporation as of June 1, 2024. This acquisition brings to Deloitte, End Point’s experienced and skilled software engineers, cloud developers, DevOps engineers, epidemiologists, and former public health officials.

Since 2008, End Point’s CasePointer business has worked with open-source public health software to modernize tools, automate processes, improve the user experience, and provide better return on investment to state and local public health agencies for their disease surveillance and epidemiologic needs.

Jon Jensen, End Point’s former chief technical officer, has joined Deloitte with this transaction. He said: “We are excited to work with Deloitte’s team of professionals and serve their broad client base. Together, we expect to make an even greater impact for government health organizations.”

Deloitte is only acquiring assets, clients, and personnel related to End Point’s CasePointer business. All other business lines remain with End Point, including systems administration, database engineering, e-commerce programming, application development, and our immersive GIS platform, VisionPort.

See Deloitte’s Public Health Transformation website for further information.

Achieving Healthcare Data Interoperability

2023-07-28T00:00:00+00:00

(Co-authored by Jon Jensen.)

Background

For many years, healthcare providers, public health experts, and software developers have been hard at work on standards and methods for interconnecting systems to share vast and ever-expanding patient and lab data.

In the late 1980s the non-profit organization Health Level Seven International released the HL7 data standard. That was updated many times up to the year 2007 with HL7 v2.5.1 which is still widely used today.

New healthcare data standards have emerged, including HL7 v3, the Consolidated Clinical Document Architecture (C-CDA), the Fast Healthcare Interoperability Resource (FHIR, pronounced “fire”), and more. These are not yet as broadly adopted as HL7 v2.5.1.

Under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), most of this data is classified as PII (personally identifiable information) and/or PHI (personal health information) and must be kept secure and protected at all times, so that it will not be accessed without proper authorization or patient consent.

The data dilemma

Healthcare data systems now routinely communicate in many ways, but there are sometimes incompatibilities when patient data travels from one system to another.

The U.S. Centers for Disease Control (CDC) encourages and sometimes incentivizes, but does not mandate, adoption and implementation of common standards. So each jurisdiction’s public health agency (PHA), lab, and vendor may be using different and only partially overlapping standards.

Different labs, doctors, and public health workers use varying conventions for things like facility names and lab codes, which presents problems for interpreting and reporting data. For example, “KU MAIN” may be recognized as the main campus of the University of Kansas Medical Center in nearby communities or states, while providers elsewhere may not recognize this code, or may mistake it for a similarly named facility in their area. The University of Kansas Health System consists of a large network of satellite facilities that span the states of Kansas and Missouri, rather than just one location in a single state. This may create additional confusion about which state jurisdictions should be involved.

This semantic category is called a vocabulary, and if two systems use incompatible vocabulary, one of them, or an intermediary, must have a mapping from the terms in one vocabulary to another.

The syntactic category of challenge is called a grammar, and covers the kinds of message types and actions a system works with.

An article published in December 2022 by Dr. Naheed Ali identifies “inconsistent data and lack of standardized data structure” as the number one issue to be overcome regarding the Electronic Health Record (EHR) interoperability challenges facing healthcare professions today:

One of the biggest EHR interoperability challenges in healthcare interoperability is managing inconsistent data from multiple sources. Information stored in different databases can have a variety of formats and data types that are not easily compatible with one another. A single record may contain different information about a patient’s medical history or treatment plan, making it more difficult for different systems to interpret correctly. —Dr. Naheed Ali, EHR Interoperability Challenges and Solutions

Cooperating for a healthier future

Although great strides have been made to digitize healthcare data and improve interoperability, much remains to be done. Newer standards (like HL7 FHIR, released in 2014) face an uphill battle for industry adoption to become as widely utilized as HL7 v2.5.1 (from 2007) and C-CDA (from 2011).

While networks of hospitals and laboratories typically set up EHR platforms built by companies like Cerner or Epic to manage patient data, public health agencies require additional applications to aid in the identification, tracking, and reporting of reportable health conditions from those patient EHRs.

Public health services in the United States are provided by various federal, state, tribal, territorial, regional, municipal, and other bodies that decide which software they will use to support their communities. Some look to software offered by the CDC or software firms to provide the application functions they require. Others contract with consulting firms to develop custom software. Still others opt to develop and maintain everything in house.

Getting so many diverse software systems to work together is difficult due to a phenomenon known as the quadratic cost problem. This occurs when the need for bi-directional connections between software applications increases exponentially, instead of linearly, with each component added to a system.

An organization called TechChange explains this concept and more in their video Standards and Interoperability in Digital Health: Explained.

The book Patient Safety: Achieving a New Standard for Care identifies in chapter 4 this concern:

The fact that there is no standard means of representing the data for any of these datasets or requirements is astonishing and highlights the amount of unnecessary work performed by health care and regulatory organizations to prepare, transmit, and use what amount to custom reports.

Nearly 20 years after those words were written, and almost a decade after the FHIR standard was introduced, the variety of standards and systems has not narrowed. Change is difficult.

Health Information Exchanges

One architectural attempt to simplify data sharing is by connecting applications of each jurisdictional segment within a larger governing body to a centralized Health Information Exchange (HIE).

An example of this would be an individual state public health organization connecting its own software to an HIE, along with the software currently in use by each local jurisdiction within that state. Each jurisdiction does not have to use the same software, but can communicate by using its connection to the HIE rather than individual bi-directional connections to every other application used throughout the state.

This sounds like just what is needed, and likely is for some use cases.

But HIEs generally work at the syntactic (grammar) level. Many HIEs have agreements with the facilities they serve, that they will not change the content of messages in any way. Unfortunately that means most HIEs essentially work as a passthrough.

They thus are helpless when it comes to the wide variety of nonstandard content semantics that they encounter, and have no way of correcting vocabularies, so they pass on junk data.

Even a small, steady volume of unusable messages can at best clog up manual review queues and overwhelm already overworked staff, and at worst give a false sense that all data are being ingested and reported on, when they are not.

Something like an HIE that is capable of semantic (vocabulary) inspection, translation, and rule-based routing, customizable per reporter for the jurisdiction’s changing needs, is called for.

The CasePointer software suite

We at End Point are solving the interoperability problem for our client jurisdictions’ public health disease surveillance with CasePointer, a new suite of proven open source software. It interoperates with many other systems, including HIEs, and is configurable to map varying local data conventions into a single system that routes messages and reporting as needed.

EpiTrax disease surveillance system

We began in 2008 to work with software for public health using the open-source TriSano disease surveillance system.

In 2017, the Utah Department of Health and Human Services (DHHS) released a new open source disease surveillance application called EpiTrax to replace their use of TriSano. EpiTrax is a more capable, comprehensive, and supportable application that supports all 170+ reportable health conditions identified by the National Notifiable Disease Surveillance System (NNDSS).

As open source software, we and others can use it, extend its capabilities, and contribute back to a shared source code repository.

Today EpiTrax serves as the central application within the CasePointer suite.

EMSA preprocessing powerhouse

The separate application Electronic Message Staging Area (EMSA) was also designed by the team at Utah DHHS to work in tandem with EpiTrax. EMSA ingests electronic case and lab reports (eCRs & ELRs) from various reporters and allows public health organizations to create extremely powerful custom configurations capable of message inspection, semantic (vocabulary) mapping and transformation, and routing, tailored to each jurisdiction’s needs and preferences.

Once these EMSA rules are set up, the healthcare data can flow continuously while automatically being pre-processed by EMSA according to its matching jurisdiction with minimal manual intervention by the area’s public health agency. PHA staff can focus on their primary objective: investigating and tracking disease to protect the health of their community.

Investigators can customize their individual dashboards within EpiTrax to analyze, sort, trace, and process the data prepared by EMSA in the way that is most efficient for them. Working together, these two powerhouse applications provide the cost and time saving benefits that public health organizations around the country need.

NMI automatic CDC reporting

Once a public health case reaches a certain status within EpiTrax, certain data must be reported per current requirements of the CDC. Historically, this has been a manual and tedious process for investigators involving referencing a text file with the latest CDC guidelines as they process these reports.

More recently, the NNDSS Modernization Initiative (NMI) by the CDC has provided options for a much more automated method of reporting the necessary case data. This is a critical part of the process for PHAs, as they receive funding for their organization based on their ability to meet CDC reporting requirements and interoperability standards.

The NMI module is integrated into the CasePointer workflow to ensure that once data reporting has been configured for a case, any updates will be automatically sent to the CDC without additional manual processing.

CasePointer Disease Reporting Portal

During COVID-19, nontraditional reporters such as pharmacies, university health centers, community drive-up testing centers, and others not part of our state clients’ formal public health infrastructure, needed to be able to submit test results to the state.

We developed a specialized disease reporting portal, initially focusing on COVID-19, to accept simple batch uploads of test results and, based on changing policy, to forward test data to the disease surveillance system. This separate system had no access to the main EpiTrax disease surveillance system, or to any other reporters’ data.

Bringing it all together

CasePointer provides two prominent strengths:

First, its ability to map the endless local conventions used by those reporting the data into a unified standard for the rest of the workflow.
Second, the customizability and agility of the CasePointer applications are unique among available disease surveillance solutions.

CasePointer puts the ability to customize data collection and surveillance in the hands of the public health experts. New fields can be added into an investigation form with the click of a button. The ability to quickly pivot and document disease information is critical in a quickly changing public health landscape.

Join the evolution of public health technology

Such highly configurable, unified, robust tools can be a game changer for public health jurisdictions in need of an affordable, extensible solution that meet all their needs. CasePointer can even work to further streamline systems that are already integrated with an HIE.

Within the United States, four states have already partnered with us to implement EpiTrax. We are helping them reduce unnecessary manual data processing costs, more effectively manage caseloads, and further automate their data workflows.

If this piqued your curiosity, contact us to learn more about CasePointer and how our team is evolving public health support with customized data solutions.

We would love to support your efforts to protect the well-being of people and communities you care about!

CSTE Conference 2023 Retrospective

2023-07-14T00:00:00+00:00

End Point is proud to have been an exhibitor at the 2023 Council of State and Territorial Epidemiologists (CSTE) conference in Salt Lake City, Utah.

We are grateful to have had the opportunity to showcase our public health software suite offering, CasePointer, to numerous state, tribal, territorial, and international epidemiologists.

The conference served as a meeting place to hear about the latest research in the fields of informatics and disease surveillance, and discuss the future of data management on state and national levels, with many talks exploring the technologies that will become future standards and practices.

The End Point booth was abuzz with visitors getting hands-on demos using the EpiTrax software as well as learning about the other aspects of the CasePointer suite, such as the Electronic Message Staging Area (EMSA), our new disease reporting portal, and the EpiTrax NMI module.

The CasePointer demo highlighted its capability of streamlining the management of epidemiological data with a user-friendly and highly customizable interface.

The CSTE conference provides a valuable opportunity to engage with epidemiologists and gain insights into the daily obstacles they encounter in data reception, management, and sharing. It offers a platform to learn about their strategies for overcoming these challenges within their respective jurisdictions.

One of the common topics that came up was tackling the challenge of file transfers using current protocols and systems in place. We were happy to share our successes using EMSA to customize how data is received and uploaded to EpiTrax, making transfers faster, more reliable, and easier to manage.

We look forward to further conversations with the visitors that stopped by our booth, and hope that you enjoyed the locally crafted chocolates and caramels and saved some for the trip home!

Are you interested in a demo of the CasePointer suite? Reach out to us at ask@endpointdev.com to set up a meeting.

Announcing CasePointer

2023-06-20T00:00:00+00:00

Photo by Diva Plavalaguna, Pexels license

End Point is pleased to announce CasePointer, the expanded branding of our line of public health systems and services. Before this we referred to it simply by the name of one of its components, EpiTrax.

The name CasePointer more appropriately reflects the broad scope of services we provide within the disease reporting and surveillance sector.

This change coincides with the launching of the dedicated CasePointer website at www.casepointer.com and our participation next week in this year’s conference of CSTE (Council of State and Territorial Epidemiologists) in Salt Lake City, Utah. We will be staffing a booth there on the exhibition floor. Come visit us!

Starting in 2008, End Point helped develop and maintain the TriSano open source disease surveillance system. In 2019 we migrated our customer, the Kansas Department of Health and Environment, from TriSano to a new disease surveillance system called EpiTrax, which was developed by the state of Utah, and is also open source.

This timeline shows those and other key points on our journey:

Due to the need for major additional features and capabilities, especially since the onset of the COVID-19 pandemic, End Point is now integrally involved with public health agencies in four states. For each of them we configured, deployed, maintain, and enhance the cloud hosting, relevant software, and databases to run those components they need, including:

the EpiTrax disease surveillance system
EMSA (the Electronic Message Staging Area)
the NMI (NNDSS Modernization Initiative) module
End Point’s Disease Reporting Portal
End Point’s merge tool
Mirth Connect

All of these interoperate harmoniously around the central EpiTrax application and database.

Our team is composed of public health professionals, software engineers, database specialists, and security experts. We are committed to our public health clients and their needs. We are here to help you help our communities and look forward to discussing the CasePointer approach with you and your team.

eCR Coordinator job opening

2023-05-23T00:00:00+00:00

We are seeking a full-time Electronic Case Reporting (eCR) Coordinator to provide high-level expertise in the validation and automation of eCR messages.

This position is responsible for establishing complete, up-to-date, timely, and automated reporting of individual-level data, and automation of incoming EHR data. Position is remote, in the United States only.

The person in this role will be responsible for coordinating and overseeing the eCR onboarding process for our clients. Additionally, the person will become our subject matter expert for the NNDSS Modernization Initiative (NMI) and how systems in place within EpiTrax can be configured to report through the NMI module.

Job responsibilities

eCR onboarding—40%
- Assist the on-boarding team with eCR reporters.
- Develop Structure, Dictionary, LOINC and SNOMED codes in EMSA.
- Assist in eCR message structure approval.
- Assist with EMSA management.
Troubleshooting—30%
- Issues found by the program epis and the LHDs.
- Issues found by the surveillance team.
- Create trouble tickets for issues.
Testing—15%
- Test the structure for incoming messages.
- Test new enhancement functionality.
- Test bug fixes.
Grant document development—5%
- Assist with determining next steps in development to be included in grants.
- Develop documentation for grants.
Process documentation—5%
- Thoroughly document changes and the processes put in place.
NMI—5%
- Work with state and CDC teams to determine MMG onboarding schedule.
- Map EpiTrax variables to PHIN VAD variables in the NMI module.
- Document all mappings and changes.

Skills required

Working knowledge of public health surveillance or EHR and healthcare data
Good communication skills, both spoken and written
Ability to analyze problems
Good testing skills
Ability to multitask and set priorities

Skills to have, or to learn on the job

In-depth knowledge of eCR messaging
In-depth knowledge of EMSA
In-depth knowledge of EpiTrax
Working knowledge of NMI

For some of our clients you will need to submit to and pass a criminal background check.

What work here offers:

Starting annual salary range: $50k–$85k
Paid holidays (10 per year) and vacation (2 weeks per year)
Health insurance subsidy and 401(k) retirement savings plan
Collaboration with knowledgeable, friendly, helpful, and diligent co-workers around the world
Freedom from being tied to one office location
Flexible, sane work hours
Annual bonus opportunity

Get in touch with us:

~~Please email us an introduction to jobs@endpointdev.com to apply.~~ (This job has been filled.)

Include your location, a resume, your LinkedIn URL if you have one, and whatever else may help us get to know you.

We look forward to hearing from you! Direct work seekers only, please—this role is not for agencies or subcontractors.

We are an equal opportunity employer and value diversity at our company. We do not discriminate on the basis of sex/gender, race, religion, color, national origin, sexual orientation, age, marital status, veteran status, or disability status.

How To Set Up pgTAP for Writing PostgreSQL Database Unit Tests

2023-04-12T00:00:00+00:00

In a previous blog post, my colleague Josh Tolley introduced the concept of using pgTAP, a set of Postgres functions designed for writing unit tests within the database. This post will serve as a supplement to Josh’s post, focusing on the process of setting up pgTAP for testing a Postgres database.

Installing & setting up pgTAP

Note: make sure you have Postgres installed on your system. If you don’t have it, you can follow the Postgres documentation to learn how to install it.

To install pgTAP for Postgres, you will need to follow these steps:

Download the pgTAP source code from its GitHub repository.
```
git clone https://github.com/pgtap/pgtap.git
```
Navigate to the pgtap directory.
```
cd pgtap
```
Install with make.
```
make && make install
```
Finally, connect to your Postgres database using psql or any other Postgres client and run the following SQL command to create the pgTAP extension.
```
CREATE EXTENSION pgtap;
```

Now you should have pgTAP installed and ready to use in your Postgres database. If you face issues with installation, visit the pgTAP documentation for further help.

Writing simple database tests with pgTAP

Test to check if a table exists:

SELECT plan(1);
SELECT has_table('public', 'your_table', 'Table your_table should exist');
SELECT finish();

Test to check if a column exists in a table:

SELECT plan(1);
SELECT has_column('public', 'your_table', 'your_column', 'Column your_column should exist in your_table');
SELECT finish();

Test to check if a function returns the expected result:

SELECT plan(1);
SELECT is(your_function(), expected_result, 'your_function() should return expected_result');
SELECT finish();

More pgTAP tests

Test to check if a trigger is triggered

Consider the following example. We have a table named employees and a table named audit_log. When a new employee is added to the employees table, a trigger named insert_employee_trigger fires and logs the new employee’s ID and creation timestamp in the audit_log table. Let’s test if the trigger gets fired and produces the expected outcome.

Create the tables.

CREATE TABLE employees (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255) NOT NULL
);

CREATE TABLE audit_log (
  id SERIAL PRIMARY KEY,
  employee_id INTEGER NOT NULL,
  created_at TIMESTAMP NOT NULL
);

Create the trigger and trigger function.

CREATE OR REPLACE FUNCTION insert_employee_trigger_function()
RETURNS TRIGGER AS $$
BEGIN
  INSERT INTO audit_log (employee_id, created_at) VALUES (NEW.id, NOW());
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER insert_employee_trigger
  AFTER INSERT ON employees
  FOR EACH ROW
  EXECUTE FUNCTION insert_employee_trigger_function();

Now, write a test using pgTAP to test the trigger.

-- Set the test plan
SELECT plan(1);

-- Prepare test data and perform operations that should fire the trigger
INSERT INTO employees (name) VALUES ('John Doe');


-- Check if the desired outcome of the trigger has occurred
SELECT is(
  (SELECT name FROM employees WHERE id = (SELECT employee_id FROM audit_log ORDER BY id DESC LIMIT 1)),
  'John Doe',
  'The insert_employee_trigger should have been fired and produced the expected outcome'
);

Test to check if a constraint is enforced

For this example, we’ll use the following two tables:

customers table with columns id and name.
orders table with columns id, customer_id, and amount
- There is a foreign key constraint between the orders table and the customers table on the customer_id column.

First, create the two tables and add the foreign key constraint.

CREATE TABLE customers (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255) NOT NULL
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INTEGER REFERENCES customers(id),
  amount INTEGER
);

Now, create a test script named fk_test.sql with the following content.

BEGIN;

-- Create test data in customers table
INSERT INTO customers (id, name) VALUES (1, 'Customer 1');

-- Declare the number of tests
SELECT plan(1);

-- Attempt to insert an order with an invalid customer_id
-- This should fail due to the foreign key constraint
SELECT throws_ok(
    'INSERT INTO orders (id, customer_id, amount) VALUES (1, 969, 100);',
    '23503',
    'insert or update on table "orders" violates foreign key constraint "orders_customer_id_fkey"'
);

-- Conclude the test and discard changes
SELECT finish();
ROLLBACK;

Organizing and naming your test files based on Test Anything Protocol (TAP)

Test Anything Protocol (TAP) is a convention for naming test files and organizing them within a project directory structure. The naming convention involves adding a numeric prefix to the test file name to indicate the order in which the tests should be run. For example, 00-test.sql is the first test file to be executed, followed by 01-another-test.sql, and so on.

The project directory structure usually includes a directory called t (short for “test”) under the project root directory. This t directory contains all the test files following the TAP naming convention.

Using this structure makes it easier to maintain and organize tests, as well as to run them in the correct order. This is especially important when tests depend on the results of previous tests, or when you want to ensure that tests are executed in a specific sequence.

Here’s an example of a project directory structure using the TAP-related naming convention:

my_project/
│
├─ src/
│   ├── function1.sql
│   ├── function2.sql
│   └── function3.sql
│
└─ t/
    ├── 00-test.sql
    ├── 01-another-test.sql
    └── 02-yet-another-test.sql

In this example, the project contains a src directory for the source code (database functions) and a t directory for the test files following the TAP naming convention.

Running your tests using pg_prove

Now that we have written some tests using pgTAP, let’s see how we can run them. We’ll use pg_prove, a utility included with pgTAP, to automate the process and get a summary of the results.

To run your tests with pg_prove, you’ll need to specify the name of the database you want to connect to and the path to your test file. For example, if your test file is located at t/00-test.sql and your database is named epitrax_db, you can run the following command:

pg_prove -d epitrax_db t/00-test.sql

When you run this command, pg_prove will execute all the tests in the specified file and print a summary of the results. The output will include the number of tests run, the number of tests passed, the number of tests failed, and any diagnostic messages or errors that were encountered.

Here’s an example of what the output might look like:

t/00-test.sql .. ok
All tests successful.
Files=1, Tests=5,  0 wallclock secs ( 0.01 usr  0.00 sys +  0.02 cusr  0.00 csys =  0.03 CPU)
Result: PASS

In this example, pg_prove ran one test file (00-test.sql) and executed 5 tests. All of the tests passed, so the output shows that the result was PASS.

If any of the tests fail, pg_prove will print a detailed report of the failures, including any error messages or diagnostic information. This can help you quickly identify and fix any issues in your code.

Using pg_prove to automate your tests can save you a lot of time and effort, especially if you have a large number of tests to run. It also makes it easy to integrate your tests into your build process or continuous integration pipeline.

pgTAP in EpiTrax

EpiTrax relies on Postgres and its functions, making pgTAP an ideal tool for testing the platform’s database functions, ensuring data integrity, and maintaining the robustness of the system. By utilizing pgTAP, EpiTrax efficiently validates various aspects of its database structure and behavior.

Conclusion

pgTAP database unit tests provide numerous benefits, including ensuring code quality and simplifying the testing process. This guide should serve as a starting point for setting up pgTAP, and we encourage you to explore the pgTAP documentation and read the aforementioned blog post on automated database testing with pgTAP for more in-depth information on writing and running tests with pgTAP. By integrating pgTAP in projects like EpiTrax, it’s possible to improve overall database performance, stability, and security.

Identifying Vulnerabilities in Code Using Horusec

2023-03-28T00:00:00+00:00

Horusec is an open source tool which, by orchestrating other security tools, identifies security flaws and vulnerabilities in source code. It puts all the possible vulnerabilities it finds into a database for analysis.

Currently, Horusec supports C#, Java, Kotlin, Python, Ruby, Go, JavaScript, TypeScript, PHP, Swift, C, Dart, Elixir, shell, Terraform, Kubernetes, nginx, HTML, and JSON. You can see an up-to-date list of supported languages in Horusec’s docs.

It can also be integrated with CI/CD to execute the scan every time a developer creates a pull request or merge request.

Horusec CLI Installation

Requirements: Docker, Git.

The easiest installation method listed in the docs is curling Horusec’s install script and piping it into bash:

curl -fsSL https://raw.githubusercontent.com/ZupIT/horusec/main/deployments/scripts/install.sh | bash -s latest

Be aware that there is risk to piping unseen commands into the shell like this: It can lead to unintended consequences and it is a bad security practice.

If a user blindly pipes the output of a website response to be run by a shell without fully understanding what each command does, they may inadvertently execute malicious code or perform actions that could compromise the security of the system.

To mitigate these risks, one solution is to use a virtual machine specifically set up for code scanning. This virtual machine should have no production data, no secret keys, and no other sensitive information. It should be used only for the purpose of scanning source code and nothing else.

To instead download an executable directly, as well as for instructions for different platforms, see the installation docs.

VS Code Extension

Horusec has a VS Code extension which is helpful for making complete code analysis with a single click.

Usage

Navigate to the application directory and run the generate command to make a configuration file called horusec-config.json which has a set of customisations:

cd /path/to/project
horusec generate

The start command executes the code scan throughout the repository, searching for possible vulnerabilities:

horusec start -p . --output-format=json --json-output-file=<filename>.json

All the detected vulnerabilities are stored in the named JSON output file.

Classification of Vulnerabilities

Horusec may identify (or, as the docs say, accuse) possible vulnerabilities that aren’t vulnerabilities at all. Possible vulnerabilites need to be classified to sort out those that are wrong.

Here are the classification types from Horusec’s docs:

False positive: Vulnerability found is wrong, because it is accused in a test file or it is not a vulnerability in fact, and is safe code.
Accepted Risk: Vulnerability that was accused, but at the moment, you don’t have the option to correct it, so it is classified as an accepted risk to not raise alarms in future runs.
Corrected: Vulnerability that doesn’t exist and can be considered as corrected.
Vulnerability: A possible security problem found and accused by the analysis.

The hashes to be ignored can be added to the configuration file, horusec-config.json:

{
  ...
  "horusecCliFalsePositiveHashes": [
      "f9e5abe187ad4246daa4e9113e0a11a175347e793fbc40acd7663df67b2f89d2",
      "878c35116d043311403a0a2e8a64f2c8d00479a1c23373dcd50372ff35e123c8"
  ],
  "horusecCliRiskAcceptHashes": [
      "5c9af42834ca77233a0e7afc98df317fb0e6041ea69a109754f278331039f844",
      "b494003277bcd7792390f032ba39e9a860da66ddb1ccfcd8a581978eab744561"
  ],
  ...
}

Ignore Files

To entirely ignore a file or certain paths under the directory, add the paths to the configuration file:

{
  ...
  "horusecCliFilesOrPathsToIgnore": [
      "**/tmp/**",
      "**/.vscode/**"
  ],
  ...
}

Code Scanning in EpiTrax

The use of a code scan tool has become an integral part of our work with the EpiTrax disease surveillance system for public health.

By integrating Horusec into our software development process, we have been able to identify potential security vulnerabilities, code quality issues, and other problems before they can cause any significant harm.

Moreover, it has helped us reduce the overall cost and time associated with bug-fixing and maintenance tasks, making our projects more efficient and effective. By automating the scanning process, we can identify problems quickly and accurately, allowing us to prioritize and address the most critical ones first.

By leveraging the power of code scans, we can ensure that our code is of the highest quality, and our projects are as secure and reliable as possible.

Special thanks to my colleagues Kürşat Kutlu Aydemir and Edgar Mlowe for their insights and feedback on this blog post.

Nevada State EpiTrax Launch

2022-12-01T00:00:00+00:00

Photo by Adrien Drj

If COVID-19 has taught us anything, it is that the public health landscape can change quickly, and we need a disease surveillance system that is adaptable to support our ever-evolving climate.

Having access to surveillance data for purposes of contact tracing, following trends, and monitoring evolving disease conditions allows health departments to be agile in response. This is a critical component in providing communities with a robust public health infrastructure.

For all these reasons and many more, the State of Nevada embarked on a journey to migrate away from their surveillance system, NBS, to the open-source EpiTrax system created by the Utah Department of Health. Ultimately, the Nevada decisionmakers made this change because they needed to be on one state-wide system and wanted autonomy to customize the system.

Nevada had been exploring this change for a while but due to unforeseen problems the window of time for implementation was incredibly narrow. In the first four months of End Point’s partnership with Nevada, the team was able to accomplish what was believed to be impossible in so short a time.

The Four Month Sprint

Some of the major milestones on the way to the new EpiTrax system included the following:

Building Out Custom Forms

EpiTrax is composed of core and form fields. Core fields are consistent across all conditions. Form fields allow jurisdictions to customize the data system to collect data specific to the needs of their area or the reporting requirements of their funders.

In Nevada, we framed these forms to collect the data outlined in the Message Mapping Guide set forth by the CDC. Collecting form data is the first step in configuring the system to use the NMI module which allows for seamless reporting.

Configuring the System

EpiTrax is an intuitive system that is highly configurable. For example, EpiTrax will show specific fields by condition or condition type, allowing an investigator working on a COVID record to only see vaccines and treatments for COVID which reduces time and error in data entry.

These parameters need to be defined and set up in the system for a large number of items. End Point was able to provide templates and examples from other states and having a framework for this documentation was vital.

Testing the System

Testing sounds easy: “You just log in and make sure the functionality is there.” However, to adequately test a new environment with multiple jurisdictions and a variety of user groups takes time, attention, and follow-through.

Nevada worked with End Point to bring in users from across the state to test both the functionality of the system and disease-specific variables. Then the test failures were discussed daily and the programmers provided options and support for resolving problems. After modifications were made to the environment the second round of testing was implemented.

Given the tight window of time to launch EpiTrax we were building (testing) the ship as we were sailing it and this was only possible given the commitment of everyone on the team.

Training

You cannot launch a statewide system without training the end users, answering questions, and providing a mechanism for ongoing support. End Point provided countless trainings ranging from general use to administrative functionality of the system, and also provided Nevada with a user manual template that they were able to build on and grow to fit their needs.

Electronic Messaging Staging Area (EMSA)

EMSA is an application that processes lab messages and delivers them into EpiTrax. The delivery of these messages is what creates the record for investigation in EpiTrax. Since this was a new process and system to Nevada, End Point worked with the Nevada team to configure the various vocabularies and rules.

Going Live

On September 12 EpiTrax officially launched in Nevada. End Point staff were there both in person and with a consistent virtual presence to work through user concerns, login issues, and workflow questions.

Conclusion

The customization and scope of EpiTrax are crucial components in allowing Nevada to optimize work processes, streamline the multiple data systems being used into one cohesive system, and greatly reduce redundancy.

While switching systems can seem like a daunting and time-consuming task, so is continuing to operate in crisis mode with a system that stops your team from being dynamic. Any change for the better involving hundreds of people and a lot of data is going to take time, normally much longer than 4 months.

The partnership between Nevada and End Point during this fast-paced launch has better positioned the state to use their data to support well-coordinated public health responses to emerging diseases or outbreaks.

CSTE Conference EpiTrax retrospective

2022-06-29T00:00:00+00:00

Last week we were in Louisville, Kentucky for the CSTE Conference. End Point staffed a conference booth to represent the EpiTrax public health surveillance system to a wonderful group of public health experts.

You can read some background about the conference and CSTE in our earlier blog post announcing our plans.

We really enjoyed meeting new friends in person after two years of canceled events due to the pandemic. We spoke with staff from health departments and disease surveillance teams from several state and local jurisdictions, as well as with experts from the CDC and other software and service vendors.

One of the highlights was going around to meet other people staffing booths at the conference. It charged us up to see and hear about all of the interesting and innovative things going on in the public health space at a time when there is so much that needs to be done. We were particularly struck by the efforts being made in onboarding and distributing ELRs and eCRs, areas where the Electronic Message Staging Area (EMSA, which we deploy and support) can complement and enrich those activities.

The open-source disease surveillance and reporting software EMSA and EpiTrax both enjoyed well-deserved attention as we demonstrated them to numerous groups seeking better solutions to serve people in their jurisdictions. People were very interested in the functionality EpiTrax has for case management, encounters, and NMI reporting.

Of course there is a lot more we could say about EpiTrax and EMSA. So, if you didn’t find us at the conference or if you are interested in what EpiTrax and EMSA can do, contact us here online. We are happy to give you a demo!

End Point booth at CSTE 2022 conference

2022-06-09T00:00:00+00:00

Photo by David Barajas

Converging on Kentucky

We are excited to announce that End Point will be attending the CSTE (Council of State and Territorial Epidemiologists) conference in less than two weeks!

We will be running a booth during the 3-day conference in Louisville, Kentucky from Monday, June 20 through Wednesday, June 22, 2022. Our crew is scheduled to include Steve Yoman, Linda King, Ben Goldstein, and me.

Please come visit us in booth #35 to learn more about the EpiTrax Disease Surveillance System and EMSA (Electronic Message Staging Area). Now is the time for public health entities to turn to modern systems to perform disease surveillance, automate the ingestion of electronic laboratory records (ELRs) and electronic case reports (eCRs), report to the CDC through NMI reporting methods, track outbreaks, perform contact management, and do it all with a highly configurable system.

Our booth will feature a VisionPort Mini to showcase EpiTrax and EMSA! VisionPort is our product combining hardware and software to give organizations the ability to create dynamic, shared immersive multimedia experiences. We are delighted when we have opportunities like this to use VisionPort to inform conference attendees about our own offerings such as EpiTrax and EMSA.

We will be happy to demonstrate EpiTrax to you there. Here is a preview screenshot of the application’s disease outbreaks list view:

CSTE

What is CSTE? The Council of State and Territorial Epidemiologists is an organization that works to advance public health policy and epidemiologic capacity. They also provide information, education, and developmental support of practicing epidemiologists in a wide range of areas as well as expertise for program and surveillance efforts.

Here are some of the conference sessions we plan to attend:

Monday, 2:00–3:15 PM: In-Person Concurrent Breakout Sessions: Surveillance / Informatics I: Not Your Grandma’s Old-Fashioned: Data Modernization
Monday, 5:45–6:30 PM: Virtual Concurrent Roundtable Sessions / Networking Surveillance / Informatics II: Electronic Case Reporting and Public Health Agencies—Needs and Directions
Tuesday, 8:45–10:00 AM: In-Person Concurrent Breakout Sessions: Surveillance / Informatics I: Taking off the Blinders: Innovative Methods for Detection and Surveillance
Tuesday, 5:45–6:30 PM: In-Person Concurrent Roundtable Sessions / Networking: Surveillance / Informatics I: CSTE National ELR Workgroup Meet and Greet
Wednesday, 7:30–8:15 AM: In-Person Concurrent Roundtable Sessions / Networking: Surveillance Informatics I: National Notifiable Disease Surveillance System (NNDSS): A Comprehensive Review

Come see what End Point and EpiTrax can do for you! We would love to meet with you in person, a privilege we don’t take for granted these days.

Or if you can’t make the conference, contact us here online.

Data Reporting with EpiTrax

2022-02-16T00:00:00+00:00

Early COVID-19 form-building in Kansas

In March of 2020, many states struggled with disease surveillance systems that were not ready for the COVID-19 pandemic. States were forced to wait lengthy periods for their vendors or systems administrators to stand up customized forms for COVID-19 investigations.

State of Kansas informatics staff were able to configure their form within a matter of hours. When the first COVID-19 records came rolling in, the state was ready to go. The Kansas Department of Health and Environment (KDHE) was using EpiTrax, a National Electronic Disease Surveillance System (NEDSS) compliant application created by the state of Utah.

EpiTrax contains a powerful form-building utility that was easily customizable, allowing jurisdictional users to create forms for investigation and reporting purposes. Users could configure questions and value sets based on configurable lists, cutting down on free-text entries and ensuring data quality. Forms could be attached automatically or manually and assigned to specified agencies and conditions.

Screenshot of the form builder

December 2021 updates

Flash forward to December 2021. State of Utah developers rolled out an update to the EpiTrax form builder utility. All the previous version features, such as quick configurability and use of lists, remain, with additions to make investigators’ and informaticians’ lives easier. While the old form module was configurable, it did have room for improvement.

The latest updates include question banks and value set banks that can be used across disease forms. This option allows for consistency across all forms and in reporting and analyzing data. State jurisdictions use system forms and core fields to pull data for CDC reporting purposes. The CDC NMI message mapping guides (MMGs) are the new generation of data transfer. These MMGs often require repeating fields, one option now available in the EpiTrax form builder.

Users can configure forms based on the guide formats. Forms can be shared across conditions, aiding in the use of forms across comorbidities. The new form builder allows users to relate fields to existing core fields and sections. This allows the system to be more flexible and aids in creating a better flow in the user interface. The question formats accommodate many data types including address, phone and dates.

Screenshot of the field type selector

Utah’s experience

End Point staff discussed the new form builder with the Utah Department of Health’s (UDOH) Health Informatics Program Manager, Rachelle Boulton. Rachelle related that UDOH was able to add form fields and configure those fields in the EpiTrax NMI Module within one day when the CDC recently released version 1.1 of their COVID-19 MMG. They reached out to the CDC on December 13th to announce their readiness and were the first state to onboard on December 29th.

She attributed the quick turnaround to the new form builder’s ease of use and to their use of the NMI Module. Rachelle said, “The form builder gives us the opportunity to collect data for CDC reporting requirements and allows us to make changes quickly and send data out quickly.”

When asked what she likes most about the new form builder, Rachelle stated that she appreciates the new question and answer banks and their ability to quickly and efficiently create new forms that are appealing on the user interface.

Screenshot of the question manager

Summary

End Point is collaborating with our current clients to migrate data from the old form builder to the new. We are excited to help them use the new functionality.

Along with this effort, we hope to build a form repository for future clients using the new form enhancements which will allow users to quickly onboard for CDC MMG reporting. These new forms would accommodate any needed state workflow changes or additions and would allow states to implement EpiTrax in a timelier manner.

When asked if she had anything else to add, Rachelle said, “I really like that we try to make EpiTrax not just a surveillance system, but a change management system. We embed these changes in the workflow to make users’ lives easier.”

We at End Point agree with Rachelle. We look forward to the future of EpiTrax and what we can do to help it continue to improve moving forward.

EMSA: Electronic Messaging Staging Area

2020-10-30T00:00:00+00:00

Photo by Lee Roberts, CC BY-SA 2.0

End Point has been involved with developing disease surveillance software for over a decade. One component of that work is EMSA, short for “Electronic Messaging Staging Area”.

The EMSA system we’re currently using was developed by a consortium of states led by Utah, Kansas, and Nevada. It is a PHP web application and can be hosted in the cloud or on-premises as you would any other PHP application.

EMSA:

Is an ingest system for HL7 or CSV-formatted lab reports from doctor offices, labs, and other official reporting groups.
Allows exporting XML output to your disease surveillance system.
Is a web console for managing messages.
Allows you to see messages that are malformed.
Has configurable rules for disease types and message routing; some messages may go directly into a surveillance system while others may be stored for later.
Has configurable “automated workflows” to validate message information and perform tasks.
Can be connected to a BI (Business Intelligence) tool for reporting, or the database can be queried directly.
Works with integration packages like Rhapsody to bring in data from other systems.

End Point has also made custom modifications to EMSA allowing address validation for incoming messages.

EMSA can be deployed along with EpiTrax, the open source tracking system, or as a standalone application connected to a different disease surveillance system.

Benefits of EMSA

Aside from all the features mentioned above, EMSA as an open-source solution brings other benefits:

Reduced cost: Other than development and consulting to help set it up, there are no ongoing licensing costs.
Designed to work as part of the open-source EpiTrax disease surveillance system.
Participating in the open source community that is growing in the healthcare industry.

Help is available!

Interested in talking to us more about EMSA for your disease tracking? Reach out today.

References

Emily Roberts, Rachelle Boulton, Josh Ridderhoff, Theron Jeppson. “Automated Processing of Electronic Data for Disease Surveillance.” Online Journal of Public Health Informatics, 10(1):e2, May 22, 2018. https://doi.org/10.5210/ojphi.v10i1.8903

COVID-19 Support for the Kansas Department of Health and Environment

2020-09-14T00:00:00+00:00

Kansas’s existing EpiTrax system

End Point has worked on Kansas’s disease surveillance systems since 2011. In 2018 we migrated them from their legacy TriSano application to the open source EpiTrax surveillance system created by Utah’s Department of Health. The new EpiTrax system had been in full production for about eight months when COVID-19 cases started to grow in the United States.

COVID-19: Help needed

In March 2020, the Director of Surveillance Systems at the Kansas Department of Health and Environment (KDHE) asked us at End Point to create a web-based portal where labs, hospitals, and ad-hoc testing locations could enter COVID-19 test data. While systems existed for gathering data from labs and hospitals, they needed a way to quickly gather data from the many new and atypical sites collecting COVID-19 test information.

Our approach

Since the portal was intended for people who were unfamiliar with the existing EpiTrax application, we were able to create a new design that was simple and direct, unconstrained by other applications. It required a self-registration function so users could access the system quickly and without administrative overhead, and users needed to understand how to use it without extensive training.

We at End Point agreed to create the portal and dashboard for test results reporters immediately, while planning for later development of additional administrative functions. We used Ruby on Rails and Vue.js to build the portal due to their usefulness for rapid development. The Vue.js front-end JavaScript framework allowed us to quickly put together the portal UI and integrate it with the Rails back-end web services.

Once approved, our team got to work setting up the environment, developing the portal application, and rigorously testing it.

Here are some screenshots of the application:

Portal home page

User registration page

Dashboard

Reporters’ entry screens

The portal was launched on April 30.

Contact tracers support

After the EpiTrax portal for COVID-19 was up and running, Kansas made urgent plans to hire 400 contact tracers. We updated the EpiTrax portal to accommodate this new type of user, showing contact tracers only the data they are authorized to view, while providing them the ability to make limited contact record updates and to create tasks. The project is ongoing, and eventually will be used for all diseases.

EpiTrax for Missouri

Late this Spring, after learning of Kansas’s use of the EpiTrax platform and the powerful capabilities that it provides to the Kansas public health system, the State of Missouri reached out to us at End Point to request their own EpiTrax implementation. End Point and Missouri quickly came to agreement, and since July we have been working together build out a full production EpiTrax surveillance system for them.

Contact us!

To discuss an EpiTrax project, contact us. Our expert team is ready to help you meet your requirements.