Schema Sync - Improving Interoperability in Healthcare Data

Inspiration

The current standard for exchanging healthcare data is FHIR, but health systems can be slow to adapt and often use an older version of FHIR or a predecessor to the FHIR standard such as HL7 v2 or v3. Additionally, the FHIR standard is purposefully vague in order to give flexibility to those using the standard.

As a result, consumers of healthcare data are challenged to create a standard data model that encompasses the unique data standards of different providers. Additionally, any standard data model is not static. As standards change so must the data model.

This type of problem exists in other healthcare domains, such as machine readable files of rates and contracts that providers and payers must publish and many other areas outside of healthcare. When there a significant number of data producers, true data standardization is rare, and consistently causes headaches for data consumers.

What it does

This project aims to resolve data model discrepancies by reviewing new data and adjusting a master schema to handle the new data. It's been built to only add to the new schema, not remove any fields. These should be used as suggestions as any application code will need to be ready for the schema changes. Even in only adding fields, data type changes can break application code. We prefer to solve data discrepancies upstream, at the data layer, so that application logic can be built upon one standard.

How it works

We created a FastAPI server. Our main service is an endpoint (POST /new_schema/{use_case_id) that:

• Accepts healthcare data in JSON format.
• We convert this data to a schema with the data types for each field.
• We check if this schema has already been mapped to our master schema. If it has, we return a message stating that the master schema does not require any modifications
• If the schema has not been mapped, we generate a report of the differences between the new data schema and our master schema
• We invoke Gemini to suggest a modification to the master schema and return the suggested changes to the user

Our service allows for multiple use cases, each with their own unique schema, and we've exposed endpoints to generate new use cases, view existing use cases, and view all schemas that have been mapped into a use case's master schema.

Challenges we ran into

FHIR documentation is dense and expansive we were not able to organize the data to create a RAG model that references relevant documentation before providing an answer. We also did not have access to enough sample data (or time to generate sample data) in order to fine tune our model.

Accomplishments that we're proud of

While our initial implementation is rather simple

What we learned

This was our first time working on Google Cloud, and we learned the basics of creating a database, using Google's Generative AI tools, and deploying a service.

What's next for Improving Interoperability in Healthcare Data

Future iterations will need to make more intelligent decisions in how to handle new data schemas by referencing FHIR documentation and taking in human feedback. We would also like our tool to better the "so what" - now that we have a new data model, how, if at all, would our application logic need to change to handle the updated master schema.

Built With

• fastapi
• gemeni
• google-cloud
• postgresql
• python