Level : 13,720 WORDPRESS BOOK LINKEDIN PATENT Send Mail 동냥하기 윤지오

Digital Nomad

서강대 신운섭 교수 




 전기삼투펌프, 센서

 의료펌프, 분석용 펌프

 이산화탄소 전환기술, 배터리

 환경, 에너지

1.A Miniature, Nongassing Electroosmotic Pump Operating at 0.5 V - J. Am. Chem. Soc. 2011, 133, 2374–2377
2.Reduction of CO2 to CO at Low Overpotential in Neutral Aqueous Solution by a Ni(cyclam) Complex Attached to Poly(allylamine) - ChemSusChem. 2012, 5, 634-636
3.From Fundamental Science to Product Development: An Electrochemical Paradigm - ChemPhysChem. 2013, 4, 2007-2008
1.Electro-osmotic Pumps, Systems, Methods, and Compositions - WO 2011/112723
2.Electrochemical Reduction Method of Carbon Dioxide Using Solution Containing Potassium Sulfate - KR 10-1372532

홈페이지 : http://sgbnel.sogang.ac.kr/


케어메디 주소 


회사주소(04107) 서울 마포구 백범로 35 서강대학교 떼이야르관 415호
인근전철서울 6호선 대흥1번 출구 에서 500m 이내


체내이식형 약물주입 펌프는 극심한 고통에 시달리는 만성통증 환자 및 말기암 환자들에게 이식된 펌프와 카테터를 통해 척수강(Spinal cord)에 직접 모르핀을 자동적으로 주입할 수 있는 표적약물전달(Target Delivery) 장치이다. 

이는 구강투여의 1/300, 정맥투여의 1/100 정도의 양으로 동일한 약효를 나타내며, 약물 확산의 최소화로 부작용도 적다. 또한 펌프가 체내에 이식돼 있기 때문에 환자의 일상생활을 가능하도록 한 장점을 가진다.


케어메디는 혁신적인 펌프 기술 기반의 의료기기 개발로 인류의 삶의 질 향상에 기여하고자 하는 목표를 가지고 설립된 의료기기 개발 회사입니다. 
가스 발생 없는 전기삼투펌프의 원천기술을 확보하여 이를 기반으로 배터리 구동 가능한 초소형, 저전력형의 체내 이식형 약물펌프를 개발 중에 있으며, 그 외에도 패치형 펌프와 소형 정량 펌프도 함께 개발되고 있어 다양한 분야에 사용될 수 있도록 비즈니스모델을 확장해 나가고 있습니다. 
대표자신운섭, 황선주
TIPS 선정2017.11


팁스 선정 http://www.jointips.or.kr/bbs/board.php?bo_table=team&wr_id=432

유사 기업
이오플로우 http://www.jointips.or.kr/resources/ir2017/#/67

Comment +0

백윤정 교수




신운섭 교수


Comment +0

박정연 교수님 자료

국내 의료기기 연관된 모든 사람들이 필독해야 할 문서.

미국의 의료기기 법제에 관한 분석.pdf

Comment +0

오래된 문서긴 하다. 파일은 첨부하였음.

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.


그리고 다음 내용이 있어야 한다.

  1. 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


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:

    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


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


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.


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:


  • 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


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)).



Comment +1

원문 : https://www.bioin.or.kr


FDA, 혁신적인 기기 프로그램(Breakthrough Devices Program) 실행을 위한 가이드라인 초안 발표

             FDA는 연방  식품,  의약품    화장품법(The Federal Food, Drug, and Cosmetic Act. section 515B) 21세기   치료법(21st  Century  Cures  Act, section 3051) 등을 이행하고, 혁신적인  의료기기가  빠르게  환자들에게  보급될 수 있도록 하는 혁신적인  기기 프로그램* 가이드라인 초안(Breakthrough Devices Program Draft Guidance) 발표(2017.10.25)

*   생명을 위협하거나 회복할 없을 만큼의 쇠약한 질환이나 상태에 대해 효과적인 진단과 치료를 위해 제공되는 특정 의료기기에 대한 인허가 프로그램

             상기 프로그램은 FDA의 신속접근 경로(Expedited Access Pathway, EPA)*와 우선검토 프로그램(Priority Review Program)** 대체

*   의약품 신속처리 프로그램(FDA drug expedited programs)과 유사한 것으로, 기기 인증에 필요한 데이터 일부를 시판 추적과정을  통해  수집함으로써  조기에  시장 출시 가능

** 대체 치료법이 없는 의료기기에 대한 우선검토 시행

혁신적인 기기 프로그램의 주요 원칙

            쌍방향의 시의적절한 소통(Interactive and Timely Communication)

-   FDA는 의료기기 개발  또는 검토과정에서  개발업체와 시의적절한 상호  의사소통 기회를 가질 계획

※ FDA는 다양한 규제의사결정을 도달하기 위해서 외부전문가나 자문위원회와 소통 필요

-   또한 FDA와 개발업체 최선의 대화를 위해 사전 준비사항* 언급

* 모든 문서를 대화식(document being revised interactively)으로 수정, 합의점을 문서화하기 위한 요약표 작성 등

            시판 전/후 데이터 수집(Pre/Postmarket Balance of Data Collection)

-   조기 시장출시(PMA)의 대상이 되는 모든 기기들은 안전성과 유효성에 대한 합리적인 법적 표준을 충족

-   FDA는 시판 전의 불확실성 수준에서 유익성과 위해성을 평가하기보다는  시판 후  시장에서  관련  데이터를  수집하는  것이  효율적이고,  적절한 사후시장 통제장치가 필요하다고 언급

            효율적이고 유연한 임상시험 설계(Efficient and Flexible Clinical Study Design)

-   임상시험이 과학적으로 적절하게 설계*되었을 때는 효율적이고 유연하게 임상이 진행될 수 있도록 조치

* (예) 임상적으로 최소한의 의미가 있는 목표 설정 경우, 단계별 연구 설계 등

            검토팀 지원(Review Team Support)

-   접수된 혁신적 의료기기에 대해 FDA에서는 해당과제를 신속하고 대화식으로 해결할 있는 전문인력을 배정하여 검토팀을 구성・지원

            우선순위 검토(Priority Review)

-   혁신적인 기기로 지정된 기기는 우선적 검토대상이 되며, 대기열 상단에 위치하여 필요한 경우에는 추가 검토지원을 받을 계획

과거  FDA의  우선순위  검토  프로그램에서는  ‘공공  보건’에  중점을   두어   검토시간이 오래 발생한 경우 간혹 존재 ⇨ FDA와 개발업체 간 상호소통 등

통해  다른  프로그램보다 더 시기적절하게 시장출시 가능

혁신적인 기기 프로그램의 특징

             FDA는 혁신적인 기기의 안전성과 효과성을 최선으로 평가하기 위해 개발 업체와 평가 초기부터 정기적인 상호작용 기회를 가짐

            혁신적 기기를 위한 속결토론(Breakthrough Device Sprint Discussion)

-    FDA는 정해진  기간(예, 45일) 내에  특정주제에  대한  상호합의  도달을 목표로 하는 속결토론을 제공

※ 속결토론의 참여자 수 및 형식 등은 프로젝트에 따라 다를 수 있으며, 토론  중에  개발업체는 초기  제안서를  추가로  수정  가능.  ①  하나의  주제만  있

어야  하며,  ② 정해진 종료일자 필요, FDA는 토론이 끝난 개발업체에게 요약 피드백을 제공

            데이터 개발 계획(Data Development Plan, DDP)

-   개발업체에 대한 적절한 유연성 제공과 부담을 최소화하기  위해  데이터 개발 계획(DDP)*에 관한 초기합의 내용을 FDA와 조정 가능

* 제품 사이클에 대한 데이터  수집 기대치를  간략하게  설명하여, 예측가능하고 효율적이며 시기적절한 장치에 대한 평가 검토를 지원하기 위한 문서

            규칙적인 업데이트(Regular Status Updates)

-   FDA와 개발업체 간에는 프로젝트 전반의 진척상황과 향후일정  등을  논의 하기 위해 정기적으로 공유자료를 업데이트화(이메일, 원격 회의 등)

혁신적인 기기(Breakthrough Device) 지정기준 및 고려사항

             혁신적인 기기는 생명을 위협하거나 회복할 수 없을 만큼 쇠약하게 하는 질환이나 상태를 보다 효과적으로 치료 진단할 있어야 지정 가능

-   혁신적 기기 지정은 1) 혁신적인 기술이거나, 2) 승인되거나 뚜렷한 대안이 존재하지 않거나, 3) 기존 승인 및  뚜렷한 대안보다  상당한  이점을  보유 하거나,

4) 기기의  가용성이  환자에게  최대이익을  제공하는  4가지  요건  하나를 충족해야 가능

            획기적인 기기 지정 시 고려사항

(1)         효과적인 치료를 위한 기기(Device Provides for More Effective Treatment)

※ 사망 가능성이 높은 질환을 타켓으로 개발업체에서는 문헌이나 데이터 등을 통해 해당기기가 적절한 치료법이라는 것을 제시하여 효과적인 치료장치임을


(2)         획기적인 기술을 대표하는 기기(Device Represents Breakthrough Technology)

※ FDA에서는 진단, 치료, 치유, 완화 또는  생명을  위협하거나  돌이킬  수  없는  쇠약  상태를 예방할 있는 임상적 개선에 대한 잠재력을 기초로 획기적인

 기술을 판단

(3)         승인되거나 뚜렷한 대안이 없는 기기(No Approved or Cleared Alternatives Exist)

※ FDA에서 허가받은 약물, 생물학적 제품, 기기 중에서 사전허가 심사를 받은  것이 있는지에 대한 여부를 고려

(4)         기존 장치보다 상당한 이점 보유(Device Offers Significant Advantages over Existing Approved or Cleared Alternatives)

(5)         환자에게 최대이익 제공(Device Availability is in the Best Interest of Patients)

지정철회(Designation Withdrawal) 사유

            개발업체는 언제든지 해당 프로그램을 철회하도록 FDA에 서면요청 가능

-   단, FDA에서는 ‘연방 식품, 의약품 및 화장품법’에 의거하여 다른 획기적 치료기기 또는 우선검토를 받은 기기를 기준으로 철회하지 않을 수도 있음

             FDA에서는 더 이상 획기적 기기로 지정받을 자격이 없다고 결정이 되면, 개발업체에게 서면통지를 통해 언제든지 지정을 철회 가능

※ (예) FDA에 제출된 정보가 허위진술이거나 중요한 사실이 누락된 경우 등

Comment +0

var ie7 = 0;