Lze pomocí bluetooth přenosu a přemostění na server udělat provizorní JIP?

[Filip Jirsák]

A to se řešit dá i jinak. Například stavební úpravou pokoje (okno..), kamerou, neustálou přítomností sestry, vytvořením dohledového pracoviště blíže (aby alespoň slyšeli, že něco pípá), atd..

Chápu, takže netušíte, co se kolem děje. V nemocnicích teď podle vás mají spoustu volného místa, takže je ideální čas na to něco tam bourat a zdít. A nebo tam aspoň mají spoustu sestřiček, které se nudí. Já teda mám úplně jiné zprávy.

Ale máte pravdu v tom, že pokud pacient zemře, protože už pro něj nebylo místo na JIP, nehrozí už u něj to, že by došlo k úrazu elektrickým proudem nebo ke komplikacím způsobeným infekcí.

Něco tam bastlit s Raspberry Pi a podobně je opravdu nemožné. Pořád je to nemocnice.

Svým způsobem vám to závidím, že si myslíte, že nemocnice zvládají všechno v pohodě a ještě mají rezervy, aby zvládly další covid případy, vše naprosto podle norem, bez přetěžování zdravotnického personálu.

Jedna vec je podomacku udelana rouska z bavlny nebo z kusu plexiskla udelanej stit, druha vec je elektricke zarizeni primo pripojene na pacienta nebo zivotni funkce monitorujici.

A třetí věc je, že máte pacienta, u kterého by bylo monitorování životních funkcí vhodné nebo dokonce nutné – a máte na výběr, zda je nemonitorovat vůbec, protože další zařízení podle norem už není k dispozici, nebo je monitorovat alespoň něčím, co nesplní normy, ale jakž takž to funguje.

Všimněte si, že jsem hned na začátku psal, že pokud by takové zařízení víc nefungovalo než fungovalo, napáchá víc škody než užitku. Ale pokud by nějak rozumně fungovalo, dává smysl ho použít, pokud profesionální zařízení splňující všechny normy nebudou k dispozici.

[Reklama]

[skopda]

Prosím experty o radu. V naší nemocnici ukládáme i dosti těžké případy Covidu na oddělení, která rozhodně nejsou určená pro intenzivnější péči....

Je otázkou jaká jsou v této situaci legislativní omezení. Než se pustíte do tvorby nějakých náhradních řešení, nechte si to posvětit od vedení, že za to přebírá plnou odpovědnost. Mohl by jste svým řešením 10 lidí zachránit a pozůstalí po 11. který umřel zažalují nemocnici a bude problém že v dohledu nad pacientem bylo použito necertifikované řešení. Nechci vás od toho odradit, ale před nasazením si to ověřte s kompetentními osobami.

Tohle je life critical aplikace, kde každý bug může mít velké následky. Pokud zamrzne přehledový dashboard, může se stát že někdo umře protože nedostane pomoc včas. Hledal bych hotová a otestovaná řešení. asi nebude první nemocnice na světě která něco podobného řeší. nicméně řešení bych hledal spíše v zahraničí (některá chudší země, kde není tolik byrokracie).

Kdyby jste si to přesto chtěl dělat sám, po technické stránce, jsou 2 možnosti.
1. Mobilní aplikace na telefon která data z oxymetru předá na server nemocnice, bude to znamenat více méně 1 telefon na 1 pacienta, je potřeba řešit dobíjení, kompatibilitu s různými telefony a tak podobně.
2. Vlastní bridge z BLE na ethernet např raspberry, s aplikací  která bude předávat data z BLE na server.
vyhodnocovací server + dashboard. je nezbytné mít na všech komunikacích watchdog aby se nemohlo stát že něco přestane komunikovat a na dashboardu zůstane vyset stará hodnota.

[jouda2]

Je otázkou jaká jsou v této situaci legislativní omezení. Než se pustíte do tvorby nějakých náhradních řešení, nechte si to posvětit od vedení, že za to přebírá plnou odpovědnost. Mohl by jste svým řešením 10 lidí zachránit a pozůstalí po 11. který umřel zažalují nemocnici a bude problém že v dohledu nad pacientem bylo použito necertifikované řešení.

Nemyslím (ale nejsa právník), že byť s posvěcením vedení by to za normálního, nebo i nouzového stavu bylo legální.
Dokázal bych si představit použití paragrafu o krajní nouzi v situaci "Itálie na jaře", a budu pevně doufat, že tak daleko to u nás nedojde.
(ale docela chápu při té extrámní míře nekompetence vlády, které jsme svědky dnes a denně, že se lidé kolem nemocnic připravují i na takovou extrémní možnost)

[SPECZ]

No, ještě jednodušší než bastlit něco s RPi by mohlo být udělat to kamerovým systémem - nějaký NVR co umí x kamer a rovnou i zobrazování, kamery nejlépe s  napájením skrz ethernet , a tím koukat na zobrazovače vzdálených přístrojů. A tam je instalace v jednotkách hodin - rozbalit, natahat kabely, kamery namířit na to na co se mají dívat, žádný velký laborování s tím. S trochou štěstí by se mohl nechat ukecat nějaký větší prodejce takové techniky aby to zasponzoroval. Zároveň tak nic není připojeno na pacienta, dokonce ani do stejné zásuvky jako jsou připojeny jeho podpůrné přístroje ...

[Filip Jirsák]

Dokázal bych si představit použití paragrafu o krajní nouzi v situaci "Itálie na jaře", a budu pevně doufat, že tak daleko to u nás nedojde.

Závidím vám váš optimismus, že to u nás v takovém stavu ještě není.

[Reklama]

[_Jenda]

No, ještě jednodušší než bastlit něco s RPi by mohlo být udělat to kamerovým systémem - nějaký NVR co umí x kamer a rovnou i zobrazování, kamery nejlépe s  napájením skrz ethernet , a tím koukat na zobrazovače vzdálených přístrojů.

Mně furt není jasné (a tazatel se již dále nevyjádřil), jestli je problém v tom, že ty přístroje vůbec nemá (nedivil bych se, kdyby monitory životních funkcí v nemocnicích prostě došly), nebo v tom, že z nich nedokáže dostat data do velitelské konzole.

[_Jenda]

Tak jemu to přišlo, je to tohle https://www.aliexpress.com/item/1005001749841026.html, má to prý UART po kterém to data vypisuje (což je pozitivní, protože jednosměrný UART se dá oddělit optoizolátorem za pár korun, když teda jako chcete - https://www.gme.cz/6n137), Bluetooth ještě nereverzoval. Saturaci to prý nějakou (vysokou ) ukazuje, ale nemáme to jak zkalibrovat.

[Charon351]

2. Vlastní bridge z BLE na ethernet např raspberry, s aplikací  která bude předávat data z BLE na server.
vyhodnocovací server + dashboard. je nezbytné mít na všech komunikacích watchdog aby se nemohlo stát že něco přestane komunikovat a na dashboardu zůstane vyset stará hodnota.

Toto jsem psal jsem to už na začátku a přijde mi to jako nejlepší varianta, ble senzory takže není nutné řešit spojení s pacientem, rpi se dá klidně hodit pod strop nebo do nějaké abb krabice aby k tomu nemohla voda, a data z něj streamovat do nějaké time series databáze, třeba můj oblíbený influxdb a z něj do grafany, v grafaně lze nastavit alerty jak na mezní hodnoty tak na to že netečou data,
pro sichr klidně může těch rpi sbírajících ze vzduchu data více, databáze se s tím popere, dají se i nastavit indexy tak, že se data budou sami mazat třeba po dni. Grafana má integrováno docela dost rozhraní přes který dokáže poslat error.
K rpi lze i přidělat reproduktory které mohou při výpadku dat začít řvát když se mu nějaké zařízení odmlčí.  
K reverzovani protokolu těch ble, na zacatku fora bylo nadhozeno par linku s kodem pro esp prěklopit to na rpi by neměl být problém, případně se daji použít i ty esp32 jako zběrače.

Ale jak tu podotkli jiní nejprve si skoč na právní zda je vůbec něco takového možné. Trochu se bojím, že po jejich odpovědi se toto vlákno zamkne.

Pokud ti to nezatrhnou, tak můžu z některými částmi pomoci.

[_Jenda]

Dodatek: „Jsme se možná nepochopili, ten UART je jako skrz bluetooth“

[czipis]

no zrovna ten odkazovany nebude moc ideal, kdyz

Low-power consumption,continuously work for more than six hours with two AAA batteries

to aby sestry nafasovali jeste peknou radku baterek a nabijecku

[Charon351]

Ještě k nápadům všelijakých kamer namířených na tablet
tak jednoduší je obrazovku streamovat třeba aplikací
https://play.google.com/store/apps/details?id=info.dvkr.screenstream

je to klasický mjpeg takže jej lze zobrazit jak v prohlížeči nebo třeba vlc.

[_Jenda]

So the module board did not arrive, but I have meanwhile ordered the bluetooth one.

Using on Linux: (credit: https://blog.atx.name/)

Kód: [Vybrat]

# pip3 install adafruit-circuitpython-ble
# apt-get install bluez-hcidump


Kód: [Vybrat]

#!/usr/bin/env python3

# SPDX-FileCopyrightText: 2020 ladyada for Adafruit Industries
# SPDX-License-Identifier: MIT

import time
import binascii

from adafruit_ble import BLERadio
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement
from adafruit_ble.services.nordic import UARTService

ble = BLERadio()
while True:
    while ble.connected and any(
        UARTService in connection for connection in ble.connections
    ):
        for connection in ble.connections:
            if UARTService not in connection:
                continue
            uart = connection[UARTService]
            # Returns b'' if nothing was read.
            data = uart.read(16)
            if not data:
                continue
            if len(data) < 16:
                print(data)
                continue
            print(binascii.hexlify(data))
            pi = data[8] / 10
            spo2 = data[7]
            hr = data[6]
            print(f"SpO2: {spo2} %")
            print(f"HR:   {hr} BPM")
            print(f"PI:   {pi:2f} %")
        time.sleep(0.1)

    print("disconnected, scanning")
    for adv in ble.start_scan(ProvideServicesAdvertisement, timeout=10):
        print(adv, adv.complete_name)
        if adv.complete_name == "F7" or True:
            ble.connect(adv)
            break
    ble.stop_scan()
Inside is HS6620C (https://www.reddit.com/r/AskElectronics/comments/e1fbrz/any_info_on_the_chip_labeled_hs6620_found_in/ - pretty much no info available) and HX3603 - http://www.synercontech.com/Public/uploads/file/2019_10/20191020144044_24730.pdf. There are SDA/SCL testpoints on the board, so one can probably get raw data. Current consumption is about 70 mA, lots of it is probably the display, it should be possible to probe for backlight connection on the board and dim it down, though I have not tried that.