Rust's Universal Medical Toolkit is a toolkit being developed to put together a set of tools and libraries to facilitate communication and automation in medicine.

• To create a simple toolkit with the necessary libraries, dependencies, and utilities for managing bridging HL7 V2 Medical IT infrastructure to FHIR based systems.
• Also, I would like the project to be accessible to hospitals to enable interoperability between systems. I plan to package it for package managers and containers.
• The toolkit will focus on increasing security and simplicity with the first step taken by starting the project using Rust.
• The toolkit shall foster reliability and will make attempts to be as strictly standards compliant as possible. Strictness may be relaxed later once the project sees use in the wild.

• Toolkit Core Library
  • UTF-8 Support
  • Small String Optimization Support
  • String Encodings to UTF-8 Support
  • RegEx Support
  • Memory Cache Support
  • Network Core library
  • JSON Serialization Support
  • Cryptographic Adapters
  • Commandline Standard Argument Interface
  • Enable STDIN|Pipe Functionality
  • Toolkit Core Tests
  • Async support
  • Multithreaded support
  • SQLite Bindings
  • PyO3 for extending message processing
  • SIMD support?? [Maybe]
• Healthcare Web Dashboard Library
  • Server Side Rendering.
  • High Performance Web framework (see MedicalMasses L.L.C.'s website which uses this framework).
  • Simple old-school organization of web project via the Askama templating engine.
  • Mechanism for component definition.
  • Mechanism for rendering components that is familiar to React users while being based on pure SSR.
  • Mechanism for registering user made components (can be used to override library components).
  • Mechanism for statically defining web page layout in Rust.
  • Mechanism for rendering pages.
  • Mechanism for bundling CSS via component level and as part of a global minified bundle generated on first run.
  • Usage of HTMX as a very light JS front end to extend HTML tag functionality.
  • Mechanism for falling back to local copies of HTMX and FontAwesome as needed if CDNs are down.
  • Features exposed via Rust macros.
  • Tests
  • Fuzz Targets
• HL7 v2 Library
  • Parser
    • HL7 v2 Sanitize Segment Separator (\n\r, \n) => \r
    • HL7 v2 Escape Sequences Support
    • HL7 v2 Repeating Field Support
    • HL7 v2 UTF-8/Unicode Support
    • HL7 v2 Encodings to UTF-8 Conversion
    • Hl7 v2 Message to JSON Serialization Support
    • HL7 v2 Component Searching (<segment>(<subgroup>)<field>[sub_field].<component>)
    • HL7 v2 Primitive Types
    • HL7 v2 Component Optionality
    • HL7 v2 Complex Types (aka structs)
    • HL7 v2 Tables + Validation
    • HL7 v2 Complex traits
    • HL7 v2 Base Message to HL7 Type casting
    • HL7 v2 Custom Message Overrides
    • HL7 v2 Message Validator
    • HL7 v2 Message to ASCII Message Generation
    • HL7 v2 Message Python Bindings
  • MLLP
    • Protocol
    • Client
    • Server
    • Tests
  • Fuzz Targets
• MLLP Interfaces
  • HL7 v2 Endpoint Interface utility
  • HL7 v2 Client Interface utility
  • HL7 v2 Tests
• HL7 v2 Parser
  • Basic parsing of v2 message from pipes to V2Message type.
  • Basic generation of v2 message from V2Message to pipes format.
  • Allow reading of JSON or HL7 messages
  • Tests
  • Fuzz Targets
• HL7 v2 to FHIR Conversion
  • HL7 v2 to FHIR Basic Mapping
  • HL7 v2 to FHIR Custom Mappings
  • HL7 v2 to FHIR Conversion utility
  • HL7 v2 to FHIR Conversion Tests
• HL7 v2 to DB [Maybe]
  • HL7 v2 Python bindings
  • HL7 v2 to DB utility
  • HL7 v2 to DB Tests
• HL7 v2 Dashboard [Maybe]
  • HL7 v2 Message History DB
  • HL7 v2 Dashboard service
  • HL7 v2 Dashboard Tests
• HL7 FHIR Interface
  • HL7 FHIR CRUD
  • HL7 FHIR Client
  • HL7 FHIR Client utility
  • HL7 FHIR Tests
• HIFLAMES utility => HL7 Interface - FHIR Loader And Message Exporter System
• Package [Maybe]
  • Fedora
  • Ubuntu
  • Arch
  • Docker

• Best Open Source and Best Security

• Create an issue ticket if it has not been done.
• Fork this repository.
• Create your own feature.
• Include the ticket number in feature branch name.
• Open PR when ready to submit code for review.
• Include an appropriate set of tests to help protect against regressions. I don't require full TDD, but some basic testing is useful. Some of those tests should be doctests if applicable (introducing new APIs).

If coming from SIIM, welcome! Follow the steps above to start contributing.

Any contributions are very appreciated.