...

• Every system needs to have a full representation of a person or patient locally within their system.
• There's business logic that needs to be executed on both sides of an integration for each system. Each system is responsible for receiving the content, parsing it and storing it appropriately within the system.
• Each CHIS has to have a FHIR REST API that conforms to the specification.

Notes on Architecture:

• We need to consider the process of patient de-duplication in both systems.
  • We probably assume that the receiving system will handle this. In a point to point integration, we would need to return a response in the case there's a high likelihood that they are the same patient.
  • How much data do I want to store in my system about the patient's state in another system? ← This is a big question.
• Considerations:
  • Only sync what you know you need to sync.
    • You could send a bundle, which would be great for the sending system.
    • Being able to create a bundle is hugely important for the sending system. The receiving system will need to break down that bundle, loop through each item and then
• General points:
  • Sending side support
    • Needs to package a bundle
  • Receiving side support
    • Break down a bundle
    • Return a response of failed in the event there's a parsing error in the bundle
  • Most of our integration requests are for sending DHIS2 aggregate information
  • We need to determine if we want to send a standardized document or just particular transaction
    • We send the limited things that we know will be used by the receiving end.
• Big problems to solve:
  • What does the sending system care about in the case of duplicates in the receiving system?
  • What information do you want to store in the sending system to make it easier in the receiving system?
  • From a project perspective, who takes on the responsibility of implementing the requirements in the receiving system?
    • For OpenMRS there's a multiple stage process
    • For DHIS2 there's a two stage process
• There is a difference between the syntax of the interoperability and the content that gets sent over.
• HIPAA in the back of our minds as ownership.
  • We can use data about the patient we need so we can match patients, but only send the data that we need to send over.
  • What data are you looking for? We provide that and then send it over.
  • What about authorization and access to information within roles?
• We are all dealing with Community Health Workers and their use cases. Either CHWs are registering patients or they have a set of patients already.
  • If you already have a set of patients, they come from somewhere with system generated ids and primary keys, making it easy to sync.
• We should explicitly call out the semantic vs syntactic interoperability so it's clear for people to understand when they see this work.
• The primary use case would be to implement CHIS to facility, but we don't know if there's a difference between syncing with a facility.
  • Who owns the routing of information?
• Push, Pull and PubSubHub architecture
  • If you push, you need to support retries and acknowledgement
  • Does OpenHIE have an opinion on this?
• Our FHIR API may need to:
  • Support providing state at each version of the resource
  • We need a way of identifying all of the version changes for each resource since a point in time
    • We don't know if this is a hard requirement.
• Our systems could
  • Add a Clinical Data Repository
  • Façade API in front of an existing API that's custom

Point to Point FHIR Interoperability

CHIS to 3P System

• Setup a regular schedule
  • CHIS identifies the last time that the data was pulled or page that was pulled

HIE Mediated FHIR Interoperability

...