헬스 케어 IT 팀에 '애자일'을 적용 할 수 있습니까?

Agile을 Healthcare IT와 같은 분야에서 사용할 수 있습니까? 많은 환자 치료가 시스템의 품질과 적시 제공에 달려 있습니까?

예. 민첩한 개발은 헬스 케어 IT 개발에서 절대적으로 중요한 역할을합니다. 최종 사용자가 아닌 환자가 아니며 개발 팀이 아닌 사람은 제대로 수행되지 않은 개발 프로세스를 잘 수행하지 못합니다. 애자일 선언문의 기초가되는 몇 가지 원칙을 고려할 때 (나의 논평과 함께 Wikipedia에서 뻔뻔스럽게 찢어진 목록) :

• 유용한 소프트웨어를 신속하게 제공하여 고객 만족 . 언제 목표가 아닌가?
• 심지어 개발 후반에도 변화하는 요구 사항을 환영합니다 . 헬스 케어 IT는 기술에 절대적으로 영향을 미치지 않지만 특히 IT에 중점을 두지 않는 분야에 통합됩니다. 배트에서 바로 "올바로"얻을 수있는 시스템의 가능성은 매우 낮습니다.
• 작동하는 소프트웨어는 자주 제공됩니다 (몇 달이 아닌 몇 주) . 이 물건의 최종 사용자로서, 나는 이것을 좋아할 것입니다. 빠르게 변화하는 업무 변화는 매우 중요하며 Healthcare IT를 "우리가해야하는 것"에서 "내 업무 방식을 변화시키는 것"으로 바꾸는 것은 무엇입니까?
• 작동하는 소프트웨어는 주요한 진전 척도입니다 . 대부분의 응용 프로그램에서 의미가 있으므로 HIT에 적용되지 않을 이유가 없습니다.
• 지속 가능한 개발, 일정한 속도를 유지할 수 있습니다. 감염 감시부터 HIT, 시설에 이르기까지 모든 의료 분야에서 이러한 상황을 볼 수 있습니다. 건강 관리는 붐이나 버스트주기가 아니며 끊임없는 드럼 비트입니다.
• 비즈니스 사람과 개발자 간의 긴밀한 협력 . 대부분의 HIT는 개발자 도구가 아닙니다. 개발자가 만든 도구입니다. 고객과의 접촉은 열쇠이며 반드시 있어야합니다. 시스템을 작동시키고 클라이언트 워크 플로에 통합하면 시스템을 채택하거나 패치하는 것보다 훨씬 쉽게 시스템을 채택 할 수 있습니다.
• 대면 대화는 가장 좋은 형태의 의사 소통 (공동 위치) 입니다. 임상의와의 상호 작용을 통해 다른 방법보다 종이 패드로 직접 작업 하는 것이 훨씬 쉽습니다.
• 프로젝트는 신뢰할 수있는 동기 부여 된 개인을 중심으로 구축됩니다 . 이것은 당신의 삶을 더 좋게 만들어 줄 것입니다. 그래서 채택해야합니다.)
• 우수한 기술과 우수한 디자인에 대한 지속적인 관심 . 이것은 다시 "모든 사람이해야하므로 당연히해야 할 것"중 하나입니다. 그러나 HIT 시스템의 복잡성과 하루 종일 매일 사용되는 무수한 방법을 고려하십시오. 혼란스러운 시스템은 그것을 자르지 않을 것입니다.
• 단순성 . 그것은 즉시 작동해야합니다. 항상 잘 작동해야합니다. 사람들은 바보입니다. 의료 종사자는 사람들입니다. 따라서 ... 당신은 나머지를 알고 있습니다. 단순성이 도움이됩니다.
• 자기 조직 팀 . 이것은 HIT에 대한 약간의 스트레칭 일 수 있습니다. 솔직히, 나는이 환경에서 자체 조직이 좋은지 아닌지 어떤 식 으로든 말할 수 있다고 확신하지 않습니다.
• 변화하는 환경에 대한 정기적 인 적응 . HIT는 복잡하고 변화하는 규제 부담이있는 활발한 산업입니다. 적응할 수 있다는 것은 괜찮은 생각처럼 보입니다.

FDA 규제 환경에서 Agile Medical Device Software Development 를 사용하는 것에 대한 논의 는 잠시 동안 진행되었으며이 질문과 관련이 있습니다. 몇 가지 이유는 다음과 같습니다.

1. Waterfall vs. 반복 개발 장단점은 본질적으로 동일하며 모든 Health IT 프로젝트에 대해 고려해야합니다.
2. 사용되는 의료 기기 소프트웨어 개발에 대한 FDA 의무 품질 시스템 ( 소프트웨어 검증의 일반 원칙; 산업 및 FDA 직원에 대한 최종 지침 참조 )은 산업 금 표준입니다. 이 규정은 특정 개발 방법론을 지시하지 않습니다. 어쨌든 이러한 모범 사례를 모두 준수하면 Health IT 소프트웨어의 품질이 크게 향상됩니다.
3. 대부분의 Heath IT 소프트웨어 개발은 ​​현재 이러한 FDA 규제 표준에 따라 작동하지 않습니다. 의료 기기 상호 운용성, 특히 모바일 플랫폼에 대한 장벽이 계속 감소함에 따라 변경 될 가능성이 있습니다 ( FDA 주소 모바일 의료 앱 참조) .
4. 또한 상용 Health IT 소프트웨어를 개발하는 경우 의료 기기 데이터 시스템 (MDDS)을 작성 중인지 자문해야합니다. 내 제품이 MDDS입니까?

짧은 대답은 "예"입니다. 더 길지만 더 정확한 답변은 "심각하게 생각하면"입니다.

명심해야 할 몇 가지 주제가 있는데, 나는 (a) 환자 안전 및 제품 품질 및 (b) 산업 규제와 관련된 우려로 분리하고 싶다.

안전 및 품질 측면에서는 안전한 소프트웨어를 만드는 것이 어렵다는 점을 명심하십시오. 도메인에 대한 지식이있는 몇몇 훌륭한 프로그래머는 매우 안전한 유용한 소프트웨어를 사용할 수 있습니다. 이들이 로컬 임상 환경에서 배치의 일부이고 소프트웨어의 배치 및 사용 중에 이벤트에 계속 응답하고 조정할 수있는 경우, 소프트웨어는 가치를 제공하고 몇 가지 부상이나 사망으로 생명을 구하거나 개선하여 사용 오류와 관련 될 수 있습니다 또는 소프트웨어 버그. 그러나 소프트웨어는 프로그래머가 소프트웨어의 사용이 진화함에 따라 항상 소프트웨어에 응답하고 함께 진화 할 것을 요구합니다. 이것은 확장 가능한 프로세스가 아니며 프로그래머가 죽거나 지루해질 때 시스템은 매우 빠르게 매우 위험해질 수 있습니다. 이러한 결과를 개선하고 안전한 소프트웨어를 만들기 위해 소프트웨어를 개발하는 동안 수행해야하는 중요한 개발 프로세스 단계가 있습니다. 의료 장비 소프트웨어, ISO / IEC 62304 개발을위한 국제 표준에서 "제외"에 대한 좋은 소개를 찾을 수 있습니다. 주요 개념은 모든 단계에서 사용 사례 분석 및 스토리 개발, 요구 사항 중 안전 위험 관리입니다. 설명, 시스템 및 건축 설계, 구현, 단위 및 통합 테스트. 민첩성을 갖추면 이러한 작업이 사라지거나 덜 어려워지지는 않지만 가치 창출에 집중하고 가치를 창출하지 않는 불필요한 작업 (예 : 불필요한 기능 또는 과도한 검증 테스트 / 수정주기)을 제거함으로써 민첩한 개발이 가능합니다. 팀이이 작업을 개발에 통합하여보다 안전한 소프트웨어를 동시에 개발할 수 있습니다. 애자일 팀이 일반적으로 사용하는 반복적 인 개발 관행은 안전 위험 관리 작업을 수행하는 데 매우 적합하며 사후에 생각하지 않고 프로젝트 수명 전체에 걸쳐 발전합니다. 소프트웨어가 작동 한 후에는 소프트웨어를 안전하게 사용하기 위해 사용자의 의견과 부상을 초래할 수있는 모든 이벤트를 개별적으로 그리고 종합적으로 고려해야합니다. 애자일은 시스템의 다른 부분을 훼손하지 않고 변경 사항을 신속하고 안전하게 통합 할 수있는 프로세스를 제공하는 데 도움이 될 수 있습니다. 다시 한 번 소프트웨어를 개발할 때 만들어진 우수한 아키텍처와 이해하기 쉬운 설계 상호 작용이 필요합니다. 사후에 생각하지 않고 프로젝트의 수명 전체에 걸쳐 진화합니다. 소프트웨어가 작동 한 후에는 소프트웨어를 안전하게 사용하기 위해 사용자의 의견과 부상을 초래할 수있는 모든 이벤트를 개별적으로 그리고 종합적으로 고려해야합니다. 애자일은 시스템의 다른 부분을 훼손하지 않고 변경 사항을 신속하고 안전하게 통합 할 수있는 프로세스를 제공하는 데 도움이 될 수 있습니다. 다시 한 번 소프트웨어를 개발할 때 만들어진 우수한 아키텍처와 이해하기 쉬운 설계 상호 작용이 필요합니다. 사후에 생각하지 않고 프로젝트의 수명 전체에 걸쳐 진화합니다. 소프트웨어가 작동 한 후에는 소프트웨어를 안전하게 사용하기 위해 사용자의 의견과 부상을 초래할 수있는 모든 이벤트를 개별적으로 그리고 종합적으로 고려해야합니다. 애자일은 시스템의 다른 부분을 훼손하지 않고 변경 사항을 신속하고 안전하게 통합 할 수있는 프로세스를 제공하는 데 도움이 될 수 있습니다. 다시 한 번 소프트웨어를 개발할 때 만들어진 우수한 아키텍처와 이해하기 쉬운 설계 상호 작용이 필요합니다.

두 번째 관심사는 규제입니다. 이상적인 세상에서 안전 규정은 충분히 위험 할 수있는 모든 제품에 적용되며, 공급 업체는 일단 라인을 통과하기 시작하면 몇 가지 간단한 작업을 수행하여 준수 할 수 있습니다. 실제로,이 업계에서 국제 규정은 복잡하고 빠르게 변화하고 있습니다. 언젠가 의료 데이터를 보여주는 작은 iPhone 앱을 개발할 수 있으며 다음에는 "품질 관리"에 대한 ISO 및 FDA 표준을 준수해야합니다. 시스템 "또는 QMS. 과거에는 공식 QMS를 가지고 있지 않은 회사에게는 무섭습니다. 또한 제품 개념으로 시작하여 민첩하게 의도 된 규제 용도 (예 : 임상 진단 데이터를 사용자에게 표시)로 발전시켜 민첩성이이를 악화시킬 수 있습니다. 2011 년 10 월입니다. 범주 이름에 "건강", "의료", "건강 관리"가있는 제품을 마케팅하려는 회사에 대한 조언은 전 세계에서 하나 이상의 의료 기기 규제 기관에 의해 제품이 규제되는시기를 계획해야한다는 것입니다. 민첩한 관행은 일반적으로 규정 준수 출력을 생산 (또는 쉽게 생산할 수 있음)하여 시장 출시 전 제출 (FDA 510k 등), 인증 (ISO 13485 등) 및 시판 후 운영 모두에 대해 규제 고객을 만족시키기 위해 준수 출력을 생성 (또는 쉽게 생성 할 수 있음)하기 때문에 여기에서도 다시 민첩성이 도움이 될 수 있습니다. 테스트 우선 개발은 의료 소프트웨어에 적합합니다. 지속적인 통합, 자동화 된 단위 테스트 및 SCRUM 스프린트 메타 데이터는 위험 관리 및 적절한 검증이 사후뿐만 아니라 개발 프로세스에 반영되었다는 완전한 객관적인 증거를 제공 할 수 있습니다. 대부분의 경우, 민첩성이 "폭포"보다 더 많은 인공물을 생성한다고 생각합니다. 아마도 같은 형식이 아닐 수도 있습니다. 그러나 출력을 만족스러운 레귤레이터로 변환하는 것은 해결하기에는 비교적 작은 문제입니다.

요약하자면 ... 예 버지니아에서는 헬스 케어 IT (및 기타 의료 기기) 소프트웨어 개발에 민첩성이 있습니다. 민첩한 모든 것과 마찬가지로 처리, 비즈니스 지원 및 용기에 대한 헌신이 필요합니다.

예. 애자일 개발의 전제 중 하나는 고객 참여입니다. 이는 의료 IT 시스템 및 프로세스에서 중요합니다. 건강 관리 IT 부서는 고객 담당자가 관여하고 의사 결정이 환자 치료에 미치는 영향에 대한 정보를 제공 할 경우 더 나은 의사 결정을 내릴 것입니다.

나는 그것이 가능하다고 생각하지만, 업계는 거대한 패러다임 전환이 필요합니다. 저는 2 년째에 건강 관리 개발자로서 신뢰와 자기 조직이 명백한 곳이 아닙니다. 헬스 케어는 공식적으로 민첩성을 채택하는 데 큰 도움이 될 것입니다. 어쨌든 대규모 설계 초기에는 효과가 없기 때문에 "스 래시"라고하는 반복 개발과 늦게 변화하는 요구 사항으로 인해 혼란에 빠지기 때문입니다.

나는 당신의 질문을 이해합니다. 애자일 개발의 좋은 예는 누군가를위한 웹 사이트를 구축하는 것입니다. 일반적으로 고객은 자신이 원하는 것을 정확히 알지 못하므로 고객과 많은 상호 작용이 있습니다.

헬스 케어 IT는 컴퓨터 과학에서 매우 사전 정의 된 분야처럼 보일 수 있습니다. 엄격한 표준 (DICOM, HL7)을 사용하면 표준을 구현하는 한 가지 방법이있는 것처럼 보이지만 선호도 및 의사 결정이 많이 있습니다.

제 생각에는, 어떤 제품을 만들고 있더라도 미리 모든 요구 사항 을 결정할 수는 없으므로 민첩한 소프트웨어 개발 방법이 매우 훌륭하게 작동합니다.

언급했듯이 대답은 '예'입니다.

규제 또는 고위험 영역에 애자일을 적용 할 때는 규제 준수 및 기타 위험 완화 전략이 포함되도록 각 반복에서 "완료"를 정의해야합니다. 예를 들어, QA 문서, 요구 사항 추적 성, 보안 감사 및 기타 반복 작업마다 완료해야하는 작업이 필요할 수 있습니다.

예를 들어, FDA 규제 환경에 민첩한 접근 방식을 적용하기위한 좋은 예술과 실습이 있습니다.

짧은 대답 : 그렇습니다. High-Assurance Environments의 Agile에 대한 유용한 블로그가 있습니다.

그러나 몇 가지 타협이 필요합니다. 민첩한 선언을 고려하십시오 .

프로세스 및 도구에 대한 개인 및 상호 작용

포괄적 인 문서에 대한 작업 소프트웨어

계약 협상을 통한 고객 협업

계획 에 따라 변경에 응답

규제 기관은 민첩한 팀만큼 왼쪽을 중요하게 생각하지만 일반적인 민첩한 팀보다 오른쪽을 강조해야합니다. 예를 들어 FDA는 공정 및 도구의 유효성을 검사하고 상당히 포괄적 인 설계 및 테스트 문서를 요구하며 많은 계획이 필요합니다.

반대로 많은 민첩한 원칙은 다음을 포함하여 의료 분야에 매우 적합합니다.

• TDD 및 페어 프로그래밍-품질 향상
• 엄격한 고객 피드백 루프-조기 검증이 훌륭합니다
• 반복 계획-규제 기관은 계획에 관한 모든 것

일부 학문은 이미 자연스럽게 민첩합니다. 예를 들어, 간호는 최종 결과를 점진적으로 달성하기 위해 진단 / 예후의 여러 반복에 의존하는 '평가-평가-계획-개입'주기에 의존합니다.

그러나, 그러한 방식으로 제공된 건강 관리 서비스가 상기 서비스 제공에 사용하기위한 소프트웨어 툴 또는 시스템에 대한 애자일 소프트웨어 개발의 본질적으로 단일 인스턴스 적용에 특히 적합하다는 것을 제안하는 것은 치명적인 혼란 일 것이다.

AAMI 는 AAMI TIR SW1 이라는 제목의 기술 정보 보고서 , 의료 기기 소프트웨어 개발에서 민첩한 관행 사용에 관한 지침을 적극적으로 연구하고
있습니다.

2012 년에 출판 될 수 있다고 들었습니다.

또한 Agile Manifesto (EpiGrads 답변 참조)의 원칙을 의료 기기 소프트웨어와 관련된 규제 요구 사항, 일반적인 프로세스 및 기타 제품 실용성과 맞추는 방법에 대해 설명합니다.