FHIR Chat · FHIR Implementation Stages/Levels · implementers

Stream: implementers

Topic: FHIR Implementation Stages/Levels


view this post on Zulip Muhammad Abubakar Ikram (May 14 2018 at 12:10):

Being an implementor I have felt that there is not a smooth or a step by step procedure for implementing FHIR. When a new implementor comes to the spec s/he gets horrified that from where s/he should start. One thing I want to suggest and recommend that FHIR can also have implementation stages from beginner/basic level to the expert/full-featured FHIR. So a new implementer can start from stage one and grow accordingly. Some resources can be and some resources cannot be a part of a stage. The CapabilityStatement would tell the stage of a server. So a client from outside can have a hint that how much this server is grownup.

view this post on Zulip Lloyd McKenzie (May 14 2018 at 12:36):

We're open to the notion of providing more guidance to implementers approaching the specification. The challenge is how to do that when implementers approach the specification from such a wide variety of viewpoints. We have people with CDA experience or v2 experience or no healthcare experience at all. We have people wanting to do full EHRs, wanting to do claims, wanting to do decision support, wanting to do terminology. Some are starting with FHIR documents or FHIR messaging rather than REST. So the "what do you need to look at" is pretty wide ranging and what's a logical step 1 for one implementer might be step 5 for someone else.

This is not intended to discourage development of better guidance, just identifying the reason we've struggled to do this better so far. Suggestions or concrete proposals for guidance would certainly be welcome.

view this post on Zulip Steve Munini (May 14 2018 at 12:40):

Hi Muhammad, we found that implementing the Patient FHIR Resource first covers a lot of ground. Implementing Patient will have you implement many of the CRUD operations in the FHIR REST API, it will also get you familiar with the FHIR data model including primitive and non-primitive types, as well as extensions, as well as choice types too. The search parameters in Patient also offer a good sample of what is also found in other FHIR Resources. If you attend a FHIR Connectathon, there is a Patient track that is very helpful too for testing what you have built.

view this post on Zulip Michael Donnelly (May 14 2018 at 12:48):

I recommend starting with a read on any given resource before attempting search. (This goes for clients or servers and for every resource.)

view this post on Zulip Muhammad Abubakar Ikram (May 14 2018 at 13:59):

@Lloyd McKenzie What I have understood (kindly correct me if I am wrong) at last FHIR is a server which exposes the health data in a certain format which we used to call "resources". So, what we can do that we can chop the spec according to the complexity level.

A new implementer comes and spec should redirect to the stage one and spec should ask the implementer to understand the stage one. I know somehow spec is doing this but it is not in a flowchart manner the information is scattered and implementer has to choose that where should I start.

Like @Steve Munini and @Michael Donnelly said I did the exact same thing! I went with Patient resource and I implemented the read on that. But what if it was written in the spec? it would be more acceptable and it will expedite the process of adaptation.

view this post on Zulip Lloyd McKenzie (May 14 2018 at 16:16):

Can you submit a change request? That'll get us to start the process. You can reference this chat


Last updated: Apr 12 2022 at 19:14 UTC