HL7 FHIR® has defined many type of "Resources", which are the smallest unit for data exchange, that can easiliy fulfill your requirements.
If you are not familiar with FHIR, we will support you through our consultation services to identify what resources are suitable for you.Contact us to learn about Our Customer Support Policy
Based on the characteristics of your use cases and applications, you may need extensions (new elements), restrictions (on cardinalities), specializations, value set restrictions on resource models. FHIR provides a profiling mechanism for this process and a special resource "StructureDefinition" is used to define these changes in machine processable way.
|Dietary Intake Observation
There are free toolings (e.g. Forge) for FHIR that are used to create these definitions over a GUI.
Don't worry, if you are not familiar with FHIR, we will support you in defining your custom Resource Profiles.Contact us to learn about Our Customer Support Policy
Based on your use cases you may have different data manipulation policies for different resource types; e.g. not allowing deletion or update for specific type of resources or need different query parameters for a specific type of resources. FHIR allows this and such customizations are defined by Infrastructure resources (e.g. Conformance, SearchParameter, etc)
keyboard_arrow_right Allow CRUD and search operations for Condition resource
keyboard_arrow_right Patient's conditions can be searched by patient id, the code (the coded description of the condition), and clinicalStatus
onFHIR.io provides you a administrative panel to manage the platform; select what and how you want to share the health data you are responsible for
Don't worry, if you are not familiar with FHIR, we will support you in all these customizations with consultations and training.Contact us to learn about Our Customer Support Policy
You may have different performance (SLA) and scalability requierements for different resources (e.g. Observation vs Procedure).
Observation records for 100 Millions of patient
Avg. 2 observations per patient per day (e.g. blood glucose)
Mostly patient and day based queries for observations
Deploy on at most 10 servers (hardware restrictions)
Horizontal Scaling (Sharding) over patient id
Indexing on patient and time of observation (descending order)
onFHIR.io is configurable for each resource type to tune the system and services specifically to your requirements (SLA, hardware restrictions, volume of data, etc).
onFHIR.io is providing default configurations for most basic use cases and we support you with our extensive expertise to find what suits you bestContact us to learn about Our Customer Support Policy
onFHIR.io implements User Managed Access (UMA) as "Resource Manager" for authorization and specifically OAuth 2.0 and Heart WG UMA and OAuth profiles for authorization, and HL7 FHIR for audit recording. So, If you have existing authorization and audit systems compliant with these standards, it can easily be integrated with them
Our onAuth.io suite provides you the following features;
- Authentication/Identity Service compliant with OpenID Connect and Heart WG-OpenID Connect profile to handle single sign-on, user registration, user profile data.
- Authorization Service compliant with OAuth2, UMA specifications and Heart WG profiles for these specifications.
- Audit Server compliant with HL7 FHIR to persist audit records.
- A web application for administration of the platform and enable patients Privacy management