What do I need to think about in regards of creating a FHIR service

Introduction

FhirStarter is meant to quickly setup a FHIR service without having to think about anything else than datasources you want to use and the mapping of FHIR resources in the different FHIR services.

This means that you need to know in beforehand that you have

1. the data that you require to map a FHIR resource.
2. the knowledge of what fields in your datasource is mapped to which property in a FHIR resource.
3. You have thought out what is a valid FHIR resource according to your organization and created a mapping which can be used to validate your FHIR resources that are exposed through the FhirStarter service.

Challenges

The real challenge is mainly on the datasource bit, because any information that is remotely linked to healthcare is more than often sensitive. You can't f.ex. use real patients during testing since it'll violate privacy between a patient and his/hers/its caretaker and such information can't be used freely (however researcher are very keen on such data).

If your organization does not have any good ways of making patient data anonymous, you are most likely working in the dark since you don't have access to any data which can give you a hint of whether your mapping is correct or the service exposes the right amount of data. To put it bluntly; if you don't have any data to develop and test on, you are basically screwed and this must be your top priority before beginning development. Mockdata is a good starting point for mapping resources, but it does not give an idea of performance. We've more than often discovered indexes that were poorly maintained, databases which are not as described and so on, this is a huge timesink if it's not handled along the way instead of handling it during a huge testing phase. Tests are more than often done a monolitic scale (unfortunalty).

If you have data available, which is up to date, correct and anonymous, then you are in great shape to create FHIR services with FhirStarter.

Updates from FhirStarter and if they might break projects

We try to avoid making breaking changes in the code for each iteration of the (D)STUs, some time next year we'll have STU4. Meaning, nothing huge will happen in STU3, mainly bugfixes and more focus on making the framework more streamlined. However, things that worked in STU3, might not work in STU4. We've seen that Conformance is now called CapabilityStatement plus some resources have been dividied into several resources instead of being incorporated into each other.

We use the FhirStarter.Inferno and FhirStarter.Inferno.Template as a testing ground to make sure our changes does not break existing projects using FhirStarter. If the FhirStarter.Inferno does not work, then we can't publish new nuget packages. If the nuget packages are released and they don't work in the FhirStarter.Inferno.Template project, most likely there's some configuration missing.

We strive to have the template project as correct and complete as possible to any given time. So if an update causes you problem, you should have a look at the template project to see if you are missing any settings.

We are looking into creating a configSection or JSON setting for FhirStarter which makes it easier to spot FhirStarter settings. The question is whether it should be a loose file which is in the root of the FHIR service instead of a configSection in the web.config.