Skip to main content

#EHR System0 utenti parlano di questo argomento

Working on a large Healthcloud Implementation with over 30 API integrations with various Epic objects for things such as medication refills, scheduling, insurance registration, patient profile to name just a few. This project also includes marketing cloud and data cloud. TIBCO is the clients middleware - Mulesoft is not being used and will not. In addition FHIR is not the API standard in use.

My question is this- what kind of performance can be expected in Salesforce when these are API calls are made ? Is this something to be overly concerned about (performance) ? Does anyone have any examples where they have done these types of integrations between Sf and Epic?

As expected Epic has not been helpful at all. In fact they would not sign an nda to allow the SF team to work with then. So SF cannot even look at screen shots so this is also a factor making this harder. I work for the client not SF. @epic @healthcloud @integrationwithepic @epicintegrationwithsalesforce

#Integration #Automation #Salesforce Health Cloud #HealthCloud #EHR #EHR System #API #Integration Tool #SFDC Integration #Data Cloud
1 commento
  1. 8 mag 2024, 04:49

    Aiming to reduce the burden on Salesforce and improve overall performance:

    1. Utilize Middleware Effectively:

    • TIBCO as a Buffer: Leverage TIBCO's capabilities to:
      • Aggregate and Batch Requests: Combine multiple API calls into fewer, larger batches to reduce network traffic and improve efficiency.
      • Error Handling and Transformation: Handle potential errors from Epic's API and transform data to a format suitable for Salesforce.
      • Caching: Implement caching mechanisms within TIBCO to store frequently accessed data and reduce calls to Epic's API.

    2. Optimize Salesforce Configuration:

    • Bulk API: Consider using the Salesforce Bulk API for large data loads instead of individual DML operations.
    • Asynchronous Processing: Utilize asynchronous Apex or Queues to handle API calls and data processing in the background, improving user experience for Salesforce operations.
    • Governor Limits: Be mindful of Salesforce governor limits (e.g., concurrent callouts, DML statements per transaction) and design your integration accordingly.

    3. Data Management Strategies:

    • Denormalization: If certain data is frequently accessed, consider denormalizing it in Salesforce to reduce the need for multiple API calls to Epic.
    • Change Data Capture (CDC): If only changed data needs to be synced, implement CDC mechanisms to capture updates in Epic and trigger corresponding updates in Salesforce.

    4. Integration Patterns:

    • Enterprise Integration Patterns (EIP): Explore patterns like Message Queueing or Publish-Subscribe to decouple Salesforce from Epic and improve scalability.

    5. Performance Monitoring and Optimization:

    • Monitor Performance: Continuously monitor API call performance using tools like Workbench or Apex Execution Logs.
    • Profile and Analyze: Profile Apex code and identify bottlenecks for optimization.
    • Performance Tuning: Tune heap size, governor limits, and caching mechanisms based on usage patterns.

    Additional Considerations:

    • Security: Ensure secure communication between Salesforce, TIBCO, and Epic using HTTPS and proper authentication mechanisms.
    • Error Handling and Rollback: Implement robust error handling and rollback strategies to handle potential issues during data transfer.
    • Documentation: Document the integration architecture, configurations, and procedures for future maintenance and scalability.

    Categorization based on Data Flow and Processing:

    1. Point-to-Point (Request/Reply):
      • Suitable for: Simple one-time interactions like medication refills, where Salesforce initiates a request to Epic and receives a response.
      • Considerations: High volume of calls can overload both Salesforce and Epic.
      • Optimization: Leverage TIBCO for batching requests and caching frequently accessed data.
    2. Enterprise Service Bus (ESB) Pattern (using TIBCO):
      • Suitable for: Decoupling Salesforce and Epic, facilitating asynchronous communication, and centralizing message routing (especially for many API interactions).
      • Considerations: Requires additional configuration and management of the ESB (TIBCO in this case).
      • Optimization: Improves scalability and flexibility for handling various data flows.
    3. Event-Driven Architecture (EDA):
    • Suitable for: Real-time updates or notifications, like changes in patient profiles or scheduling updates.
    • Considerations: Requires event streaming infrastructure and handling mechanisms for real-time data processing.
    • Optimization: Improves responsiveness for situations requiring near real-time updates.

    Additional Considerations:

    • Hybrid Approach: You can combine these patterns based on the specific needs of each integration. For example, use point-to-point for medication refills and EDA for scheduling updates.
    • Data Transformation: Regardless of the chosen pattern, TIBCO can play a crucial role in transforming data between Epic's format and Salesforce's format.

     

    Choosing the Right Pattern:

    The best pattern depends on the specific requirements of each integration:

    Data Volume and Frequency: High volume or frequent calls might benefit from batching or an ESB.

    Real-time Needs: Real-time updates might necessitate an EDA approach.

    Complexity and Scalability: Complex integrations with multiple objects might favor an ESB for centralized routing.

0/9000

Hi,Can anyone tell me when should we use Candidate patients and when to use Lead Object,I am a bit confused ,I know that we can use Candidate Patients when we get data from EHR system and lead can be used to get leads from web etc.are there any other use cases that I might be missing.

2 commenti
  1. 2 ago 2020, 17:23
    @Ankit Singh - I would not recommend Candidate Patients, unless potentially for research use cases. The SF documentation can be a bit mis-leading here. Candidate is usually NOT used. For potential leads, a lead record type is sufficient, prospect usually the word of choice.
0/9000

Hi, I am Currently using eClinicalWorks EHR System. Does Health Cloud provide me interoperability between two systems out of the box or Do I need a third-party integration to accomplish this?

 

Can HealthCloud out of box features help me to replace the current EHR systems? Or should I have my EHR system as a Source System for Creating new Records? 

4 commenti
  1. 6 gen 2020, 16:19

    We have insatalled Salesforce HealthCloud in our Org. "Healthcare Provider" is standard object. I am admin in the system. I have modify all access to the object. When I open the record, on the page layout, there is no "Edit" button or there is no pencil beside the fields, which means I am not able to edit the record/fields on the page layout. Can someone give me ideas pls ?

    Also I am in the process of creating process builder for "Healthcare Provider" object, I have to update couple of fields .. I don't see any field being listed under this object.

    I felt like it's access issue .. but I have required access for the object.. please help me..We are using lightning....thanks.

    Any help will be appreciated.

0/9000