Монгол Улсын ЭМӨМТ Хэрэгжүүлэлтийн Удирдамж
1.0.0 - Хянах
Монгол Улсын ЭМӨМТ Хэрэгжүүлэлтийн Удирдамж
1.0.0 - Хянах
Монгол Улсын ЭМӨМТ Хэрэгжүүлэлтийн Удирдамж - Local Development build (v1.0.0). See the Directory of published versions
While attempts have been made to include enough information in this document for it to be read and referred to in isolation, it gains context in combination with the FHIR implementation Guide found at http://hl7.org/fhir/ A firm recommendation for any implementers is to read through the official FHIR implementation guide, especially the overview sections.
The basic building block in FHIR is the resource. All exchangeable content is defined as resources. All resources share a common way of definition and representation, and are built from data types that define common reusable set of patterns of elements. All resources share a common set of metadata and contain a human readable part.
The philosophy behind FHIR is to build a base set of resources that satisfy the majority of use cases, either by themselves or combined. The built in extension mechanism covers remaining content.
For interoperability to be achievable, backward compatibility must be assured between a resource profile and the FHIR profile that is extended.
It can be good to keep in mind that everything is a resource, both exchangeable content mentioned above, value sets, code systems and the actual resource profiles are resources that follow the StructureDefinition profile.
Even the implementation guide itself is a resource that follows the ImplementationGuide profile. The HTML-based output format is then achieved by tooling that uses the ImplementationGuide resource to produce easily accessible content.
FHIR is RESTful specification, but only supports level 2 of the REST maturity model. To achieve Level 3 conformance the use of extensions is needed.
Since FHIR itself is a standard it dictates a standardized resource structure and interfaces whih may be considered a violation of REST principles, but is necessary to ensure interoperability.
While resources can be represented in XML, JSON and Turtle according to the FHIR standard, JSON is the preferred format to use within the Mongolian systems.
While a resource is created according to a specific profile, it should be seen as an instance of it’s base resource while in transit from system to system.
A sender creates a resource following a specific profile, for example PatientMn. This resource is sent to another system. When it is being sent, it should be viewed as a instance of the Patient profile.
As the resource is received at the destination, it is validated against the required profile, in this case also PatientMn, and after validation is complete it can be viewed as an instance of the PatientMn profile again.
The takeaway here is that a resource can conform to many profiles, by intent or by coincidence, and as long as that it can be validated as the destination profile it can be exchanged between the two systems.
The implementation guide is delivered in two languages; English and Mongolian. If there are conflicts between the two, the English version of the Implementation guide has precedence.
When creating resources it is important to always use the english element names since the Mongolian translation of the element names can not be utilized in data exchange. This is represented in the Mongolian translation as well where the element names have deliberately been left in english.
A receiver of resources is expected to perform validation of the resource against the mongolian implementation guide.
Validation means checking the validity of following aspects of the resource:
The most competent validator at the time of writing is the official FHIR Validator which is a Java jar provided as part of the specification. It can be run stand alone or used as a dependency in a JVM based project