Fordern Sie eine Sandbox an und lassen Sie sich Projektkennung, Mandantencode und Zugangsdaten bereitstellen. Trennen Sie Test- und Produktivumgebungen. Aktivieren Sie die benötigten Anmelde-, Registrierungs- und Einladungsabläufe für Patienten und Behandelnde bewusst.

Neue Patienten benötigen eine Standard-Patientenrichtlinie im Projekt. Für neue Behandelnde muss eine Standard-Practitioner-AccessPolicy hinterlegt sein. Hinterlegen Sie die E-Mail-Vorlagen der verwendeten Einladungs- und Registrierungsabläufe.

Patient repräsentiert die behandelte Person, Device das Messgerät und Observation den Messwert. Referenzen verbinden diese Ressourcen. Speichern Sie Messzeitpunkt, Einheit und fachliche Kodierung zusammen mit dem Wert. Lesen und suchen Sie Daten über die FHIR-API unter dem Pfad /fhir/R4/.

Projekte und Unterprojekte organisieren Teams und Daten. Die Anwendung übernimmt die Benutzeroberfläche und die Versorgungslogik; das Backend verwaltet die gemeinsame Datenbasis und die unterstützten Integrationen.

Die Paketnamen sind technische Bezeichner und bleiben unverändert. Verwenden Sie die zum Backend passende SDK-Version und die zugehörigen Typdefinitionen. Ein vorhandener SDK-Aufruf bedeutet nicht automatisch, dass eine Funktion für Ihr Projekt freigeschaltet ist.

Mit dem React Native SDK können Sie Bluetooth-Erkennung und Messwertübernahme mit einem unterstützten physischen Gerät testen. Die produktive Datenübertragung von vernetzten Geräten und Systemen wird mit dem ACTIMI-Team eingerichtet. Dabei wird die Verbindung zum IoT-Dienst mit gegenseitiger TLS-Authentifizierung abgesichert.

Das Backend ordnet eingehende Werte dem Projekt zu und speichert sie als FHIR-Ressourcen. Ihre Anwendung liest aktuelle Werte und Verlauf über die API. Prüfen Sie das konkrete Gerätemodell und den unterstützten Übertragungsweg vor der Integration.

Projekteinstellungen entscheiden, ob ein Ablauf verfügbar ist; AccessPolicies bestimmen, auf welche Ressourcen und Aktionen ein angemeldetes Mitglied zugreifen kann. Vergeben Sie Lese-, Such-, Erstellungs-, Änderungs- und Löschrechte gezielt und begrenzen Sie den Datenzugriff mit passenden Kriterien.

Eine fehlende Richtlinie bedeutet bei gewöhnlichem Projekt- und FHIR-Zugriff keine eingeschränkten Rechte. Weisen Sie jedem Mitglied ausdrücklich eine passende Richtlinie zu. Für Signals benötigen Nicht-Administratoren zusätzlich die benannten Signals-Berechtigungen und den zugehörigen Patientenzugriff.

Die FHIR-Datenhaltung funktioniert auch ohne Signals. Aktivieren Sie Signals gezielt pro Patient. Nur geeignete Vitalwerte von eingeschriebenen Patienten werden zur Auswertung übermittelt; die Alarmentscheidungen stehen Ihrer Anwendung anschließend zur Verfügung.

Signals ist ein Medizinprodukt der MDR-Klasse IIa. Diese Klassifizierung gilt nicht pauschal für das FHIR-Backend oder eine darauf entwickelte App. Datenzugriff, Alarmdarstellung und klinische Reaktion müssen im eigenen Versorgungsablauf definiert werden.

Prüfen Sie Geräteanbindung, Berechtigungen und Projektkonfiguration mit Testdaten. Vereinbaren Sie anschließend den Produktionstarif, die Datenverarbeitung, Umgebungen und Supportanforderungen. Schließen Sie die Live-IoT-Einrichtung mit ACTIMI ab, bevor Sie produktive Gerätemessungen einplanen.

Nutzen Sie für Fehlerbehandlung die dokumentierten Antwortformate: Standard-HTTP-APIs verwenden Problem Details; FHIR-Aufrufe liefern OperationOutcome. Protokollieren Sie Status und Trace-ID für Supportanfragen, ohne Zugangsdaten oder Patientendaten in Logs aufzunehmen.

Request a sandbox and obtain the project identifier, tenant code and credentials. Keep test and production environments separate. Explicitly configure the sign-in, registration and invitation flows needed for patients and practitioners.

New patients require a default patient policy on the project. New practitioners need a configured default Practitioner AccessPolicy. Map the email templates used by invitation and registration flows.

Patient represents the person receiving care, Device the measurement device and Observation the reading. References connect these resources. Store the measurement time, unit and clinical coding with the value. Read and search resources through the FHIR API under /fhir/R4/.

Projects and sub-projects organise teams and data. Your application owns the user experience and care logic; the backend manages the shared data foundation and supported integrations.

Package names are technical identifiers and remain unchanged. Use an SDK version compatible with the backend and its corresponding type definitions. An available SDK method does not establish that a feature is enabled for your project.

Use the React Native SDK to test Bluetooth discovery and measurement capture with a supported physical device. Production ingestion from connected devices and systems is configured with the ACTIMI team. The connection to the IoT service uses mutual TLS authentication.

The backend associates incoming readings with the project and stores them as FHIR resources. Your application reads current and historical values through the API. Confirm the exact device model and supported connection method before integration.

Project settings control whether a flow is available; AccessPolicies control which resources and operations an authenticated member may access. Assign read, search, create, update and delete permissions deliberately, with criteria that scope access to the appropriate data.

A missing policy does not imply restricted access for ordinary project and FHIR operations. Assign an explicit policy to each member. Non-admin Signals callers additionally need the named Signals capabilities and corresponding Patient access.

FHIR storage works independently of Signals. Enable Signals per patient. Only eligible vital readings from enrolled patients are forwarded for evaluation; resulting alert decisions are returned to your application.

Signals is an MDR Class IIa medical device. This classification does not automatically apply to the FHIR backend or an application built on it. Define data access, alert presentation and clinical response within your own care workflow.

Validate device integration, permissions and project configuration using test data. Then agree the production plan, data processing, environments and support requirements. Complete live IoT setup with ACTIMI before relying on production device ingestion.

Use the documented response formats for error handling: standard HTTP APIs use Problem Details; FHIR calls return OperationOutcome. Record status and trace identifiers for support without exposing credentials or patient data in logs.