Mongolian HDIT Implementation guide
1.0.0 - Review
Mongolian HDIT Implementation guide
1.0.0 - Review
Mongolian HDIT Implementation guide - Local Development build (v1.0.0). See the Directory of published versions
An implementation guide (IG) is a set of rules about how FHIR resources are used (or should be used) to solve a particular problem, with associated documentation to support and clarify the usage. Typically, FHIR implementation guides are published on the web after they are generated.
It represents a logical, coherent whole that covers a specific context to allow for validation and conformance within that context.
An implementation guide consists of three principal parts. An ImplementationGuide resource and two different types of resource references; contents and examples. The contents are logical statements to which implementation must conform to, and examples that support implementation by guiding the implementer. While the former is almost always conformance resources, the latter can be any kind of resource.
Resources are the building blocks in FHIR - each one a representation of some kind of healthcare entity. The FHIR standard provides a core set of profiles for common things like “patient”, “observation”, “an order”, and so on.
The FHIR specification describes a set of base resources that are used in many different contexts in healthcare. However, there is wide variability between jurisdictions and across the healthcare ecosystem around practices, requirements, regulations and education.
For this reason, the FHIR specification is a “platform specification” - it creates a common platform or foundation on which a variety of different solutions are implemented. As a consequence, this specification usually requires further adaptation to particular contexts of use.
To allow for such adaptation in a controlled manner, FHIR resources are meant to be customized and specialized via profiles.
A resource can conform to multiple FHIR ImplementationGuides as long as the ImplementationGuides are compatible.
By profiling (creating a profile), any FHIR resource can be modified to suit a particular use.
The profile can specify additions of data elements, or removals of existing elements, as well as changing the cardinality of elements.
It can add new, possibly complex, data structures via extensions.
It also allows for binding elements to code systems, as a way to further specialize or narrow down the specification.
More details about what profiling entails can be found under the section 3.5 Profiling Concepts.
StructureDefinitions are used to define the basic structure of FHIR; data types, resources, extensions and profiles, so every resource profile is in fact a StructureDefinition resource.
The StructureDefinition resource describes a set of data element definitions, and their associated rules of usage. These structure definitions are used to describe both the content defined in the FHIR specification itself - Resources, data types, the underlying infrastructural types, and also are used to describe how these structures are used in implementations.
StructureDefinitions are used by CapabilityStatement instances for specifying how resources are used and use ValueSets to specify content of coded elements.
The ImplementationGuide resource is the orchestrating document of an implementation guide. It serves to define metadata about the implementation guide as well as contain references to all content that is to be included.
This resource describes the behaviours / capabilities that a FHIR server supports for a particular version of FHIR. It can be used for a statement of actual server functionality or a statement of required server implementation meaning it is a key part of the FHIR conformance framework.
A CapabilityStatement resource describing actual server functionality is named “Instance” and producing it is the responsibility of the implementer of the FHIR conformat server, meaning the HIEP implementation team.
When creating or reading a profile for a resource there are three main operations that are performed; changes to cardinality, adding extensions and slicing.
Cardinality of an element can be altered within a given set of rules. In this way an element can be, for example, set to required, or excluded. The rules that apply to changes to cardinality are in place to ensure backwards compatibility with ancestral resource profiles. A resource must always be conformant to it’s given profile and all ancestral profiles. For example a mandatory element must not be changed to optional or removed by an inheriting profile and an excluded element may not be re-introduced by an inheriting profile.
Extensibility is a fundamental part of the design of the FHIR specification. Every element in a resource can have extension child elements that represent additional information that is not part of the basic definition of the resource. An extension is composed of an URL identifying the meaning of the extension and either a value or child extensions. A extension containing child extensions is referred to as a Complex extension as opposed to Simple extensions which only contain a value.
An extension comes in two variants; extensions and modifier extension. A modifier extension means that the extension significantly changes the interpretation of the resource and that. If a system receives a resource containing a modifier extension where the system does not support the modifier extension, the resource must be rejected. Non-modifier extensions that are unknown to a system should be ignored but kept intact when the resource is passed on.
A element in a StructureDefinitions that allows for multiple occurrences, e.g. list, can be split into a series of sub-lists, each with different restrictions on the elements with associated additional meaning. In this way it is possible to effectively put constraints on each element in the list. Examples of this can be seen for example in the Patient identifier where several slices have been defined representing different systems of identification such as birth registration number and passport number.
A system’s claim to conformance depends on the scope of the systems responsibilities. For an EMR system that handles all aspects of the healthcare process this means that the system must be able to produce resources following all composition profiles listed in Section 5.2.5 including any referenced profiles. It must be able to send and receive resources following workflow profiles listed in Section 5.2.4 concerned with referrals and send medication requests according to the defined profile. The system must also be able to expose any services rendered at the facility according to the healthcare service profile, respond to requests for schedules & slots and accept appointment requests.
A system that is only concerned with handling bookings on the other hand would only be required to respond to requests for schedules & slots and accept appointment requests. List of healthcare services could be supplied by the booking system, or another system instead. But it is vital that the facility does expose a list of healthcare services in one way or another.
Being compliant to a resource profile means that, for a system sending the resource, the resource validates against the profile without errors. For a receiving system compliance means that any incoming resource is validated against the specified profile and that all elements marked MUST SUPPORT in the resource profile are handled by the system.
The profiles make a distinction between elements in a resource that must be populated by the sender and elements that must be supported by the receiver. All elements with a cardinality of at least one are required data that must be populated by sender. Any element that has the MUST SUPPORT flag, must be handled by the receiver.
As development of IT within the mongolian health sector progresses additional profiles will be added to the list.
For more details on general conformance from a FHIR point of view, the conformance pages of the FHIR implementation guide are recommended reading