'Action Figure' 카테고리의 다른 글
의료용 펌프 전문가 (0) | 2019.03.22 |
---|---|
국내 의료기기 담당자를 찾아서... (0) | 2019.03.22 |
미국의 의료기기 법제에 관한 분석 (0) | 2019.01.30 |
FDA의 의료기기 SRS (1) | 2019.01.28 |
Breakthrough Medical Device (0) | 2019.01.21 |
의료용 펌프 전문가 (0) | 2019.03.22 |
---|---|
국내 의료기기 담당자를 찾아서... (0) | 2019.03.22 |
미국의 의료기기 법제에 관한 분석 (0) | 2019.01.30 |
FDA의 의료기기 SRS (1) | 2019.01.28 |
Breakthrough Medical Device (0) | 2019.01.21 |
서강대 신운섭 교수
http://www.sogangtech.com/html/search_view.php?mode=list&idx=287&PHPSESSID=49c6fdfbeb99948d98928b0ca2410155
제품명 | 응용분야 |
전기삼투펌프, 센서 | 의료펌프, 분석용 펌프 |
이산화탄소 전환기술, 배터리 | 환경, 에너지 |
| |||||||||||||
|
홈페이지 : http://sgbnel.sogang.ac.kr/
https://blog.naver.com/PostView.nhn?blogId=sogangpr&logNo=221401567945&categoryNo=26&parentCategoryNo=0&viewDate=¤tPage=1&postListTopCurrentPage=1&from=postView
케어메디 주소
http://www.saramin.co.kr/zf_user/jobs/view?rec_idx=32556500
회사주소 | (04107) 서울 마포구 백범로 35 서강대학교 떼이야르관 415호 |
---|---|
인근전철 | 서울 6호선 대흥1번 출구 에서 500m 이내 |
http://news.mt.co.kr/mtview.php?no=2018110117547432159
체내이식형 약물주입 펌프는 극심한 고통에 시달리는 만성통증 환자 및 말기암 환자들에게 이식된 펌프와 카테터를 통해 척수강(Spinal cord)에 직접 모르핀을 자동적으로 주입할 수 있는 표적약물전달(Target Delivery) 장치이다.
이는 구강투여의 1/300, 정맥투여의 1/100 정도의 양으로 동일한 약효를 나타내며, 약물 확산의 최소화로 부작용도 적다. 또한 펌프가 체내에 이식돼 있기 때문에 환자의 일상생활을 가능하도록 한 장점을 가진다.
사업분야 | 바이오의료 |
---|---|
설립일 | 2015.06.23 |
대표자 | 신운섭, 황선주 |
사이트 | www.caremedi.co.kr |
TIPS 선정 | 2017.11 |
운영기관 | 포스코 |
다크나이트 조커 피규어 (0) | 2020.06.22 |
---|---|
국내 의료기기 담당자를 찾아서... (0) | 2019.03.22 |
미국의 의료기기 법제에 관한 분석 (0) | 2019.01.30 |
FDA의 의료기기 SRS (1) | 2019.01.28 |
Breakthrough Medical Device (0) | 2019.01.21 |
백윤정 교수
한국보건산업진흥원
한국산업기술평가관리원
한국연구재단
신운섭 교수
중소기업기술정보진흥원
다크나이트 조커 피규어 (0) | 2020.06.22 |
---|---|
의료용 펌프 전문가 (0) | 2019.03.22 |
미국의 의료기기 법제에 관한 분석 (0) | 2019.01.30 |
FDA의 의료기기 SRS (1) | 2019.01.28 |
Breakthrough Medical Device (0) | 2019.01.21 |
다크나이트 조커 피규어 (0) | 2020.06.22 |
---|---|
의료용 펌프 전문가 (0) | 2019.03.22 |
국내 의료기기 담당자를 찾아서... (0) | 2019.03.22 |
FDA의 의료기기 SRS (1) | 2019.01.28 |
Breakthrough Medical Device (0) | 2019.01.21 |
오래된 문서긴 하다. 파일은 첨부하였음.
Guidance for Industry and FDA Staff
Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
Document issued on: May 11, 2005
FDA 문서에서 SRS를 요구한다.
Software Requirements Specification (SRS) |
Summary of functional requirements from SRS. |
The complete SRS document. |
|
그리고 다음 내용이 있어야 한다.
Software Requirements Specification
The Software Requirements Specification (SRS) documents the requirements for the software. This typically includes functional, performance, interface, design, developmental, and other requirements for the software. In effect, this document describes what the Software Device is supposed to do. Examples of some typical requirements that would be included in a SRS are
11
Contains Nonbinding Recommendations
described below. For Software Devices that are identified as Minor Level of Concern, we recommend that you provide only the summary functional requirements section from the SRS, includingidentificationofoff-the-shelfsoftware. ForSoftwareDevicesthatareidentifiedas Major or Moderate Level of Concern, we recommend that you provide the complete SRS document.
Hardware Requirements
Hardware requirements generally include:
microprocessors
memory devices
sensors
energy sources
safety features
communications.
Programming Language Requirements
Programming language requirements include program size requirements or restrictions, and information on management of memory leaks.
Interface Requirements
Interface requirements generally include both communication between system components and communication with the user such as:
• printers
• monitors • keyboard • mouse.
Software Performance and Functional Requirements
Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. Software performance and functional requirements may also include:
device limitations due to software
internal software tests and checks
error and interrupt handling
fault detection, tolerance, and recovery characteristics
12
Contains Nonbinding Recommendations
safety requirements
timing and memory requirements
identification of off-the-shelf software, if appropriate.
Architecture Design Chart
This document is typically a flowchart or similar depiction of the relationships among the major functional units in the Software Device, including relationships to hardware and to data flows suchasnetworking. Itisusuallynotnecessarytoincludeeveryfunctioncallandmoduleinthis document; however, there should be sufficient information to allow for review of the organization of the software relative to the functionality and to the intended use of the Software Device. For Moderate and Major Level of Concern devices, detailed information such as state diagrams may be useful to clearly depict the relationships among the software functional units. If the Architecture Design Chart is included in another document such as the SRS then you should include in your submission a statement to that effect and a reference to the location of the Architecture Design Chart in the submission.
Software Design Specification
The Software Design Specification (SDS) describes the implementation of the requirements for the Software Device. In terms of the relationship between the SRS and the SDS, the SRS describes what the Software Device will do and the SDS describes how the requirements in the SRS are implemented. The information presented in the SDS should be sufficient to ensure that the work performed by the software engineers who created the Software Device was clear and unambiguous, with minimal ad hoc design decisions. The SDS may contain references to other documents, such as detailed software specifications. However, the document you submit should, in and of itself, provide adequate information to allow for review of the implementation plan for the software requirements in terms of intended use, functionality, safety, and effectiveness.
Traceability Analysis
A Traceability Analysis links together your product design requirements, design specifications, andtestingrequirements. Italsoprovidesameansoftyingtogetheridentifiedhazardswiththe implementationandtestingofthemitigations. Werecommendthatyousubmitforreview explicit traceability among these activities and associated documentation because they are essential to effective product development and to our understanding of product design, development and testing, and hazard mitigations. The Traceability Analysis commonly consists of a matrix with line items for requirements, specifications and tests, and pointers to hazard mitigations. It is possible to document traceability simply through a shared organizational
13
Contains Nonbinding Recommendations
structure with a common numbering scheme; however, we recommend that you include some mechanism, such as a matrix for guiding the reviewer through the information you submit.
Software Development Environment Description
For Moderate and Major Level of Concern Software Devices, the submission should include a summary of the software development life cycle plan. This summary should describe the sponsor’s software development life cycle and the processes that are in place to manage the various life cycle activities. For Major Level of Concern Software Devices, this document should also include an annotated list of the control/baseline documents generated during the software development process and a list or description of software coding standards.
As mentioned elsewhere, configuration or change management is a crucial aspect of software development. Changes to the Software Device after initial market release should be subject to positive control, with definitive specification and test plans including well-defined regression testing where appropriate. The description of the development environment should provide information on your configuration management and maintenance plan that addresses these aspects of the software development life cycle. For a Major Level of Concern device, we recommend that you provide sufficient detail to allow for a thorough understanding of the configuration management and maintenance plan. For a Moderate Level of Concern device, we recommend that you provide only a summary of the configuration management and maintenance plans.
Verification and Validation Documentation
The terms “verification” and “validation” described earlier in this document refer to two phases of Software Device testing. This section recommends the type of testing documentation you should include in a premarket submission for a Software Device, based on the Level of Concern.
Minor Level of Concern Devices
For Minor Level of Concern devices, we recommend that you submit documentation of system or device level testing, and, where appropriate, integration testing. The documentation submitted should include system or device level test pass/fail criteria and a summary of the test results.
Moderate Level of Concern Devices
For Moderate Level of Concern devices, we recommend that you submit a summary list of validation and verification activities and the results of these activities. We also recommend that you submit your pass/fail criteria. You should ensure that the Traceability Analysis effectively links these activities and results to your design requirements and specifications.
14
Contains Nonbinding Recommendations
Major Level of Concern Devices
For Major Level of Concern devices, we recommend that you submit the information recommended above for Moderate Level of Concern devices and a description of any tests that were not passed. We also recommend that you include any modifications made in response to failed tests and documentation of results demonstrating that the modifications were effective. Documentation provided in your submission should include examples of unit integration testing and a summary of the results.
Revision Level History
Your submission should include the history of software revisions generated during the course of productdevelopment. Thistypicallytakestheformofaline-itemtabulationofthemajor changes to the software during the development cycle, including date, version number, and a brief description of the changes in the version relative to the previous version. The last entry in the list should be the final version to be incorporated in the released device. This entry should also include any differences between the tested version of software and the released version, along with an assessment of the potential effect of the differences on the safety and effectiveness of the device.
Unresolved Anomalies (Bugs or Defects)
For Moderate and Major Level of Concern Software Devices, the submission should include a list of all unresolved software anomalies. For each anomaly, we recommend that you indicate the:
• problem
impact on device performance
any plans or timeframes for correcting the problem (where appropriate).
We recommend that you annotate each item with an explanation of the impact of the anomaly ondevicesafetyoreffectiveness,includingoperatorusageandhumanfactorsissues. Typically, this list can be generated as an output of a change control board or similar mechanism for evaluation and disposition of unresolved software anomalies. We recommend that you communicate this list to the end user as appropriate to assist in the proper operation of the device. Inallinstanceswhereitispracticaltodoso,youshouldincludeanymitigationsor possible work-arounds for unresolved anomalies; this recommendation applies to Blood Establishment Computer Software in particular.
The Special 510(k) Program
For a premarket submission to qualify for review under the Special 510(k) Program, the device should be a modification of your 510(k) cleared device that you own, where the modification does
15
Contains Nonbinding Recommendations
notaltertheintendeduseorthefundamentalscientifictechnologyofthedevicevii. InaSpecial 510(k), you should follow the recommendations in this guidance on the documentation to submit, but submit only the documentation related to the modification that prompted the submission. For example, when submitting the documentation of requirements and specifications in a Special 510(k), the documentation should focus on the modifications and may not necessarily include all of the requirements and specifications of the entire device.
We recommend that you submit the regression testing performed to verify and validate the modifications. Werecommendthatyousubmityourtestplans,pass/failcriteria,andsummary results rather than test data. In all cases, the type of software-related documentation and the level of detail you provide should be appropriate to the Level of Concern associated with your device in thecontextofthemodifications. SinceaSpecial510(k)submissionreliesonyourdeclarationof conformance to design controls, we believe you cannot properly submit a Special 510(k) until you have completed testing or other activities relied on by your declaration (see section 514(c)(1)(B) of the Federal Food, Drug, and Cosmetic Act (Act) (21 U.S.C. 360d(c)(1)(B)).
다크나이트 조커 피규어 (0) | 2020.06.22 |
---|---|
의료용 펌프 전문가 (0) | 2019.03.22 |
국내 의료기기 담당자를 찾아서... (0) | 2019.03.22 |
미국의 의료기기 법제에 관한 분석 (0) | 2019.01.30 |
Breakthrough Medical Device (0) | 2019.01.21 |
다크나이트 조커 피규어 (0) | 2020.06.22 |
---|---|
의료용 펌프 전문가 (0) | 2019.03.22 |
국내 의료기기 담당자를 찾아서... (0) | 2019.03.22 |
미국의 의료기기 법제에 관한 분석 (0) | 2019.01.30 |
FDA의 의료기기 SRS (1) | 2019.01.28 |