Feature Article

1 Introduction
The European Union currently is overhauling its medical device law and medical software regulation and clarifying the scope of the EU medical device law with respect to software used in clinical settings. This paper analyses EU regulation of clinical decision support (CDS) software and is a companion paper to one published on 28 December 2011 on FierceHealthIT.¹ In this paper, we intend to provide the EU perspective on regulation of CDS software.

We have kept the structure identical to facilitate comparing the regulations under both jurisdictions. Since the US regulatory framework in relation to software is more detailed and developed and EU law has a different approach to certain issues, we expect the comparison to be valuable for companies that have an interest in both jurisdictions. To that end, we will address the same four questions that were addressed in the previous paper:

1. To what extent has CDS software been regulated historically?
2. What do we know about planned changes to CDS software regulations?
3. What specific types of software are likely to be affected?
4. What are the open policy and regulatory issues that need to be addressed by the European Union?

In addition, we will make several comparisons and examine the differences between the US and EU approaches to the regulation of CDS software to help companies operating in both jurisdictions.

2 Past regulation
CDS software has fallen within the scope of the EU medical device directives² (MDD and AIMDD) since 1990. As in the United States, no CDS-specific guidance documents have been published thus far, but there are guidance documents that address software more generally. For example, MEDDEV 2.1/1 from April 1994 already identifies software for diagnostic and therapeutic purposes as being explicitly within the scope of the MDD, but it does not specifically mention CDS software purposes.³

2.1 Categories
EU law, like in the United States, divides software into two categories: (1) stand-alone software and (2) accessories. Software that comes pre-installed on a device when the device is placed on the market is not regulated as a separate medical device. Accessories are defined as software that is not intended to be used as a stand-alone product but, instead, is intended specifically by the manufacturer to be used together with a device (which can be stand-alone software) from another manufacturer. This combination enables the software to be used in accordance with the use of the device (as intended by the device manufacturer).⁴

Understanding that framework is important because it determines the regulatory requirements that apply to a given piece of software. If the software is designed to analyse data downloaded from a blood glucose meter, for example, the software is an accessory and will be regulated in the same manner as the blood glucose meter. The classification and most of the EU regulatory requirements will be dictated by how the parent medical device is regulated. Stand-alone CDS software, by contrast, is regulated or not based on its own merits, without regard to another medical device.

2.2 Regulatory status
If you are sure of the regulatory category in which your CDS software falls, you can determine its regulatory status. Typically that would be one of the following three options:

1. Software that does not meet the legal definition of a device and is not regulated under the EU medical device directives;
2. software that does meet the legal definition of a device and can be self-certified before it is placed on the market or put into service; and
3. software that does meet the definition of a device and needs to be certified by a notified body before it may be placed on the market or put into service.

Software that does not meet the legal definition of a device would be, for example, a system that would not serve any of the intended purposes set forth in the definition of device in the MDD:⁵

• Diagnosis, prevention, monitoring, treatment or alleviation of disease;
• diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap;
• investigation, replacement or modification of the anatomy or of a physiological process; and
• control of conception.

If the software falls within the scope of the MDD, the manufacturer must take another step to determine specifically how the software is regulated—as a general medical device or as an in vitro diagnostic device. The latter category is regulated under yet another EU directive, the In-Vitro Diagnostic Devices Directive (IVDD). ⁶ Software is regulated under the IVDD if it meets the definition of a medical device, as stated above, and is, moreover, intended to be used in vitro for the examination of specimens, including blood and tissue donations, derived from the human body, solely or principally for the purpose of providing information:

• Concerning a physiological or pathological state;
• concerning a congenital abnormality;
• to determine the safety and compatibility with potential recipients; or
• to monitor therapeutic measures.

With CDS specifically in mind, software that is intended to create or modify medical information might be qualified as a medical device. If such alterations are made to facilitate the perceptual and/or interpretative tasks performed by healthcare professionals when reviewing medical information (for example, when searching a medical image for findings that support a clinical hypothesis involving diagnosis or evolution of a therapy), the software could be a medical device.

2.2.1 Unregulated software
Software that is outside the scope of the MDD is not regulated. This typically concerns “software for general purposes when used in a healthcare setting.”^₇ However, all software “when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, is a medical device.”⁸ So, software that is not specifically intended by the manufacturer to be used as a medical device is not covered—that would include general database and spreadsheet software. Generally speaking, if the software does not perform an action on data, or performs an action limited to storage, archiving, communication, “simple search” or lossless compression (i.e., using a compression procedure that allows the exact reconstruction of the original data), it is not a medical device.⁹

There is some difference in opinion about whether patient file database software (i.e., an electronic health record) is regulated or not. For example, Sweden requires that all electronic patient file software be certified. CDS software, if it is provided as a stand-alone product, would normally fall within Class I, as the default classification rule in the MDD defines stand-alone software as an “active medical device.”¹⁰

2.2.2 Software that can be self-certified
Class I devices are not subject to review by a third party but may be self-certified by the manufacturer. As stated above, all CDS software by default falls into Class I, and is, therefore, subject to self-certification with some exceptions (see 2.2.3). Self-certification involves assembling a technical file and designing a quality system that is in conformity with ISO 13485, for example.

2.2.3 When does software need to be certified by a third party?
The default classification for all CDS software is Class I, unless an applicable classification rule bumps it up to Class IIa, IIb or III. If the CDS software has functionality that allows it to drive a device or influence the use of a device, it falls automatically into the same class as that device.¹¹ CDS software that implements a recommended action by exercising control over another Class IIa or higher device would be subject to this. A specific example is CDS software that assists a cardiologist in interpreting data transmitted via WiFi from a patient’s pacemaker and then, following the cardiologist’s approval on a suggested reconfiguration, remotely reconfigures the patient’s pacemaker.

2.3 Examples of currently regulated CDS software
Here are examples of CDS products that are currently regulated:

• Accessory software. Any software marketed to complement the functionality of a medical device (for example, an iPad app that takes blood glucose data from a measuring device via Bluetooth and trends it).
• Calculators. Radiation dose and medication dose calculators would typically be regulated calculators.
• Medication reminders. Software that reminds patients of what type of medication to take and when.
• Advanced analytics. Websites or computer programs that perform advanced analytics on medical device data, such as medical images or electrophysiological signals. For example, a website that performs immunohistochemical image analysis for diagnostic or therapeutic purposes may be regulated.
• Data transmitters. Software that transmits or receives medical data including laboratory information and medical images.
• Storage devices. Software that archives medical device data (a database that is used to archive heart rate and blood pressure measurements obtained from a Holter monitor, for example). As noted above, storage of general health information in an electronic health record system seems to fall outside the scope, as long as the actions performed are limited to storage only.
• Data converters. Software that converts medical data falls within the scope of the concept of medical device, even if the conversion process is well known, unless the manufacturer can prove the conversion is lossless (i.e., using a compression procedure that allows the exact reconstruction of the original data). For example, software that converts medical data archived in a regulated storage device into XML or PDF might be regulated. Likewise, software that takes high-fidelity medical images and compresses them for mobile viewing also may be regulated.
• Display devices. Products that display medical data are regulated. In some sense this might be considered data conversion or analytics, but unlike advanced analytical programmes or high-tech converters, even fairly simple display devices, that graph trends of medical data, for example, would be defined as a medical device.
• In vitro diagnostic results interpretation software. Any software that is used for analysis and interpretation of in vitro diagnostic data (for example, the optical density delivered by an ELISA reader, line or spot pattern of a blot).

2.4 Summary
The following summarises the similarities and differences between the historical approach to regulation of software in the United States and the European Union.

Similarities

• Software is divided into two categories: (1) stand-alone software and (2) accessories.
• Software that comes pre-installed on the device when the device is placed on the market is not regulated as a separate medical device.
• Accessory software is regulated at the same level as the device to which it connects.
• General-purpose software used in a healthcare setting is not regulated, unless its specific intended use is that of a medical device.

Differences

• Software that merely performs storage, archiving, communication, “simple search” or lossless compression of medical data is not regulated in the European Union. In the United States, however, this software would be regulated as a Class I medical device data system (commonly referred to as an MDDS device), if any of the data is obtained electronically from a medical device.
• In the European Union, the default classification for stand-alone software that is not otherwise classified under the medical device directives is Class I—the lowest-risk classification. In the United States, however, the default classification is Class III, which includes devices that present the greatest risk in the eyes of US FDA.

3 Stand-alone software MEDDEV and expected changes in review
There are two ongoing developments that will likely influence the way CDS software is regulated in the European Union: new EU guidelines on the qualification and classification of stand-alone software under the medical device directives,² and the review of the two oldest medical device directives.¹³ Together, these instruments will be the most important documents for CDS software. Since both of these projects are in the works, what the final texts will look like are currently unknown.

3.1 Stand-alone software MEDDEV
A new MEDDEV guidance document titled Guidelines on the Qualification and Classification of Stand Alone Software Used in Healthcare within the Regulatory Framework of Medical Devices (the “MEDDEV”) has just been released.¹⁴ The MEDDEV addresses all of the medical device directives and includes two convenient decision trees to determine if particular software is regulated under the MDD or the IVD Directive. The decision tree for the MDD is shown in Figure 1.

It seems to be a refined version of the decision tree for software that COCIR published in 2010.¹⁵ Let’s clarify the steps.

1. Computer program?
The first step is to determine if the software is a “computer program”. Both COCIR and the MEDDEV propose to use the definition from ISO/IEC 2382-1:1993: “A computer program is defined as a syntactic unit that conforms to the rules of a particular programming language and that is composed of declarations and statements or instructions needed to solve a certain function, task or problem.” If you answer no to question 1, the software does not contain any instructions or subroutines in any programming language and you are probably dealing with an electronic document containing a protocol (such as a Word document in which a treatment protocol has been written out).

2. Embedded or incorporated?
If the software is incorporated in a medical device, rather than being a stand-alone product, it must be considered to be part of that medical device for regulatory purposes. Updates to the software at a later stage are regulated as changes to the device.

3. Action different from storage, archival, lossless compression, or simple search?
If the software performs an action on data at all or performs an action on data that is limited to storage, archival, communication¹⁶ or simple search,¹⁷ it should not fall within the scope of a medical device. In all other cases, actions on data to assist the user for a medical purpose would likely make the software a medical device. Such assistance would typically be facilitation of perception and interpretation. An example would be software that filters out noise in images or that provides decision support based on its interpretation of patient data.

4. For the benefit of individual patient(s)?
The software must be intended to produce results for a specific patient or group of patients, anonymous or otherwise, for it to qualify as a medical device.¹⁸ Software not intended to produce results for specific patients includes, for example, software for statistical, research, registry, or data aggregation purposes. This software—even if used in clinical trails—is not a medical device. Software providing generic diagnostic or treatment pathways (software that displays a treatment protocol as a flowchart, for example) also would not be software for the benefit of individual patients, according to COCIR.¹⁹

5. Action in scope of intended use regulated under medical device directives?
The intended use must fall within the definition of a medical device under the MDD. This is a hard question for software developers to answer. As a start, it is helpful to consider what the manufacturer of the software intends it to do. Is it something medical or a general function, such as invoicing or planning, that could be used for any purpose? If the answer is that the software is to be used specifically for a medical purpose, the next step is to check if this medical purpose is regulated under the MDD (see Section 2.2 above). The intention of the manufacturer of the software determines the purpose, not how a user decides to use the software.

6. Accessory to medical device?
As explained above in Section 2.1, accessories of medical devices are regulated as medical devices in their own right. Software that is not itself a medical device and does not constitute an accessory to a device typically would be software for all types of uses in a medical setting but not with a regulated intended purpose. An example would be software that is used for reimbursement purposes, staff scheduling or some other similar function. Software that is an accessory will influence a medical device in some way and assist it to achieve its intended purpose but does not itself fall within the scope of the definition of a medical device. An example of this would be an iPad app that allows a nurse to monitor and control infusion pumps in the ward from the nurse’s station.

In Vitro Diagnostics
The decision tree for IVDs included in the MEDDEV is mainly concerned with demarcation of the MDD and the IVDD. The IVDD typically regulates expert systems that interpret data from IVD devices. If the data comes from diagnostic devices that are covered under the MDD but not under the IVDD (because the data is not derived from in vitro examination of a specimen derived from the human body), the software falls under the MDD and not under the IVDD. The same questions with respect to the accessory status must be answered for IVDs.²⁰

1. In scope of MDD?
To determine if the CDS software is within the scope of the MDD, first apply the decision tree shown in Figure 1 and then proceed with the IVD tree (Figure 2).

2. IVD functionality?
For CDS software to fall within the scope of the IVDD, the manufacturer’s intended use must be the examination of in vitro specimens derived from the human body (including blood and tissue donations) solely or principally for the purpose of providing information

• concerning a physiological or pathological state;
• concerning a congenital abnormality;
• to determine the safety and compatibility with potential recipients; or
• to monitor therapeutic measures.

CDS software with another functionality that is also not an accessory falls outside the scope of the IVD Directive.

3. Source of data—only from IVD?
The next step is to determine the sources of the data. If the data comes from any source other than an IVD, there is a demarcation issue because the device concerned is a combination device. Combination devices are contemplated in the IVDD:²¹ if the IVD is intended for use in combination with other (medical) devices or equipment, the whole combination, including the connection system, must be safe and must not impair the specified performance of the devices. Any restrictions on use must be indicated on the label and/or in the instructions for use.

4. Source of data—only from medical device?
If the software obtains the data only from one or more medical devices that are not IVDs, the IVDD does not apply and the software is regulated under the MDD.

5. and 6. Accessory of an IVD?
A device can fall outside the scope of both directives (as explained above in relation to accessories) but still be subject to regulation as an accessory to a medical device or to an IVD.

Modules
The MEDDEV also regulates software that is a module of a larger interoperable software package that falls within the scope of the MDD. However, it is up to the manufacturer to define correctly the boundaries of the module(s) and to identify clearly what is regulated and what is not. The MEDDEV does not provide guidance on how to make such a determination but instead refers to the existing rule in Annex I MDD and IVDD for combination devices: “If the device is intended for use in combination with other devices or equipment, the whole combination, including the connection system, must be safe and must not impair the specified performances of the devices. Any restrictions on use must be indicated on the label and/or in the instructions for use.”²²

It may be challenging for manufacturers to identify how the different modules of a larger software system relate to each other and where medical functionality starts or ends. Indeed, the rule in Annex I that the MEDDEV refers to was written for modular physical medical devices rather than software. Furthermore, manufacturers must ensure that the whole system is safe and does not impair the specified performance of the modules that are subject to the medical device directives if medical functionality modules are combined with nonmedical functionality modules. On the other hand, medical device regulations in the European Union are appreciated for their flexibility, allowing manufacturers to present evidence in a way that works for them.

3.2 Review
The European Union is currently in the process of preparing a first draft review of the MDD, which will probably be a single regulation that incorporates both directives.²³ The IVDD also will be reviewed but will not be incorporated in the same regulation.
This review process will take time and the new legislation probably will not go into effect before 2015, at the earliest. We mention this development, though, because we believe that the new legislation will impact CDS software in the following ways:

• In terms of scope, more diagnostics will be covered under the MDD. The European Union intends to include within the scope of the new regulation genetic tests for lifestyle purposes and diagnostic services provided at a distance.
• The requirements for clinical validation of CDS software will become stricter. Specifically for IVDs, the European Union is contemplating evaluation of clinical validity and utility of IVDs. As suggested above, CDS software associated with an IVD would be subject to these requirements.
• The requirements for postmarket surveillance of CDS software will be harmonised and streamlined, as they are currently largely member-state focused.
• The European Union will impose further traceability requirements and is likely to start a registry for the publication of summary information for higher-risk devices, as is currently mandated by US FDA.

3.3 Summary
The following summarises the similarities and differences between the regulatory framework for stand-alone software and the expected regulatory changes in the United States and European Union.

Similarities

• As an initial step, both the US and EU approach is to determine whether the software is embedded in a medical device or if it functions independently (i.e., as stand-alone software). Embedded software is regulated as part of the medical device; stand-alone software is regulated as an independent product.
• US FDA is actively developing a regulatory approach to software that produces “actionable” information—software that takes any information from any source and converts that information into information that is intended to be used to support a patient-specific clinical decision. Steps 3, 4 and 5 of the EU MDD decision tree is similar to this concept.

Differences

• In the United States, software that reads and processes information from an IVD generally is regulated as an accessory to an IVD device. In the European Union, the regulation of this software depends on the data sources.
• The European Union explicitly contemplates regulation of diagnostic services emanating from outside its borders. In the United States, on the other hand, US FDA does not regulate such services, but would regulate any home or clinical diagnostic devices used as part of the services under the existing framework^.24
• In the European Union, stand-alone software can be broken into modules and regulated separately; in the United States, stand-alone software is regulated as a system, with one exception: MDDS devices, which can be treated separately from the rest of a software system if the architecture is properly designed.

4 Potentially Affected Types of Software
So what types of present day software uses might end up in the regulated CDS software category when applying the decision trees from the draft MEDDEV? Here are our best guesses.

1. All CDS software mentioned as examples in this article, including, for example, a website that performs immunohistochemical image analysis for diagnostic or therapeutic purposes.
2. Electronic health records (EHRs) that do more than passively store medical information for retrieval at a later time. If algorithms and other conversion tools are used, expect them to be considered for regulatory oversight.
3. Consumer-targeted software that facilitates a diagnosis or makes treatment recommendations based on manually entered data or data that is electronically transferred from medical devices. This could include websites or mobile apps that allow a consumer to enter symptoms and get something more than textbook-like information about possible medical conditions associated with those symptoms. Depending on the degree of specificity and the messaging involved, another example might be a website that analyses search strings (“HIV” or “migraine,” for example) and targets the consumer with specific diagnoses or treatment options (such as advertisements for branded test kits or a specific drug).
4. Supercomputers that crunch large volumes of data in an effort to improve patient diagnosis. An example might be software that analyses physician notes stored in a patient’s EHR for trends in observations or symptoms over time in order to diagnose a medical condition, such as seasonal allergies. Another example could be DNA profiling for personalised medical purposes that requires a large amount of computing power or is more efficiently done in the cloud.
5. Software that makes treatment recommendations for whole groups of patients, where the intent is to act upon the recommendation as opposed to simply learning something. For example, a mobile app that not only informs you of the daily pollen count for your location but also suggests an antihistamine to protect against an allergic reaction might fall under the scope of the MDD.
6. Software that performs other advanced analytics that have a direct impact on patient safety. Examples include software that evaluates a patient’s treatment regimen for drug-drug interactions or that directs where to biopsy or the type of cancer treatment to use.
7. Software that monitors patients on research and treatment protocols or that manages patient work-flow, if such software significantly impacts patient safety (emergency-room resource planning based on triage data, for example). Another example is software that prioritises a specific patient for clinician review over other patients because of a “critical” condition.
8. Software that promotes the use of in-office best practices based on condition-specific clinical guidelines and population-based management, if such software is intended to influence decision-making for individuals or groups of patients. This might include, for example, software that recommends that a nurse wear a mask when entering a specific patient’s room because of increased susceptibility to infection.
9. Software that analyses intra-operative data for recommendations on patient-specific surgical planning.

5 Open Issues
Resolving the broad issue of what types of CDS software US FDA should regulate will require a detailed analysis of at least the following six areas:

1. The types of data manipulation and mining that qualify for regulation. It may be difficult to determine if the software performs an action on data that goes beyond storage, archival, communication or simple search such that it should not fall within the definition of a medical device. In all other cases, actions on data to assist the user for a medical purpose would likely make the software a medical device.
2. Marketing claims and label. Marketing claims for medical devices will have to conform to their label and intended use. New software- and IT-related terms used in relation to CDS software may provoke discussions about off-label promotion or the incorrect scope of a CE mark for specific software, such as:
   a. “Decision support,” “artificial intelligence” or other similar terms;
   b. “Real-time” or “active” (suggesting no time for the exercise of judgment of a healthcare professional);
   c. “Patient-specific” or “personalised” (suggesting that the software somehow produces individualised actionable information);
   d. “Integrated” (suggesting that a regulated medical device can easily transfer information into the software); and
   e. “Flags,” “notifications” or “alarms” (suggesting there is a real-time alert that should be acted on by a healthcare professional).
3. The freedom of end users to tailor software to their individual needs without regulatory oversight. There has always been an ambiguity around how much hospitals and other end-users can configure software without themselves becoming a regulated manufacturer. The current definition of manufacturer excludes assembly or adaptation of devices already on the market to their intended purpose for an individual patient.²⁵ This definition was, however, written with modular physical devices in mind rather than software, which may be configured to include functionality that the manufacturer did not intend.
4. The regulatory significance of modules. In other industries, like aerospace, there are accepted principles for breaking software down into modules. The MEDDEV gives very succinct guidance by reference to provisions that were originally drafted with physical device systems in mind, but it is not clear at this stage whether this guidance will be adopted.
5. International harmonisation. Many software products are deployed globally. To be efficient, we need to harmonise regulatory standards globally as much as possible. With the Global Harmonization Task Force (GHTF) coming to a close at the end of 2012, the burden will be on its successor—the International Medical Device Regulators’ Forum (IMDRF)—to continue to drive the successful international harmonisation project for medical technology.
   6. Wellness versus disease. Intended use determines the regulatory status of a product. Sometimes the mere mention of the use of a product in connection with a disease is enough to be regulated as a medical device. However, since the EU has a binary criterion for medical devices, software intended for general health and wellness purposes may fall into regulated territory. One could ask if, for example, software for patient education and lifestyle management (in regard to chronic diseases, for example) should be regulated.

6 Conclusion

In the European Union and the United States, the regulatory approach to CDS software is in flux and important developments are slated for 2012. If the future of this software category is important to you, you'll want to monitor developments closely and become engaged. As table 1 shows, this approach should account for the many essential similarities between the systems on both sides of the pond. The majority of differences lie in the underlying documentation requirements prescribed by the broader regulatory framework of each jurisdiction. Companies that want to stay ahead of the regulatory compliance curve should learn to take advantage of the similarities while efficiently accounting for differences. The observant reader will have noticed, for example, that the open issues in the fifth paragraph are virtually identical for both jurisdictions. Time will tell how the United States and the European Union choose to resolve these open issues; we hope the approaches will remain largely convergent.

References
1. http://www.fiercehealthit.com/special-reports/fdas-approach-clinical-dec...
2. Directive 93/42/EE on medical devices and Directive 90/385/EEC on active implantable medical devices
 3. http://ec.europa.eu/health/medical-devices/files/meddev/2_1-1___04-1994_... , para. 1.1 (f)
 4. See definition of accessory, Directive 93/42 article 1 (2) (b)
 5. Directive 93/42, article 1 (2) (a)
6. DIRECTIVE 98/79/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 October . 1998 on in vitro diagnostic medical devices
 7. Directive 2007/47, recital 6
 8. Directive 2007/47, recital 6
9. MEDDEV 2.1/6 Qualification and Classification of stand alone software, explanation of decision step 3 in respect of medical devices decision tree, p. 12
10. MEDDEV 2.4/1 Rev. 9 http://ec.europa.eu/health/medical-devices/files/meddev/2_4_1_rev_9_clas..., p. 10 and Directive 93/42 Annex IX, point I.1.4
 11. Directive 93/42, Annex IX, sub II, point 2.3
 12. MEDDEV 2.1/6 Qualification and Classification of stand alone software
 13. Directive 93/42 on general medical devices and 90/385 on active implantable medical devices
 14. MEDDEV 2.1/6 Qualification and Classification of stand alone software, January 2012
15. http://www.cocir.org/uploads/documents/-48-cocir_medical_software_qualif...
16. COCIR suggests to define “communication” in accordance with IEEE 620.10-1994: “the flow of information from one point, known as the source, to another, the receiver.”
17. “Simple search” is limited to the searching functionality only: retrieval of records by matching record metadata against record search criteria and not, for example, identifying, marking or drawing attention to portions of record data or portions of images that match the search criteria.
18. See COCIR decision tree explanation sub 5
19. See COCIR decision tree explanation sub 5
20. See the definition of ”accessory” in article 1 (2) (c) of the IVD directive
21. See Annex I, B.3.1 IVDD
22.  See Annex I, 9.1 MDD and Annex I, B.3.1 IVDD
23. For the roadmap, see http://ec.europa.eu/governance/impact/planned_ia/docs/2008_sanco_081_pro...
24. Such services may be regulated by another regulatory agency under separate statutory authority.
25. Article 1 (2) (f) MDD

Erik Vollebregt is a Founding Partner at Axon Lawyers, Piet Heinkade 183, 1019HC Amsterdam, tel +31 88 650 6500, fax +31 650 6555, email erik.vollebregt@axonlawyers.com, URL www.axonlawyers.com
Bradley Merrill Thompson
is a Member of the Firm, Washington, DC Office, Phone: 202/861-1817
Fax: 202/861-3517, 1227 25th Street, NW, Suite 700, Washington, DC 20037-1156, bthompson@ebglaw.com

and
M. Jason Brooke
is associate at Epstein Becker & Green, Washington, DC Office
Phone: 202/861-1812
Fax: 202/861-3512
1227 25th Street, NW
Suite 700
Washington, DC 20037-1156
JBrooke@ebglaw.com