Apache JMeter는 부하 테스트 (load test) 기능과 성능 측정을 위해 만들어진 100% 순수 자바, 오픈소스 소프트웨어 어플리케이션이다. 원래는 웹 어플리케이션 테스트를 위해 고안되었지만, 다른 테스트를 위해 기능이 확장되었다.

Apache JMeter 로 할 수 있는것들

Apache JMeter 는 정적/동적 리소스의 성능 측정을 하기위해 사용될 수 있다. 서버, 서버 그룹, 네트워크 또는 객체에 대한 무거운 부하를 시뮬레이션하여 강도를 테스트하거나 다양한 부하 유형에서 전반적인 성능을 분석하는 데 사용할 수 있다.

JMeter Download

다음 링크에 접속하여 JMeter 어플리케이션을 다운 받아서 사용할 수 있다.

Java JDK : https://java.com/ko/download/ie_manual.jsp?locale=ko

JMeter Archives : https://mirror.navercorp.com/apache//jmeter/binaries/

2021년 4월 기준으로 5.4.1 이 최신 버전이다. 하지만 테스트 환경 및 결과 저장이 되지 않아서 5.2.1 버전으로 테스트를 진행하였다.

• Windows 10

  .zip 파일을 다운 받아서 압축을 해제하기만 하면 JMeter 를 사용할 수 있다. 실행 파일은 압축을 해제한 폴더에서 다음의 경로를 따라가면 있다.

  Desktop\apache-jmeter-5.2.1\bin`jmeter.bat`

  jmeter.bat 를 실행하면 다음과 같이 GUI 버전으로 실행이 된다.

Load testing 을 할때는 GUI 모드를 사용하지 마세요! GUI 모드는 테스트 생성과 테스트 디버딩용 입니다.

1. OSS 웹사이트에서 제공하는 테스트 케이스 입니다.
2. NGINX 서버를 현재 문서와 동일하게 JMeter 를 사용하여 테스트한 결과입니다.
3. 2010년도에 진행된 테스트이기 때문에 버전이 크게 차이가 나겠지만, 어떤식으로 테스트하는지 참고하기 위해서 첨부하겠습니다.

테스트 툴

Apache JMeter(version 5.2.1) : 다운로드 링크 Apache Jmeter는 모든 운영체제에서 사용이 가능하지만, Java 8 버전 이상을 가지고 있어야 합니다. Jmeter는 Windows 10 운영체제에서 EC2에 배포한 Node JS 웹 에플리케이션의 부하 테스트를 위해 사용하였습니다. 2021년 04월 21일 기준으로 Apache Jmeter (version 5.2.1) 는 최신 버전이 아닙니다.

최신 버전은 5.4.1 이지만, 테스트 환경을 파일로 저장해야 하는데, 저장이 되지 않아 더 낮은 버전을 사용하였습니다.

다른 테스트는 GUI를 제공하여 실시간 그래프 및 차트를 볼 수 있지만, 부하 테스트 (Load Test)는 GUI모드를 사용하지 말라는 권장사항이 있습니다.

GUI 모드에서 환경을 설정하면 설정 파일을 저장 할 수 있는데, 이 파일을 이용하여 CLI 모드에서 테스트를 진행할 수 있습니다.

라운드 로빈 방식 (Round Robin Method)

서버에서 들어온 요청을 순서대로 돌아가는 배정하는 방식이다. 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 있고, 서버와의 연결이 오래 지속되지 않는 경우에 활용하기 적합하다.

적용

예시의 server에서 서로 사양이 다르다면 가중치를 다르게 줄 수 있습니다. 더 좋은 사양의 서버에게 높은 가중치를 줄 수 있습니다. weight가 없으면 default로 1로 설정됩니다.

upstream backend {
    server backend1.example.com;
    server backend2.example.com weight=4;
    server backend3.example.com weight=2;
    server backend4.example.com weight=1;
}

IP 해시 방식 (IP Hash Method)

클라이언트의 IP 주소를 특정 서버에서 요청을 처리하는 방식이다. 사용자의 IP를 해싱해 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.

upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    server backend4.example.com;
}

최소 연결 방식 (Least Connection Method)

요청이 들어온 시점에 가장 적은 연결 상태를 보이는 서버에 우선적으로 트래픽을 분배한다. 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합하다.

upstream backend {
    least_conn;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    server backend4.example.com;
}

최소 리스폰 타임 방식(Least Response Time Method)

서버의 현재 연결 상태와 응답 시간을 모두 고려하여 트래픽을 분배하는 방식이다. 가장 적은 연결 상태와 가장 짧은 응답 시간을 보이는 서버에 우선적으로 로드를 배분하는 방식이다.

upstream backend {
    least_conn;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    server backend4.example.com;
}

Generic HASH 방식

요청이 전송되는 서버는 텍스트 문자열, 변수 또는 조합일 수 있는 사용자 정의 키로 결정됩니다.

upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

Random 방식

각 요청은 임의로 선택한 서버로 전달됩니다.

# least_conn – The least number of active connections
upstream backend {
    random two least_time=last_byte;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    server backend4.example.com;
}

Docker-compose 내부 NGINX 사용

nginx.conf 코드

# nginx/nginx.conf

user nginx;
worker_processes 1;

pid         /var/run/nginx.pid;

events {
        worker_connections  1024;
}

http {
        access_log  /var/log/nginx/access.log;
        error_log   /var/log/nginx/error.log;

        include       /etc/nginx/mime.types;
        default_type  application/octet-stream;

        upstream nodeApps {
                server node-app1:3000;
                server node-app2:3000;
                server node-app3:3000;
        }

        server {
                listen 80;
                server_name http://localhost;

                location / {
                        proxy_pass         http://nodeApps;
                        proxy_redirect     off;
                        proxy_set_header   Host $host;
                        proxy_set_header   X-Real-IP $remote_addr;
                        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                }
        }

        sendfile        on;
        keepalive_timeout  65;
}

독립적인 NGINX 와 Docker-Compose Node Web Application 사용

nginx.conf

# nginx/nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
        worker_connections 1024;
}

http {

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 10;
        types_hash_max_size 2048;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;
}

node.conf

# conf.d/node.conf
server {
        listen 80;
        server_name localhost;

        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_set_header X-NginX-Proxy true;

                proxy_pass http://nodeApps;
                proxy_redirect off;
        }


}

upstream nodeApps {
        server 172.20.0.5:3000;
        server 172.20.0.6:3000;
        server 172.20.0.7:3000;
}

참고

1. Nginx Beginner's Guide : http://nginx.org/en/docs/beginners_guide.html
2. O'Reilly's Nginx Cook book 2019 (무료 배포 버전): https://www.nginx.com/wp-content/uploads/2017/07/Complete-NGINX-Cookbook-2019.pdf
3. Nginx 소개 : https://www.nginx.com/resources/glossary/nginx/
4. Nginx Directives: http://nginx.org/en/docs/http/ngx_http_upstream_module.html https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
5. Load-balancing Methods : https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/
6. Nginx Embadded Variables : http://nginx.org/en/docs/http/ngx_http_core_module.html#variables https://www.javatpoint.com/nginx-variables
7. OSS - NGINX 소개서 : https://www.oss.kr/storage/app/public/oss/78/97/[Nginx]%20Solution%20Guide%20V0.95.pdf
8. NGINX 권장사양 : https://docs.nginx.com/nginx-controller/admin-guides/install/nginx-controller-tech-specs/

• user : 시스템의 어떤 사용자가 NGINX 서버를 동작시킬지 결정 (root로 설정하면 보안에 취약점이 생길수도 있음)
• worker_processes : 몇 개의 thread가 사용될지 정의한다. CPU 코어 수에 맞추는것을 권장하지만, * CPU 코어 수 보다 높은 수를 넣어도 에러가 나지 않는다.
• pid : NGINX 의 pid 정보가 있는 파일
• include : 외부 configuration 내용을 가져온다. 모듈에 따라 다른 파일에 작성하여 include 하는것을 권장한다.

block directive

• simple directive와 구성이 동일하지만 ';' (세미콜론) 대신 추가적인 내용들이 { } 안에 있다. events { } : 일반적인 connection process를 담당한다. http { } : http 트래픽을 담당한다. main { } : 메일 트래픽을 담당한다. stream { } : TCP / UDP 트래픽을 담당한다.

NGX_HTTP_UPSTREAM_MODULE

proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass 및 grpc_passdirectives에서 참조할 수 있는 서버 그룹을 정의하는 데 사용됩니다.

• upstream 서버 그룹을 정의합니다. 서버는 서로 다른 포트에서 수신 대기할 수 있습니다. 또한 TCP와 UNIX 도메인 소켓에서 수신하는 서버를 혼합할 수 있습니다.

요청은 Default로 가중 라운드 로빈 방식을 사용하여 서버 간에 분산됩니다.

# 다음 명령어 실행
$ sudo apt update
$ sudo apt install nginx

Ubuntu 20.04 에서 Nginx 설정하기

Nginx 시스템 서비스 등록 및 동작

# 참고
$ sudo service nginx start # 서비스 실행
$ sudo service nginx stop  # 서비스 중단
$ sudo service nginx restart # 서비스 재시작

Nginx 파일의 구조

/etc/nginx

├── conf.d 
├── fastcgi.conf 
├── fastcgi_params
├── koi-utf
├── koi-win
├── mime.types
├── nginx.conf 
├── proxy_params
├── scgi_params
├── sites-available 
│   └── default
├── sites-enabled
│   └── default -> /etc/nginx/sites-available/default
├── snippets
│   ├── fastcgi-php.conf
│   └── snakeoil.conf
├── uwsgi_params
└── win-utf

nginx.conf 파일

Nginx 의 동작과 기본 환경설정을 nginx.conf 파일에 정의해야 한다. nginx.conf 환경설정 파일은 관리자 권한으로 편집하거나 프로그램으로 분석할 수 있는 텍스트 파일이고, 여러가지 값을 지정해 프로그램의 동작 방법을 결정한다.

nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
       ...
}

http {
       ...
}

Nginx 파일 및 디렉토리

/etc/nginx/

NGINX 서버의 기본 환경설정 루트입니다. 이 디렉토리에서 NGINX에게 동작 방법을 지시하는 구성 파일을 찾을 수 있습니다.

/etc/nginx/nginx.conf

NGINX 서비스에서 사용하는 기본 환경 진입점(Entry-Point)입니다. 이 구성 파일은 작업자 프로세스, 튜닝, 로깅, 동적 모듈 로드 및 기타 NGINX 구성 파일에 대한 참조와 같은 전역 설정을 설정합니다. 기본 구성에서 /etc/nginx/nginx.conf 파일에는 다음에 설명된 디렉터리에 있는 모든 구성 파일이 포함된 최상위 http 블록이 포함됩니다.

/var/log/nginx

NGINX의 기본 로그 위치입니다. 이 디렉토리에서 access.log 파일과 error.log 파일을 찾을 수 있습니다. 액세스 로그에는 NGINX가 제공하는 각 요청에 대한 항목이 포함됩니다. 오류 로그 파일에는 디버그 모듈이 활성화된 경우 오류 이벤트 및 디버그 정보가 포함됩니다.

/etc/nginx/nginx.d

기본 HTTP 서버 구성 파일이 포함되어 있습니다. .conf로 끝나는 이 디렉토리의 파일은 etc/nginx/nginx.conf 파일 내에서 최상위 수준의 http 블록에 포함됩니다. 구성 파일을 간결하게 유지하려면 포함 문을 활용하고 구성을 구성하는 것이 좋습니다.

Deprecated Convention 일부 패키지 저장소에서는 이 폴더의 이름이 site-enable이고 구성 파일은 site-available 폴더에서 연결됩니다.

1. AWS EC2 인스턴스 ( t2.micro )
2. OS: Ubuntu 20.04
3. Nginx 사용 버전 : nginx-1.19.10

NGINX 최소 및 권장 사양

지원되는 배포판

지원되는 브라우저

주의 !! NGINX 컨트롤러 사용자 인터페이스를 사용하는 동안 광고 차단기를 꺼야 할 수도 있습니다.

• Google Chrome
• Firefox
• Safari
• Internet Explorer and Microsoft Edge

문서 작성 목적

매크로 처리 오류 'jira' : 이 매크로에 대한 Jira Server를 찾을 수 없습니다. 
응용프로그램 링크 구성 때문일 수 있습니다.

위의 작업을 통해 Node JS 웹 어플리케이션을 배포하기 위해 효율적인 방법을 찾던 중 다음을 조건으로 Nginx 를 선정하였음. 2020년 - 2021년 점유율이 높은 웹서버 프록시 서버 기능 로드밸런싱 기능

Nginx 주요기능

systemd 에 python (venv) 서비스 등록 SSH를 종료하면 venv 프로세스가 종료되는 현상이 발생하여 Kallithea를 자동으로 시작하는 서비스를 등록하기로 함.

권장사항

Kallithea 는 Unix/Linux 환경에 설치를 진행할 경우 가상환경 (Virtual environment)을 이용할것을 가장 권장한다.

그 이유는 다음과 같다:

Kallithea 설치에 별도의 Virtual Environment (가상환경)을 사용하는 것이 좋습니다. 이렇게 하면 Kalithea에 필요한 모든 라이브러리는 기본 Python 설치와 별도로 설치되고 다른 응용 프로그램 및 Kalithea를 업그레이드할 때 문제가 덜 발생합니다. 가상 환경의 또 다른 이점은 루트 권한이 필요하지 않다는 것입니다.

작업 내용

Kallithea 전용 EC2 인스턴스 Kallithea 설치 경로 /path/to/kallithea_070 내부에서 kallithea_070 가상환경을 사용하여 서버를 실행시킴

/etc/systemd/system 경로에 .service 파일 만들기

kallithea@aws-ec2-server:/etc/systemd/system$ cat kallithea.service
# vi /etc/systemd/system/kallithea.service

[Unit]
Description=Kallithea SCM
After=network.target

[Service]
Type=simple
# 서비스로 동작하면 /data 또는 /repos 중 일부 파일의 소유권이 root 로 저장됩니다.
# 유지보수 및 테스트 환경에서는 사용자 및 그룹을 ubuntu 로 설정해서 사용하시길 바랍니다.
# User=root
# Group=root
User=ubuntu
Group=ubuntu
ExecStart=/bin/sh /path/to/kallithea_070/start-kallithea.sh
TimeoutSec=600
Restart=on-failure
RuntimeDirectoryMode=755

[Install]
WantedBy=multi-user.target

start-kallithea.sh 작성 내용

/path/to/kallithea_070:~/kallithea_070$ cat start-kallithea.sh
#!/bin/bash

echo "Kallithea is running"
. "/path/to/kallithea_070/bin/activate"
gearbox serve -c /path/to/kallithea_070/kallithea.ini

권한 변경

# start-kallithea 권한
kallithea@aws-ec2-server:~$ chmod 755 /home/ubuntu/kallithea_070/start-kallithea.sh

# kallithea.service 소유 및 권한
kallithea@aws-ec2-server:~$ sudo chmod 755 /etc/systemd/system/kallithea.service
kallithea@aws-ec2-server:~$ sudo chown root:root /etc/systemd/system/kallithea.service

Kallithea 서비스 등록 및 실행

kallithea@aws-ec2-server:~$ sudo systemctl enable kallithea.service
kallithea@aws-ec2-server:~$ sudo systemctl daemon-reload
kallithea@aws-ec2-server:~$ sudo systemctl start
kallithea@aws-ec2-server:~$ sudo systemctl start kallithea.service
kallithea@aws-ec2-server:~$ sudo systemctl status kallithea.service
● kallithea.service - Kallithea SCM
     Loaded: loaded (/etc/systemd/system/kallithea.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-06-09 01:37:13 UTC; 2h 6min ago
   Main PID: 339830 (sh)
      Tasks: 2 (limit: 4638)
     Memory: 81.6M
     CGroup: /system.slice/kallithea.service
             ├─339830 /bin/sh /path/to/ubuntu/kallithea_070/start-kallithea.sh
             └─339833 /path/to/kallithea_070/bin/python3 /path/to/kallithea_070/bin/gearbox serve -c /path/to/kallithea_070/kallithea.ini

Jun 09 03:43:07 aws-ec2-server sh[339833]: 2021-06-09 03:43:07.758 DEBUG [sqlalchemy.engine.base.Engine] Row (125, 18, 4, 197, 4, 'repository.write', 35, >
Jun 09 03:43:07 aws-ec2-server sh[339833]: 2021-06-09 03:43:07.758 DEBUG [sqlalchemy.engine.base.Engine] Row (148, 18, 4, 214, 4, 'repository.write', 35, >
Jun 09 03:43:07 aws-ec2-server sh[339833]: 2021-06-09 03:43:07.758 DEBUG [sqlalchemy.engine.base.Engine] Row (143, 18, 4, 210, 4, 'repository.write', 48, >
Jun 09 03:43:07 aws-ec2-server sh[339833]: 2021-06-09 03:43:07.763 INFO  [sqlalchemy.engine.base.Engine] SELECT repo_to_perm.repo_to_perm_id AS repo_to_pe>
Jun 09 03:43:07 aws-ec2-server sh[339833]: FROM repo_to_perm LEFT OUTER JOIN repositories AS repositories_1 ON repositories_1.repo_id = repo_to_perm.repos>
Jun 09 03:43:07 aws-ec2-server sh[339833]: WHERE repo_to_perm.user_id = %(user_id_1)s
Jun 09 03:43:07 aws-ec2-server sh[339833]: 2021-06-09 03:43:07.763 INFO  [sqlalchemy.engine.base.Engine] {'user_id_1': 39}
Jun 09 03:43:07 aws-ec2-server sh[339833]: 2021-06-09 03:43:07.764 DEBUG [sqlalchemy.engine.base.Engine] Col ('repo_to_perm_repo_to_perm_id', 'repo_to_per>
Jun 09 03:43:07 aws-ec2-server sh[339833]: 2021-06-09 03:43:07.765 DEBUG [kallithea.lib.auth] Middleware check areum for {'repository.write', 'repository.>
Jun 09 03:43:07 aws-ec2-server sh[339833]: 2021-06-09 03:43:07.765 INFO  [kallithea.controllers.base] pull action on git repo "Hicare-Smart/v3/HicareM" by>
lines 1-20/20 (END)

Kallithea 서버 환경구성을 위한 명령어 및 설치 순서 입니다.

1. Kallithea를 동작시키 위한 Ubuntu에 필요한 패키지

apt-get

# update & upgrade
sudo apt-get update
sudo apt-get -y upgrade

# 기본 패키기 설치
sudo apt-get install -y build-essential git libffi-dev python3-dev python3-venv npm nodejs

2. Python virtual environment

venv

python3 -m venv kallithea

pip install 모음

pip install Kallithea 
# pip install psycopg2 -> 에러 발생
pip install psycopg2-binary # 정상적으로 설치 완료

3. Kallithea 준비

kallithea-cli

kallithea-cli config-create waitress.my.ini database_engine=postgres http_server=waitress

# waitress.my.ini 파일 생성됨

waitress.my.ini 파일 수정사항

[수정한 라인]
#line 66 → host = 0.0.0.0
#line 72 → threads = 3

#line 362 → sqlalchemy.url = postgresql://{ kallithea user } : { password } @localhost/kallithea

[추가한 라인]

#line 363 → ignore_alembic_revision = True (Kallithea 버전을 변경하면서 alembic 모듈에 등록된 alembic version 이 달라지면서 다음과 같은 애러가 발생할 수 있음)

Kallithea front end 빌드

kallithea-cli front-end-build

Internal Git Repository hooks 다시 받기

kallithea-cli repo-scan -c wiatress.my.ini --install-git-hooks

4. Kallithea를 systemd 서비스 등록

주의사항!!

EC2 인스턴스 환경구성은 ssh 명령어를 통해 진행하는데, Python venv 는 ssh 를 종료하는 동시에 같이 종료됩니다. 따라서 Linux의 Daemon 으로 등록하여 ssh 를 종료하여도 Kallithea가 계속 동작할 수 있게 설정해야 합니다.

서버에 변경 및 수정 사항이 있을때

# 1. kallithea.service 를 멈춘다.
sudo systemctl stop kallithea.service

# 2. kallithea 에 관련된 환경설정 및 서비스 등을 수정한다.
(수정)

# 3. kallithea 편집한 수정파일을 서비스에 반영
sudo systemctl daemon-reload

# 4. 서비스를 수정하고 자동으로 Kallithea가 자동으로 시작되지 않는다면 다음 코드를 실행
sudo systemctl disable kallithea.service
sudo systemctl enable kallithea.service

# 5. Kallithea 서비스를 시작하고 상태를 확인
sudo systemctl start kallithea.service
sudo systemctl status kallithea.service

문서에서 다루는 케이스는 회사 온프레미스 서버에서 AWS EC2 인스턴스로 SCM Kallithea 서버를 이전하는 작업을 다루었습니다.

작업순서

1. 기존 AWS EC2 에 저장되어있는 Kallithea repository 확인

2. docker kallithea container 내부에 /var/kallithea/repos 를 호스트로 옮기기

• host로 repos directory copy 성공
• host 용량부족으로 인해 압축 실패

3.기존 AWS EC2 호스트에 남은 용량을 확인

user@filepath:~$ df . # 남아있는 사용가능한 Storage
Filesystem     1K-blocks      Used Available Use% Mounted on
/path/to/kallithea/nvme0n1p1 304885740 283483000  21386356  93% /

4.기존 AWS EC2 docker 컨테이너에서 repos 를 압축

user@filepath:~$ docker exec -it kallithea bash
root@{docker container id}:/path/to/kallithea/nvme0n1p1/src# cd..
root@{docker container id}:/path/to/kallithea# tar -zcvf repos.tar.gz repos
... 압축 완료 후
root@{docker container id}:/path/to/kallithea# 

5. 새로운 AWS EC2 key 파일을 기존 AWS EC2 로 전송하여 컨테이너 안으로 복사

새로운 인스턴스 접속에 필요한 Key값 전송

scp -i .\${전송 할 파일 이름}.pem .\${전송 받을 파일 이름}.pem ${전송받을 유저 이름}@${전송 받을 서버 ip}:${전송 받을 파일 경로}

기존 서버에서 Key(.pem)파일을 컨테이너 안으로 복사

user@filepath:~$ docker cp ${aws-key}.pem ${docker container kallithea}:/var/kallithea

6. 기존 AWS EC2 인스턴스의 docker kallithea conatiner 에서 새로운 EC2 인스턴스로 repo 압축파일 전송

# 컨테이너로 진입
user@filepath:~$ docker exec -it kallithea bash

# 컨테이너에서 repos.tar.gz 전송
root@{docker container id}:/var/kallithea/src# cd ..

# 주의사항 : EC2 인스턴스에서 인바운드 설정 및 보안설정을 완료한 후에 진행
root@{docker container id}:/var/kallithea# scp -i ${aws-key}.pem repos.tar.gz ${전송받을 유저 이름}@${전송 받을 서버 ip}:${전송 받을 파일 경로}

7.새로 생성한 AWS EC2 인스턴스에 접속하여 Kallithea 서버 repository 전용 directory 생성 후 압축해제

user@ip-aws-ec2:~$ tar -zxvf repos.tar.gz
user@ip-aws-ec2:~$ cd /var
user@ip-aws-ec2:/var$ sudo mkdir kallithea
user@ip-aws-ec2:/var/kallithea$ sudo tar -zxvf ~/repos.tar.gz

8.다음 코드로 kallithea 실행

(kallithea_070) user@ip-aws-ec2:~/kallithea_070$ gearbox serve -c kallithea.ini

일반적인 경우 리눅스 네임스페이스를 직접 활용하는 경우는 많지 않습니다만, 네트워크 테스트나 컨테이너 구현에서 활용됩니다. 리눅스 컨테이너는 리눅스 네임스페이스와 루트 파일 시스템 격리 등 리눅스의 다양한 기능을 사용해 격리시킨 프로세스를 의미합니다.

man page 설명

네임스페이스는 전역 시스템 리소스를 추상화로 감싸고, 이 추상화는 전역 리소스의 고유한 분리된 인스턴스가 있는 네임스페이스 내의 프로세스에 표시합니다. 글로벌 리소스에 대한 변경 내용은 네임스페이스의 구성원인 다른 프로세스에는 표시되지 않지만 다른 프로세스에는 표시되지 않습니다. 네임스페이스의 한 가지 용도는 컨테이너를 구현하는 것입니다.

리눅스의 namespace 는 프로세스를 실행할 때 시스템의 리소스를 분리해서 실행할 수 있도록 도와주는 기능을 합니다. 한 시스템의 프로세스들은 기본적으로 시스템의 리소스를 공유해서 실행됩니다. 리눅스에서 1번 프로세스로 할당되어 있는 namespace들을 자식 프로세스들이 모두 공유해서 사용하는 구조로 이루어져 있습니다.

WSL (Ubuntu 20.04)

/prod//ns 디렉터리에서 현재 프로세스에서 사용하고 있는 네임스페이스의 고유 ID를 확인하는 것이 가능합니다.

# 각 리소스 별 namespace
ubuntu@DESKTOP-xxxx:~$ sudo ls -al /proc/1/ns
total 0
dr-x--x--x 2 root root 0 Jun  2 09:48 .
dr-xr-xr-x 9 root root 0 Jun  2 09:48 ..
lrwxrwxrwx 1 root root 0 Jun  2 09:48 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Jun  2 09:48 ipc -> 'ipc:[4026532187]'
lrwxrwxrwx 1 root root 0 Jun  2 09:48 mnt -> 'mnt:[4026532185]'
lrwxrwxrwx 1 root root 0 Jun  2 09:48 net -> 'net:[4026531992]'
lrwxrwxrwx 1 root root 0 Jun  2 09:48 pid -> 'pid:[4026532188]'
lrwxrwxrwx 1 root root 0 Jun  2 09:48 pid_for_children -> 'pid:[4026532188]'
lrwxrwxrwx 1 root root 0 Jun  2 09:48 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Jun  2 09:48 uts -> 'uts:[4026532186]'

The namespace API

대부분의 경우 clone(2) 및 unshare(2)를 사용하여 새 네임스페이스를 생성하려면 CAP_이 필요합니다. SYS_ADMIN 기능은 새 namespace에서 생성자가 이후에 생성된 다른 프로세스에 표시되는 글로벌 리소스를 변경하거나 네임스페이스에 가입할 수 있는 권한을 가지기 때문입니다. user namespace는 예외입니다.

Linux 3.8부터는 user namespace를만드는 데 권한이 필요하지 않습니다.

The namespace Flag

Namespace 종류

PID namespace

PID 네임스페이스는 프로세스의 ID를 격리할 수 있는 네임스페이스입니다.

리눅스에서 PID는 init 프로세스 1을 시작하며 그 외에 모든 프로세스는 항상 1보다 큰 PID를 부여받습니다.

PID 네임스페이스를 분리하면 PID가 다시 1부터 시작합니다.

단, 이 프로세스는 디폴트 네임스페이스와 분리된 PID 네임스페이스에 동시에 속하게 되며, 분리된 새로운 네임스페이스에서는 PID가 1부터 시작합니다.

하지만 디폴트 네임스페이스 관점에서는 1보다 큰 어떤 값을 PID로 가지게 됩니다.

Network namespace

네트워크 네임스페이스는 프로세스의 네트워크 환경을 분리할 수 있는 네임스페이스입니다.

네트워크 환경을 분리하면 네임스페이스에 속한 프로세스들에 새로운 IP를 부여하거나 네트워크 인터페이스를 추가하는 것이 가능합니다.

네트워크 네임스페이스는 ip 명령어로 조작할 수 있습니다.

UTS namespace

UTS 네임스페이스는 호스트 네임과 NIS 도메인 이름을 격리하는 네임스페이스입니다.

네트워크 네임스페이스와 함께 네트워크를 격리하는 용도로 사용됩니다.

참고

1. Linux Namespace - https://man7.org/linux/man-pages/man7/namespaces.7.html
2. Linux Container - https://www.redhat.com/ko/topics/containers/whats-a-linux-container

해당 서적의 Chapter 1.3 의 OS(Linux) 기초지식 부분을 소개

Docker 에서 주로 사용하는 Linux 파일 시스템에 대해 작성한다. 일반적인 Linux 의 파일 구조를 설명한다.

직접적인 Docker 와 연동은 해당 문서와 관계가 없다. 간략한 Linux 의 디렉터리 구조일뿐, 깊은 수준의 Linux 운영체제에 관한 문서가 아님.

Linux 파일 시스템

Linux 커널이 갖고 있는 중요한 기능으로 파일 시스템이 있습니다. 파일 시스템은 Linux에서 하드디스크나 USB 메모리, CD, DVD 등과 같은 데이터에 액세서 하기 위한 장치 입니다.

보통 컴퓨터가 데이터를 읽어 들일 때는 데이터가 어떤 디스크에 어떻게 저장되어 있는지를 인식해야 합니다. 하지만 데이터를 이용하는 애플리케이션의 관점에서 보면 데이터가 하드디스크에 저장되어 있든지, 플래지 메모리에 저장되어 있든지, 네트워크 너머의 스토리지 서버에 저장되어 있든지 상관없이 투과적으로 액세스할 수 있는 방법이 있다면 편리할 것 입니다.

Linux 커널은 VFS(Virtual File System; 가상 파일 시스템) 이라는 장치를 사용하여 데이터에 대한 투과 액세스를 가능하게 하고 있습니다.

VFS에서는 각 디바이스를 "FILE"로 취급하는 것이 특징입니다.

1. VFS 예시
2. 파일구성 예시

Linux 주요 파일 시스템

Linux 디렉토리 구성

현재 대부분의 주요 배포한은 다음의 FHS(Filesystem Hierarchy Standar)를 바탕으로 디렉토리를 구성하고 있습니다. 하지만 이 규격에 완벽히 준거하여 구성하는것은 아니므로 Linux 배포판에 따라 차이가 있습니다.

Linux의 대표적인 3가지 보안기능

계정에 대한 권한 설정

리눅스에서는 시스템을 이용할 수 있는 사용자 계정에 권한을 설정할 수 있습니다. 권한은 시스템 전체를 관리할 수 있는 특권 사용자인 'root'와 그 외의 일반 사용자가 있습니다. root 는 시스템의 종료나 파일 시스템의 마운트/언마운트, 애플리케이션의 설치와 같은 실행 권한을 가지며, 시스템 전체를 관리할 수 있습니다. 또한 미들웨어와 같은 데몬을 가동시키기 위한 시스템 계정도 작성할 수 있습니다. 시스템 계정은 특정 프로세스를 작동시키기 위한 계정입니다. 사용자가 시스템 계정을 직접 이용하는 경우는 없기 때문에 로그인 할 수 없도록 해 둘 필요가 있습니다. 계정에는 그룹을 설정할 수도 있습니다. 리눅스의 파일이나 디렉토리에 대한 액세스 권한을 계정 및 그룹별로 세세하게 설정할 수 있습니다. 이러한 액세스 권한을 Permission 이라고 합니다.

네트워크 필터링을 사용한 보안

리눅스는 원래 네트워크를 경우하여 멀티유저가 이용하는 것을 전제로 한 OS이기 때문에 네트워크에 관한 기능이 풍부합니다. iptables는 리눅스에 내장된 패킷 필터링 및 네트워크 주소 변환(NAT) 기능을 설정하는 기능입니다. 패킷 필터링이란 패킷이 헤더 부분(송신원 IP 주소와 수신처 IP 주소, 포트 번호 등)을 보고 조건과 일치하면 설정한 액션(전송, 파기, 주소 수정 등) 을 수행하는 것입니다. 방화벽과 같은 역할을 하므로 비정상적인 패킷을 파기할 수 있습니다.

SELinux (Security-Enhanced Linux)

SELinux는 미국 국가안전보장국이 제공하는 Linux 커널에 강제 액세스 제어 기능을 추가한 기능입니다. 리눅스 시스템에서 디렉토리나 파일에 대한 액세스는 퍼미션에 기초하여 허가하고 있습니다. Permission에서는 '오너', '그룹', '기타' 에 대한 각각 '읽기(read)', '쓰기(write)', '실행(execute)' 허가를 설정할 수 있습니다. 하지만 root 사용자는 이러한 권한과 상관없이 모든 액세스가 가능하기 때문에 만약 비밀번호를 도난당하면 시스템에 치명적인 결점이 생기는 셈 입니다. SELinux는 보안 대상에 따라 HTTP/FTP 와 같은 프로세스마다 액세스 제한을 거는 Type Enforcement(TE)와 root도 포함한 모든 사용자에 관해 제어를 거는 RoleBase Access Control(RBAC)등으로 리눅스를 제어합니다. 이렇게 root 사용자에게 권한이 집중되는 것을 막음으로써 보안성이 높은 시스템을 구축할 수 있습니다.

Dockerfile이란 docker에서 이용하는 이미지를 기반으로 하여 새로운 이미지를 스크립트 파일을 통해 내가 설정한 나만의 이미지를 생성할 수 있는 일종의 이미지 설정파일입니다.

즉, Dockerfile은 이미지를 구성하는 지시사항을 포함하고 있고, Docker는 그 지시사항(Dockerifle)을 읽고 이미지를 빌드합니다. Dockerfile은 사용자가 명령행에서 호출하여 이미지를 구성할 수 있는 모든 명령을 포함하는 텍스트 문서입니다.

Dockerfile 사용법

$ docker build .

docker의 build 명령어가 Dockerfile 과 컨텍스트로부터 이미지를 빌드합니다. 빌드 컨텍스트란 지정된 위치의 PATH(로컬 파일, 디렉토리) 또는 URL(Git Repository)의 파일 집합입니다.

컨텍스트는 재귀적으로 진행됩니다. 그래서 PATH는 하위 디렉토리를 포함하고 URL은 서브 모듈과 레포지토리를 모두 포함하게 됩니다.

Dockerfile Path Example

다음과 같은 경로에 Docker file 을 작성한다고 가정합니다.

# workspace/~ 경로

workspace:.
│  .dockerignore
│  .gitignore
│  app.js
│  Dockerfile
│  package-lock.json
│  package.json
│  README.md
│
├─bin
│      www
│
├─controller
│ .....

Dockerfile 내용

# cat Dockerfile
FROM node:latest

RUN mkdir -p /app
WORKDIR /app

ADD ./ /app

RUN npm install

CMD ["npm", "start"]

Docker Daemon Examples

구현 내용 Docker 데몬이 디버그 모드로 실행되고 TLS를 사용하며 포트 8888에서 192.169.xxx.xxx로 라우팅된 트래픽을 수신합니다. dockerd 참조 문서에서 사용할 수 있는 configuration 옵션을 확인할 수 있습니다.

# cat /etc/docker/daemon.json

{
  "debug": true,
  "tls": true,
  "tlscert": "/var/docker/server.pem",
  "tlskey": "/var/docker/serverkey.pem",
  "hosts": ["tcp://192.168.xxx.xxx:8888"]
}

# dockerd 실행
dockerd --debug \
  --tls=true \
  --tlscert=/var/docker/server.pem \
  --tlskey=/var/docker/serverkey.pem \
  --host tcp://192.168.xxx.xxx:8888

참고 Windows default docker 위치 C:\ProgramData\docker\config\daemon.json

Docker는 개발, Shipping, 어플리케이션 실행을 위한 오픈 플랫폼 입니다. Docker는 어플리케이션을 환경(Infrastructure)으로 부터 분리하여 빠르게 전달할 수 있습니다. Docker를 사용하면 배포하고자 하는 어플리케이션의 환경(Infrastructure)을 관리할 수 있습니다. Shipping, 테스팅, 그리고 신속한 코드 배포를 위한 도커의 방법론의 이점을 취함으로써, 코드 작성과 서비스간에 지연시간을 눈에띄게 줄일 수 있습니다.

Docker 의 정체성 : 플랫폼 Docker 가 지향하고 자랑하는 방향성 :

• 신속한 배포,
• 환경 관리,
• 느슨한 환경 분리 (Loosely Isolated Environment) = Container

Docker의 구조

Docker Architecture

The Docker Daemon (dockerd)

Docker Daemon은 Docker API 의 요청(request)을 listen 하고 이미지, 컨테이너, 네트워크, 볼륨과 같은Docker 객체들을 관리합니다. 또한 Docker 서비스를 관리하기위해 통신할 수 있습니다.

The Docker Client (docker)

대부분의 Docker 사용자들이 주요하게 Docker와 상호작용하는 방법 입니다. docker run 과 같은 커맨드를 사용할 때, 클라이언트가 dockerd 에게 명령어들을 전하고 실행합니다. docker 는 Docker API를 사용합니다. Docker 클라이언트는 한개 이상의 Docker Daemon과 통신할 수 있습니다.

Docker Registeries

Docker Registeries 는 Docker 이미지들을 저장합니다. Docker Hub는 누구나 사용할 수 있는 공개 레지스트리이고, default로 Docker Hub에서 이미지들을 찾아보도록 설정되어 있습니다. docker pull 또는 docker run 과 같은 명령어들을 사용할 때, 필요한 이미지들이 설정된 레지스트리에서 받아옵니다. docker push 명령어를 사용하면, 설정된 레지스트리로 올라가게 됩니다.

Docker Objects

Docker를 사용할때 이미지, 컨테이너, 네트워크, 볼륨, 플러그인 그리고 다른 객체들을 생성하고 사용하게 됩니다.

1. Images 이미지는 Docker 컨테이너를 만드는 지시사항이 있는 읽기 전용 템플릿 입니다. 이미지가 다른 이미지를 기반으로 하는경우가 많으며 일부 추가 사용자 지정/설정 이 있습니다. 예를 들어, Ubuntu 이미지를 기반으로 하지만 Apache 웹 서버와 응용 프로그램을 설치하고 응용 프로그램을 실행하는데 필요한 구성 상세 사항을 설치할 수 있습니다. 자신의 이미지를 만들거나 다른 사용자가 만들어 레지스트리에 게시된 이미지만 사용할 수 있습니다. 자신의 이미지를 구축하려면 이미지를 만들고 실행하는데 필요한 단계를 정의하는 구문들 사용하여 Dockerfile 을 작성합니다. Dockerfile 의 각 지시사항은 이미지에 계층(Layer)를 만들게 됩니다. Dockerfile 을 변경하게 되어 이미지를 재구성할 경우 변경된 계층만 재구성 됩니다. 이것은 다른 가상화 기술과 비교하면 매우 가볍고, 작고 빠르게 만드는 요소중 하나입니다.

2. Containers 컨테이너는 실행 가능한 이미지의 인스턴스입니다. Docker API 또는 CLI를 사용하여 컨테이너를 생성, 시작, 중지, 이동 또는 삭제할 수 있습니다. 하나 이상의 네트워크에 컨테이너를 연결하거나, 컨테이너에 스토리지를 연결하거나, 현재 상태에 따라 새 이미지를 생성할 수도 있습니다. 기본적으로 컨테이너는 다른 컨테이너와 해당 호스트 시스템에서 비교적 잘 격리되어 있습니다. 컨테이너의 네트워크, 스토리지 또는 기타 기본 하위 시스템이 다른 컨테이너 또는 호스트 시스템에서 격리되는 방식을 제어할 수 있습니다. 컨테이너는 이미지를 생성하거나 시작할 때 제공하는 구성 옵션뿐만 아니라 이미지에 의해 정의됩니다. 컨테이너가 제거되면 영구 저장소에 저장되지 않은 상태의 모든 변경 사항이 사라집니다.

참고 사항

컨테이너는 docker 만이 가지고 있는 특유의 기술이 아니다.

Linux 운영체제에서 컨테이너란 운영체제 수준의 가상화 기술로 리눅스 커널을 공유하면서 프로세스를 격리된 환경에서 실행하는 기술이다.

커널을 공유하기 때문에 실행 속도가 빠르고, 성능상의 손실이 거의 없는것이 특징이고, 리눅스의 네임 스페이스, 컨트롤 그룹, 루트 디렉토리 격리 등의 커널 기능을 활용해 격리되어 실행되는 것이다.

이러한 격리 기술 덕분에 호스트 머신에게는 프로세스로 인식되지만 컨테이너 관점에서는 마치 독립적인 환경을 가지는 가상 머신처럼 보이게 되는것이다.

회원가입

Docker 가입 (https://www.docker.com)을 진행하고 자신의 레지스트리를 등록하여야 자신이 만들어 배포하려고 하는 이미지를 pull / push 할 수 있습니다. 회원가입과 plan을 선택하여 진행하시길 바랍니다. 회원가입을 완료 한 후, 레지스트리에 접근하려면 반드시 로그인을 한 상태에서 진행해야 합니다.

# dockerd 로그인 명령어
$ docker login -u <username> --password-stdin

레지스트리는 Public 과 Private 로 만들 수 있으니, 용도에 알맞게 생성하여야 합니다.

링크 : 링크텍스트

Introduction

클라우드 컴퓨팅 솔루션의 확산과 광범위한 채택으로, HIPAA는 전자 보호 보건 정보(ePHI)의 개인 정보 보호 및 보안을 보호하는 규정을 준수하면서 클라우드 컴퓨팅을 활용할 수 있는지, 그리고 어떻게 활용할 수 있는지에 대해 의문을 제기하고 있다. 이 지침은 클라우드 서비스 공급자(CSP)를 포함한 그러한 기업들이 그들의 HIPAA 의무를 이해하는 데 도움이 된다.

클라우드 컴퓨팅은 여러 형태가 있다. 이 지침은 서비스 사용을 고려할 때 대상 기업 또는 비즈니스 관계자와 법적으로 분리된 CSP가 제공하는 클라우드 리소스에 초점을 두었다.

CPS는 일반적으로 사용자의 요구에 따른 여러 단계의 기능을 하는 컴퓨터 자원을 공유하기 위한 온라인 엑세스, (전자 의료 기록 시스템과 같은) 단순한 데이터 스토리지에서 완전한 소프트웨어 솔루션에 이르기까지 다양한 기능, 애플리케이션 개발자의 새로운 제품 생성 능력을 단순화하는 플랫폼, 그리고 소프트웨어 프로그래머가 프로그램을 배포하고 테스트할 수 있도록 전체 컴퓨팅 인프라를 제공한다.

흔한 클라우드 서비스는 컴퓨팅(예: 네트워크, 서버, 스토리지, 애플리케이션) 서비스에 대한 온디맨드 인터넷 액세스다.

클라우드 컴퓨팅 서비스 유형 및 기술 준비 옵션에 대한 정보를 찾고자 하는 대상 기업과 비즈니스 관계자에게 국립표준기술연구소가 제공하는 리소스를 참조할 것을 권장한다.; 참고 문서

HIPAA 프라이버시, 보안 및 위반 통지 규칙(HIPAA 규칙) 은 그러한 정보의 사용 및 공개에 대한 제한, 부적절한 사용 및 공개에 대한 보호, 자신의 건강 정보에 대한 개인의 권리를 포함하여 개별적으로 식별 가능한 건강 정보(HIPAA가 다루는 기업이나 사업 관계자에 의해 생성, 수신, 유지 또는 전송되는 경우 보호되는 건강 정보 또는 PHI라고 하는)에 대한 중요한 보호를 확립한다.

대상 기업과 비즈니스 관계사는 HIPAA 규칙의 해당 조항을 준수해야 한다.

대상 기업은 특정 청구 및 지급 관련 거래를 전자적으로 수행하는 의료 계획, 의료 정보 센터 또는 의료 제공자이다.

사업연관자는 PHI의 생성, 수령, 유지 또는 전송을 수반하는 피보험자의 노동인력을 대신하여 기능이나 활동을 수행하거나 특정 용역을 제공하는 기업 또는 개인이다.

비즈니스 관계사는 또한 다른 비즈니스 관계사를 대신하여 PHI를 생성, 수신, 유지 또는 전송하는 모든 하청업체이다.

대상 기업이 이를 대신하여 ePHI(ePHI 처리 및/또는 저장)를 생성, 수신, 유지 또는 전송하기 위해 CSP의 서비스를 사용하는 경우 CSP는 HIPAA에 따라 비즈니스 관계사이다.

또한, 기업이 자신을 대신하여 ePHI를 생성, 수신, 유지 또는 전송하기 위해 CSP와 하청계약을 체결하는 경우, CSP 하청업체 자체는 사업상 협력업체가 된다.

CSP가 암호화된 ePHI만 처리하거나 저장하며 데이터에 대한 암호화 키가 없는 경우에도 마찬가지이다.

암호화 키가 부족하다고 해서 CSP가 HIPAA 규칙에 따른 비즈니스 관련 상태 및 의무에서 제외되는 것은 아니다.

그 결과, 대상 기업(또는 비즈니스 관계사)과 CSP는 HIPAA 준수 비즈니스 제휴 계약(BAA)을 체결해야 하며, CSP는 BAA의 조건을 준수할 수 있는 계약상의 책임과 HIPAA 규칙의 해당 요건을 준수할 직접적인 책임이 있다.

이 지침은 HIPAA 규제 CSP와 고객이 클라우드 제품 및 서비스를 사용하여 ePHI를 생성, 수신, 유지 또는 전송할 때 HIPAA 규칙에 따른 책임을 이해하는 데 도움이 되는 주요 질문과 답변을 제시한다.

Q1 : HIPAA의 대상 기업이나 사업 제휴사가 클라우드 서비스를 사용하여 ePHI를 저장 또는 처리할 수 있는가?

처리할 수 있다, 대상 기업이나 사업 제휴사가 자신을 대신하여 전자 보호 상태 정보(ePHI)를 작성, 수신, 유지 또는 전송하는 CSP와 HIPAA 준수 비즈니스 제휴 계약(BAA)을 체결하고, 그렇지 않으면 HIPAA 규칙을 준수할 것이다.

무엇보다도 BAA는 당사자와 비즈니스 관계사가 수행하는 활동 또는 서비스 간의 관계를 기반으로 해당 대상 또는 동업자를 위해 활동 또는 서비스를 수행하는 비즈니스 관계사가 ePHI의 허용 또는 필수 사용 및 공개를 설정한다.

BAA는 또한 계약적으로 보안 규칙의 요구 사항 구현을 포함하여 비즈니스 관계자에게 ePHI를 적절히 보호할 것을 요구한다.

OCR은 다음의 문서를 만들었다. guidance on the elements of BAAs.

CSP를 체결하는 대상 기업(또는 사업 제휴사)은 특정 CSP가 제공하는 클라우드 컴퓨팅 환경 또는 솔루션을 이해하여 대상 기업(또는 사업 제휴사)이 자체 위험 분석을 적절하게 수행하고 위험 관리 정책을 수립할 수 있어야 하며 적절한 BAA를 체결할 수 있어야 한다.

다음을 참고

• 45 CFR §§ 164.308(a)(1)(ii)(A);
• 164.308(a)(1)(ii)(B); and
• 164.502. 대상 기업과 비즈니스 관계사 모두 위험 분석을 수행하여 이들이 생성, 수신, 유지 또는 전송하는 모든 ePHI의 기밀성, 무결성 및 가용성에 대한 잠재적 위협 및 취약성을 식별하고 평가해야 한다.

예를 들어, 대상 기업이나 사업 관련자는 CSP와 함께 BAA에 가입하는 경우(공용, 하이브리드, 프라이빗 등) 모든 구성의 클라우드 기반 서비스를 사용할 수 있지만, 사용할 클라우드 구성의 유형은 모든 당사자의 위험 분석 및 위험 관리 계획 및 BAA의 결과적인 규정에 영향을 미칠 수 있다.

또한 서비스 수준 계약(SLA)은 일반적으로 CSP와 고객 간의 보다 구체적인 비즈니스 기대 사항을 해결하는 데 사용되며, 이는 HIPAA 규정 준수와도 관련이 있을 수 있다.

예를 들어, SLA에는 다음과 같은 HIPAA 문제를 다루는 조항이 포함될 수 있다.

• 시스템 가용성 및 신뢰성;
• 백업 및 데이터 복구(예: 랜섬웨어 공격 또는 기타 비상 상황에 대응할 수 있는 필요 시)
• 서비스 이용 종료 후 고객에게 데이터를 반환하는 방식
• 보안 책임
• 사용, 보존 및 공개 제한

Q2 : CSP가 암호화된 ePHI만 저장하고 암호 해독 키가 없는 경우 HIPAA 비즈니스 관계사인가?

그렇다. CSP는 대상 기업 또는 다른 비즈니스 관계자에 대해 전자 보호 상태 정보(ePHI)를 수신 및 유지 관리(예: 처리 및/또는 저장)하기 때문이다.

수신 및 유지 관리하는 암호화된 데이터에 대한 암호화 키가 부족하다고 해서 CSP가 HIPAA 규칙에 따른 비즈니스 관련 상태 및 관련 의무에서 제외되는 것은 아니다.

기업이 실제로 ePHI를 볼 수 없는 경우에도 적용 대상 기업(또는 다른 비즈니스 관계자)을 대신하여 ePHI를 유지하는 기업이 비즈니스 관계자이다.

따라서, 암호 해독 키를 보유하지 않아 정보를 볼 수 없는 경우에도, 대상 기업(또는 다른 비즈니스 관계자)를 대신하여 암호화된 ePHI를 유지하는 CSP는 비즈니스 관계자이다.

편의를 위해 이 지침에서는 CSP가 암호 해독 키에 액세스하지 않고도 대상 기업(또는 다른 사업 관계자)을 대신하여 암호화된 ePHI를 유지하는 상황을 기술하기 위해 no-viewservices 라는 용어를 한다.

암호화는 권한이 없는 사람이 보는 정보의 위험을 크게 줄임으로써 ePHI를 보호하지만, 이러한 보호만으로는 보안 규칙에서 요구하는 대로 ePHI의 기밀성, 무결성 및 가용성을 적절히 보호할 수 없다.

암호화는 악성 프로그램으로 인해 정보가 손상되지 않도록 보장하거나 비상 계획을 통해 비상 상황이나 재해 상황에서도 공인 작업자가 데이터를 사용할 수 있도록 보장하는 등 ePHI의 무결성과 가용성을 유지하지 않다.

또한 암호화는 ePHI에 대한 위험을 분석하는 관리적 보호 또는 ePHI를 수용하는 시스템과 서버의 물리적 보호와 같이 기밀성을 유지하는 데 중요한 다른 보호 조치를 다루지 않다.

비즈니스 관계자로서, no-view 서비스를 제공하는 CSP는 HIPAA 규칙의 다른 적용 가능한 요건에서 제외되지 않습니다.

그러나 이 규칙의 조건은 CSP가 제공하는 서비스의 no-view 특성을 고려하여 유연하고 확장 가능하다.

Security Rule Consideration

비즈니스 관계자인 모든 CSP는 ePHI와 관련하여 보안 규칙의 해당 표준 및 구현 사양을 준수해야 한다.

그러나 CSP가 대상 기업(또는 비즈니스 관계) 고객에게 no-view 서비스만 제공하는 경우, CSP가 유지하는 ePHI에 적용되는 특정 보안 규칙 요구 사항은 당사자 중 한 사람의 조치를 통해 양쪽 당사자에게 모두 충족될 수 있습니다.

특히 CSP가 관리하는 ePHI를 볼 수 있는 고객 제어만 있는 경우 인증이나 고유한 사용자 식별과 같은 특정 액세스 제어는 고객의 책임일 수 있으며, 암호화와 같은 다른 제어는 CSP 비즈니스 관계자의 책임일 수 있습니다.

그러나 비즈니스 관계자로서 CSP는 고객의 ePHI를 유지하는 정보 시스템에 대한 액세스를 제한하기 위해 합리적이고 적절한 다른 제어를 구현하는 보안 규칙에 따라 여전히 책임이 있다.

예를 들어, 고객이 ePHI에 대한 액세스를 인증할 책임이 있다고 동의한 경우에도, 당사자들이 CSP는 여전히 정보 시스템 운영에 필수적인 자원(스토리지, 메모리, 네트워크 인터페이스, CPU .. )을 관리하는 관리 도구에 대한 인증된 액세스만 보장하기 위해 적절한 내부 제어를 구현해야 할 수 있다.

이 지침은 링크에서 확인할 수 있는, 18-cv-0040호(D.D.C. 1월 23일)의 Ciox Health, LLC v. Azar, No. 18-cv-0040에 대한 법원의 명령과 일관되는 범위에서만 유효하다. 명령에 대한 자세한 내용은 링크에서 확인할 수 있다. 본 지침 내에서 Ciox Health 결정에 의해 무효화된 모든 조항은 폐기된다.

Question & Answer 1

Q: HIPAA는 받은 건강정보의 사용 또는 공개에 대해 HIPAA 프라이버시, 보안 또는 위반 통지 규칙(HIPAA 규칙)에 따라 애플리케이션이나 다른 소프트웨어(앱)에 전자 보호 건강정보(ePHI)를 전송하기 위한 개인의 요청을 이행하는 기업을 대상으로 하고 있는가?

A: 대답은 적용대상 기업과 앱 간의 관계에 따라 다르다. 일단 HIPAA에 따라 보상받는 기업이나 사업 제휴사가 아닌 앱에 의해 개인의 지시에 따라 건강 정보가 수신되면, 그 정보는 더 이상 HIPAA 법의 보호의 대상이 되지 않는다. 개인의 앱이 개인이 요청한 ePHI를 받기 위해 그것을 자의적으로 선택한 경우, 피보험자에 의해 또는 피보험자에 의해 제공되지 않은 경우(따라서 피보험자를 대신하여 ePHI를 생성, 수신, 전송 또는 유지하지 않는 경우), 피보험자는 피보험자가 수령한 요청 ePHI의 후속 사용 또는 공개에 대해 HIPAA 규칙에 따라 책임을 지지 않을 것이다. 예를 들어 나중에 개인에게 ePHI를 받도록 지정한 앱이 위반을 경험한다면, 보장 단체는 HIPAA법 또는 법적 책임을 지지 않을 것이다.

한편, 적용대상 기업과 애플리케이션 개발자의 사업연관 관계로 인해 이 후속적으로 허용할 수 없는 공시에 대해 HIPAA 규정에 따라 해당 애플리케이션을 개발하거나 제공한다면, 해당 기업이 후속적으로 허용할 수 없는 공시에 대해 책임을 질 수 있다. 예를 들어 개인이 의료보험 제공자가 ePHI와 관련된 개인에게 서비스를 제공하기 위해 사용하는 앱을 선택하는 경우, 의료 제공자는 받은 ePHI를 허용할 수 없이 공시하는 경우 HIPAA 법에 따라 책임을 져야 할 수 있다.

Question & Answer 2

Q: 적용대상 기업이 안전하지 않은 방법을 사용하여 ePHI를 앱에 전송하려는 개인의 요청을 이행할 경우 어떤 책임을 져야하는가?

A: 개인 접근 권한에 따라, 개인은 자신의 ePHI를 안전하지 않은 방식으로 또는 비보안 채널을 통해 제3자 앱으로 유도할 것을 대상 기업에 요청할 수 있다.

45 CFR 164.524(a)(1), (c)(2)(ii), (c)(3)(ii)를 참조한다. 예를 들어 개인은 편의상 암호화되지 않은 ePHI를 앱으로 전송하도록 요청할 수 있다.

그러한 상황에서, 적용대상 기업은 앱으로 전송되는 동안 개인의 ePHI에 대한 무단 액세스에 대해 책임을 지지 않을 것이다.

그러한 적용과 관련하여, 적용대상 기업은 개인이 요청을 처음 할 때 관련된 잠재적 위험을 개인에게 알리는 것을 고려할 수 있다.

Question & Answer 3

Q: 개인이 대상기업에 대해 지정된 앱에 ePHI를 보내도록 지시하는 경우, 대상기업의 전자건강기록(EHR) 시스템 개발자는 대상 기업을 대신하여 앱에 대한 ePHI 전송을 완료한 후 HIPAA 법을 적용하는가?

A: 대답은 적용 대상 기업, EHR 시스템 개발자 및 개인이 개인의 ePHI를 받기 위해 선택한 앱 간의 관계에 따라 다르다. 제휴사 관계는 기업이 적용대상 기업의 적용 기능을 수행하기 위해 적용 대상 기업을 대신하여 (직접 또는 간접적 동업관계를 통하여) ePHI를 생성, 수신, 유지 또는 전송하느 경우에 존재한다. EHR 시스템 개발자와 대상 기업 사이에 제휴관계가 존재한다. EHR 시스템 개발자가 앱을 소유하지 않거나 앱을 소유하지만 앱을 적용 대상 기업(예: 앱을 생성하여 다른 비즈니스 라인의 일부로 앱 스토어에서 사용할 수 있도록 하는 경우(적용 대상 기업과의 동업 관계의 일부가 아님)를 통해 앱을 제공하지 않는 경우 – EHR 시스템 개발자는 앱에서 받은 요청 ePHI의 후속 사용 또는 공개에 대해 HIPAA 규칙에 따라 책임을 지지 않는다.

EHR 시스템 개발자가 앱을 소유하거나 앱 개발자와 제휴 관계를 맺고, 앱을 적용 대상 기업(직접 또는 간접적 제휴사를 통해)를 통해 또는 대신 제공하는 경우, EHR 시스템 개발자는 잠재적 (HIPAA 적용 대상 기업의 제휴사로서)으로 앱이 수신한 건강 정보의 허용할 수 없는 사용과 공개에 대해 HIPAA 법에 책임을 질 수 있다.

예를 들어, EHR 시스템 개발자가 애플리케이션 개발자와 계약을 체결하여 적용 대상 기업을 대신하여 앱을 만들고 나중에 개인이 ePHI를 수령하는 앱을 식별한다면, EHR 시스템 개발자는 해당 앱이 수령한 ePHI를 무단으로 사용하거나 공개할 경우 HIPAA 책임의 대상이 될 수 있다.

Question & Answer 4

Q: 적용대상 기업이 받는 ePHI를 어떻게 사용하거나 공시할 것인가에 대한 우려 때문에 개인이 선택한 앱에 대한 ePHI의 공시를 거부할 수 있는가?

A: 거부할 수 없다. HIPAA 개인정보보호규칙은 일반적으로 ePHI가 앱에서 사용하는 형식과 형식으로 쉽게 생산될 수 있는 경우 개인이 지정한 제3자 앱에 대한 ePHI의 공개를 거부하는 것을 금지하고 있다.

45 CFR 164.524(a)(1), (c)(2)(ii), (c)(3)(ii)를 참조한다.

HIPAA 법은 앱과 같은 개인 또는 개인의 피지명자가 개인의 접근권에 따라 공개된 건강정보를 사용하는 방법에 대해 어떠한 제한을 두지 않는다.

예를 들어, 적용 대상 기업은 개인이 연구를 위해 개인의 ePHI를 공유하거나 정지 상태에서 개인의 데이터를 암호화하지 않기 때문에 제3자 앱으로 정보를 지시하는 경우 개인의 ePHI에 대한 접근권을 거부할 수 없다.

Question & Answer 5

Q: HIPAA는 ePHI를 앱에 전송하기 위해 개인에 의해 지정된 앱과 업무 제휴 계약을 체결하도록 보장된 기업이나 EHR 시스템 개발자에게 요구하는가?

A: 앱 개발자와 기업 과 EHR 시스템 개발자와의 관계에 따라 다르다.

제휴사(직접적 또는 다른 제휴사를 통하여)자는 피보험자의 기능을 수행하기 위하여 피보험자를 대신하여(또는 피보험자를 위해) 피보험자를 조성, 수취, 유지 또는 송부하는 개인 또는 기업이다.

앱이 개인의 요청으로 개인의 ePHI에 쉽게 접근할 수 있도록 하는 것만으로 제휴 관계가 형성되는 것은 아니다.

이러한 촉진에는 타사 앱이 동의한 API 이용약관(즉, 상호운용성 약정)이 포함될 수 있다.

HIPAA는 적용대상 기업의 이익을 대신하여 또는 그 이익을 위해 ePHI를 생성, 수신, 유지 또는 전송하지 않는 애플리케이션 개발자와 제휴 계약을 체결하도록 요구하는 것은 아니다.

그러나 만약 앱이 적용대상 기업을 대신하여 ePHI를 생성, 수신, 유지 또는 전송하기 위해 개발되었거나, 적용대상 기업 또는 (적용대상 기업의 제휴사로서 활동하는) EHR 시스템 개발자에 의해 제공되었다면, 제휴 계약이 요구될 것이다.

링크

Overview

다음 질문들과 답변을 읽고 해당 개발자가 작성한 App이 모바일 의료 앱인지 아닌지 판별을 도와주는 문서이다. 총 10개의 문항이 있다.

Question 1. 귀하의 APP은 식별가능한 건강정보를 작성, 수신, 유지, 또는 전송합니까?

YES

HIPAA가 적용되는지 결정하려면 문항 2 로 이동하세요.

NO

HIPAA가 적용되지 않습니다. FD&C 규정이 적용 되는지 보려면 문항 5 로 이동하세요.

Question 2. 귀하는 의료 공급자 또는 의료 건강 보험 기관입니까?

YES

HIPAA 규칙이 적용되는 HIPAA 적용 대상 일 가능성이 높습니다.

FD&C 법규 또한 적용 되는지 보려면 문항 5 로 이동하세요.

HIPAA 개인 정보 보호 법

• HIPAA 개인 정보 보호 법은 식별 가능한 개인 건강 정보를 보호하기 위한 적절한 안전장치를 요구하고(HIPAA가 다루는 기업이나 사업 관계자에 의해 유지 또는 전송되는 경우 보호되는 건강 정보 또는 PHI Protected Health Information 라고 함) 소비자 없이 그러한 정보의 사용 및 공개에 대한 제한과 조건을 설정합니다. 이 규칙은 또한 소비자에게 건강기록의 사본을 검사하고 입수할 수 있는 권리뿐만 아니라 커버리지가 모바일 건강앱과 같이 자신이 선택한 개인이나 기업에 자신의 건강정보를 직접 전송하도록 지시하는 권리와 같은 자신의 건강정보에 대한 권리를 부여합니다. 비즈니스 제휴사는 특정 조항만 준수하면 됩니다.

The HIPAA Security Rule

• HIPAA 보안 규칙은 전자 PHI의 기밀성, 무결성 및 가용성을 보장하는 데 사용할 수 있는 일련의 관리, 물리적 및 기술 안전장치를 명시한다. 비즈니스 파트너는 전체 보안 규칙을 준수해야 합니다.

The HIPAA Breach Notification Rule

• HIPAA 위반 통지 규칙은 보호대상 기업이 소비자, HHS 장관 및 경우에 따라 보안되지 않은 PHI 위반에 따른 미디어에 통지를 제공하도록 요구하고 있다. 비즈니스 제휴사는 HIPAA 적용 엔티티에 통지를 제공해야 합니다.
• HIPAA가 모바일 앱에 적용되는지 여부에 대한 추가 지침은 OCR의 건강 앱 개발자 포털을 참조하십시오.

NO

HIPAA가 적용되는지 보려면 문항 3 으로 이동하세요.

Question 3. 소비자가 귀하의 APP에 접근하기위해 처방전이 필요합니까?

YES

HIPAA 개인 정보 보호 법

HIPAA 개인 정보 보호 법은 식별 가능한 개인 건강 정보를 보호하기 위한 적절한 안전장치를 요구하고(HIPAA가 다루는 기업이나 사업 관계자에 의해 유지 또는 전송되는 경우 보호되는 건강 정보 또는 PHI Protected Health Information 라고 함) 소비자 없이 그러한 정보의 사용 및 공개에 대한 제한과 조건을 설정합니다. 이 규칙은 또한 소비자에게 건강기록의 사본을 검사하고 입수할 수 있는 권리뿐만 아니라 커버리지가 모바일 건강앱과 같이 자신이 선택한 개인이나 기업에 자신의 건강정보를 직접 전송하도록 지시하는 권리와 같은 자신의 건강정보에 대한 권리를 부여합니다. 비즈니스 제휴사는 특정 조항만 준수하면 됩니다.

The HIPAA Security Rule

HIPAA 보안 규칙은 전자 PHI의 기밀성, 무결성 및 가용성을 보장하는 데 사용할 수 있는 일련의 관리, 물리적 및 기술 안전장치를 명시한다. 비즈니스 파트너는 전체 보안 규칙을 준수해야 합니다.

The HIPAA Breach Notification Rule

HIPAA 위반 통지 규칙은 보호대상 기업이 소비자, HHS 장관 및 경우에 따라 보안되지 않은 PHI 위반에 따른 미디어에 통지를 제공하도록 요구하고 있다. 비즈니스 제휴사는 HIPAA 적용 엔티티에 통지를 제공해야 합니다.

NO

HIPAA 법규가 적용되는지 보려면 문항 4 으로 이동하세요.

Question 4. HIPAA가 적용되는 기업(병원, 진료실, 의료 보험사 및 의료 건강 보험 프로그램) 을 대신하여 이 APP을 개발하고 있습니까?

YES

귀하는 HIPAA 보안법 및 개인정보 보호 위반 통지법의 특정 조항에 따라 HIPAA 제휴사일 가능성이 높습니다.

FD&C 규정 또한 적용 되는지 보려면 문항 5 로 이동하세요.

HIPAA 개인 정보 보호 법

HIPAA 개인 정보 보호 법은 식별 가능한 개인 건강 정보를 보호하기 위한 적절한 안전장치를 요구하고(HIPAA가 다루는 기업이나 사업 관계자에 의해 유지 또는 전송되는 경우 보호되는 건강 정보 또는 PHI Protected Health Information 라고 함) 소비자 없이 그러한 정보의 사용 및 공개에 대한 제한과 조건을 설정합니다.

이 규칙은 또한 소비자에게 건강기록의 사본을 검사하고 입수할 수 있는 권리뿐만 아니라 커버리지가 모바일 건강앱과 같이 자신이 선택한 개인이나 기업에 자신의 건강정보를 직접 전송하도록 지시하는 권리와 같은 자신의 건강정보에 대한 권리를 부여합니다.

비즈니스 제휴사는 특정 조항만 준수하면 됩니다.

The HIPAA Security Rule

HIPAA 보안 규칙은 전자 PHI의 기밀성, 무결성 및 가용성을 보장하는 데 사용할 수 있는 일련의 관리, 물리적 및 기술 안전장치를 명시한다. 비즈니스 파트너는 전체 보안 규칙을 준수해야 합니다.

The HIPAA Breach Notification Rule

HIPAA 위반 통지 규칙은 보호대상 기업이 소비자, HHS 장관 및 경우에 따라 보안되지 않은 PHI 위반에 따른 미디어에 통지를 제공하도록 요구하고 있습니다.

비즈니스 제휴사는 HIPAA 적용 엔티티에 통지를 제공해야 합니다.

NO

귀하의 APP은 HIPAA 규정에 적용되지 않은 것 같습니다. FD&C 법이 적용되는지 보려면 문항 5 로 이동하세요.

Question 5. 귀하의 APP은 질병이나 다른 건강 상태 진단, 또는 질병 치료, 완화, 치료 또는 예방에 사용하도록 되어 있습니까?

YES

귀하의 APP은 FD&C 법의 적용을 받는 의료기기 입니다. FDA가 귀하의 APP 유형에 대한 규제 및 감독을 적용할 의도가 있는지 보려면 문항 6 으로 이동하세요.

NO

FD&C 법은 적용되지 않습니다. 귀하의 앱은 의료기기로 고려되지 않으며 FDA의 권한 밖입니다. FTC 법이 적용되는지 보려면 문항 8로 이동하세요.

Question 6. 귀하의 APP이 사용자에게 "최소한의 위험"을 초래합니까?

FDA에 따르면, "최소한의 위험" APP이란 다음 중 하나 이상을 위한 APP 입니다.

특정 치료 제안을 제공하지 않고 사용자가 질병이나 상태를 스스로 관리할 수 있도록 돕는 것.

1. 사용자에게 자신의 건강 정보를 구성하고 추적할 수 있는 간단한 도구를 제공하는 것.
2. 건강 상태 또는 치료와 관련된 정보에 쉽게 접근할 수 있도록 하는 것.
3. 사용자가 의료 서비스 제공자에게 잠재적인 의료 조건을 기록하고, 보여주거나, 전달할 수 있도록 지원하는 것.
4. 의료 사업자를 위한 간단한 작업 자동화.
5. 사용자 또는 제공자가 개인 건강 기록(PR) 또는 EHR(전자 건강 기록) 시스템과 상호 작용할 수 있도록 지원.
6. FDA의 MDDS 의료기기 데이터 시스템 규정에 의해 정의된 의료기기 데이터의 전송, 저장, 포맷 변환 또는 표시.

YES

FDA는 귀하의 앱이 "최소한의 위험"으로 고려하며, 규제 요건을 준수하도록 강제할 수 없습니다. FTC 법이 적용되는지 보려면 문항 8로 이동하세요.

NO

FDA는 귀하의 APP이 "최소한의 위험" 이라고 고려하지 않습니다. FDA가 규제 감독을 적용하려는 의도가 있는지 보려면 문항 7로 이동하세요.

Question 7. 귀하의 APP은 "의료 모바일 APP"입니까?

"모바일 의료 APP"은 다음 중 하나에 해당 됩니다:

• 통제된 의료기기의 부속품으로 사용 (예: Infusion pump의 기능 또는 설정을 변경하는 APP)
• 모바일 플랫폼을 통제된 의료기기로 변환(예: 모바일 플랫폼에 첨부되어 혈당 수치를 측정하는 APP)
• 다른 의료기기로 부터 받은 데이터에 대해 정교한 분석 해석 (예: 소비자 특유의 매개 변수를 사용하고 방사선 치료를 위한 복용량 계획을 만드는 앱)

YES

FDA는 규제 감독을 적용하려고 합니다. FDA 정보

• FDA는 현재 규제되고 있는 의료기기의 성능이나 기능에 영향을 미치거나 소비자가 의도한 대로 작동하지 않을 경우 독립적으로 더 큰 위험을 초래할 수 있는 모바일 앱의 작은 하위 집합에 규제 감독을 집중하고 있습니다. FDA 심사를 거친 모바일 의료 앱은 기관이 다른 의료기기에 적용하는 것과 동일한 규제 기준과 위험 기반 접근법에 따라 평가 됩니다. FDA는 기기가 소비자에게 부과하는 위험, 의도된 사용 및 사용에 대한 표시에 기초하여 의료기기를 등급 1, 등급 2 및 등급 3 의 세 가지 범주로 분류합니다. 등급 1 장치는 낮은 위험으로 간주되며 최소한의 규제 통제를 받습니다. 등급 2 장치는 중간 위험 장치이며 기기의 안전성과 효과에 대한 합리적인 보증을 제공하기 위해 더 큰 규제 통제를 필요로 하며, 등급 3 장치는 일반적으로 가장 높은 위험 장치이며 가장 높은 수준의 규제 통제를 받습니다. 몇 가지 예외를 제외하고, FDA는 사전 시장 제출 절차를 통해 대중에게 판매되기 전에 등급 2 및 등급 3 장치의 안전성과 효과를 평가합니다. 사전 시장 제출과 관련된 수수료가 있습니다. 의료기기 제조업체는 분류와 관계없이 FDA의 기기 등록 및 상장 데이터베이스에 설치등록 및 상장해야 하며 등록비도 있습니다. 또한 모바일 의료 앱 제조업체는 품질 시스템(QS) 규정/의료 기기 모범 제조 관행(GMP) 및 의료기기 보고와 같은 기타 모든 관련 법규를 준수해야 합니다. 위의 FDA 링크를 통해 앱의 분류 및 규제 요구사항을 결정할 수 있습니다. FDA의 MobileMedicalApps@fda.hhs.gov(이메일 전송) 이메일 주소는 FDA의 모바일 앱 규정에 대한 제조업체 및 앱 개발자의 질문에 답변하는 데 사용됩니다. FTC 법이 적용되는지 보려면 문항 8로 이동하세요.

NO

FDA 규정 요건을 준수해야 하는지 여부를 확인하려면 mobilemedicalapps@fda.hhs.gov(링크에서 이메일 보내기)로 FDA에 문의하십시오.

Question 8.비영리 단체 입니까?

YES

대부분의 비영리 단체에는 공정위법이 적용되지 않습니다. 하지만 회원들에게 경제적 이익을 제공하는 일부 무역 협회와 같은 비영리 단체에도 적용됩니다.

FTC의 의료 위반 통보 규칙이 적용되는지 보려면 문항 9 로 이동하세요.

NO

공정위법이 적용될 가능성이 높습니다. FTC의 의료 위반 통보 규칙이 적용되는지 보려면 문항 9 로 이동하세요.

The FTC Act

공정위법은 기만적이거나 불공정한 행위나 관행을 금지하고 있다. 즉, 다음과 같다:

• 고객에게 중요한 사항에 대해 소비자들에게 기만적이거나 잘못된 주장을 할 수 없다.
• 소비자가 피할 수 없고 득보다 실이 더 큰 피해를 입히는 행위나 관행에 관여할 수 없다.

Question 9.이 APP을 병원, 진료실, 의료 보험사 및 건강보험 프로그램과 같은 HIPAA 적용 대상으로 또는 대신하여 개발하고 있습니까?

YES

공정위의 의료 침해 통지 규칙은 적용되지 않습니다. 귀하는 이 대화형 가이드를 완료하였습니다. 질문 10번을 대답할 필요가 없습니다.

NO

FTC의 의료 위반 통보 규칙이 적용되는지 보려면 문항 10 으로 이동하세요.

Question 10.귀하는 의료기록을 소비자에게 직접 제공합니까(또는 의료 관련 직원과 상호 작용하거나 서비스를 제공합니까)?

YES

사용자는 개인 건강 기록(PR) 제공자, PR 관련 기업 또는 서비스 제공 업체일 수 있으며, 이는 FTC의 의료 위반 통지 규칙을 준수해야 합니다. 귀하는 HIPAA 적용 기업이거나 사업 관계자로서 행동하는 정도 까지는 FTC의 법에 적용되지 않습니다.

FTC's Health Breach Notification Rule PR 제공자 또는 PR 관련 엔터티인 경우 Health Breakage Notification Rule은 영향을 받는 소비자, FTC 및 경우에 따라 보안되지 않은 개인 의료 정보의 위반에 따른 미디어에 통지하도록 요구합니다.

PR 제공자와 PR 관련 엔티티에 대한 서비스 제공자는 이러한 PR 제공자와 PR 관련 엔티티에 통지해야 합니다.

NO

공정위의 의료침해통지규칙은 적용되지 않는다.

GLOSSARY

Identifiable health information

식별 가능한 건강 정보에는 인구 통계 정보가 포함되며 소비자의 과거, 현재 또는 미래의 신체적, 정신적 건강 또는 상태, 의료 제공, 또는 소비자에게 의료 제공을 위한 과거, 현재 또는 미래의 지불, 소비자를식별하거나 믿을 만한 타당한 근거가 있는 경우심지어 소비자를 식별하는 데도 사용할 수 있습니다.

예를 들어, 건강 보험의 건강 앱에 의해 유지되는 경우, 소비자의 IP 주소는 식별 가능한 건강 정보입니다.

HIPAA covered entities

• Health care providers who conduct certain electronic transactions* 의료 서비스 제공자는 의사, 클리닉, 심리학자, 치과의사, 척추 지압사, 요양원, 그리고 의료 관련 특정 지불 및 보상 거래를 전자적으로 수행하는 약국을 포함한다. 소규모 의사 사례에서 대규모 병원 시스템에 이르기까지 다양한 서비스 제공합니다.

• Health plans* 건강 보험에는 의료 보험 회사, HMO, 회사 의료 계획, 그리고 노인 의료 보험 제도, 저소득층 의료 보장 제도, 군 및 참전 용사 의료 프로그램과 같은 의료 비용을 지불하는 정부 프로그램이 포함됩니다.

• Health care clearinghouses* 의료 청산소는 다른 기업으로부터 받은 비표준 의료 정보를 표준으로(즉, 표준 전자 형식 또는 데이터 콘텐츠) 처리하는 기업이다. 예를 들어, 보험 가입자의 보험금 청구 정보를 표준화하여 보험금 지급인에게 전송함으로써 의료 정보를 처리하는 기업은 의료 청산소 입니다.

HIPAA business associate

비즈니스 관계자는 특정 기능 또는 활동을 수행하거나 특정 서비스를 대상 엔터티를 대신하여 제공하면서 보호된 상태 정보를 생성, 수신, 유지 또는 전송합니다.

이러한 기능 또는 활동에는 클레임 처리, 데이터 분석, 활용도 검토 및 청구가 포함됩니다.

사업 제휴사에는 일상적으로 정보에 접근해야 하는 PHI와 관련하여 데이터 전송 서비스를 제공하는 사람뿐만 아니라, 커버리지를 대신하여 개인 건강 기록을 제공하는 사람, 그리고 다른 사업 제휴사에 하청업자가 포함됩니다.

비즈니스 관계자에 대한 더 많은 정보는 다음의 링크를 참고:

• OCR’s Health App Developer Portal
• Health Information Privacy, Understanding HIPAA Privacy for Covered Entities and Business Associates
• Health Information Privacy, Business Associates, Frequently Asked Questions
• Health Information Privacy, Understanding HIPAA Privacy for Covered Entities and Business Associates, Sample Business Associate Agreement Provisions

Medical Device

의료기기는 다음의 조건을 만족하는 기기, 기구, 구현체, 기계, 관용, 임플란트, 시험관내 시약 또는 구성부품 또는 부속품을 포함한 기타 유사하거나 관련 물품이다.

• 공식 국가 처방 의약품집 또는 미국 약전에 인정 되거나 공급
• 사람 또는 동물의 질병 또는 기타 상태의 진단, 질병의 치료, 완화, 예방에 사용되도록 의도된 경우
• 사람이나 다른 동물의 몸의 구조나 어떤 기능에 영향을 미치도록 의도된 것으로, 사람이나 다른 동물의 몸 안에서 또는 다른 동물의 신체에 화학 작용을 통해 일차적인 의도된 목적을 달성하지 않으며, 일차적인 목적의 달성을 위해 대사되는 것에 의존하지 않습니다.

Health App Use Scenarios & HIPAA

Overview

이 시나리오는 HIPAA에 따라 두가지 문제점을 다룬다.

1. HIPAA는 환자 헬스 앱을 통해 환자가 생성, 관리 및 구조화한 생체 정보를 어떻게 적용하는가?
2. 앱 개발자는 언제 HIPAA 규정을 준수해야 하는가?

이러한 질문에 대한 답변은 사실과 상황에 따라 다르다. 아래의 각 시나리오는 특정 사실을 기반으로 한다. 시나리오를 검토하고, 자신의 상황에 적용할 때 이러한 사항을 유념한다. 시나리오의 변화는 분석을 달라지게 할 수 있으며, 결과적으로 앱 개발자가 HIPAA를 준수해야 하는지 여부를 결정하는 데 영향을 미칠 수 있다. 이를 통해 자체 분석에서 살펴봐야 할 특정 측면을 파악하는 데 도움이 되기를 바란다.

배경

의료 계획, 의료 정보 센터 및 대부분의 의료 서비스 제공 업체만이 HIPAA에 따라 보험에 가입되어있다.

이러한 개채 중 하나에서 일하고 있으며 작업의 일부로 식별 가능한 건강 정보의 사용 또는 공개를 포함하는 앱을 만드는 경우, 해당 개체(및 해당 직원의 구성원)는 HIPAA 규칙을 준수하여 해당 정보를 보호해야 한다.

HIPAA 규칙의 요구 사항과 준수 방법에 대한 자세한 내용은 이 문서을 참조.

그러나 귀하가 피보험자가 아니더라도 피보험자(또는 피보험자의 계약자 중 한 명)를 대신하여 앱을 만들거나 제공하는 경우, HIPAA 규칙의 특정 규정을 준수해야 하는 경우 사용자는 제휴사가 될 수 있다.

일반적으로, 동업자는 보호받는 기업이나 다른 제휴사를 대신하여 PHI를 생성, 수신, 유지 또는 전송하는 사람(또는 기업) 을 일컫는다.

PHI는 HIPAA 규정에 정의되어 있으며 일반적으로 식별 가능한 건강 정보이다.

따라서 PHI에 대한 접근을 수반하는 포괄기업에 대한 서비스를 제공하거나 기능을 수행하는 대부분의 벤더나 계약자(하도급자 포함)는 사업 관계자이다.

예를 들어, 피보험자가 환자나 등록자에게 제공하는 개인 건강 기록이나 환자 포털을 제공하고 관리하기 위해 피보험자가 PHI에 접근할 수 있는 기업은 사업 관계자이다.

아래 시나리오에서는 앱 개발자에게 HIPAA를 적용하는 방법을 언급한다.

의료정보 기관이 PHI를 전송하고 있는 모든 경우에, 의료정보 기관(예: 제공자)이 HIPAA를 준수해야 하는 독립적 의무를 경감시키는 것은 아래 분석에서 정보를 보호하기 위한 합리적인 보호 장치를 적용해야 한다.

Senario 1

소비자가 스마트폰에 헬스 앱을 다운 받는다. 그 소비자는 본인 정보를 축적한다. 예를 들어, 소비자는 가정 건강 용품을 사용하여 자신의 혈당 수치와 혈압 수치를 입력한다.

시나리오에 제시된 사실을 바탕으로 앱 개발자는 HIPAA 협력사인가?

아니다. 개발자는 피보호된 실체나 다른 사업체를 대신하여 PHI를 생성, 수신, 유지 또는 전송하지 않는다. 이 소비자는 개발자의 앱을 이용하여 의료 서비스 제공자의 개입 없이 정보를 관리하고 정리할 수 있도록 돕고 있다.

Senario 2

소비자는 본인의 만성적인 상태를 관리하는 것을 돕기 위해 고안된 건강 앱을 스마트폰에 다운로드한다. 소비자는 의사의 EHR에서 환자 포털을 통해 컴퓨터로 데이터를 다운로드한 다음 앱에 업로드한다. 소비자는 또한 앱에 자신의 정보를 추가한다.

시나리오에 제시된 사실을 바탕으로 앱 개발자는 HIPAA 협력사인가?

아니다. 개발자는 피보호된 실체나 다른 사업체를 대신하여 보호되는 건강 정보(PHI)를 생성, 수신, 유지 또는 전송하지 않는다. 대신에, 소비자는 제공자로부터 생체정보를 얻고, 그것을 소비자가 입력하는 생체정보와 결합하고, 앱을 이용하여 자신의 목적을 위해 그 정보를 구성하고 관리한다. 이 서비스를 제공하거나 용이하게 하기 위해 제공자의 제공자 또는 사업자가 앱 개발자를 고용한 표시가 없다.

Senario 3

의사는 환자에게 BMI가 너무 높다고 조언하고, 식이요법, 운동, 체중을 추적하는 특정 앱을 추천한다. 소비자는 스마트폰으로 앱을 내려받아 다음 진료 예약 전에 의사에게 요약 보고서를 보내는 데 사용한다.

시나리오에 제시된 사실을 바탕으로 앱 개발자는 HIPAA 협력사인가?

아니다. 개발자는 피보호된 실체나 다른 사업체를 대신하여 보호되는 건강 정보(PHI)를 생성, 수신, 유지 또는 전송하지 않는다. 의사의 권고는 앱에 대한 소비자의 신뢰를 암시하지만, 의사가 PHI를 다루는 환자들에게 서비스를 제공하기 위해 앱 개발자를 고용한 흔적은 없다. 소비자가 커버리지에 데이터를 전송하기 위해 앱을 사용하는 것 자체만으로 앱 개발자가 커버리지에 속하는 BA가 되는 것은 아니다.

Senario 4

소비자는 본인의 만성적인 상태를 관리하는 것을 돕기 위해 고안된 건강 앱을 스마트폰에 다운로드한다. 의료 사업자와 앱 개발자는 제공자인 EHR과 앱 사이의 소비자 정보의 안전한 교환을 촉진하는 소비자의 요청에 따라 상호운용성 협정을 체결하였다. 소비자는 앱에 정보를 저장하고 앱이 제공자의 EHR로 정보를 전송하도록 한다. 소비자는 앱을 통해 공급자의 테스트 결과에 액세스할 수 있다.

시나리오에 제시된 사실을 바탕으로 앱 개발자는 HIPAA 협력사인가?

아니다. 개발자는 피보호된 실체나 다른 사업체를 대신하여 보호되는 건강 정보(PHI)를 생성, 수신, 유지 또는 전송하지 않는다. 소비자가 개시한 접근을 용이하게 하기 위해 약정이 존재하기 때문에 상호운용성 약정만으로는 BA 관계가 형성되지 않는다. 앱 개발자는 소비자의 요청에 따라, 그리고 그녀를 대신하여 서비스를 제공하고 있다. 앱 개발자는 소비자를 대신하여 공급자에게 데이터를 전송하고 있다. 이 활동은 대상 기업과 BA 관계를 형성하지 않는다.

Senario 5

제공자의 지시에 따라 환자는 스마트폰에 건강 앱을 다운로드한다. 제공자는 원격 환자 건강 상담, 환자의 음식 및 운동 모니터링, 환자 메시지, EHR 통합 및 애플리케이션 인터페이스를 포함한 환자 관리 서비스를 위해 앱 개발자와 계약했다. 환자가 입력한 정보는 제공자 전자 건강 기록(EHR)에 자동으로 통합된다.

시나리오에 제시된 사실을 바탕으로 앱 개발자는 HIPAA 협력사인가?

맞다, 개발자는 보호 대상 엔티티를 대신하여 보호 상태 정보(PHI)를 생성, 수신, 유지 및 전송하기 때문에 공급자의 BA다. 이 경우, 제공자는 PHI의 생성, 수신, 유지 및 전송을 포함하는 환자 관리 서비스를 위해 앱 개발자와 계약하며, 앱은 이러한 서비스를 제공하는 수단이다.

회사 업무중 원문 링크 를 읽고 번역문서를 작성하게 되었다.

대략적인 내용은 생체정보(혈압, 체온, 혈당 등)를 다루는 어플리케이션을 만들때 따라야 할 규칙에 대한 것이다.

Overview

기술제품에 개인정보 보호와 보안기능을 구축하면 사용자들에게 해당 정보는 안전하며 승인되거나 예상대로만 사용 및 공개될 것임을 어느정도 보장하여 그 가치를 향상시킨다.

이러한 보호는 때로 HIPAA 개인정보 보호, 보안 및 위반 통지 규칙을 포함한 연방 및 주 법률에 의해 요구되기도 한다.

OCR은 건강 정보 기술과 HIPAA 프라이버시 및 보안에 관심이 있는 모바일 건강(mHealth)앱 개발자와 다른이들에게 지침을 제공한다.

Health App Use Scenarios & HIPAA - PDF - 이 지침은 모바일 헬스 애플리케이션에 대한 다양한 사용 시나리오를 자세히 다루고 앱 개발자가 HIPAA 규칙에 따라 제휴사로 활동할 수 있는 시기를 설명한다.

Mobile Health Apps Interactive Tool - 연방무역위원회(FTC)는 OCR, HHS 국가보건정보기술조정국(ONC), 식품의약국(FDA) 등과 함께 건강 모바일 앱 개발자들이 그들에게 적용할 수 있는 연방법과 규정을 이해할 수 있도록 웹 기반 도구를 만들었다.

해당 지침서는 개발자에게 앱의 기능, 수집 데이터 및 사용자에게 제공하는 서비스를 포함한 앱의 특성에 대한 일련의 질문을 한다.

개발자의 답변을 배경으로 지침서는 앱 개발자가 적용될 수 있는 특정 연방법에 대한 상세한 정보를 알려준다.

여기에는 FTC(공정위법), 공정위의 건강침해통보법, HIPAA(건강보험이동성 및 책임법), FD&C법(연방식품의약품화장품법)등이 포함된다.

Access Right, Apps, and APIs - 액세스 권한, 애플리케이션 및 API와 관련하여 HIPAA 법이 적용된 엔티티 및 해당 제휴사에게 어떻게 적용되는지 자주 묻는 질문.

Access Right, Apps, and APIs - 액세스 권한, 애플리케이션 및 API와 관련하여 HIPAA 법이 적용된 엔티티 및 해당 제휴사에게 어떻게 적용되는지 자주 묻는 질문.

Health Information Technology - HIPAA 및 보건 IT에 대해 자주 묻는 질문.

Guidance on HIPAA & Cloud Computing - OCR은 HIPAA가 자사의 HIPAA 법을 준수하면서 클라우드 컴퓨팅 기술을 사용할 수 있는 방법을 이해하는 데 있어 클라우드 서비스 공급자(CSP)를 포함한 기업 및 제휴사를 지원하는 지침을 개발하였다.

1996년에 제정된 건강보험 이전과 책임에 관한 법(Health Insurance Portability and Accountability Act, HIPAA) 은 귀하의 의료 정보를 열람 및 수령할 수 있는 사람에 대한 규정을 명시한 연방법입니다.

FDA - Medical Device Data Systems

Overview

• 의료기기 데이터 시스템(이하 MDDS) 는 의료기기의 데이터를 전송, 저장, 형식 변환 및 표시하는 경향이 있는 하드웨어 또는 소프트웨어이다.
• MDDS는 데이터를 수정하거나, 데이터 출력을 수정하거나, 의료 기기가 스스로 기능이나 매개변수를 제어하지 않는다.
• MDDS는 능동적인 환자 모니터링일 수도 있고, 그렇지 않을 수도 있다.

연방 식품 의약품 및 화장품 법 520 (o)(1)(D) 조

• 의료기기 데이터 또는 의료 이미징 데이터를 전송, 저장, 변환 및 표시하기 위한 소프트웨어 기능 자체는 기기에 포함되는 것이 아니며, 기기에 적용되는 FDA 규제 요건에 따르지 않는다. FDA는 이러한 소프트웨어 기능을 Non-Device-MDDS 라고 묘사한다.
• 의료기기 데이터나 결과를 전송, 저장, 변환 및 표시하기 위한 하드웨어 기능만을 Device-MDDS 라고 한다.

소프트 웨어 기능을 포함하는 Non-Device-MDDS 예시

• 나중에 검토 가능한 혈압 측정과 같은 환자에 대한 데이터 저장
• 맥박 산소계에 의해 생성된 디지털 데이터를 출력 가능한 형식으로 변환
• 특정 환자에 대하여 이전에 저장된 심전도를 표시

MDDS 규칙

Overview

2011년 2월 15일 관보(76 RF8637)에서 FDA는 MDDS를 등급 3(사전 식장 승인 대상) 에서 등급 1(일반 통제 대상)로 재분류 하는 최종 규칙을 발표했다.

1976년 5월 28일 이전에 상업적으로 배포되지 않은 기기는 일반적으로 수정 후 장치라고 하여, 식품 의약품 및 화장품법 (21 U.C. 360c(f)) 제 513조 (f) 에 의거하여 등급 3의 장치로 분류된다. 장치 및 방사선 건강 센터CDRH 는 그러한 수정 후 장치를 평가하여 안전성 효과에 대한 합리적인 보증을 제공하는데 필요한 적절한 수준의 규제 통제를 설정한다. CDRH는 이러한 장치를 등급 1(일반 제어 필요), 등급 2(특별 제어 필요), 등급 3( 사전 시장 필요)로 분류하기로 결정할 수 있다.

이와 관련된 위험은 의료기기 데이터의 부정확하거나 불완전하거나 시기 적절하지 않은 데이터 전송, 저장, 변환 및 표시의 가능성을 내포한다. 경우에 따라 이것이 환자의 오진 및 잘못된 치료를 유발할 수 있다. 이러한 위험성 평가에 기초하여, FDA는 품질 시스템 규정(21 CFR Part 820)과 같은 일반적인 통제가 안전성과 효과에 대한 합리적인 보증을 제공할 것이라고 결정하였다. 따라서 특별 통제와 사전 시장 승인이 필요하지 않다.

관보는 의료 장비 데이터 시스템을 다음과 같은 정의를 제공한다.

1. MDDS는 의료기기의 기능이나 매개변수를 제어하거나 변경하지 않고 다음 사용법 중 하나 이상을 제공하도록 의도된 기기 이다.
   • 의료기기 데이터의 전자적 전송
   • 의료기기 데이터의 전자적 저장
   • 사전 설정된 규격에 따른 의료기기 데이터의 전자적 변환
   • 의료기기 데이터 전자적 표시
2. MDDS는 물리적 통신 매체(무선 하드웨어 포함), 모뎀, 인터 페이스 및 통신 프로토콜과 같은 소프트웨어, 전자 또는 전기 하드웨어를 포함할 수 있다. 이 식별법은 능동적인 환자 모니터링과 관련하여 사용하도록 설계된 장치는 포함되지 않는다.

실제로 MDDS는 다음 기능중 하나 이상을 제공하기 위한 의료 기기다.

• 연결된 장치의 기능이나 매개변수를 변경하지 않고 의료기기에서 의료기기 데이터를 전자적으로 전송 또는 교환한다. 예를 들면, 환자의 CO2 레벨에 대한 인공 호흡기의 출력을 수집하고 중앙 환자 데이터 저장소에 정보를 전송하는 소프트웨어가 포함된다.
• 연결된 장치의 기능이나 매개변수를 변경하지 않고 의료기기 데이터를 전자적으로 저장 및 검색한다. 예를 들어, 의료행위를 제공한 사람이 나중에 검토할 수 있도록 이전의 혈압 정보를 저장하는 소프트웨어 이다.
• 사전 설정된 규격에 따라 한 형식에서 다른 형식으로 의료기기 데이터를 전자적으로 변환한다. 예를 들어, 맥박 산소계에서 생성된 디지털 데이터를 출력할 수 있는 디지털 형식으로 변환하는 소프트웨어 이다.
• 연결된 장치의 기능 또는 매개 변수를 변경하지 않고 의료기기 데이터를 전자적으로 표시한다. 예를 들어, 특정 환자에 대한 이전 저장된 심전도를 표시하는 소프트웨어이다.

의도한 용도가 MDDS 규정과 일치할 경우 다음이 포함된다.

• MDDS 규정에서 의도된 용도와 일치하는 목적으로 특별히 제작된 소프트웨어 또는 하드웨어를 포함하는 네트워크 구성 요소의 조립 또는 배치
• MDDS로서 제조자가 특별히 라벨로 표시한 제품(21 CFR 801에 따라)은 추가 기능을 제공하지 않는 경우 의료기기 정보를 얻기 위해 의료기기에 직접 연결하는 원래 의료기기 제조업체(예: 병원, 제3자 공급업체) 이외의 주체가 작성한 사용자 정의 소프트웨어
• 특정 MDDS 기능을 위해 생성 및/또는 수정된 IT 인프라의 일부인 소프트웨어 또는 하드웨어의 수정된 부분. 예를 들어 소프트웨어를 수정할 때(소프트웨어 소스 코드 작성 및 컴파일), 수정된 부분은 MDDS로 간주한다.

MDDS가 아닌 것 이란?

의료 시설에 사용되는 범용 IT 인프라로서 제조된 사양을 벗어나 변경 또는 재구성되지 않는다. 기성 운영 매개 변수 내의 수정은 MDDS가 아닌 일반 IT 인프라로 고려된다. 예를 들어 다음과 같은 기능을 가진 구성 요소는 다은 정보에 추가하여 의료 기기 데이터를 전송, 저장, 표시 또는 변환 할 수 있지만, 일반 IT 인프라의 일부로 사용되는 경우 MDDS로 간주되지 않는다.

• FD & C 규정 201(h)에 따른 의료기기 정의를 충족하지 않는 어떤 시스템이 작동 중이거나 오작동 하는지 또는 기타 유사한 사용을 확인하기 위해 의료기기를 유지 관리하는데 사용되는 네트워크이다.
• 제조업체에서 MDDS로 특별히 판매하지 않는 표준 IT 소프트웨어로서, 의료 기기에서 일련번호, 바코드, UDI 또는 기타 데이터를 읽는 등의 MDDS 기능을 가질 수 있지만 환자 진료 서비스에는 사용되지 않는다.
• 일반적으로 네트워크 성능을 모니터링하기 위해 사용되는 기성 수동 네트워크 스니핑 소프트웨어는 이 소프트웨어가 의료기기에 직접 연결되지 않는 경우 네트워크에서 TCP/IP 패킷을 읽음으로써 사용된다.

Examples

• 의료기기 데이터 전자적 전송
  • 네트워크 라우터
  • 네트워크 허브 무선 액세스 포인트(Access point)
• 의료기기 데이터 전자적 스토리지
  • NAS네트워크 연결 스토리지
  • SAN 스토리지 영역 네트워크
• 사전 설정된 규격에 따라 의료기기 데이터를 한 형식에서 다른 형식으로 전자 변환
  • 가상화 시스템
  • PDF 소프트웨어
• 의료 기기의 전자적 표시
  • 컴퓨터 모니터
  • 큰 화면 디스플레이

Requirements for Health Care Facilities and Manufactures

MDDS 제조사는 누구인가?

"MDDS 제조사"란 다음 활동에 종사하는 의료 시설 및 제조업체일 수 있다.

• MDDS 규칙(데이터 전송, 저장, 표시 또는 변환)에 설명된 기능 수행 및 의료기기의 접점을 위한 범용 IT 장비/소프트웨어 또는 인프라.
• MDDS로 라벨링한 의료기기와의 인터페이스 및 MDDS 규칙(데이터 전송, 저장, 표시 또는 변환)에 기술된 기능 수행을 목적범용 IT 장비/소프트웨어.
• MDDS 규칙(데이터 전송, 저장, 표시 및 변환)에 설명된 기능 수행 및 의료기기와 인터페이스 목적의 사용자 정의 소프트웨어 또는 하드웨어의 설계 및 구현

최종 규칙 준수 방법

구현 타임라인

MDDS 최종 규정은 2011년 4월 18일에 발효되었다. MDDS(이 정의를 충족하는 의료 시설 포함)의 모든 제조업체는 특정 조치를 취해야 하는 다음과 같은 주요 날짜를 알고 있어야 한다.

1. 2011년 5월 18일: 제조 업체들은 FDA에 등록 및 리스트 작성이 요구한다. (2011년 2월 15일 FR 공지로 부터 90일)

2. 2012년 4월 18일: 제조 업체들은 인증된 품질 시스템을 구현하고 부작용 보고를 시작해야 한다. (2011년 4월 18일 규칙이 발효된 날 부터 12개월)

MDDS 제조와 관련된 MDDS 제조 업체 및 의료 시설에 대한 지침

최종 MDDS 규칙은 MDDS 제조업체(MDDS 제조에 관련된 의료 시설 포함)가 premarket신청서 제출을 요구하지 않는다.

MDDS를 제조하는 의료 시설을 포함한 모든 MDDS 제조자는 다음을 포함하여 등급 1의 의료기기의 요건을 준수해야 한다.

기관 등록 및 모든 MDDS 제품을 연간 기준과 연간 목록의 일부를 나열하여, 모든 업데이트된 정보(예: 새로운 버전의 소프트웨어)가 반드시 포함되어야 한다. 등록과 목록은 다음과 같은 내용을 포함한다:

• MDDS 제조 여부 판단
• 새로운 업데이트 또는 소프트웨어 버전을 포함하여 제조한 제품 식별
• 시설의 연간 등록 및 기기 목록을 담당하는 시설의 소유자/운영자가 지정한 공식 통신원을 지정. 공식 통신원은 또한, FDA로부터 소유자/운영자와 회사의 모든 시설을 포함하는 편지 수령.

1. 기업용 Apple 계정 개설하기

Apple 계정으로 로그인하여 절차를 진행합니다. 계정 등록에 사용하는 이메일 주소는 Apple ID와 연결되어 있어야합니다. 해당 계정으로 개발자 등록 절차를 진행하게되므로 개인이 아닌 기업용 계정을 사용하셔야 합니다. 여기에서 간편하게 Apple ID를 만들 수 있습니다.

2. 이중 인증 활성화 하기

Apple 개발자 계정을 신청하기 전에 Apple ID에 이중 인증 (two-factor authentication, 2FA)이 활성화되어 있어야합니다. iOS 또는 macOS 기기가 필요합니다. Apple ID가 해당 기기의 기본 계정으로 로그인 된 경우에만 이중 인증을 활성화 할 수 있습니다. 또한 이중 인증은 2 단계 확인과는 다릅니다. 이중 인증이 활성화되면 Apple ID를 모든 장치에 보조 계정으로 추가 할 수 있습니다. iCloud 및 Apple 개발자 계정 (권장사항)에 Apple ID를 사용하는 경우, Apple에서 정해놓은 인증 단계를 수행 할 수 있습니다.

3. 계정을 Apple 개발자로 등록하기

Apple 계정으로 로그인하셨다면 Apple 개발자 계정 등록 페이지에서 해당 계정을 개발자로 등록하세요. 신청이 완료되면 며칠내로 Apple에서 입력한 정보 확인을 위해 전화/이메일을 발송합니다.

<주의> "기업"으로 등록하십시오. 가이드북은 개인 또는 회사계정으로 앱을 App Store에 제출할 수 없습니다.

4. Apple 개발자 프로그램 연회비 지불하기

개발자로 등록이 완료되면 최종 승인 이메일을 받게 됩니다. 해당 메일에서 Apple 개발자 프로그램 멤버십 비용 및 지불 절차에 대한 안내를 확인하세요.

• 비용: $99 USD | 한화 129,000원
• 가이드북이 아닌 Apple에 납부하는 비용입니다.

대상 국가에 소재하고 있으며 App Store에서 무료로 앱을 배포하려는 비영리 조직, 공인된 교육 기관 및 정부 기관은 Apple Developer Program 멤버십 연회비 면제를 요청할 수 있습니다. Apple은 요청을 검토한 후 별도의 연락을 통해 요청 승인 여부를 안내해 드릴 것입니다. 대상 국가: 호주, 브라질, 캐나다, 중국 본토, 프랑스, 독일, 이스라엘, 이탈리아, 일본, 멕시코, 대한민국, 영국, 미국.