bawmedical / clinical-calculation-api Goto Github PK

there's a Gem for that

https://www.qcancer.org/

this layer should

• proxy all requests to the API
• serve as a support centre with documentation in Swaggery form
• handle API keys
• handle rate limiting and quotas
• handle billing if that should become necessary

clinical_calculator_api/calculators/obesityprevalenceuk/data/obesity&excess_weight_by_electoral_ward.json

missing field "recp_number_obese" when the CSV was parsed to JSON
simple omission error
not critical but needs fixing at some point by re-parsing the CSV

currently an example entry is:

"Burn Valley": {
    "ward_code":"E05008942",
    "la_code":"E06000001",
    "la_name":"Hartlepool",
***missing field***
    "recp_%_obese":"8.8%",
    "recp_obese_95%_confidence_limits_lower":"6.2%",
    "recp_obese_95%_confidence_limits_upper":"12.3%",
    "yr6_number_measured":"314",
    "yr6_number_obese":"69",
    "yr6_%_obese":"22.0%",
    "yr6_obese_95%_confidence_limits_lower":"17.7%",
    "yr6_obese_95%_confidence_limits_upper":"26.9%",
    "recp_number_measured":"341",
    "recp_number_excess_weight":"78",
    "recp_%_excess_weight":"22.9%",
    "recp_excess_weight_95%_confidence_limits_lower":"18.7%",
    "recp_excess_weight_95%_confidence_limits_upper":"27.6%",
    "yr6_number_measured":"314",
    "yr6_number_excess_weight":"123",
    "yr6_%_excess_weight":"39.2%",
    "yr6_excess_weight_95%_confidence_limits_lower":"33.9%",
    "yr6_excess_weight_95%_confidence_limits_upper":"44.7%"

try something like NG12 https://www.nice.org.uk/guidance/ng12

Moving to using Rails for Clinical Calculation API 2.0 is I believe a positive step in that it makes the whole codebase more maintainable by external developers, and more likely to attract external contibutions

Individual calculators will simply be a controller, which either runs its own code and returns JSON, or runs an external library and returns JSON.

Yes, there are many other, more performant, frameworks I could use for this, in other languages, however I also think the readability and relatively understandable syntax of Ruby will be better for clinicians who would like to get involved.

• Implement msoaobesity calculator
• Complete clinical_calculator_frontend
• Tidy up codebase
  • Work out a better way of subclassing CalculatorLoader and HelperLoader, as they both implement some of the same functionality
  • Make parentheses usage consistent
• Change file names to use snake case (calculatorloader.rb -> calculator_loader.rb)
• Write unit tests
  • Add .travis.yml for Travis CI
• Fix all RuboCop offences
• Create example calculator code
  • Fix grammar and spelling
• Create docker container with management tools
• Add an analytics platform (see Tyk)
• Find a better way to handle not_found
  • Possibly abstract response generation to it's own method
• Add configuration file
• Add versioning to system
• Add API versioning to calculators
• Add documentation endpoint
  • Add documentation method to CalculatorContext, allowing request fields to be documented
  • Add special documentation endpoint to access documentation for different endpoints
• Implement QRISK2 calculation (C implementation can be found here)
• Document calculator API and syntax
• Write RDoc comments for classes
• Update calculator style

class MyCalculator < Calculator
 def initialize
   # Set up all of your stuff here (e.g. load JSON files)
 end

 # Endpoints are named the same as their method unless otherwise specified
 #
 # GET /first
 def my_first_endpoint
   return "Hello, this is the first endpoint!"
 end

 # GET /my_second_endpoint
 def my_second_endpoint
   return "Hello, this is the second endpoint!"
 end

 endpoint :my_first_endpoint, name: :first
 endpoint :my_second_endpoint # Name is not required
end

https://www.macmillan.org.uk/about-us/health-professionals/programmes-and-services/prevention-early-diagnosis-programme/cancer-decision-support-tool.html