Healthcare Software

Validating CCR and CCD XML Documents

I read a lot about people trying to find the XML schemas for CCR and CCD documents. So for anyone interested, they are easily available by following these links provided by Microsoft: [CCR schema] [CCD schema].

The pages open up on the HealthVault developer page, but there are links at the bottom to download the XSD file and also a link if you just want to verify some XML against it. For doing either of these actions, you will have to have a Windows Live ID or OpenID.

Microsoft is quite good to make the XML schemas for these and all other HealthVault components available. For a complete list, check out their list of "thing" types.

Software Documentation to include in an FDA Premarket Submission

Although it is not necessary to submit every piece of documentation as part of an FDA premarket submission, it is still important to have the document on hand should something change along the way. It also goes a long way to demonstrate a good development process.

In the table below, I list the documents along with columns for whether the document is required or if it is FDA application specific, meaning that it wouldn't be part of a normal development process. For example, normally I wouldn't make a document called "Level of Concern," but for the FDA it is required for all submissions. Those interested can read more about the different document types on the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices page.

Developing Software in an FDA Regulated Environment

A lot of focus is often given to the development lifecycle followed and how it can help or harm the process of getting and retaining FDA premarket approval. Some believe that since the FDA is more familiar with a traditional waterfall process it is advantageous to use the same. The logical argument given is that it would simplify the audit process because there would be no need to explain your alternate process. In reality, the lifecycle you choose to follow is entirely up to you since the law, like a good requirement, will never over constrain itself against evolutionary improvement.

The key to passing an FDA review or audit as far as the software of a device is concerned is to have a sound development process in place and ensure that it is followed with the knowledge that it will be scrutinized when applying for FDA approval. The need to back up your process with evidence is fulfilled by good management empowered with good tools. For example, using a requirements management tool will help to track relationships between requirements as they get added, removed or modified. Such a tool will also provide links between requirements and design and test plan documentation. These tools have extended their use into agile development processes as is the case with Inflectra’s SpiraTeam product. More general solutions come in the form of the popular Telelogic DOORS. Using these tools allow you to build traceable documents and help you to conform to FDA standards.