Section: 11

newheader.html

<meta name="viewport" content="width=device-width, initial-scale=1.0"/> <meta name="author" content="http://hl7.org/fhir"/> <!-- Bootstrap core CSS --> <!-- Project extras --> <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries --> <!--[if lt IE 9]> <![endif]--> <!-- Favicons --> <hr/><h2>newnavbar.html</h2> <div id="segment-header" class="segment"><!-- segment-header --> <div class="container"><!-- container --> <a id="logo" href="http://hl7.org/fhir" no-external="true"><img src=./assets/images/fhir-logo-www.png" alt="logo fhir"/> </a> <div id="hl7-status"> <b</b> </div> <div id="hl7-nav"> <a id="hl7-logo" href="http://www.hl7.org" no-external="true"> <img src=./assets/images/hl7-logo.png" width="42" height="50" alt="visit the hl7 website"/> </a> </div> </div> <div class="container"><!-- container --> </div></div><!-- /segment-header --> <div id="segment-navbar" class="segment"><!-- segment-navbar --> <div id="stripe"> </div> <div class="container"><!-- container --> <!-- HEADER CONTENT --> <nav class="navbar navbar-inverse"> <div class="container"> <button data-target=".navbar-inverse-collapse" data-toggle="collapse" class="navbar-toggle" type="button"> <span class="icon-bar"> </span> <span class="icon-bar"> </span> <span class="icon-bar"> </span> </button> <a href=index.html" class="navbar-brand hidden">FHIR</a> <div class="nav-collapse collapse navbar-inverse-collapse"> <ul class="nav navbar-nav"> <li><a href=./index.html">Home</a></li> <li><a href=./modules.html">Getting Started</a></li> <li><a href=./documentation.html">Documentation</a></li> <li><a href=./resourcelist.html">Resources</a></li> <li><a href=./profilelist.html">Profiles</a></li> <li><a href=./extensibility-registry.html">Extensions</a></li> <li><a href=./operationslist.html">Operations</a></li> <li><a href=./terminologies-systems.html">Terminologies</a></li> </ul> </div><!-- /.nav-collapse --> </div><!-- /.container --> </nav><!-- /.navbar --> <!-- /HEADER CONTENT --> </div><!-- /container --> </div><!-- /segment-navbar --> <div id="segment-breadcrumb" class="segment"><!-- segment-breadcrumb --> <div class="container"><!-- container --> <ul class="breadcrumb"> </ul> </div><!-- /container --> </div><!-- /segment-breadcrumb --> <div id="segment-content" class="segment"><!-- segment-content --> <div class="container"><!-- container --> <div class="row"> <div class="inner-wrapper"> <!-- CONTENT CONTENT --> <hr/><h2>ns.html</h2> <div class="col-12"> <h2>Namespaces defined by FHIR</h2> <table class="colsi"><tr><td id="wg"><a _target="blank" href="</a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: N/A</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>:<!--!ns!--><a href="versions.html#std-process">Informative</a></td></tr></table> </div> <hr/><h2>op-example-request.html</h2> <div class="col-12"> <a name="SOA"></a> <a name="soa"></a> <h2>Operation Request Example</h2> <table class="colsi"><tr><td id="wg"><a _target="blank" href="</a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: N/A</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>:<!--!ns!--><a href="versions.html#std-process">Informative</a></td></tr></table> <pre> POST [base]/ValueSet/$expand HTTP/1.1 Content-Type: application/fhir+xml <!-- This is an example of an operation request for a value set expansion where the value set is submitted on the fly --> <Parameters xmlns="http://hl7.org/fhir"> <parameter> <name value="filter"/> <valueString name="abdo"/> </parameter> <parameter> <name value="valueset"/> <resource> <ValueSet> <text> <status value="generated"/> <div xmlns="http://www.w3.org/1999/xhtml"><!-- Snipped for brevity --></div> </text> <identifier value="http://hl7.org/fhir/ValueSet/body-site"/> <name value="SNOMED CT Body Structures"/> <publisher value="FHIR Project team"/> <telecom> <system value="url"/> <value value="http://hl7.org/fhir"/> </telecom> <description value="This value set includes all the &quot;Clinical finding&quot; SNOMED CT codes (i.e. codes with an is-a relationship with 91723000: Anatomical structure)"/> <status value="draft"/> <compose> <include><!-- all the descendants of clinical finding, not include itself --> <system value="http://snomed.info/sct"/> <filter><!-- todo: work this over. what this means is any concepts where they have is-a with 91723000. how should this be done? --> <property value="concept"/> <op value="is-a"/> <value value="91723000"/> </filter> </include> </compose> </ValueSet> </resource> </parameter> </Parameters> </pre> </div> <hr/><h2>operations.html</h2> <div class="col-12"> <a name="base"></a> <h2>Extended Operations on the RESTful API</h2> <table class="colsn"><tr><td id="wg"><a _target="blank" href="</a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: Normative</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>:<!--!ns!--><a href="versions.html#std-process">Normative</a></td></tr></table> <p> The <a href="http.html">RESTful API</a> defines a set of common interactions (read, update, search, etc.) performed on a repository of typed resources. These interactions follow the RESTful paradigm of managing state by <b>C</b>reate/<b>R</b>ead/<b>U</b>pdate/<b>D</b>elete actions on a set of identified resources. While this approach solves many use cases, there is some functionality that can be met more efficiently using an RPC-like paradigm, where named operations are performed with inputs and outputs (<b>E</b>xecute). </p> <p> Operations are appropriately used where: </p> <ul> <li>the server needs to play an active role in formulating the content of the response, not merely return existing information</li> <li>the intended purpose is to cause side effects such as the modification of existing resources or creation of new resources, or other changes out of scope of the RESTful interface (e.g. merging patient records)</li> <li>The task involves business rules to be enforced across multiple different resources and/or</li> <li>the task involves updating several resources in a coordinated manner (note: this can also be done by a <a href="http.html#transaction">Transaction</a>, but an operation can be more focused on the task</li> </ul> <p> This specification describes a lightweight operation framework that seamlessly extends the RESTful API. The framework covers both how to execute such an operation (this page) and how to <a href="operationdefinition.html">define an operation</a>. </p> <p> Operations have the following general properties: </p> <ul> <li>Each operation has a name</li> <li>Each operation has a list of 'in' and 'out' parameters</li> <li>Parameters are either resources, data types, or search parameters</li> <li>Operations are subject to the same security constraints and requirements as the RESTful API</li> <li>The URIs for the operation end-points are based on the existing RESTful API address scheme</li> <li>Operations may make use of all types of resources existing in the repository</li> <li>Operations may be performed on a specific resource, a resource type, or a whole system</li> </ul> <a name="executing"></a> <h3>Executing an Operation</h3> <p> Operations are executed using a URL derived from the FHIR endpoint, where the name of the operation is prefixed by a "dollar sign" ('$') character. For example: </p> <pre> POST http://fhir.someserver.org/fhir/Patient/1/$everything </pre> <p> When an operation has affectsState = false, and the parameters are all primitive data types with no extensions (as is the case with the example above), it may be invoked using GET as well. (Note: A HEAD request can also be used - see <a href="http.html#head">Support for HEAD</a>). </p> <p> Operations can be invoked on four types of FHIR endpoints: </p> <ul> <li>The "base" FHIR service endpoint (e.g. http://fhir.someserver.org/fhir): These are operations that operate on the full scale of the server. For example, "return me all extensions known by this server"</li> <li>A Resource type (e.g. http://fhir.someserver.org/fhir/Patient): These are operations that operate across all instances of a given resource type</li> <li>A Resource instance (e.g. http://fhir.someserver.org/fhir/Patient/1): These are operations that involve only a single instance of a Resource, like the $everything operation above does</li> <!-- see task GF# <li>A specific version of a resource instance (http://fhir.someserver.org/fhir/Patient/1/_history/4): These operations involve only a specific version of a single instance of a FHIR Resource and exists only to allow manipulation of profile and tag metadata of past versions</li> --> </ul> <p> The body of the invocation contains a special infrastructure resource called <a href="parameters.html">Parameters</a>, which represents a collection of named parameters as <key,value> pairs, where the value may be any primitive or complex datatype or even a full Resource. It may also include strings formatted as search parameter types. </p> <p> Upon completion, the operation returns another <code>Parameters</code> resource, containing one or more output parameters. This means that a FHIR operation can take a set of zero or more parameters <i>in</i> and return a set of zero or more result parameters <i>out</i>. Both the body of the POST and the returned result are always a Resource. </p> <p> Operations may be invoked using a <code>GET</code>, with parameters as HTTP URL parameters, if: </p> <ol> <li>there are only simple input parameters - i.e. no complex datatypes like 'Identifier' or 'Reference', and</li> <li>and the operation does not <a href="operationdefinition-definitions.html#OperationDefinition.affectsState">affect the state of the server</a></li> </ol> <p> If there is a single output parameter named 'return' then the response MAY be the resource that is the return value, with no Parameters resource. These kinds of usage are discussed further below. </p> <p> If the response is a <a href="bundle.html">Bundle</a>, the correct <a href="bundle-definitions.html#Bundle.type">Bundle.type</a> is '<a href="codesystem-bundle-type.html#bundle-type-collection">collection</a>', unless it has <a href="http.html#search">search semantics</a>, such as matching resource counts, and <a href="http.html#paging">page links (next etc)</a>. </p> <a name="executing"></a> <h4>Operations with no parameters</h4> <p> Executing operations without any parameters is a special case. For an operation that doesn't cause any state change, the operation is invoked in a straight forward fashion: </p> <pre class="http"> GET [base]/Composition/example/$document </pre> <p> For operations that call state changes, they must be invoked by a POST. There is no parameters resource in this case because a parameters resource cannot be empty. So the operation is invoked with a POST with an empty body: </p> <pre class="http"> POST [base]/Claim/example/$submit Content-Length: 0 </pre> <a name="defined"></a> <h3>FHIR defined Operations</h3> <p> See <a href="operationslist.html">the list of defined operations</a>. </p> <a name="extensibility"></a> <h3>Implementation Defined Operations</h3> <p> Implementations are able to define their own operations in addition to those defined here. Name clashes between operations defined by different implementers can be resolved by the use of the server's <a href="capabilitystatement.html">Capability Statement</a>. </p> <p> Also, the definition of these or additional run time operations does not prevent the use of other kinds of operations that are not dependent on and/or not integrated with the RESTful API, provided that their addressing scheme does not clash with the scheme defined here. </p> <a name="defining"></a> <h3>Defining an Operation</h3> <p> Each Operation is defined by: </p> <ul> <li>A context for the Operation - <i>system</i>, <i>resource type</i>, or <i>resource instance</i></li> <li>A name for the Operation</li> <li>A list of parameters along with their definitions</li> </ul> <p> For each parameter, the following information is needed: </p> <ul> <li>Name - the name of the parameter. For implementer convenience, the name should be a valid token in common implementation languages</li> <li>Use - In | Out | Both</li> <li>Type - a data type or a Resource type</li> <li>Search Type - for string search parameters, what kind of search parameter they are (and what kind of modifiers they have)</li> <li>Profile - a <a href="structuredefinition.html">StructureDefinition</a> that describes additional restrictions about the parameter - only used if the parameter type is a resource or data type</li> <li>Documentation - a description of the parameter's use</li> <li>(Optional) Search Type - if the type is a string, and the parameter is being used like a search parameter, which kind of search type applies</li> </ul> <p> Parameters may be nested into multi-part parameters. Each part has the same information as a parameter, except for use, which is taken from the parameter it is part of. </p> <p> The resource <a href="operationdefinition.html">Operation Definition</a> is used to provide a computable definition of the Operation. </p> <a name="extending"></a> <h3>Extending an Operation</h3> <p> Implementations are able to extend an operation by defining new named parameters. Implementations can publish their own extended definitions using the <a href="operationdefinition.html">Operation Definition</a> resource, and this variant definition can use OperationDefinition.base to refer to the underlying definition. </p> <p> Note that the FHIR specification will never define any parameter names starting with "x-". </p> <a name="executing"></a> <a name="synchronous"></a> <h3>Executing an Operation Synchronously</h3> <p> Operations are typically executed synchronously: a client sends a request to a server that includes the operation's <i>in</i> parameters and the server replies with the operation's <i>out</i> parameters. </p> <p> The URL for an operation end-point depends on its context: </p> <ul> <li>system: the URL is [base]/$[name]</li> <li>resource type: the URL is [base]/[type]/$[name]</li> <li>resource instance: the URL is [base]/[type]/[id]/$[name]</li> </ul> <a name="request"></a> <h4>Operation Request</h4> <p> An operation is generally invoked by performing an HTTP POST to the operation's end-point. The submitted content is the special <a href="parameters.html">Parameters</a> format (the "in" parameters) - a list of named parameters. For an example, see <a href="op-example-request.html">the value set expansion request example</a>. Note that when parameters have a search type, the search modifiers are available and are used on the parameter name in the Parameters resource (e.g. "code:in"). </p> <p> Note that the same arrangement as for the RESTful interface applies with respect to <a href="http.html#mime-type">content types</a>. </p> <p> If all the parameters for the operation are <a href="datatypes.html#primitive">primitive types</a> and the operation has <a href="operationdefinition-definitions.html#OperationDefinition.affectsState"><code>affectsState</code></a> = false, the operation may be invoked by performing an HTTP GET operation where all of the values of the parameters are appended to the URL in the search portion of the URL (e.g. after the '?' character). Servers SHALL support this method of invocation. E.g. </p> <pre> GET [base]/ValueSet/$expand?url=http://hl7.org/fhir/ValueSet/body-site&filter=abdo </pre> <p> When using the HTTP GET operation, if there is a repeating parameter for the extended operation the values for that parameter are repeated by repeating the named parameter. E.g. Observation $stats statistic parameter </p> <pre> GET [base]/Observation/$stats?subject=Patient/123&code=55284-4&system=http://loinc.org&duration=1&statistic=average&statistic=min&statistic=max&statistic=count </pre> <p> If, when invoking the operation, there is exactly one input parameter of type Resource (irrespective of whether other possible parameters are defined), that the operation can also be executed by a POST with that resource as the body of the request (and no parameters on the url). </p> <p> Servers MAY choose to support submission of the parameters represented in <a href="https://www.ietf.org/rfc/rfc2388.txt">multi-part/form-data</a> format as well, which can be useful when testing an operation using HTML forms. </p> <a name="response"></a> <h4>Operation Response</h4> <p> If an operation succeeds, an HTTP Status success code is returned. This will usually be a 2xx code, though it may also be a 303 See Other. Other kinds of 3xx codes should be understood to indicate that the operation did not proceed, and the client will need to re-issue the operation if it can perform the redirection (e.g. may get redirected to an authentication step). User agents should note that servers may issue redirects, etc. to authenticate the client in response to an operation request. An HTTP status code of 4xx or 5xx indicates an error, and an <a href="operationoutcome.html">OperationOutcome</a> SHOULD be returned with details. </p> <p> In general, an operation response uses the same <a href="parameters.html">Parameters</a> format whether there is only one or there are multiple named <i>out</i> parameters. </p> <p> If there is only one <i>out</i> parameter, which is a Resource with the parameter name "return" then the parameter format is not used, and the response is simply the resource itself. </p> <p> The result of an operation is subject to <a href="http.html#mime-type">content negotiation like any other interaction</a>. Specifically, if the returned resource is a Binary, the response SHALL behave in the same manner as if a 'read' operation had been performed on the resource. I.e. The content will be returned as either a FHIR resourse with base64-encoded content or as a raw binary, depending on the Accept header specified when invoking the operation (see <a href="binary.html#rest">Serving Binary Resources using the RESTful API </a>). </p> <p> The resources that are returned by the operation may be retained and made available in the resource repository on the operation server. In that case, the server will provide the identity of the resource in the returned resources. When resources that are not persisted are returned in the response, they will have no <code>id</code> property. </p> <a name="asynchronous"></a> <h3>Executing an Operation Asynchronously</h3> <p> Use the <a href="async.html">standard RESTful API Asynchronous pattern</a> to execute operations asynchronously. </p> </div> <hr/><h2>operationslist.html</h2> <div class="col-12"> <a name="base"></a> <h2>Defined RESTful API Operations</h2> <table class="colsi"><tbody><tr><td id="wg"><a href="http://www.hl7.org/Special/committees/fiwg/index.cfm" _target="blank">FHIR Infrastructure </a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: N/A</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>: <!-- !ns! --><a href="versions.html#std-process">Informative</a></td></tr></tbody></table> <p> The <a href="http.html">RESTful API</a> defines a set of common interactions (read, update, search, etc.) performed on a repository of typed resources. For further information concerning how operations are defined and invoked, see <a href="operations.html">Extended Operations on the RESTful API</a>. </p> <p> This is a full list of the operations defined by this specification: </p> <p> Notes: </p> <ul> <li>The special operations on the <code>meta</code> element also operate on previous versions of a resource (/_history/). They are the only operations that can manipulate versions other than the "current" version.</li> <li>Implementation Guides can define additional operations</li> </ul> <h3>Services Defined by the FHIR specification</h3> <p> This specification defines a set of services, which are business level aggregations of <a href="resourcelist.html">Resources</a> and Operations that provide a defined package of functionality that correspond to an identified business need. </p> <p> Note that in addition to the services defined in this specification, many <a href="http://fhir.org/implementation_guides">implementation guides</a> define business level services. </p> <p> This table lists the services currently defined: </p> <table class="grid"> <tr> <td><b>Name</b></td> <td><b>Description</b></td> <td><b>Links</b></td> </tr> <tr> <td><a href="terminology-service.html">Terminology Service</a></td> <td><p>A service that lets healthcare applications make use of codes, code systems, and value sets without having to become experts in the fine details of the code system, value set and concept map resources, and the underlying code systems and terminological principles. The service provides the following functionality: </p> <ul> <li>Defining and managing code systems, value sets, and concept maps</li> <li>Code lookup & Validation</li> <li>Value Set Expansion (including for UI data entry support)</li> <li>Value Set Validation</li> <li>Translations between code systems</li> <li>Subsumption testing and other logical analyses</li> <li>Maintaining a closure table</li> </ul> </td> <td><a href="capabilitystatement-terminology-server.html">Capability statement</a><br/><a href="terminology-module.html">module</a></td> </tr> <tr> <td>Conformance Service</td> <td><p>A service that provides the underlying services needed to test whether resources conform to the rules defined by the FHIR specification and applicable implementation guides, and to help author implementation guides. The service provides the following functionality: </p> <ul> <li>Defining and managing structure definitions, data elements, Capability statements, search parameters, and operation & compartment definitions</li> <li>Resource Validation</li> <li>Comparing and subsetting Capability statements</li> </ul> </td> <td>To be developed</td> </tr> <tr> <td>Knowledge Repository</td> <td><p>A service that provides basic retrieval and maintenance functionality for clinical knowledge artifacts. The service provides the following functionality:</p> <ul> <li>Defining and managing plan and activity definitions (e.g. order sets, protocols, decision support rules, documentation templates, etc.), libraries, and measures</li> <li>Search and retrieval of knowledge artifacts</li> <li>Data requirements analysis of knowledge artifacts</li> </ul> </td> <td><a href="capabilitystatement-knowledge-repository.html">Capability statement</a><br/><a href="clinicalreasoning-module.html">module</a></td> </tr> <tr> <td>Measure Processor</td> <td><p>A service that provides measure evaluation functionality. The service provides the following functionality:</p> <ul> <li>Searching and retrieval of measure definitions</li> <li>Evaluation of measures for patients and populations</li> <li>Data requirements analysis of measure definitions</li> </ul> </td> <td><a href="capabilitystatement-measure-processor.html">Capability statement</a><br/><a href="clinicalreasoning-module.html">module</a></td> </tr> </table> <p> Possible candidate Business Services for future versions: </p> <ul> <li>Conversion Service (using mapping language, and also iso-semantic transforms in a resource)</li> <li>Questionnaire related functionality (though see SDC)</li> <li>Patient Registration & Reconciliation service (per IXS)</li> <li>Medication Management service (home specific variant?)</li> <li>Clinical Data Repository</li> <li>Clinical Task Manager</li> <li>Communications Manager</li> <li>...?</li> </ul> <p> Note that there is already past & current work on some of these in HL7 (though not necessarily FHIR specific). </p> </div> <hr/><h2>overview-arch.html</h2> <div class="col-12"> <h2>FHIR Overview - Architects</h2> <table class="colsi"><tr><td id="wg"><a _target="blank" href="</a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: N/A</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>:<!--!ns!--><a href="versions.html#std-process">Informative</a></td></tr></table> <p> At its core, FHIR contains two primary components: </p> <ol> <li>Resources - a collection of information models that define the data elements, constraints and relationships for the “business objects” most relevant to healthcare. From a model-driven architecture perspective, FHIR resources are notionally equivalent to a physical model implemented in XML or JSON. See <a href="resource.html">the formal definition</a>.</li> <li>APIs – a collection of well-defined interfaces for interoperating between two applications. Although not required, the FHIR specification targets RESTful interfaces for API implementation. See <a href="http.html">details on FHIR RESTful interfaces</a>.</li> </ol> <p> In the healthcare domain, the set of “business objects” is not universally defined, but there is a notional and ongoing evolutionary, consensus-based process for standardizing on a core set of common business objects including things like “a patient”, “a procedure”, “an observation”, “an order”, etc. (see <a href="resourcelist.html">a list of defined resources</a>). The FHIR specification provides a framework for defining these healthcare business objects (“resources”), for relating them together in a compositional manner, for implementing them in a computable form, and for sharing them across well-defined interfaces. The framework contains a verifiable and testable syntax, a set of rules and constraints, methods and interface signatures for “FHIR-aware” APIs, and specifications for the implementation of a server capable of requesting and delivering FHIR business objects. </p> <p> From an operational perspective, HL7’s internal standards development and governance processes determine what constitutes a resource and which resources exist. In addition, the FHIR specification also provides a mechanism for contextualizing resources for specific needs within specific bounds (see <a href="profiling.html">Profiling Resources</a>). </p> <a name="frameworks"></a> <h3>Architecture Frameworks and FHIR Alignment</h3> <p> FHIR resources fit firmly within the information architecture domain and the FHIR APIs for data exchange address aspects of application architecture. </p> <table class="none"> <tr> <td> <p> From a <a href="http://www.opengroup.org/subjectareas/enterprise/togaf">TOGAF perspective</a>, FHIR addresses aspects of architecture views related to information model definition and data exchange, which are described in the Information Systems Architectures portion of the TOGAF Architecture Development Method. </p> </td> <td> <p> <img src="togaf.png" width="235" height="300"/> </p> </td> </tr> <tr> <td> <p> With regards to the <a href="https://www.zachman.com">Zachman Framework</a>, FHIR fits within the What and the How dimensions of the Architect, Engineer and Technician Perspectives </p> </td> <td> <p> <img src="zachman.png" width="392" height="376"/> </p> </td> </tr> <tr> <td> <p> When considering the <a href="http://www.hl7.org/implement/standards/product_brief.cfm?product_id=3">HL7 Services Aware Interoperability Framework (SAIF)</a>, FHIR resources and RESTful APIs represent the “Physical Models” and “Interface Implementations” within the Platform Specific Specifications layer of the Information Models and the Behavioral Models Viewpoints, respectively. </p> </td> <td> <p> <img src="saif.png" width="461" height="202"/> </p> </td> </tr> </table> <a name="principles"></a> <h3>FHIR and Architectural Principles</h3> <p> FHIR’s primary purpose is to address interoperability with well-structured, expressive data models and simple, efficient data exchange mechanisms. In addition, FHIR aligns to the following architectural principles: </p> <ol> <li> Reuse and Composability – FHIR resources are designed with the 80/20 rule in mind – focus on the 20% of requirements that satisfy 80% of the interoperability needs. To this end, resources are designed to meet the general or common data requirements of many use cases to avoid the proliferation of numerous, overlapping and redundant resources. Extension and customizations exist (see <a href="profiling.html">FHIR Profiles</a>) to allow common, somewhat generic resources to be adopted and adapted as needed for specific use case requirements. In addition, FHIR resources are highly composable in that resources commonly refer to other resources. This further promotes reuse and allows for complex structures to be built from more atomic resources. </li> <li> Scalability – Aligning FHIR APIs to the REST architectural style ensure that all transactions are stateless which reduces memory usage, eliminates the needs for “sticky” sessions within a server farm and therefore supports horizontal scalability. </li> <li> Performance – FHIR resources are lean and suitable for exchange across the network. Highly optimized formats are available, which has the potential to improve performance in complex transactions across multiple systems connected via a shared and finite network, though most implementers find the standard JSON / XML formats adequate. </li> <li> Usability – FHIR resources are understood by technical experts and non-technical people alike. Even if the details of XML or JSON syntax are not understood, non-technical people can view these in any browser or text reader and understand the contents within them. </li> <li> Data Fidelity – FHIR is strongly typed and has mechanisms built in for clinical terminology linkage and validation. In addition, XML and JSON documents can be validated syntactically as well as against a defined set of business rules. This promotes high data fidelity and goes a long way towards using FHIR to achieve semantic interoperability. </li> <li> Implementability – One of the driving forces for FHIR is the need to create a standard with high adoption across disparate developer communities. FHIR is easily understood and readily implemented using industry standards and common mark-up and data exchange technologies. </li> </ol> <p> There are additional architecture principles related to consistency, granularity, referential integrity, and others that are not as well established or proven. See the section below on Outstanding Issues for details. </p> <a name="decomposition"></a> <h3>FHIR Decomposition</h3> <p> As discussed, FHIR’s principal components are resources and RESTful APIs. However, there is more to the FHIR specification including the components depicted below. </p> <blockquote> <p> NOTE: The term “component” is used loosely to mean a part of something and does not intend to carry the specific meanings for this term provided by rigorous ontologies, modeling frameworks, or other architectural and organizational constructs. Diagrammatically, the components below are depicted below as UML classes. This is done purely to take advantage of the semantics afforded using this notation. FHIR is neither objected oriented in its modeling approach nor are the components that make up the FHIR specification UML classes or objects in the formal sense. Likewise, the UML packages shown below are notional and used for organizational purposes only. </p> </blockquote> <p> As shown in the diagram below, it is convenient to think of the FHIR specification as having components that address the following: </p> <ul> <li> Information Model – the components of FHIR related to the creation of FHIR resources </li> <li> Constraints – the components of FHIR addressing constraints and validity </li> <li> Terminology – the components of FHIR related to clinical terminologies and ontologies </li> <li> Usage – the component of FHIR addressing the use of FHIR in a run-time capacity </li> </ul> <p> <img src="layout.png" width="600" height="460" style="float: none"/> </p> <p> Component definitions: </p> <ul> <li>FHIR Information Model <ul> <li>Base Classes: <a href="element.html">Element</a> and <a href="resource.html">Resource</a></li> <li>Definitions for Base Classes: <a href="elementdefinition.html">ElementDefinition</a> and <a href="structuredefinition.html">StructureDefinition</a></li> <li><a href="datatypes.html">Data Types</a></li> </ul> </li> <li>FHIR Conformance Model <ul> <li><a href="capabilitystatement.html">Capability Statement</a></li> <li><a href="profiling.html">Profile</a></li> </ul> </li> <li>FHIR Terminology <ul> <li><a href="codesystem.html">Code System</a></li> <li><a href="valueset.html">Value Set</a></li> </ul> </li> <li>FHIR Usage <ul> <li><a href="http.html">REST API</a></li> </ul> </li> </ul> <a name="creating"></a> <h3>Creating Resources – Architectural Considerations</h3> <p> The following list provides general guidelines that apply when FHIR resources are defined. Most of these items are not enforced programmatically requiring human due diligence and governance to ensure adherence. </p> <ul> <li>Resources should have a clear boundary; one that matches one or more logical transaction scopes</li> <li>Resources should differ from each other in meaning, not just in usage (e.g., each different way to use a lab report should not result in a different resource)</li> <li>Resources need to have a natural identity</li> <li>Most resources should be very common and used in many different business transactions</li> <li>Resources should not be specific or detailed enough to preclude support for a wide range of business transactions</li> <li>Resources should be mutually exclusive [this is a very important consideration that helps to reduce redundancy and ambiguity]</li> <li>Resources should use other resources, but they should be more than just compositions of other resources; each resource should introduce novel content</li> <li>Resources should be organized into a logical framework based on the commonality of the resource and what it links to (see resource framework below)</li> <li>Resources should be large enough to provide meaningful context; resources that contain only a few attributes are likely too small to provide meaningful business value</li> <li>Resources should reflect general usage: <ul> <li>if most systems treat something as a single concept, that suggests a single resource; if most systems treat something as distinct concepts, then that suggests multiple resources</li> <li>if two different uses of a "resource" would result in wildly different interpretations of what constitutes "core" then that suggests two resources might be appropriate.</li> </ul> </li> <li>There is a bias towards fewer resources rather than more</li> </ul> <a name="organizing"></a> <h3>Organizing FHIR Resources</h3> <p> It is impractical to model the entirety of health data in a single information model. Every modeling initiative in healthcare from HL7 version 2 message specifications to FHIR resources decomposes the healthcare domain into smaller, more manageable sub-domains or information model snippets. With FHIR, each resource is essentially a snippet of the larger healthcare information domain. </p> <p> When breaking down the healthcare information model into smaller chunks (or resources for FHIR), it is important to have a framework and set of guidelines to promote consistency and integrity within the resource structures and in the way resources reference each other. The framework shown below includes health information model sub-categories organized into layers based on their degree of commonness. The layers and categories are useful for identifying which parts of healthcare information are the most common and therefore need to be the most consistently defined and tightly governed. The categories at the top layers are the most common and contain the FHIR resources that support the largest number of common healthcare transactions. </p> <p> Descriptions of the layers in the framework: </p> <ol> <li><b>Foundation Resources</b>: Foundation resources are the most rudimentary, foundational resources. They are often used for infrastructural tasks. Although not prohibited, they are not always referenced by other resources.</li> <li><b>Base Resources</b>: Layer two consists of base resources. These are often the leaf nodes of a resource graph. In other words, they are often referenced by other resources, but don't typically reference other resources themselves. These resources are typically the most commonly used, and therefore require the highest degree of consistency and architectural rigor. Governance is greatest for resources in layers one and two.</li> <li><b>Clinical Resources</b>: Layer 3 includes the resources that are clinical in nature but are also very common across many use cases. This includes resources for clinical observations, clinical treatment, care provision, and medications. These resources can be used by themselves, but typically build on the resources in layer two. For example, an observation resource will reference the patient resource from layer two. These resources are also frequently contextualized when they are referenced by resources in layers three, four and five.</li> <li><b>Financial Resources</b>: Layer four is dedicated to financial resources. Logically, financial resources build on clinical and base resources. For example, a billing resource will reference clinical events and activities as well as base resources like a patient.</li> <li><b>Specialized Resources</b>: In layer five, we find more specialized resources for less common use cases. These resources almost always reference resources in lower layers. Given that FHIR places priority on satisfying the most common use cases, there are fewer resources in this layer.</li> <li><b>Resource Contextualization</b>: Layer 6 does not contain resources. However, it does extend the composition framework made up by the first five layers of resources. Layer 6 includes profiles and graphs. Profiles are used to extend, constrain, or otherwise contextualize resources for a given purpose. Graphs are compositions of resources, or webs of resource, that contain attributes of their own.</li> </ol> <p> <img src="framework-2.png" style="float: none"/> </p> <p> The complete set of FHIR resources organized against this framework is found on the <a href="resourcelist.html">Resources page</a>. </p> <p> The framework serves three primary purposes: </p> <ol> <li>Organize resource for navigation and identification</li> <li>Classify resources into categories based on common sense groupings or patterns describing expected structures and/or behaviors amongst resources in the same category</li> <li>Disseminate resources across layers to stratify relative common-ness with the most common resources in the top layers</li> </ol> <p> Purposes 2 and 3 set the foundation for future architectural rigor and resource governance to optimize consistency, integrity and predictability of new or refined resources in the future. The actual rules and patterns will be defined and refined in future FHIR releases. However, one general guideline to state now is that resources generally reference resources in the same layer or higher. In other words, a layer 4 resource will typically only reference resources in layers 4, 3, 2 or 1. There is nothing prohibiting a layer 4 resource from referencing a layer 5 resource, but this is not as common. Given this guideline, it is possible to identify the resources that are likely to be most common across use cases and therefore demand the highest degree of consistency and governance. Further, the framework helps identify the areas where creating new FHIR resources is the highest priority. It is generally a higher priority to create FHIR resources in the higher layers (layers 1, 2 and 3) than it is to create FHIR resources in the lower layers (layers 4 and 5) because the higher layer resources will provide the greatest value across the largest number of use cases and stakeholders. This is not to say that the business transactions needed for the higher layers are not important, it’s just that they are not as common across the whole healthcare space. </p> <p> The 6th layer of the framework are not actually resources. Profiles and Graphs are extensions of resources or resource compositions that continue the progression through the FHIR Composition Framework. They provide additional contextualization required to satisfy certain use cases. </p> <p> There are several benefits expected from aligning the creation of FHIR resources to this framework, including: </p> <ul> <li>Organization and manageability of health domains - the framework provides a basis for decomposition and modularity</li> <li>Identifying commonality - the framework teases out the common areas from the less common areas</li> <li>FHIR resources prioritization - the framework provides a structure for determining priorities and delegating work</li> <li>Tiered governance levels - the framework separates the areas needing the most stringent and universal governance from those that require more context-specific governance</li> </ul> <p> The framework is further elaborated in the <a href="https://confluence.hl7.org/display/FHIR/Resource+Considerations">FHIR Resource Considerations page</a>. </p> <p> Another useful tool for visualizing how FHIR resources are organized relative to each other can be found using the Resource Reference Visualization tool on <a href="https://fhirblog.com/2016/06/14/resource-reference-visualization-in-clinfhir/">clinFHIR</a>. </p> <a name="implementations"></a> <h3>FHIR Implementation – High-Level Design Considerations</h3> <a name="APIs"></a> <h4>FHIR Servers and the FHIR APIs</h4> <p> A FHIR REST server is any software that implements the FHIR APIs and uses FHIR resources to exchange data. The diagram below describes the FHIR interface definitions. The methods are classified as: </p> <ul> <li> iServeInstance – methods that perform Get, Put or Delete operations on a resource </li> <li> iServeType – methods that get type information or metadata about resources </li> <li> iServeSystem – methods that expose or enable system behaviors. </li> </ul> <p> Additional details on the FHIR APIs can be found at <a href="http.html">the FHIR RESTful API</a> and the <a href="operations.html">Operations Framework</a>. </p> <p> <img src="arch-uml1.png" width="600" height="332" style="float: none"/> </p> <a name="transactions"></a> <h4>FHIR Transactions</h4> <p> As mentioned, FHIR resources are optimized for stateless transactions with RESTful APIs. Although this is not the only way FHIR resources can be used, these types of transactions are the only ones with defined interfaces and behaviors in the FHIR specification. </p> <p> FHIR transactions follow a simple request and response transaction pattern. The request and response can be for a single payload or can operate as batch. The payload or a request and response consist of a header and the content of interest. See diagram below for details. </p> <p> <img src="arch-uml2.png" width="600" height="502" style="float: none"/> </p> <a name="security"></a> <h4>Security</h4> <p> <i>(section to be filled out)</i> (but see <a href="security.html">Security</a> in the meantime). </p> <p> Example Use Cases Using FHIR </p> <p> For illustrative purposes, the following diagram depicts a simple use case of a patient accessing their personal health record (portal) enabled by an underlying electronic medical record (EMR) system. The EMR plays the role of the FHIR server in this example. </p> <p> The pre-conditions for this use case are: </p> <ul> <li> the EMR implements the necessary FHIR APIs </li> <li> the EMR implements the necessary authentication and authorization mechanisms </li> <li> the patient is successfully authenticated and authorized to access FHIR resources </li> </ul> <p> The basic flow of the use case is that the patient registers (if required), logs in, enters search criteria to identify a patient or patients of interest (the patient is most like themselves in this use case), retrieves clinical documents for the patient and retrieves clinical resources for the patient. The use cases utilize the GET methods on the iServeInstance interface and works with the following types of FHIR resources: </p> <ul> <li> The Patient resource </li> <li> One or more document resource(s) </li> <li> One or more clinical resource(s) </li> </ul> <p> <img src="arch-uml3.png" width="600" height="426" style="float: none"/> </p> <p> Although this example use case is very simple, more complex transactions using a combination of GETs, PUTs and DELETEs against resources and metadata can be envisioned. However, the exact details of these use cases including which methods are used, the orchestration of methods and the specific resources involved are outside the scope of the FHIR specification. </p> <a name="issues"></a> <h3>Outstanding Issues</h3> <ul> <li> <b>Resource Consistency and Granularity</b> – there is nothing intrinsically prohibiting one resource from duplicating the same information as another resource. Further, there is nothing prohibiting resources with the same information from defining and modeling the data elements differently. HL7 has a number of processes to ensure that resources are consistently designed, but the question is when to be consistent within the specification, and when to be consistent with the real world practices of healthcare - these are sometimes in conflict with each other. Resource granularity is a related potential problem as there are variations in the size, complexity and comprehensiveness of the existing resources. <br/> <br/> Further, the degree to which the FHIR specification can impose consistency is limited to how much agreement can be gained across various communities. While the <a href="safety.html">Implementers Safety Check List</a> and the Considerations for <a href="https://confluence.hl7.org/display/FHIR/Resource+Considerations">FHIR Resource Considerations</a> provide guidance and promote consistency, rules for achieving complete consistency of both content and granularity amongst resources are neither completely defined nor completely enforced. Considering that FHIR is still a new and emerging standard, an over-abundance of constraint and rigor has been avoided to maximize initial adoption. Further, there is a natural tension between consistency and an architectural virtue and the practicalities of supporting the real practice of health care. Considering that FHIR ultimately is a reflection of the health business processes it supports, FHIR will always carry forward some of the data discrepancies, inconsistencies and gaps that are present in the practice of healthcare across different organizations and practitioners. Nonetheless, the issues of resource consistency and granularity is a topic that gets considerable ongoing discussion, and may change as FHIR approaches a final normative standard and as FHIR adoption approaches a level where more control is warranted, or more information/process consistency emerges in the existing healthcare systems. </li> <li> <b>Resource References</b> – there are currently a lack of strict rules for what resources should be referenced by other resources and under what circumstance. There is potential for ambiguity, duplication, inaccurate and/or conflicting information communicated by a resource graph (a collection of linked resources). Imagine the scenario where Resource Type A (e.g., procedure) references Resource Type B (e.g., encounter) and Resource Type C (e.g., patient), and Resource Type B (e.g., encounter) also references Resource Type C (e.g., patient). In this scenario, is a reference to Resource A to Resource C meant to provide the same information as the reference from Resource B to Resource C? If so, is this duplication of information problematic? Note that this is not unique to FHIR - it is an innate property of information systems. If an actual instance of A, and the B that it references, reference different instances of Resource C (e.g. the procedure references patient X and an encounter for patient Y), how does the system know that the references are intentionally different versus an error or data anomaly? The problem is that there is limited ability to describe the intent of the reference which leads to the possibility of ambiguity and error. The <a href="linkage.html">Linkage resource</a> can be used to help with this problem, but additional capabilities may be considered in the future to allow systems to address referential integrity. </li> <li> <b>Conditional Semantics</b> – Currently, the constraints for element definitions including things like data types, value sets, optionality and cardinality are defined at design time with limited consideration for variable run-time semantics. Imagine the scenario where the value of Data Element Y (e.g., “intolerance type”) is constrained differently depending on the value of Data Element X (e.g., “causative agent”) in a given instance of a resource. For example, if the instance of an Intolerance Resource has the “intolerance type” data element populated with “food intolerance”, then “causative agent” should be constrained to only valid values for this value set (e.g., valid foods instead of medications or environmental agents). Tools for addressing deep semantic consistency in this regard are only gradually developing. </li> <li> <b>Business Rule Enforcement and Validation</b> – As governance increases and more resource rules are defined, it may be advantageous to have a resource validation tool that checks for things like resource consistency, duplication, referential integrity, circular or nonsensical references, and other defined and approved validation rules. Once rules are agreed to, this level of automation can help address the other issues outlined above. These kinds of facilities are planned for the future. </li> </ul> </div> <hr/><h2>overview-clinical.html</h2> <div class="col-12"> <h2>FHIR Overview - Clinicians</h2> <table class="colsi"><tr><td id="wg"><a _target="blank" href="</a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: N/A</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>:<!--!ns!--><a href="versions.html#std-process">Informative</a></td></tr></table> <p> FHIR (<i>Fast Healthcare Interoperability Resources</i>) is designed to enable the exchange of healthcare-related information. This includes clinical data as well as healthcare-related administrative, public health and research data. It covers both human and veterinary medicine and is intended to be usable world-wide in a wide variety of contexts, including in-patient, ambulatory care, acute care, long-term care, community care, allied health, etc. </p> <p> The FHIR specification is targeted to individuals and organizations developing software and architecting interoperable solutions that will be using FHIR. The FHIR specification does not attempt to define good or best clinical practices, nor does it provide guidance on user interfaces or workflows. Guidance in these areas may be useful, but it is outside of FHIR's scope. </p> <p> Because of FHIR's focus on implementation, many aspects of the specification deal with the technical underpinnings of the exchange of clinical information between electronic systems. This section provides an introduction to what FHIR provides, and tries to highlight those portions of the specification that are likely to be of most interest to the clinical community while skipping over some of the technical minutiae of interoperability. However, clinical readers are welcome to explore some of the more technical areas if they find them of interest. </p> <a name="Resources"></a> <h3>Resources</h3> <p> From a clinical perspective, the most important parts of the FHIR specification to understand are the Resources. Think of Resources as paper "forms" reflecting different types of clinical and administrative information that can be captured and shared. The FHIR specification defines a generic "form template" for each type of clinical information - so one for allergies, one for prescriptions, one for referrals, etc. </p> <p> FHIR data consists of repositories containing completed "forms" (resource instances). The resource instances describe patient-related information (such as demographics, health conditions and procedures) as well as administrative information (such as practitioners, organizations and locations). Some resources are infrastructure components used to support the technical exchange of information by describing what systems are able to do, defining allowed sets of codes, etc. FHIR repositories might be electronic health record (EHR) systems, pharmacy systems, hospital information systems (HIS), etc. Some systems, such as clinical decision support engines, may expose FHIR interfaces even though they don't actually store any patient or administrative information themselves. </p> <p> Each Resource defines a small amount of highly-focused data. A single resource doesn't say very much, but a collection of Resources taken together creates a useful clinical record. Information systems map the actions that a user takes (look up patient records, make a note in their history, etc.) to operations on the relevant resources. </p> <a name="Extensibility"></a> <h3>Extensibility and Profiling</h3> <p> The paper forms (Resources) in FHIR are somewhat generic. They have to be usable in different countries and by different types of clinicians in different contexts (human care, veterinary care, public health, research, etc.). Recognizing that a <i>one size fits all</i> approach is not appropriate in the healthcare space, FHIR provides the ability to adjust the forms (Resources) to be able to handle the needs of different implementation spaces by defining "extensions" as well as enforcing constraints. For example, a "prescription" form might have extension elements added to support tracking of restricted medications while also constraining the codes that can be used to communicate types of drugs to a particular national standard. Forms are designed in such a way that these changes can be made without changing how systems pass forms around, enabling any system to consume completed forms even if they have additional elements added, whether or not those additional elements are used by the receiving system. </p> <p> To keep the base forms that everyone uses from being overly complex, FHIR has a rule that, in most cases, a resource will only include data elements if there's an expectation that most implementations will use that particular data element. That doesn't mean the data must always exist. For example, most systems in the world are capable of tracking "deceased date" for a patient, even though that element will be blank for many patient records. On the other hand, not as many systems track hair color, so hair color would be omitted from the base form and those systems that need it (perhaps in a specialty clinical or research setting) can use a FHIR extension to capture it if needed. </p> <p> To keep the number of resources reasonable, some of them are fairly broad. For example, the <a href="observation.html">Observation</a> resource is used for vital signs, lab results, psychological assessments and a variety of other things. To support setting rules for more narrow areas (e.g. "<i>What should I send if I want to share a blood pressure?</i>"), FHIR allows the creation of Profiles. There will be a great deal of clinical work involved in forming consensus around how different types of detailed clinical information should be captured and shared in particular settings. Tooling to support the creation of profiles directly by clinicians is part of the plan for FHIR, but is still in the very early stages. </p> <a name="Narrative"></a> <h3>Narrative</h3> <p> FHIR is intended to support sharing data in a computable manner. I.e. The information shared should be usable for computer-mediated processes such as decision support, rules triggering, trend analysis, etc. However, not every system is the same and not all systems are able to recognize all discrete data. Also, there is still considerable value in data exchange in circumstances where not all or even none of that data is captured in a discrete manner. For this reason, FHIR resources support sharing not only discrete data for computation, but also a human-readable view so that the humans on each end of a healthcare information exchange can still get a full picture of what's going on. </p> <p> Narrative is expected to exist for most resource instances, although it can be omitted in a few limited circumstances. In some cases, the narrative will be generated from discrete information. For example, the narrative for a patient might look like this: </p> <table> <tbody> <tr> <td> <b><u>Peter James Chalmers (OFFICIAL), Jim</u></b><br/> <b>identifier</b>: MRN = 12345 (USUAL)<br/> <b>telecom</b>: ph: (03) 5555 6473(WORK)<br/> <b>gender</b>: MALE<br/> <b>birthDate</b>: Dec 25, 1974<br/> <b>deceased</b>: false<br/> <b>address</b>: 534 Erewhon St PleasantVille Vic 3999 (HOME) </td> </tr> </tbody> </table> <p> In other cases, the narrative might be free-form text commentary entered directly by a practitioner, such as referral letters, pathology reports, etc. Certain parts of the narrative content could also later be exposed as discrete data. </p> <a name="Interfaces"></a> <h3>Interfaces</h3> <p> In addition to defining the "forms" for data exchange (Resources), FHIR also defines a set of interfaces by which systems actually share that information. There are four primary mechanisms or "paradigms" of exchange supported by FHIR: via a REST interface, by exchanging Documents, by sending and receiving Messages and by exposing and invoking Services. </p> <a name="REST"></a> <h4>REST</h4> <p> REST is the simplest exchange mechanism. Continuing with the "form" metaphor, a RESTful server can be thought of as a room full of filing cabinets. Within the room is a cabinet for each "type" of form (or Resource) it supports. The cabinet contains folders where each folder has a unique number and represents one particular real-world thing: one Patient, one Encounter, one Medication, etc. Each folder (which represents a single Resource <i>instance</i>) contains multiple pieces of paper, with each piece of paper representing a specific "version" of that instance. Every time someone updates a record, a new piece of paper is added to the top of the file folder. To see the history of a resource, you simply have to flip through the pieces of paper in the folder. </p> <p> Note that a typical medical record is generally a big "folder-of-folders" with many different types of 'forms' or 'reports' gathered together. This is convenient for someone who wants to review the whole record, but inconvenient for someone updating bits of it. There's always contention for access to it to update the right part. In the computer application the record will be decomposed to its smallest components for management purposes, and a computer will (or should) assemble the correct bits as required, by following references that exist from one piece of information to the next. </p> <p> Now picture a clerk at the front door of that room. You can pass the clerk a requisition to have them do something with the information in those file cabinets. The "clerk" and the set of requisition forms on the clerk's counter make up the FHIR restful API. With that API, you can do the following: </p> <ul> <li><i>search</i>: Have the clerk search through the folders for one(s) that meet a set of search criteria and give you a copy of the top piece of paper in each relevant folder</li> <li><i>read</i>: Get a copy of the top piece of paper (which is the most current version) from a specific folder in one of the cabinets</li> <li><i>create</i>: Add a new folder to the appropriate cabinet (with a new number)</li> <li><i>update</i>: Add a new page (version) to the contents of a specific folder</li> <li><i>delete</i>: Remove a folder from the cabinet (or more accurately, virtually remove it by putting a sticker on it saying "do not open")</li> <li><i>history</i>: Look at all the pages in a single folder, in a particular file cabinet or possibly in the whole room. Such a broad request would be used primarily for administrative purposes rather than clinical purposes</li> <li><i>transaction</i>: Give the clerk multiple pieces of paper to place in distinct folders at the same time</li> <li><i>operation</i>: Ask the clerk to perform an action or procedure on papers from one or more of the folders - for example, averaging numbers across patients, producing a summary record, or perform a complex search just by ticking a box on a requisition saying "do that one"</li> </ul> <p> EHRs and other systems may present a more sophisticated interface to their end users, but behind the scenes they're all making these same types of requests to the file clerk. </p> <a name="Documents"></a> <h4>Documents</h4> <p> Documents are a familiar mechanism for sharing information in the healthcare space. They are useful whenever there's a desire to guide how a consumer of information will navigate it and there's a need to have a "frozen" view of information that can be reliably retrieved even years in the future. Examples of document-like things in healthcare include discharge summaries and lab reports. </p> <p> In FHIR, there's a special resource called <a href="composition.html">Composition</a> that acts as the "cover page" for a document. It identifies the title, author date, relevant patient and the table of contents. A FHIR document can be thought of as a set of sheets (Resource <i>instances</i>) stacked together with a title page on top that's stapled together. That stapled collection can then be stored or passed around, conveying a complete set of information at once. </p> <a name="Messaging"></a> <h4>Messaging</h4> <p> Much healthcare information exchange happens using a messaging paradigm. In messaging, a set of information is sent from one system to another, typically triggered by an event in the sender system. For example, a patient being admitted, a lab test being ordered, a drug being administered, the clock striking 12:00 or someone pressing a button. The message serves to notify the receiver that the event occurred as well as provide details about any existing data that was modified or new data that was created. Typically receiving a message means there's an expectation that the receiving system will "do something" in response. </p> <p>A message might request that a lab order be fulfilled or notify a system that two patient records have been merged or that a patient has been transferred from one bed to another. A message is similar to a document in that it collects resources together, however for a message, the "cover page" is a <a href="messageheader.html">MessageHeader</a> that acts as a requisition. And rather than using a staple, the resources are joined together with a paper-clip and there's no expectation that the receiving system will store the contents of the message exactly as received, if at all. </p> <a name="Services"></a> <h4>Services</h4> <p> Services can be thought of as a light-weight way of doing messaging. Rather than a full cover page, a small sticky note is attached to the front of a resource. And sometimes rather than sending a full piece of paper, the relevant pieces are cut out and sent as fragments. The response to a requisition is a similarly paper-clipped bundle of resource instances. Services are likely to be used for things like decision support. E.g. "<i>Is there a problem with prescribing medication X for patient Y?</i>" or "<i>What's the recommended care plan for a patient with conditions A, B and C?</i>" </p> <a name="Approaching"></a> <h3>Approaching the specification</h3> <p> A FHIR-based system's capabilities are defined by what the Resources can say and from a clinical perspective, these things define the clinical record: </p> <ul> <li>the kinds of Resources that are defined</li> <li>their data contents, and rules about the data such as what terminology codes are supported and/or required</li> <li>how resources reference to each other</li> <li>how you can search for information</li> </ul> <p> This information can all be found in the resource definition pages. The resources most likely to be of interest can be found in the following modules: </p> <ul> <li><a href="clinicalsummary-module.html">Clinical & Care provision</a></li> <li><a href="diagnostics-module.html">Diagnostics</a></li> <li><a href="medications-module.html">Medications</a></li> <li><a href="administration-module.html">Administrative</a></li> </ul> <p> Instructions on how to interpret the information found on the resource pages can be found <a href="formats.html">here</a>. The <i>Logical table</i> or the <i>UML</i> views are likely to be easiest to understand. Don't forget to look at the examples tab for an idea of what kind of information can be expressed. Seeing how elements are used to convey real data is often more useful than just looking at definitions. Also, look at the Profiles tab to see examples of how different resources can be constrained for use in particular contexts. </p> <p> Clinician and other domain expertise and feedback is always welcome as we continue refining the FHIR specification. At the top of each resource page is a link to the home page for the work group responsible for that particular resource. If you have feedback on resource design, consider getting involved. </p> </div> <hr/><h2>overview-dev.html</h2> <div class="col-12"> <h2>FHIR Overview - Developers</h2> <table class="colsi"><tr><td id="wg"><a _target="blank" href="</a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: N/A</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>:<!--!ns!--><a href="versions.html#std-process">Informative</a></td></tr></table> <p> FHIR (<i>Fast Healthcare Interoperability Resources</i>) is designed to enable information exchange to support the provision of healthcare in a wide variety of settings. The specification builds on and adapts modern, widely used RESTful practices to enable the provision of integrated healthcare across a wide range of teams and organizations. </p> <p> The intended scope of FHIR is broad, covering human and veterinary, clinical care, public health, clinical trials, administration and financial aspects. The standard is intended for global use and in a wide variety of architectures and scenarios. </p> <a name="Framework"></a> <h3>Framework</h3> <p> FHIR is based on "Resources" which are the common building blocks for all exchanges. Resources are an instance-level representation of some kind of healthcare entity. All resources have the following features in <a href="resource.html">common</a>: </p> <ul> <li>A URL that identifies the resource</li> <li>Common metadata</li> <li>A <a href="narrative.html">human-readable XHTML summary</a></li> <li>A set of defined data elements - a different set for each type of resource </li> <li>An <a href="extensibility.html">extensibility framework</a> to support variation in healthcare</li> </ul> <p> Resource instances are represented as either <a href="xml.html">XML</a>, <a href="json.html">JSON</a> or <a href="rdf.html">RDF</a> and there are currently different <a href="resourcelist.html">resource types defined</a> in the FHIR specification. </p> <p> This specification describes a set of resources - that is, a set of resource types that describe the set of resource instances that can actually be exchanged. The term 'Resource' is sometimes used without clarifying whether it specifically refers to types or instances - the context of use makes this clear. </p> <a name="Example"></a> <h3>Example Resource Instance</h3> <p> This is an example of how a <a href="patient.html">patient</a> is represented as a FHIR object in <a href="json.html">JSON</a>. An <a href="xml.html">XML encoding</a> is also defined in the specification. </p> <div class="example"> <pre class="json linecounter"> <code>{</code> <code> "resourceType": "Patient",</code> <code> "id" : "23434",</code> <code> "meta" : {</code> <code> "versionId" : "12",</code> <code> "lastUpdated" : "2014-08-18T15:43:30Z"</code> <code> }</code> <code> "text": {</code> <code> "status": "generated",</code> <code> "div": "<!-- Snipped for Brevity -->"</code> <code> },</code> <code> "extension": [</code> <code> {</code> <code> "url": "http://example.org/consent#trials",</code> <code> "valueCode": "renal"</code> <code> }</code> <code> ],</code> <code> "identifier": [</code> <code> {</code> <code> "use": "usual",</code> <code> "label": "MRN",</code> <code> "system": "http://www.goodhealth.org/identifiers/mrn",</code> <code> "value": "123456"</code> <code> }</code> <code> ],</code> <code> "name": [</code> <code> {</code> <code> "family": [</code> <code> "Levin"</code> <code> ],</code> <code> "given": [</code> <code> "Henry"</code> <code> ],</code> <code> "suffix": [</code> <code> "The 7th"</code> <code> ]</code> <code> }</code> <code> ],</code> <code> "gender": {</code> <code> "text": "Male"</code> <code> },</code> <code> "birthDate": "1932-09-24",</code> <code> "active": true</code> <code>}</code> </pre> </div> <p> Each instance of a resource consists of: </p> <ul> <li><b>resourceType</b> (line 2) - Required: FHIR defines many different types of resources. See <a href="resourcelist.html">the full index</a></li> <li><b>id</b> (line 3) - The id of this resource. Always present when a resource is exchanged, except during the create operation (below)</li> <li><b>meta</b> (lines 4 - 7) - Usually Present: <a href="resource.html#meta">Common use/context data to all resources</a> and managed by the infrastructure. Missing if there is no metadata</li> <li><b>text</b> (lines 8 - 11) - Recommended: XHTML that provides a <a href="narrative.html">human readable representation</a> for the resource</li> <li><b>extension</b> (lines 12 - 17) - Optional: <a href="extensibility.html">Extensions</a> defined by the extensibility framework</li> <li><b>data</b> (lines 18 - 43) - Optional: data elements - a different set, defined for each type of resource</li> </ul> <p> Note that although this specification always shows the JSON properties in the order that they are defined, many JSON libraries order properties by other criteria. </p> <a name="Interactions"></a> <h3>Interactions</h3> <p> For manipulation of resources, FHIR provides a <a href="http.html">REST API</a> with a rich but simple set of interactions: </p> <ul> <li><a href="http.html#create">Create</a> = POST https://example.com/path/{resourceType}</li> <li><a href="http.html#read">Read</a> = GET https://example.com/path/{resourceType}/{id}</li> <li><a href="http.html#update">Update</a> = PUT https://example.com/path/{resourceType}/{id}</li> <li><a href="http.html#delete">Delete</a> = DELETE https://example.com/path/{resourceType}/{id}</li> <li><a href="http.html#search">Search</a> = GET https://example.com/path/{resourceType}?search parameters...</li> <li><a href="http.html#history">History</a> = GET https://example.com/path/{resourceType}/{id}/_history</li> <li><a href="http.html#transaction">Transaction</a> = POST https://example.com/path/ <i>(POST a transaction bundle to the system)</i></li> <li><a href="operations.html">Operation</a> = GET https://example.com/path/{resourceType}/{id}/${opname}</li> </ul> <p> The FHIR specification describes other kinds of exchanges beyond this simple RESTful API, including exchange of groups of resources as <a href="documents.html">Documents</a>, as <a href="messaging.html">Messages</a>, and by using various types of <a href="services.html">Services</a>. </p> <a name="Managing"></a> <h3>Managing Variability</h3> <p> There is a wide variation between different geo-political jurisdictions and segments of the healthcare industry, and no central authority to impose common business practices. Because of this, the FHIR specification defines an <a href="extensibility.html">extension framework</a> and defines <a href="profiling.html">a framework for managing variability</a>. </p> <p> Another key aspect of the variability encountered in healthcare is that the same information may be represented differently and with different levels of detail, granularity and nesting by various parties across the system. For example, in some cases a blood pressure measurement may be just a simple observation, a vital sign measure, while in other cases can be a rich set of highly defined data that includes things like controlled vocabularies for posture, exercise, etc. The <a href="resourcelist.html">resource types</a> defined in this specification focus on the general, common use cases. Richer and more specific content can be supported and standardized by <a href="profiling.html">defining "profiles"</a> on the base resource types. </p> <a name="versions"></a> <h3>Managing Versions</h3> <p> Versions, in the context of FHIR, means one of three different things: </p> <ol> <li>FHIR Version: Which FHIR version is in use?</li> <li>Record Version: for tracking changes to resources, and preventing changes overwriting each other</li> <li>Business Version: So humans know which version of the content they are dealing with (for some kinds of resources)</li> </ol> <p><b>FHIR Version</b></p> <p> Usually, the FHIR version is fixed by the context - the <a href="capabilitystatement.html">CapabilityStatement</a> that a client can use to find out about the server, but there are other ways of <a href="versioning.html">managing multiple FHIR versions</a>. </p> <p><b>Record Version</b></p> <p> FHIR Servers do not have to support versioning, though they are strongly encouraged to do so. There are three different levels of versioning support for FHIR servers: </p> <ul> <li>Versioning and .meta.version are not supported (and usually, .meta.lastUpdated is not supported either)</li> <li>Versioning and the VersionId meta-property are supported, but a history of old versions is not kept</li> <li>Versioning and the VersionId meta-property are supported, and a history of old versions is available</li> </ul> <p> In addition, servers may require that <a href="http.html#concurrency">version</a> aware updates are used, to prevent over-writing changes, but this is not described on this page. </p> <p><b>Business Version</b></p> <p> Some resources - typically those that represent content that goes through a formal publishing cycle - carry a <code>version</code> element that explicitly states what version of the content the resource represents. This is changed explicitly by a human, or by some automated process in accordance with applicable business rules. </p> <a name="Creating"></a> <h3>Creating a resource</h3> <p> To <a href="http.html#create">create a resource</a>, send an HTTP POST request to the resource type's respective end point. </p> <pre> POST https://example.com/path/{resourceType} </pre> <p> In the example below we see the creation of a Patient. </p> <div class="example"> <pre class="http linecounter"> <code>POST {some base path}/Patient HTTP/1.1</code> <code>Authorization: Bearer 37CC0B0E-C15B-4578-9AC1-D83DCED2B2F9</code> <code>Accept: application/fhir+json</code> <code>Content-Type: application/fhir+json</code> <code>Content-Length: 1198</code> <code> </code> <code>{</code> <code> "resourceType": "Patient",</code> <code> ...(properties)</code> <code>}</code> </pre> </div> <p> Submit a new patient to the server, and ask it to store the patient with an id of its own choice. </p> <p> Notes: </p> <ul> <li><b>/Patient</b> (line 1) - the manager for all patients - use the name of the type of resource</li> <li><b>Authorization</b> (line 2) - see <a href="security.html">Security for FHIR</a></li> <li><b>Accept, Content-Type</b> (lines 3-4) - the content type for all FHIR resources as represented in JSON (or application/fhir+xml for the XML version). FHIR resources are always represented in UTF-8</li> <li><b>id</b> - The client does not need to provide an id for a resource that is being created - the server will assign one. If the client assigns one, the server will overwrite it</li> <li>Resource Content, lines 8+ - There's no meta property at this point. The rest of the resource is the same content as shown above</li> </ul> <a name="create-response"></a> <h3>Create Response</h3> <p> A response will contain an HTTP code 201 to indicate that the Resource has been created successfully. A location header indicates where the resource can be fetched in subsequent requests. The server may choose to return an <a href="operationoutcome.html">OperationOutcome</a> resource, but is not required to do so. </p> <div class="example"> <pre class="http linecounter"> <code>HTTP/1.1 201 Created</code> <code>Content-Length: 161</code> <code>Content-Type: application/fhir+json</code> <code>Date: Mon, 18 Aug 2014 01:43:30 GMT</code> <code>ETag: W/"1"</code> <code>Location: http://example.com/Patient/347</code> <code> </code> <code>{</code> <code> "resourceType": "OperationOutcome",</code> <code> "text": {</code> <code> "status": "generated",</code> <code> "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">The operation was successful</div>"</code> <code> }</code> <code>}</code> </pre> </div> <p> Notes: </p> <ul> <li><b>HTTP/1.1 201</b> (line 1) - the operation was successful. Note that use of <a href="https://tools.ietf.org/html/rfc7231">HTTP v 1.1</a> is strongly recommended but not required</li> <li><b>ETag</b> (line 5) - used in the <a href="http.html#update">version aware update</a> pattern (if the server supports versioning)</li> <li><b>Location</b> (line 6) - the id the server assigned to the resource. The id in the URL must match the id in the resource when the resource is subsequently returned</li> <li><b>OperationOutcome</b> (line 9) - OperationOutcome resources in this context have no id or meta element (they have no managed identity)</li> </ul> <a name="error-response"></a> <h4>Error response</h4> <p> For a variety of reasons, servers may need to return an error. Clients should be alert to authentication related responses, but FHIR content related errors should be returned using an appropriate HTTP status code, with an <a href="operationoutcome.html">OperationOutcome</a> resource to provide additional information. Here is an example of a server rejecting a resource because of server defined business rules: </p> <div class="example"> <pre class="http linecounter"> <code>HTTP/1.1 422 Unprocessable Entity</code> <code>Content-Length: 161</code> <code>Content-Type: application/fhir+json</code> <code>Date: Mon, 18 Aug 2014 01:43:30 GMT</code> <code> </code> <code>{</code> <code> "resourceType": "OperationOutcome",</code> <code> "text": {</code> <code> "status": "generated",</code> <code> "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">MRN conflict</code> <code> - the MRN 123456 is already assigned to a different patient</div>"</code> <code> },</code> <code>}</code> </pre> </div> <p> Notes: </p> <ul> <li>The server can return additional structured information using the details of the <a href="operationoutcome.html">OperationOutcome</a></li> </ul> <a name="read-request"></a> <h3>Read Request</h3> <p> <a href="http.html#read">Reading a resource</a> is done by sending HTTP GET requests to the desired Resource Type end-point. </p> <pre> GET https://example.com/path/{resourceType}/{id} </pre> <p> Here's an example. </p> <div class="example"> <pre class="http linecounter"> <code>GET /Patient/347?_format=xml HTTP/1.1</code> <code>Host: example.com</code> <code>Accept: application/fhir+xml</code> <code>Cache-Control: no-cache</code> </pre> </div> <p> Notes: </p> <ul> <li><b>347</b> (line 1) - The id of the resource that is being fetched</li> <li><b>_format=xml</b> (line 1) - this is another method for clients to indicate the desired response format, in addition to using the accept header, and is useful for clients that don't have access to the HTTP Headers (e.g. XSLT transforms) (see <a href="http.html#mimetypes">Mime Types</a>)</li> <li><b>cache control</b> (line 4) - Cache control is important, though FHIR itself says nothing about it - see <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html</a> or <a href="https://www.mnot.net/cache_docs/">https://www.mnot.net/cache_docs/</a></li> </ul> <a name="read-response"></a> <h3>Read Response</h3> <p> The response to a GET contains the Resource. </p> <div class="example"> <pre class="http linecounter"> <code>HTTP/1.1 200 OK</code> <code>Content-Length: 729</code> <code>Content-Type: application/fhir+xml</code> <code>Last-Modified: Sun, 17 Aug 2014 15:43:30 GMT</code> <code>ETag: W/"1"</code> <code> </code> <code><?xml version="1.0" encoding="UTF-8"?></code> <code><Patient xmlns="http://hl7.org/fhir"></code> <code> <id value="347"/></code> <code> <meta></code> <code> <versionId value="1"/></code> <code> <lastUpdated value="2014-08-17T15:43:30Z"/></code> <code> </meta></code> <code> <!-- content as shown above for patient --> </code> <code></Patient></code> </pre> </div> <p> Notes: </p> <ul> <li><b>id</b> (line 9) - The id of the resource. This must match the id in the read request</li> <li><b>versionId</b> (line 11) - The current version id of the resource (if the server supports versioning). Best practice is that this value matches the ETag (see <a href="http.html#update">version aware update</a>), but clients must never assume this</li> <li>Note that servers are not required to support versioning, but are strongly encouraged to do so</li> <li><b>lastUpdated</b> (line 12) - if present, this must match the value in the HTTP header</li> </ul> <a name="search-request"></a> <h3>Search Request</h3> <p> In addition to getting single known resources it's possible to find a collection of resources by <a href="http.html#search">searching the resource type end-point</a> with a <a href="search.html">set of criteria</a> describing the set of resources that should be retrieved, and their order. The general pattern is: </p> <div class="example"> <pre class="http"> GET https://example.com/path/{resourceType}?criteria </pre> </div> <p> The criteria is a set of HTTP parameters that specify which resources to return. The search operation </p> <div class="example"> <pre class="http"> https://example.com/base/MedicationRequest?patient=347 </pre> </div> <p> returns all the prescriptions for the patient created above. </p> <a name="search-response"></a> <h3>Search Response</h3> <p> The response to a search request is a <a href="bundle.html">Bundle</a>: a list of matching resources with some metadata: </p> <div class="example"> <pre class="json linecounter"> <code>HTTP/1.1 200 OK</code> <code>Content-Length: 14523</code> <code>Content-Type: application/fhir+xml</code> <code>Last-Modified: Sun, 17 Aug 2014 15:49:30 GMT</code> <code> </code> <code>{</code> <code> "resourceType": "Bundle",</code> <code> "type": "searchset",</code> <code> "id" : "eceb4882-5c7e-4ca4-af62-995dfb8cef01"</code> <code> "meta" : {</code> <code> "lastUpdated" : "2014-08-19T15:49:30Z"</code> <code> },</code> <code> "total": "3",</code> <code> "link": [</code> <code> {</code> <code> "relation" : "next",</code> <code> "url" : "https://example.com/base/MedicationRequest?patient=347&searchId=ff15fd40-ff71-4b48-b366-09c706bed9d0&page=2"</code> <code> }, {</code> <code> "relation" : "self",</code> <code> "url" : "https://example.com/base/MedicationRequest?patient=347"</code> <code> }</code> <code> ],</code> <code> "entry": [</code> <code> {</code> <code> "resource" : {</code> <code> "resourceType": "MedicationRequest",</code> <code> "id" : "3123",</code> <code> "meta" : {</code> <code> "versionId" : "1",</code> <code> "lastUpdated" : "2014-08-16T05:31:17Z"</code> <code> }, </code> <code> ... content of resource ...</code> <code> }, </code> <code> }, </code> <code> ... 2 additional resources ....</code> <code> ]</code> <code>}</code> </pre> </div> <p> Notes: </p> <ul> <li><b>resourceType/type</b> (line 7/8) - the result of a search is always a bundle of type "searchset"</li> <li><b>id</b> (line 9) - An identifier assigned to this particular bundle. The server should assign a unique id to this bundle that it will not be re-used</li> <li><b>meta.lastUpdated</b> (line 11) - (if the server supports versioning) This should match the HTTP header, and should be the date the search was executed, or more recent, depending on how the <a href="search.html#currency">server handles ongoing updates</a>. The lastUpdated data SHALL be the same or more recent than the most recent resource in the results</li> <li><b>total</b> (line 13) - The total number of matches in the search results. Not the number of matches in this particular bundle, which may be a <a href="http.html#search">paged view into the results</a></li> <li><b>link</b> (line 14) - A set of named links that give related contexts to this bundle. Names defined in this specification: <a href="http.html#search">first</a>, <a href="http.html#search">prev</a>, <a href="http.html#search">next</a>, <a href="http.html#search">last</a>, <a href="http.html#search">self</a></li> <li><b>entry</b> (line 23) - Actual resources in this set of results</li> <li><b>entry.resource.id</b> (line 27) - Note that in some bundles, the <code>entry.resource.id</code> must be <a href="bundle.html#bundle-unique">unique in the bundle</a></li> <li>The search operation is also able to <a href="search.html#include">return additional related resources</a> as well</li> </ul> <a name="update-request"></a> <h3>Update Request</h3> <p> The client sends the server a new version of the resource to replace the existing version - it PUTs it to the location of the existing resource: </p> <pre> PUT https://example.com/path/{resourceType}/{id} </pre> <p> Note that there does not need to be a resource already existing at {id} - the server may elect to automatically create the resource at the specified address. Here is an example of updating a patient: </p> <div class="example"> <pre class="http linecounter"> <code>PUT /Patient/347 HTTP/1.1</code> <code>Host: example.com</code> <code>Content-Type: application/fhir+json</code> <code>Content-Length: 1435</code> <code>Accept: application/fhir+json</code> <code>If-Match: 1</code> <code> </code> <code>{</code> <code> "resourceType": "Patient",</code> <code> "id" : "347",</code> <code> "meta" : {</code> <code> "versionId" : "1",</code> <code> "lastUpdated" : "2014-08-18T15:43:30Z" </code> <code> },</code> <code> ...</code> <code>}</code> </pre> </div> <p> Notes: </p> <ul> <li><b>resourceType</b> (line 1) - "Patient" in the URL must match the resource type in the resource (line 9)</li> <li><b>resource id</b> (line 1, "347") - This must match the id in the resource (line 10)</li> <li><b>If-Match</b> (line 6) - if this is provided, it must match the value in meta.versionId (line 12), and the server must check the version integrity, or return 412 if it doesn't support versions</li> <li><b>meta.lastUpdated</b> (line 13) - This value is ignored, and will be updated by the server (mostly, but not always, if the server does not support versioning)</li> <li><b>resource content</b> (line 14) - Not shown here, the same as Patient above</li> </ul> <a name="update-response"></a> <h3>Update Response</h3> <p> The response to an update request has metadata / status, and optionally an OperationOutcome: </p> <div class="example"> <pre class="http linecounter"> <code>HTTP/1.1 200 OK</code> <code>Content-Length: 161</code> <code>Content-Type: application/fhir+json</code> <code>Date: Mon, 18 Aug 2014 01:43:30 GMT</code> <code>ETag: W/"2"</code> <code>Location: https://example.com/Patient/347/_history/2</code> <code> </code> <code>{</code> <code> "resourceType": "OperationOutcome",</code> <code> "text": {</code> <code> "status": "generated",</code> <code> "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">The operation was successful</div>"</code> <code> }</code> <code>}</code> </pre> </div> <p> Notes: </p> <ul> <li><b>ETag</b> (line 5) - This is the versionId of the new version, and is also found in the location header (line 6) (if the server supports versioning)</li> </ul> <a name="base"></a> <h3>Base Resource Content</h3> <p> Here is an example that shows all the information found in all resources, fully populated: </p> <div class="example"> <pre class="json linecounter"> <code>{</code> <code> "resourceType" : "X",</code> <code> "id" : "12",</code> <code> "meta" : {</code> <code> "versionId" : "12",</code> <code> "lastUpdated" : "2014-08-18T15:43:30Z",</code> <code> "profile" : ["http://example-consortium.org/fhir/profile/patient"],</code> <code> "security" : [{</code> <code> "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",</code> <code> "code" : "EMP"</code> <code> }],</code> <code> "tag" : [{</code> <code> "system" : "http://example.com/codes/workflow",</code> <code> "code" : "needs-review"</code> <code> }]</code> <code> },</code> <code> "implicitRules" : "http://example-consortium.org/fhir/ehr-plugins",</code> <code> "language" : "X"</code> <code>}</code> </pre> </div> <p> Implementers notes: </p> <ul> <li><b>resourceType</b> (line 2) - always found in every resource. In XML, this is the name of the root element for the resource</li> <li><b>id</b> (line 3) - defined when the resource is created, and never changed. Only missing when the resource is first created</li> <li><b>meta.versionId</b> (line 5) - changes each time any resource contents change (except for the last 3 elements in meta - <code>profile</code>, <code>security</code> and <code>tag</code>)</li> <li><b>meta.lastUpdated</b> (line 6) - Changes when the versionId changes. Systems that don't support versions usually don't track lastUpdated either</li> <li><b>meta.profile</b> (line 7) - An assertion that the content conforms to a profile. See <a href="profiling.html#resources">Extending and Restricting Resources</a> for further discussion. Can be changed as profiles and value sets change or the system rechecks conformance</li> <li><b>meta.security</b> (lines 8 - 11) - <a href="security-labels.html">Security labels</a> applied to this resource. These tags connect resources in specific ways to the overall security policy and infrastructure. Security tags can be updated when the resource changes, or whenever the security sub-system chooses to</li> <li><b>meta.tag</b> (lines 12 - 16) - <a href="resource.html#Meta">Tags</a> applied to this resource. Tags are used to relate resources to process and workflow. Applications are not required to consider the tags when interpreting the meaning of a resource. Tags can be <a href="http.html#tags">updated</a> without changing the resource version</li> <li><b>implicitRules</b> (line 17) - indicates that there is a <a href="profiling.html#agreement">custom agreement</a> about how the resources are used that must be understood in order to safely process the resource. Use of this is discouraged because it restricts sharing, but sometimes necessary</li> <li><b>language</b> (line 18) - The <a href="narrative.html#language">base language of the resource</a>. The resource is allowed to have content from other languages; this is just the base, but should be the main language of the resource</li> </ul> <p> The base properties of all resources are defined on the resource types <a href="resource.html">Resource</a> and <a href="domainresource.html">DomainResource</a>. </p> <p> Want more information? </p> <ul> <li><a href="modules.html">Getting Started</a></li> <li><a href="resourcelist.html">Resource Index</a></li> <li><a href="resourceguide.html">Resource Guide</a></li> <li><a href="documentation.html">Documentation Index</a></li> <li><a href="https://confluence.hl7.org/display/FHIR/Implementer+Support">Support Links</a></li> </ul> </div> <hr/><h2>overview.html</h2> <div class="col-12"> <a name="root"></a> <h2>FHIR Overview</h2> <table class="colsi"><tr><td id="wg"><a _target="blank" href="</a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: N/A</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>:<!--!ns!--><a href="versions.html#std-process">Informative</a></td></tr></table> <p> Welcome to the FHIR (Fast Healthcare Interoperability Resources) Specification, which is a standard for exchanging healthcare information electronically. This page provides an overview of the standard, and serves as a road map for first-time readers of the specification to help find your way around FHIR quickly. </p> <a name="Background"></a> <h3>Background</h3> <p> Healthcare records are increasingly becoming digitized. As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Further, to support automated clinical decision support and other machine-based processing, the data must also be structured and standardized. (See <a href="change.html">Coming digital challenges in healthcare</a>) </p> <p> <a href="http://hl7.org">HL7</a> has been addressing these challenges by producing healthcare data exchange and information modeling standards for over 20 years. FHIR is a new specification based on emerging industry approaches, but informed by years of lessons around requirements, successes and challenges gained through defining and implementing <a href="http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185">HL7 v2</a>, <a href="https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186">HL7 v3</a> and the RIM, and <a href="http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7">CDA</a>. FHIR can be used as a stand-alone data exchange standard, but can and will also be used in partnership with existing widely used standards. (See <a href="comparison.html">Comparing FHIR to other HL7 standards</a>) </p> <p> FHIR aims to simplify implementation without sacrificing information integrity. It leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications. FHIR has built-in mechanisms for traceability to the HL7 RIM and other important content models. This ensures alignment to HL7's previously defined patterns and best practices without requiring the implementer to have intimate knowledge of the RIM or any <a href="https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186">HL7 v3</a> derivations. (See <a href="comparison.html">Comparing FHIR to other HL7 standards</a>) </p> <a name="Components"></a> <h3>Components</h3> <p> The basic building block in FHIR is a <a href="resource.html">Resource</a>. All exchangeable content is defined as a resource. Resources all share the following set of characteristics: </p> <ul> <li>A common way to <a href="resource.html">define</a> and <a href="formats.html">represent</a> them, building them from <a href="datatypes.html">data types</a> that define common reusable patterns of elements</li> <li>A common set of <a href="resource.html#metadata">metadata</a></li> <li>A <a href="narrative.html">human readable</a> part</li> </ul> <a name="Approach"></a> <h3>Approach</h3> <a name="modeling"></a> <h4>Approach to information modeling</h4> <p> The philosophy behind FHIR is to build a base set of resources that, either by themselves or when combined, satisfy the majority of common use cases. FHIR resources aim to define the information contents and structure for the core information set that is shared by most implementations. There is a <a href="extensibility.html">built-in extension mechanism</a> to cover the remaining content as needed. </p> <p> FHIR modeling uses a composition approach. In comparison, <a href="https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186">HL7 v3</a> modeling is based on "model by constraint" (see <a href="comparison.html">Comparing FHIR to other HL7 standards</a>). With FHIR, specific use cases are usually implemented by combining resources together through the use of <a href="references.html">resource references</a>. Although a single resource might be useful by itself for a given use case, it is more common that resources will be combined and tailored to meet use case specific requirements. Two special kinds of resources are used to describe how resources are defined and used: </p> <ul> <li><a href="capabilitystatement.html">Capability Statement</a> - describes the interfaces that an implementation exposes for exchange of data</li> <li><a href="structuredefinition.html">StructureDefinition</a> - provide additional rules that serve to constrain the optionality, cardinality, terminology bindings, data types and extensions defined in the resources used by the implementation</li> </ul> <a name="Specification"></a> <h3>The Specification</h3> <p> Broadly, the FHIR specification is broken up into a <a href="modules.html#modules">set of modules</a>: </p> <p> Resources have a wide range of uses, from pure clinical content such as <a href="careplan.html">care plans</a> and <a href="diagnosticreport.html">diagnostic reports</a> to pure infrastructure such as <a href="messageheader.html">Message Header</a> and <a href="capabilitystatement.html">Capability Statements</a>. They all share common technical characteristics (see below for a more formal definition), but they are used in totally different fashions. Note that you do not have to use REST to make use of resources. </p> <a name="Start"></a> <h3>Where to Start</h3> <p> The best place to start is to quickly read the <a href="resourcelist.html">Resources</a> list to get a sense of what resources exist and then look at the <a href="patient.html">Patient resource</a> definition to see what resource definitions look like, and then read these background pages: </p> <ul> <li><a href="resource.html">Resource Definitions</a> - basic background to how resources are defined</li> <li>About Resources: the <a href="narrative.html">Narrative</a> they all contain, and how <a href="references.html">Resources refer to each other</a></li> <li><a href="formats.html">Formats</a>: <a href="xml.html">XML</a> and <a href="json.html">JSON</a></li> <li>About <a href="extensibility.html">Extensibility</a>: a key way that the specification is kept simple</li> <li>If you are coming to FHIR with a background in another HL7 standard (<a href="http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185">HL7 v2</a>, <a href="https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186">HL7 v3</a> or <a href="http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7">CDA</a>), <a href="comparison.html">The Relationship between FHIR and other HL7 Standards</a> may also be useful</li> </ul> <a name="Headers"></a> <h4>Header Tabs</h4> <p> These header tabs found through-out the specification are important, and many readers miss them: </p> <p> <img src="header-tabs.png" style="float: none; clear: both"/> <br/> </p> <p> Resources and the <a href="datatypes.html">data types</a> that they use are presented in a concise easy to read XML-like format, but they also have detailed descriptions of their contents. In addition, most resources are mapped to several different formats, including <a href="http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185">HL7 v2</a>, the <a href="https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186">HL7 v3</a> RIM, <a href="http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7">CDA</a>, DICOM, and others. Also, all resources come with at least one example (sometimes many more) and, where appropriate, with profiles that describe their use in specific circumstances. Finally, some resources include notes that help implementers understand the design rationale underlying them. </p> <a name="Feedback"></a> <h3>Finding Additional Information and Providing Feedback</h3> <p>While intended to be consumable by a variety of audiences, the FHIR specification is targeted to the implementation community - those who will actually write the software that uses the specification. To help meet the needs of the implementation community, the editors have strived to keep the specification concise to reduce the amount of reading that must be done before writing useful code. For this reason, information that is not essential to the implementation process, such as considered alternatives, points of contention, future plans, etc. have been excluded from this specification. As well, it is likely that from time-to-time, implementers will encounter situations where the specification is unclear or incomplete. Finally, there may be circumstances where the specification is broken or where a change could allow it to better meet implementer needs. </p> <p> HL7 has therefore provided a number of mechanisms through which additional information about FHIR can be sought and maintained and through which support and requests for change can be made. </p> <a name="Wiki"></a> <h4>The FHIR Confluence Pages</h4> <p> The FHIR project team also maintains a set of <a href="https://confluence.hl7.org/display/FHIR">Confluence pages</a> where development processes, methodology and design decisions are documented. Implementers and others can also contribute to Confluence to provide additional guidance and supplemental information not found in the specification. Note that Confluence content is not authoritative and is not relevant for determining conformance to the FHIR specification. As well, some Confluence content might not be up to date with the most recent version of the FHIR specification. </p> <p> Pages defined include <a href="https://confluence.hl7.org/display/FHIR/Guide+to+Designing+Resources">FHIR methodology</a>, use of the <a href="https://confluence.hl7.org/display/FHIR/Resource+Authoring">FHIR design tools</a>, etc. To explore the FHIR Confluence pages, you can start at the <a href="https://confluence.hl7.org/display/FHIR">root page</a> </p> <a name="Change"></a> <h4>Formal Change requests</h4> <p> Formal requests for change can be submitted <a href="http://hl7.org/fhir-issues">here</a>. (There's a link at the bottom of each page as well.) These will be reviewed by the appropriate work group and a decision made on their incorporation into the specification, including which release (if any) they will be part of. </p> <a name="Engagement"></a> <h4>Additional Information sources/Engagement Mechanisms</h4> <p> In addition to the above mechanisms, HL7 provides a Stack Overflow tag, list servers and online chat system to provide various levels of implementer support and engagement. Instructions for accessing these other mechanisms (and instructions for how best to make use of them) can be found at the <a href="https://confluence.hl7.org/display/FHIR/Implementer+Support">Support Links</a>. </p> </div> <hr/><h2>page.html</h2> <div class="col-12"> <h1>FHIR QA Report</h1> </div> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>blank page