ME-TA

Health technology Assessment

1. Our experience from doing HTA

The assessment of cost/benefit is dependent on factors such as treatment options, national best practices and most importantly the patient group and cost per responder.

With the development of new, highly specialized treatments, healthcare systems must balance costs and identify the right individuals to treat. Collaboration of HTA between countries have already been established, but with more formal initiatives such as the #EUnetHTA with the Joint Clinical Assessment (JCA) process this is becoming increasingly regulated. Relevant for the pharmaceutical industry to follow and prepare for. The regulatory submission is no longer the last step in drug development.

HTA statistical package for Payer submissions has been a focus area for ME-TA the last couple of years. Our approach to the statistical HTA packaging has matured over the past 10 years.

We typically start with generalizing the analysis results from the CSR population to ensure consistency before the analyses are generalized to various populations, outcomes, subgroups, pools (studies and the combination of studies), statistical analysis methods and estimands.

Typically you end up with 15 different programs mainly because of different statistical methodologies which needs to be run foreach combination of population*pool*subgroup*outcome. In SAS this is a good use case for a macro. It is also a good use case for using a metadata driven approach.

Because we are a CRO we think a lot about how we deliver our SAS programs. One self-contained program (no macros or formats used) pr. output is a nice way to deliver our documentation. It's easy to migrate to almost any customer system. Customers can run the programs in parallel and the failure of one program (because of a convergence issue in a subgroup) does not affect the others.

To align client expectations during meetings, we first created human readable metadata. A SAS macro read and converted it to a single SAS program per output. It succeeded. However, despite the programs' success in providing a single output and being self-contained, we did not like the way they looked. With many %let statements in the program's top section the program was too generic and difficult to read. Also, a relatively complex SAS macro was used to generate the programs which would be hard to maintain.

Finally, we have tried using Python to generate the SAS programs on the same metadata. We used a templating language called Jinja which primary goal is to make it easy to create files. This helped a lot with the readability of the generated SAS programs which now are nicely formatted without including any macros and with all formats used being defined in the program.

Because this approach generates a lot of programs, which may run for a very long time based on the statistical model in question, we also needed a way to only generate the programs where actual metadata was changed, not generate all each time, this was also relative straight forward using Python.