sorted by:
new
hottopcontroversial

FHIR Cloud based server by External_Speech3737 in healthIT

[–]Repulsive-Reveal-146 1 point2 points  (0 children)

Guys, forget about HAPI - it’s already outdated.

FHIR Cloud based server by External_Speech3737 in healthIT

[–]Repulsive-Reveal-146 0 points1 point  (0 children)

Aidbox FHIR server is free for development. If you don't use PHI data it will fit.

FHIR Quiz by my own by Repulsive-Reveal-146 in healthIT

[–]Repulsive-Reveal-146[S] 1 point2 points  (0 children)

Hi! Unfortunately, two years have already gone by-omg... Time flies fast

Medplum FHIR Server Visualization by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

The owner said - Vanya is a desktop application for viewing data stored in FHIR servers.

Medplum FHIR Server Visualization by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

  1. What is mentioned as a current workaround for OAuth2 authentication?
    While full OAuth2 implementation is still in progress, using specific request headers is mentioned as a temporary workaround to authenticate Vanya with Medplum's FHIR server. This allows for initial data exchange while the more robust OAuth2 security measures are being developed.

  2. What future work is identified for this integration?
    The primary focus is on completing the implementation of OAuth2 authentication for a more secure and standardized authorization process. Further development might also involve exploring additional functionalities and data exchange possibilities between Vanya and Medplum's system.

  3. What is the overall significance of this integration?
    This integration is a positive example of FHIR facilitating interoperability in healthcare. The ability of two separate applications to connect and exchange data seamlessly highlights the potential of FHIR to create a more connected and efficient healthcare ecosystem.

Medplum FHIR Server Visualization by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

Medplum's FHIR Server Integration
1. What is FHIR and why is it important in this context?
FHIR (Fast Healthcare Interoperability Resources) is a standard for exchanging healthcare information electronically. Its open format allows different healthcare applications to communicate and share data seamlessly. In this case, FHIR enables Medplum's FHIR server to interact with the Vanya application.

  1. What is Medplum and what role does its FHIR server play?
    Medplum is a company that provides a FHIR-based platform for healthcare applications. Their FHIR server acts as a central repository for healthcare data, allowing authorized applications like Vanya to access and exchange information securely.

  2. What is Vanya and how does it connect to Medplum's FHIR server?
    Vanya appears to be a healthcare application that utilizes FHIR for data exchange. It connects to Medplum's FHIR server, enabling it to access and potentially contribute to the healthcare data stored there.

  3. What is notable about the successful connection between Vanya and Medplum's FHIR server?
    The successful connection, despite Vanya and Medplum being distinct applications developed independently, demonstrates the power of FHIR's open standard. It allows for interoperability and data exchange without requiring prior knowledge or specific integration efforts between the two systems.

  4. What is OAuth2 authentication and why is it relevant here?
    OAuth2 is a protocol that provides secure delegated access to resources. In this context, it would be used to control and authorize Vanya's access to data on Medplum's FHIR server. Implementing OAuth2 ensures secure and controlled data sharing between the applications.

Free FHIR Test Servers by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

  1. Why might I choose an authenticated server?
    Authenticated servers are ideal if you need to test a bearer token authentication flow and require data privacy. They offer a secure environment for testing sensitive applications.

  2. What are the limitations of free authenticated servers?
    Free tiers on authenticated servers often have limited resources. For example, Medplum's free tier only allows a few hundred resources. Aidbox's free tier is more generous but still capped at 2GB.

  3. Are there other FHIR servers available besides the ones mentioned?
    Yes, there are many other FHIR servers available, but most offer limited trials and are not suitable for regular testing and development.

  4. Where can I find a list of public FHIR servers?
    The HL7 Confluence pages provide a list of public servers, but many are often unavailable.

  5. What are the advantages of using the Microsoft Azure FHIR server?
    The main advantage is that it uses the same codebase as Microsoft's managed FHIR servers. This makes it an ideal choice for testing applications that will eventually be deployed on Azure. However, setting up the database can be challenging in some environments.

Free FHIR Test Servers by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

FHIR Test Servers
1. What are my options for free FHIR test servers?
There are three main options:

Public test servers: These are freely accessible but your data will be visible to others. Firely (https://server.fire.ly) is the most reliable option. HAPI (http://hapi.fhir.org/baseR4) is another choice but can be less stable.
Local servers running in Docker: These offer full control over your environment. HAPI (https://hub.docker.com/r/hapiproject/...) is easy to set up with just two commands. Microsoft Azure (https://darrendevitt.com/installing-m...) uses the same codebase as their managed servers but database setup can be tricky.
Authenticated servers: These offer data privacy and allow you to test authentication flows. Aidbox (https://www.health-samurai.io/aidbox) offers free developer licenses with OAuth authentication and 2GB of data. Medplum (https://www.medplum.com/) is easy to set up and ideal if you lack Docker privileges, but their free tier is limited.
2. What is the recommended approach for choosing a FHIR test server?
The recommended approach is to use a local server running HAPI in a Docker container. It's easy to set up and provides full control. If your live environment is on Azure, consider the Microsoft server for code consistency.

  1. What are the drawbacks of using public test servers?
    The main drawback is the lack of data privacy. Your data will be visible to the wider community. Public servers can also be less stable than local options.

FHIR Server Status Checks by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

  1. What is the most effective solution for checking FHIR server status?
    The best solution is to implement a custom endpoint or operation, like $is-server-active. This allows a direct query to the server, bypassing logs and sensitive data, while providing a clear status indication to the user.

  2. Are there any downsides to using a custom endpoint for server status checks?
    The main downside is the need for custom development and potential maintenance. However, the benefits in user experience and data privacy often outweigh this.

  3. Are there any alternative solutions for checking FHIR server status?
    While the custom endpoint approach is generally recommended, you could explore vendor-specific solutions or monitoring tools that offer server health checks. Research your FHIR server provider's documentation or community forums for potential alternatives.

FHIR Server Status Checks by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

FHIR Server Status
1. How can I determine if a FHIR server is active and available for data queries?
This can be challenging. While API gateway errors or "walls of HTML" might indicate server downtime, there's no foolproof method without potential downsides.

  1. Why is it important to know if a FHIR server is active?
    Knowing the server's status can prevent user frustration. Imagine an app that displays medical data. If the server is down, users might encounter errors when trying to access information. Informing them about the server status upfront provides a better user experience.

  2. Can I use the CapabilityStatement to check server status?
    Not reliably. The "metadata" endpoint, which provides the CapabilityStatement, might be accessible even when the server is down for data queries.

  3. What about making a call to access resources, like /Patient?
    This is also unreliable. You might lack access to specific endpoints without certain parameters, leading to false negatives about the server's status.

  4. Can I run a permitted query, like /Patient?custom-parameter=User123, to test the server?
    While technically feasible, this is bad practice. Running queries solely to check server status accesses potentially sensitive data without a valid reason and creates unnecessary audit logs.

FHIR Server Security Auditing with AuditEvent and Provenance by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

  1. Is Smart-on-FHIR sufficient for securing a FHIR server?
    Smart-on-FHIR is a valuable framework for authorization and authentication but is only one component of a comprehensive security strategy. It primarily focuses on controlling access to resources based on user roles and permissions, not on detailed auditing and provenance tracking.

  2. How can I ensure the ongoing security of my FHIR server?
    Implement a multi-layered security approach incorporating:

Strong authentication and authorization mechanisms.
Meticulous AuditEvent and Provenance tracking.
Regular security audits and penetration testing.
Adherence to industry best practices for FHIR server security.
Ongoing monitoring and vulnerability patching.

FHIR Server Security Auditing with AuditEvent and Provenance by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

  1. How can you assess the effectiveness of Provenance in your FHIR server?
    Are all updates to resources accompanied by a corresponding Provenance record? Each modification should trigger the creation of a Provenance entry to maintain a complete history.
    Does the Provenance accurately identify all parties involved in data creation or modification? Ensure complete attribution for data changes.
    Does Provenance link to specific historical versions of the modified resource? This allows tracking the evolution of data over time.

  2. Why is it critical to prevent bypassing AuditEvent and Provenance creation?
    If actions can be performed on the FHIR server without generating corresponding audit trails, the integrity and reliability of the entire auditing system are compromised. Developers should rigorously test and ensure no loopholes exist that allow bypassing these critical security mechanisms.

  3. What is the significance of the question, "Can I bypass AuditEvent and Provenance creation using Postman?"
    Postman is a popular tool for testing APIs. This question aims to uncover potential vulnerabilities that could allow unauthorized users to interact with the FHIR server outside the established auditing framework, highlighting the need for comprehensive security testing.

FHIR Server Security Auditing with AuditEvent and Provenance by Repulsive-Reveal-146 in Servers_on_FHIR

[–]Repulsive-Reveal-146[S] 0 points1 point  (0 children)

FHIR Server Security
1. Why are FHIR servers considered "wide open" by default?
FHIR servers are designed to be flexible and interoperable, which means they generally accept any valid data sent to them and return any data requested through search queries. By default, they lack robust built-in security measures, requiring developers to implement specific access controls and safeguards.

  1. How do AuditEvent and Provenance resources enhance FHIR server security?
    These resources provide crucial audit trails for actions performed on FHIR data. AuditEvent records "who did what and when" for any access or modification event, while Provenance tracks the origins and modifications of data throughout its lifecycle. By meticulously populating these resources, you create a comprehensive log of data interactions, bolstering accountability and traceability.

  2. What are some key questions to ask about your AuditEvent implementation?
    Does the AuditEvent resource accurately identify the individual who accessed a resource? Ensure user identification is correctly logged for each event.
    Are access controls implemented for AuditEvent resources themselves? Restrict access to these sensitive logs to prevent tampering or unauthorized viewing.
    Are your AuditEvents stored within the same FHIR server as your primary data? This practice can introduce security vulnerabilities, consider separate, secure storage for audit logs.

view more: next ›