Multiple observation resource providers on same FHIR server

177 views
Skip to first unread message

Kevin Wang

unread,
Feb 13, 2017, 3:52:17 PM2/13/17
to HAPI FHIR
Hi there,

I am implementing a FHIR server using HAPI-FHIR lib. My use case require that multiple extended observation resources being created to support CRUD operation for several similar but not identical observation data types. I have created several extended observation types and corresponding resource providers. however, when I register these providers to the FHIR server, I got error saying that "multiple resource providers registered for same type [observation]". 

to work around this, I have a couple of ideas but need some advices as to which might be better or maybe some general comments.

approach 1: create multiple FHIR server instances with each serving one extended observation resource.
approach 2: use server extended operations to provide CRUD operation for all extended observation resources. this approach will not use the resource provider. 

any comments and advices welcomed.

Thanks,

Kevin

James Agnew

unread,
Feb 13, 2017, 5:58:01 PM2/13/17
to Kevin Wang, HAPI FHIR
Hi Kevin,

Do you have a sense of how you want the HTTP/REST interface to work?

Like, if you only intend to support search you could probably have a single resource provider that delegates to two backing implementations based on a value for the _profile search parameter.

On the other hand, if you want separate implementations of create, and read, and the other FHIR operations it might make more sense to have entirely separate endpoints.

This is the heart of the motivation for not allowing multiple RPs for a single resource type. In FHIR, when a client does a read, there is nothing in the request that would hint to the server which RP should field it. 

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+unsubscribe@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/17d3d28e-713e-4e54-817f-853d567555fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Kevin Wang

unread,
Feb 14, 2017, 9:11:36 AM2/14/17
to HAPI FHIR, kevin.wa...@gmail.com
Hi James,

Thanks for your quick reply. 

so you think it make more sense to have separate endpoints for different RPs. I am doing that and just want to get advice from other experienced people to see if there are any better ways. 

Kevin


On Monday, February 13, 2017 at 5:58:01 PM UTC-5, James Agnew wrote:
Hi Kevin,

Do you have a sense of how you want the HTTP/REST interface to work?

Like, if you only intend to support search you could probably have a single resource provider that delegates to two backing implementations based on a value for the _profile search parameter.

On the other hand, if you want separate implementations of create, and read, and the other FHIR operations it might make more sense to have entirely separate endpoints.

This is the heart of the motivation for not allowing multiple RPs for a single resource type. In FHIR, when a client does a read, there is nothing in the request that would hint to the server which RP should field it. 

Cheers,
James
On Mon, Feb 13, 2017 at 3:52 PM, Kevin Wang <kevin.wa...@gmail.com> wrote:
Hi there,

I am implementing a FHIR server using HAPI-FHIR lib. My use case require that multiple extended observation resources being created to support CRUD operation for several similar but not identical observation data types. I have created several extended observation types and corresponding resource providers. however, when I register these providers to the FHIR server, I got error saying that "multiple resource providers registered for same type [observation]". 

to work around this, I have a couple of ideas but need some advices as to which might be better or maybe some general comments.

approach 1: create multiple FHIR server instances with each serving one extended observation resource.
approach 2: use server extended operations to provide CRUD operation for all extended observation resources. this approach will not use the resource provider. 

any comments and advices welcomed.

Thanks,

Kevin

--
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.
Reply all
Reply to author
Forward
0 new messages