I am currently tasked with creating a software architecture for compliance with IEC 62304. These regulations are notoriously vague, and do not provide any real substance as to what is required for a "software architecture". The standard states

The manufacturer shall transform the requirements for the medical device software into a documented architecture that describes the software's structure and identifies software items.

Now I went to an applied computer science school, so the vast majority of my teachings were around how to actually write code and working on projects, so as far as I can remember, we never covered anything involving creating software architecture diagrams.

I've already basically written all of the software, but for regulatory submission purposes I need to create this documentation for the project.

So in short my question is this: What exactly does a "software architecture" consist of?

  • You might also want to have a word with your quality people - the folks who write all your SOPs and such. They may be able to help you get a handle on what the standard means, as they are probably more used to reading standards than you are. – Michael Kohne Mar 5 '13 at 18:58
  • @MichaelKohne Unfortunately, software within medical devices is a new field for my company, so we don't have any established practices as of yet, I'm kind of the Guinea pig. I had to draft the SOPs from the applicable standards, and from a purely software engineering background, it isn't easy – Dan F Mar 5 '13 at 19:06
  • Oh fun. Are you in the US? I work for a medical device manufacturer (EEG machines), and I think that pure software products are viewed as 'devices' by the FDA (though I could be wrong). If you are in the US, you REALLY should get someone with expertise (there are consultants for this kind of thing) to come in and go over your procedures and such before you start selling products - they'll make sure you've got at least a stab at being in the right position if the FDA comes calling. – Michael Kohne Mar 5 '13 at 19:17
  • @MichaelKohne I did try suggesting that to my boss, but I guess the company wants to try and handle it ourselves first before shelling out the money for the consulting – Dan F Mar 5 '13 at 19:19
  • Ohh. Umm, you want to be REALLY careful on that - an FDA audit could be seriously damaging if you aren't reasonably close to being in compliance. Consultants are expensive, but flunking an FDA audit could be much more so. Are you selling for patient use, or for research use? You can get away with a lot more if it's for research only. – Michael Kohne Mar 5 '13 at 20:21

Software Architecture looking at the software from a high level. This will focus on how different software components interact with each other. It also consists of how outside systems can interact with your software system, or if you even allow outside systems to interact. If you think of how a building architect does by designing a building, a software architect will design a software system. This involves documenting the software system. Some examples of how to document would be to create a requirements document, use case document, class diagram, state diagram, interaction diagram, help files to name a few.

As far as how much detail to use, I would say you will want to use enough to effectively portray what the system is supposed to do and what different messages mean when the system is not doing what the client is trying to do. They will need help documents and a glossary of terms, specially error messages.

For your team, I would use the requirements and other various documents to specify how the system works. This will help greatly with maintenance and enhancements. The requirements will help guide the team to determined when you have a finished, working product.

  • As far as a "software architecture" is concerned, what exactly is considered a "software component"? My software isn't particularly complicated, it basically consists of a UI for entering user information, and a second UI for controlling the device – Dan F Mar 5 '13 at 19:21
  • It is everything that goes into your software system. Both user interfaces and how it interacts with the device would be part of your architecture. Also any 3rd party components and/or any other components that are written that are not part of the two user interfaces. – DFord Mar 5 '13 at 19:33
  • How fine-grained should I be with my breakdown of the system? Is it purely discretionary, or would breaking it down to each individual UI element be required? Sorry to be asking so many questions, I just really have no idea what I am doing with this, and you seem to be helping out so far – Dan F Mar 5 '13 at 19:40
  • @DanF I added more to the answer that I think will help you. – DFord Mar 5 '13 at 19:52

We're going though the 62304 learning curve right now.

As the previous answer suggests it is just the high-level view of your medical device software.

According to the standard you should at minimum list the various modules/components. Components are defined as being made of software items. However, how you define components and items is entirely up to you.

In our case, products often have one component and rarely more than three.

In the case of a engineer-workstation-based GUI project, we have four component. The GUI, the product logic, and an existing DLL we are required to integrate, and the underlying mathematical modelling engine that the whole system is based upon.

The architecture consists of

  1. description of the GUI,
    • basically a list of screens and their associated workflow
    • a description of the objects(software items) associated with each screen
  2. a description of the product logic
    • a description of the state machine, and how it interacts with the GUI workflow
    • a description of the state machine class (a software item)
    • a description of the mathematical-modelling operations being performed for the client. (broken down into stages - each stage is a software item)
  3. a description of a required DLL, its SOUP status, etc. (one software item)
  4. a reference to another software component developed under 62304

One thing to bear in mind is that (despite the heavy implication of the way the 62304 standard is written) you don't have to create the architecture diagram up front and then fix it in stone in a waterfall coding model. The FDA have encouraged the use of more agile approaches, allowing you to develop the architecture along with the code, so long as your validate the final architecture against the final design. So start with a simple architecture that allows you to make progress, and keep it up to date as you develop the code. See the AAMI's TIR45 publication for some documented justification.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.