Migration data and Apps from STU2 to STU3

[jmo...@healthcentrix.com]

Hello

   I analyzing how to migrate a web and mobile app based on STU2 java reference implementation to a STU3 impl.

   We are migrating data from our FHIR/IHE_XDS server to a hosted STU3 solution.

   We are thinking to use create a microservice with hapi_converter_10_30 feature in order to migrate the data from our server to the new STU3 server.

   Now, our question is about how to migrate our current big apps because clients and microservices are using java reference STU2 java reference implementation. I guess if we use STU3 we will have a large number of changes in the app in order to compile it and works accurately.

   One potential approach is migrating modules step by step changing the FHIR clients from STU2 to STU3; the new modules will be built based on STU3, but certain old modules will be based on STU2 for a long time. In order to make this, we could modify our current FHIR STU2 clients to retrieve STU3, but convert these resources to STU2 for current modules.

   I have seen STU2 to STU3 conversion in HAPI, but I haven't seen STU3 to STU2 conversion.  do you know some approach to this?

  are there some guides, use cases, examples, on how to migrate STU2 apps to STU3 apps? bridges/converter approaches?

Thanks in advance

Regards

[James Agnew]

One thing you might want to look at is the VersionedApiConverterInterceptor. It will automatically up-convert and down-convert your responses based on an additional value in the Accept header.

This is an experimental feature, but more testing and/or suggestions for how it should work are alwaysd appreciated.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To post to this group, send email to hapi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/1bbabd87-29ab-4fee-a113-6ed4e2b69121%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Mayfield]

Can I confirm your data is stored in a ‘fhir’ database? 

It’s not on top of another data store (so you can’t run both)

Sent from my iPhone

--

[jmo...@healthcentrix.com]

Thanks James

   Really, we are going to test to migrate our app to an FHIR server hosted solution. We couldn't add this feature to the hosted solution.

   Nevertheless, we want to add User Consent Management to the hosted solution based on API-GW/UMA and an authorization plugin. We could use that interceptor in the plugin in the API-GW in order to add fine-grained authorization and conversion in the gateway.

Regards

[James Agnew]

Sorry, I don't understand what you're asking. What does "FHIR server hosted solution" refer to?

Cheers,

James

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/af189241-2245-4acf-ad37-6bd342168747%40googlegroups.com.

[jmo...@healthcentrix.com]

On Sunday, August 12, 2018 at 12:57:57 PM UTC-7, James Agnew wrote:

Sorry, I don't understand what you're asking. What does "FHIR server hosted solution" refer to?

We are going to do testing about how to migrate our APP (fhirSTU2-based) and our data in our own FHIRserver implementation to  Google Cloud Healthcare API (just FHIR-STU3 interface).

Cheers

[jmo...@healthcentrix.com]

On Sunday, August 12, 2018 at 11:50:10 AM UTC-7, Kevin Mayfield wrote:

Can I confirm your data is stored in a ‘fhir’ database? 

It’s not on top of another data store (so you can’t run both)

Hi Kevin,

   I am not sure you mean about I cannot run both. I will try to explain a bit more our use case.

 

Really we want to substitute our current main FHIR server for a new FHIR server with better performance. We will just keep our current FHIR implementation as integration with some of legacy XDS servers.

Our current FHIR server implementation is a FHIR STU2 facade to an IHE XDS repository where:

• we store all type of documents: CCDA, PDF, DICOM images, and FHIR resources
• FHIR resources are stored in 2 ways:
• FHIR XML doc in a XDS document
• FHIR resource searchParams are stored as XDS extra-metadata
• FHIR queries are mapped to XDS queries; FHIR searchParams queries are mapped to XDS extra-metadata query arguments.
  

  We are thinking in:

• data migration from our STU2 server to STU3 hosted solution. We are thinking to create a microservice which do queries to current FHIR server, convert to STU3, reference adjustments, and persistence in the new FHIR server.
• App migration: 
• New App modules will be built with HAPI/RI STU3 client
• Old modules will be migrated progressively. Meantime, we are analyzing 2 options:
• Modification of our STU2 FHIR clients. They are currently based or JAVA STU2 RI, not HAPI client. could we add client-conversion from STU3 to STU2 objects with the HAPI/RI STU3 client?
• GW interceptor plugin for our APIGW based on something to the interceptor indicated by James in above post.

                     Initially, we were thinking in the first option: modification of our own fhir client library.

     Kevin, do you mean

• if I migrate previously the clinical data I can't adapt my clients or whatever interceptor to receive STU2 from a STU3 server?
  
• or,  I cannot keep modules in my app with 2 fhir library clients (STU3 and STU2)

    ?

Cheers

[James Agnew]

Ah, got it.

Unfortunately I don't know much about how that system works so I don't know what would be feasible there.

Cheers,

James

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/1b9519a4-c4fd-4503-b501-d028d087634e%40googlegroups.com.