ISO 9001
ISO 9001 is a Quality Management System (QMS) standard. This page describes how the standard maps to Medplum's processes. You can read more about ISO 9001 on Wikipedia. The standard follows the plan-do-check-act (PCDA) methodology.
Because Medplum is open source, a large number of the resources and practices are visible in our repositories or on our documentation pages.
Standards Mapping
The materials below map Medplum's processes to existing ISO 9001 standards.
Number | ISO Clause | Requirement | In Practice |
---|---|---|---|
1 | 5.2 Customer focus | Ensure that customer requirements are met with the aim of enhancing customer satisfaction | Product backlog creation and grooming |
2 | 5.5.1 Responsibility and Authority | Defined responsibilities and authorities | Distinct roles in the scrum team - product owner, scrum master and scrum team RACI |
3 | 5.5.3 Internal communication | Ensure that appropriate communication processes are established | Regular standup meeting, product backlog grooming, sprint review, sprint retrospective |
4 | 7.1 Planning of product realization | Planning and development of product | Product backlog creation, sprint planning, sprint backlog creation and user stories |
5 | 7.2.1 Determination of requirements | Ensure Requirements are captured properly | Issues stories with acceptance criteria |
6 | 7.2.2 Review of Requirements | Ensure that review of requirements is done | Triage, architectural and business review of issues before acceptance |
7 | 7.2.3 Customer Communication | Customer communication regarding requirements, bugs etc | Regular standup meeting and triage |
8 | 7.3.1 Design and development planning | Plan and control the design and development of product | Sprint planning |
9 | 7.3.2 Design and development inputs | Inputs relating to product requirements shall be determined and records should be maintained | Github issues filed by developers, with feedback and acceptance criteria |
10 | 7.3.3 Design and development inputs | Outputs of design and development shall be in a form suitable for verification against the design and development input shall be approved prior to release | Pull requests require review, sprint review |
11 | 7.3.4 Design and development review | At suitable stages, systematic reviews of design and development shall be performed in accordance with planned arrangements | Sprint retrospectives, quarterly security and compliance review, annual SOC 2 review |
12 | 7.3.5 Design and development verification | Verification shall be performed in accordance with planned arrangements to ensure that the design and development outputs have met the design and development input requirements | Testing, automated code scanning tools, linting tools, automated tools like Inferno |
13 | 7.3.7 Control of design and development changes | Design and development changes should be defined and records and logs should always be maintained | Issue tracking, backlog grooming and sprint review |
14 | 8.2.1 Customer satisfaction | Team should monitor information relating to customer perception as to whether they have met customer requirements | Customer submitted issue tracking, sprint review |
15 | 8.2.4 Monitoring and measurement of product | Team monitors and measures the characteristics of the built product to verify that the requirements have been met | Sprint review, stand up, sprint planning, system monitoring and logging |
16 | 8.3 Control of non-conforming product | Team should ensure that the product which does not conform to product requirements is identified and controlled to prevent its unintended use or delivery | Testing, backlog grooming and sprint review |
17 | 8.4 Analysis of data | Team should determine, collect and analyze appropriate data to demonstrate the suitability and effectiveness of the quality management system and evaluate where continual improvement of the effectiveness of the quality management system can be made | Quarterly security and compliance review, sprint retrospective |
18 | 8.5.2 Corrective action | Team should take action to eliminate the causes of nonconformities in order to prevent recurrence | Quarterly security and compliance review, incident root cause analysis, sprint retrospective |
19 | 8.5.3 Preventative action | Team should determine action to eliminate the causes of potential nonconformities in order to prevent their occurrence | Quarterly security and compliance review, root cause analysis, sprint retrospective, product backlog grooming, static analysis tools in build |
Links and Resources
- Medplum Roadmap on Github
- Medplum Github Workflows include code scanning, linters and analysis, and workflows.
- Secure development and testing practices including scorecards
- Medplum Github repository include links to issues and pull requests.