Oral Solid Dose – Unit Operations

Granulator at an OSD Plant in Vietnam

Hello good people of the world! Continuing the series on oral solid dosage forms, today we’re going to talk about unit operations typical in a oral solid dose manufacturing process.

Typical OSD processes may include some combination of weighing/dispensing, material transfer, blending, granulation, drying, milling/sieving, compression, encapsulation, and coating. Some considerations around each step may include:

1. Weighing/Dispensing: includes sampling for quality purposes. Materials to be sampled typically include: APIs, excipients, primary and secondary packaging, cleaning agents. Sampling areas must be protected from contamination.
2. Material Transfer: material flows should be documented and reviewed, with the intention of minimizing any contamination.
3. Blending: materials are typically blended to ensure a uniform composition, prior to downstream process steps. Many methods exist, including: tumble blending, bin blending, and agitator mixers.
4. Granulation: granulation is the process of combining particles into a granule. Many methods of granulation exist: wet massing/extrusion, high shear, spray, speronization, and hot melt extrusion, for example.
5. Drying: the purpose of the drying step is to remove any excess moisture from the drug product. Drying methods include: tray , fluidized bed, and spray drying.
6. Milling/Sieving: the purpose of this process step is to reduce granule size to conform to specification. Some methods include: impact/hammer mills, conical mills, and oscillating horizontal screens.
7. Compression: compression is used to create tablets.
8. Encapsulation: encapsulation is used to create capsules.
9. Coating: coating is used to apply a coat to tablets

In the next post we’ll cover supporting equipment and quality systems. What process steps do you use in your OSD process? Comment below!

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Advertisement

Oral Solid Dose – Equipment

Hello good people of the world! Today’s post is the third in the series covering the commissioning, qualification, and validation of facilities, systems, and equipment involved in the manufacture of oral solid dose (OSD) products. This post covers the equipment used to manufacture these products.

Considerations include: materials of construction, sampling, and cleanability.

1. Materials of Construction: it is critical that equipment materials do not react with or otherwise adulterate the product being manufactured. Materials of construction may be metals (e.g. 316L stainless steel), plastics, or elastomers. Other considerations include design documentation, surface finish including at welds, and any certification required.
2. Sampling: equipment must be designed so that sampling is facilitated where required. Sampling is typically a mitigation for product quality failure modes such as content uniformity in granulation, over/under drying in drying, failed particle size distribution in milling, leakage in encapsulation, and over spray in coating, among others.
3. Cleanability: automated clean-in-place (CIP) cleaning procedures are preferred where practical. Manual cleaning and sterilization may also be considerations.

What do you think about in terms of your OSD manufacturing equipment?

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Validation Project Plans

Hello good people of the world! Today’s post is about Validation Project Plans, which is a specific type of project plan for projects in the pharmaceutical, biotechnology, and medical device regulated industries. This post covers Validation Project Plans for pharmaceutical/biotechnology industries in particular.

Often I’ve see Validation Project Plans contain a lot of fluff but little meat, making them of less value to the project team. A good project plan clearly documents the following, at a minimum:

1. What facilities, systems, and equipment are in scope of the plan
2. What are the expected activities and deliverables
3. Who is responsible for what
4. What is the validation approach and rationale for that approach
5. What happens after the validation scope covered in the plan is completed (i.e. ongoing requirements)

Note I do not include project cost or schedule in a project plan, because these are often changing rapidly and should be maintained in a less controlled, more flexible manner, e.g. with scheduling software for a schedule.

The plan itself should be controlled (i.e. approved and revision controlled) as soon as possible in the project but early enough so that scope will not change (too much).

Additional things to think about when drafting your plan:

1.  Commissioning versus Qualification versus Validation. If your project has multiple phases (and any decent-sized project should), be sure to clearly state responsibilities and deliverables at each stage.
2. Include references to regulations, industry guidance, and site procedures that govern your plan. Make it clear to everyone who reads the plan what framework you are working inside.
3. The purpose and scope of the document should be clear and up front.
4. Get buy-in from all functional groups by having them approve the document.
5. Like all controlled documents, the plan should have version/revision history.
6. Use tables to clearly present information.

I put together a quick template here:

Validation Project Plan Template MWV

What do you feel is necessary in a Validation Project Plan? Comment below.

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

 

 

Specifications: How to Write Them

Hello good people of the world! Today’s post is about the left side of GAMP’s V-model: specifications. Specifically, their purpose and how to write them.

Of course there are many variations of the V-model, and it is best to find what suits your organization and processes. For the purposes of this discussion, I’ll refer to the basic GAMP V-model, pictured above.

The specifications are: User Requirements Specification, Functional Specification, and Design Specification. In general each feeds in to the next. Also, Installation Qualification may test the details of the Design Specification, Operational Qualification may test the functional descriptions in the Functional Specification, and Performance Qualification may test the high-level requirement’s of the User Requirements Specification, although these boundaries are often blurred in practice.

Any new project should start with a User Requirements Specification which clearly defines the testable user requirements. It is important that requirements are testable, and often a SMART approach is applied: each user requirements should be Specific, Measurable, Achievable, Relevant, and Time-bound. It is also helpful to categorize user requirements upfront, since not all will be quality-related. This makes it easier to rationalize the requirements that are explicitly tested in qualification protocols versus commissioning or not at all. Typical categories include: business, safety, maintenance, and quality.

The Functional Specification is then a response to the User Requirements Specification, typically provided by the vendor, explaining in detail how automated components will function to fulfill the user requirements. Functional Specifications are often confused with Functional Requirements or Functional Requirements Specification, which may be another document defined by a process. GAMP’s V-model does not intend the Functional Specification to document new or further detail requirements, but to define the functionality employed to meet the requirements defined in the User Requirements Specification. The Functional Specification can describe sequence of operations, interlocks, alarms, etc.

The Design Specification should provide sufficient detail that an engineer could recreate the control system from scratch if need-be, to recreate the functionality described in the Functional Specification to meet the user requirements. The Design Specification is typically provided by the vendor and should contain such details as I/O list, alarm list, HMI security levels, sequence of operations details including device positions at each step and transition conditions. This should be a very detailed document, and if you’re working with 10-20 pages it is too light.

Documentation can be expensive and is maybe not fun to generate and review, but is critical to a highly effective validation program.

What do you like to see in specifications?

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!