Overview of assemblies
The .NET FHIR API consists of six assemblies:
Hl7.Fhir.Model- This assembly contains Model classes which correspond to the FHIR Resources and data types, like Patient and Address. The assembly contains code generated by the FHIR publication tool, which is used to build a new version of the FHIR website.
Hl7.Fhir.Api- This assembly contains all the additional functionality to use FHIR, like the parsers and serializers, validators and the REST client.
Portable Class Libraries that support Windows phone 8.1, Windows Phone 8.0, Windows RT:
Native .NET 4.5 Assemblies:
These assemblies are currently distributed in the NuGet “FHIR” package for .NET 4.0, .NET 4.5 and Portable Class Libraries that support Windows Phone 8.1, 8.0 and Windows RT. This package is all you need to get started, unless you want to have the source code on GitHub.
The contents of these two assemblies are divided over several namespaces:
This namespace contains all the classes corresponding to the FHIR model types (Resources, complex datatypes, primitives). In addition there are classes for the “pseudo” datatypes in the FHIR standard:
BundleEntry(and its concrete subclasses ResourceEntry and DeletedEntry), which provide support for working with FHIR-style Atom feeds and entries.
TagList, which represents a list of Tags as returned by the REST Tag operations
ModelInfo, a class containing some relevant specification metadata, like FHIR’s version number, the list of FHIR resources and search parameter information.
Contains classes useful for both client and server developers to work with the REST aspects of the specification. The most important classes are:
FhirClient- represents a FHIR REST client and has methods to invoke a server with calls corresponding to the FHIR REST operations such as
ResourceIdentity- Helps build and parse FHIR’s REST identities (like
http://someserver.com/fhir/Patient/234) into its constituent type name, id and version id.
Contains the parsers and serializers for FHIR’s XML and Json wire-format. It’s main entry points are
FhirParser. Resources can be serialized and parsed using strings, byte-arrays and streams. In addition to supporting Resources, these classes also support serialization of Bundles (Atom feeds) and TagLists.
The FHIR API encodes FHIR’s datatype invariants and other constraints using .NET’s validation attributes. This namespace contain attributes that represent FHIR aspects like
CardinalityAttribute which validates cardinality of elements as determined in the core specification and
OidPatternAttribute which validates whether a primitive string value corresponds to the regular expression given for OID’s.
When the publish tools generates the contents of
Hl7.Fhir.Model, it adds these attributes to the generated classes according to the specification.
Additionally, this namespace contains the main entrypoint for validation,
The parsers and serializers provided in the API are configured at run-time with information about the model classes and the members of each of those classes. This means that, in addition to (or even instead of) the provided classes in
HL7.Fhir.Model, developers can provide their own model classes and use the functionality in this namespace to configure the parsers and serializers to support those classes. This is done using attributes like
FhirType (to mark a type as being relevant to the parsers and serializers) and
FhirElement (to supply additional information about how a class’ properties should be serialized and parsed).
The namespace contains classes to help build and parse the search parameters to the FHIR
_search operation. More importantly, it adds a fluent interface to the
Query resource to easily construct Query-based searches.
In the source code distribution, you’ll find two distinct solution files to build from the source:
This solution contains only the .NET 4.0 projects and only requires Microsoft Visual Studio 2012 to be able to build.
This solution contains all 6 all project files. To build this project you will need Windows 8.1 and Microsoft Visual Studio 2013 Update 2 RC to be able to build.
If you are building this solution and working on the Unit Tests, the basic tests are all in the same
#defined in/out of each project type. Ensure that you change the namespace of the tests
so that visual studio can recognise that these are different tests.