The next step in Medical Diagnostic Exchange, OpenCDX provides an open source solution for diagnostics, medical records and questionnaire exchange. OpenCDX is designed to be a demonstration module on how to perform this exchange of information.

Microservices Architecture

This architecture is a software design approach where applications are composed of small, independently deployable services, each focused on a specific business function and communicating with each other through well-defined APIs. These services are developed, deployed, and managed independently, allowing for scalability, flexibility, and resilience. Each service is built around a single responsibility, enabling teams to work on different services simultaneously and deploy updates without impacting the entire system. This approach fosters agility, facilitates continuous integration and delivery, and promotes rapid innovation and iteration in software development.

Protocol Buffers

Using Protocol Buffers (Protobuf) entails defining data structures and services in a language-agnostic manner using a simple interface description language. This specification facilitates efficient serialization, enabling data to be encoded in a compact binary format, reducing both transmission overhead and processing time. Protobuf offers strong backward and forward compatibility, supporting seamless evolution of data formats without breaking existing clients or services. Additionally, it provides robust support for multiple programming languages, ensuring interoperability across diverse technology stacks. By leveraging Protobuf, developers can streamline communication between microservices, enhance performance, and maintain compatibility in distributed systems.

REST

Utilizing a Representational State Transfer (REST) API involves designing an architecture where resources are identified by unique URIs, and standard HTTP methods such as GET, POST, PUT, and DELETE are employed to perform CRUD operations. This specification fosters a stateless client-server communication model, enhancing scalability and reliability. Data is exchanged in lightweight formats like JSON or XML, promoting interoperability across various platforms and programming languages. REST APIs adhere to principles of simplicity, scalability, and evolvability, facilitating easy integration and maintenance. By adopting RESTful practices, developers can build robust, loosely coupled systems that enable efficient interaction between clients and servers over the web.

Discovery, Config and Gateway

Utilizing a Discovery, Configuration, and Gateway server in a microservices architecture entails deploying a centralized system responsible for service discovery, dynamic configuration management, and API gateway functionalities. The Discovery server facilitates automatic service registration and discovery, enabling seamless communication between microservices regardless of their locations. The Configuration server manages dynamic configuration properties, allowing services to adapt to changing environments without redeployment. Additionally, the Gateway server serves as a single entry point for client requests, handling routing, authentication, and load balancing, thereby abstracting the complexities of the underlying microservices infrastructure. This specification enhances scalability, resilience, and maintainability in distributed systems, enabling efficient service communication and management.

Monitoring

Monitoring in a microservices architecture involves comprehensive tracking of API call spans, logging, and metrics to ensure system health and performance. This specification entails implementing distributed tracing to capture the lifecycle of API calls across microservices, enabling visualization and analysis of request flows. Logging mechanisms should record relevant events and errors across the system, facilitating troubleshooting and debugging. Additionally, metrics such as response times, error rates, and resource utilization should be collected and aggregated to provide insights into system performance and behavior. By integrating these monitoring components, organizations can proactively identify issues, optimize performance, and maintain the reliability of their microservices infrastructure.

Features

Protobuf – Java SDK

OpenCDX-Proto generates a Java SDK that provides both the “server” and “client” interfaces for OpenCDX based on the protobuf files.  This is a direct implementation of the protobuf files into Java by the Java Protobuf Compiler.  

Protobuf – Java Spring SKK

OpenCDX-Client generates a Spring SDK that provides the “client” interface based on a Spring library. This provides a set of services for each RPC Service in OpenCDX for communication with.  Call Credentials are required to provide the authorization token required for OpenCDX.  Configuration is required such as the trustStore to use, and to enable tracing.  In addition each client must specify the server, port and if enabled.

opencdx:
  client:
    trustStore: /certs/opencdx-clients.pem
    tracing:
      enabled: true
    audit:
      server: audit
port: 9090
enabled: true

Audit System

A process designed to record a number of different actions that occur within the OpenCDX system.  Implementation is based on a message system receiving audit messages that should be recorded.  Events that require tracking

1. User Login/Logout/Fail
2. Configuration Changes
3. Password Changes
4. PHI  (Create, Update, Access, Delete)
5. PII (Create, Update, Access, Delete)
6. Questionnaire / Forms

A system for creating, updating and serving  questionnaires.  The front end would utilize a Form Builder for building these forms, and also a Form Render for displaying and accepting the answers to a form from a user.  The questionnaire is stored with the user’s response for future identification of the questionnaire answered.  Results can be generated from TIKAR with ANF statements to represent the answers.

Once user answers are submitted the form is sent to the OpenCDX Classification system for processing.

Neural Processing / Rules Engine

OpenCDX-Classification a system designed to have an analyzer for processing of Connected Tests, and Questionnaires in order to provide a system for analyzing and recommending the next course of action.  The analyzer may consist of a Rules Engine, Machine Learning, Deep Learning or other system for performing this analysis.  The classification system pulls together relevant information for the analyzer, such as patient information, questionnaire answers, connected test details, and any attached media files.

Media

OpenCDX-Media for processing all files pushed to OpenCDX.  A media record is created, and an identifier for the file is provided.  With the identifier the file can  be uploaded, and then later downloaded.  

Communications

OpenCDX-Communications a system for creating, and updating messages to be sent to a user and/or patient. A notification event is created, this defines the message types that should be sent, and the required fields needed for these messages, when this event is triggered.  Three types of messages are allowed these are:

• Email
• SMS
• In-System Message

Notification system can be set with different levels of priority:

• Immediate – The messages are attempted to sent upon receipt of the Event, if it fails then it is attempted again with the “high” priority notifications.
• High – Every minute a check is performed looking for any unsent “high” or “immediate” notifications events that have not been sent and then attempted.
• Medium – Every hour a check is performed for any unsent “medium” notifications.
• Low – Every three hours a check is performed for any unsent “low” notifications.

A notification event may have one or more of the message types associated with it.  Each message type is tracked independent of each other on whether they have been sent.  A count for each attempt is tracked and after five attempts the message is failed.

Health Service

OpenCDX-Health tracks and maintains numerous records based on a patient’s health.  These records include the following:

• Patient Record
• Heart Rate
• Blood Pressure
• Height
• Weight
• Medications
• Medication Administration
• Allergies
• Vaccines
• Connected Tests
• Doctor Notes
• Family History *
• Medical Conditions *

This service also provides the ability to lookup providers via the NPI Registry , and medications via openFDA.  In addition the ability to transfer a patients medical records*.

TINKAR

OpenCDX-Tinkar provides an API for accessing DeLoitte’s Tinkar database for looking up Concepts and child concepts.  

Logistics

OpenCDX-Logistics provides an API for tracking inventory items such as Devices, and Testkits.  Along with an API for demonstrating how to “ship” a test to a user, with a “mock” interface for UPS, FedEx, USPS, and Doordash.

IAM

OpenCDX-IAM is used for tracking users and system accounts.  This includes the ability to create Organization and Workspaces for those users. This enables users to be assigned roles and who has access to a patient’s information.

Interfaces

Articles

Github