Fixed various typos and other minor issues in docs
This commit is contained in:
Jafer Khan
parent
5cfc75eac2
commit
8039d68608
|
|
@ -62,5 +62,5 @@ To enable detailed logging of client requests and responses (what URL is being r
|
|||
|
||||
# Server Request Logging
|
||||
|
||||
To enable detailed logging of server requests and responses, an interceptor may be added to the server which logs each transaction. See [Logging Interceptr](/docs/interceptors/built_in_server_interceptors.html#logging_interceptor) for more information.
|
||||
To enable detailed logging of server requests and responses, an interceptor may be added to the server which logs each transaction. See [Logging Interceptor](/docs/interceptors/built_in_server_interceptors.html#logging_interceptor) for more information.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ HAPI also provides a second style of client, called the *annotation-driven* clie
|
|||
|
||||
The design of the annotation-driven client is intended to be similar to that of JAX-WS, so users of that specification should be comfortable with this one. It uses a user-defined interface containing special annotated methods which HAPI binds to calls against a server.
|
||||
|
||||
The annotation-driven client is particularly useful if you have a server that exposes a set of specific operations (search parameter combinations, named queries, etc.) and you want to let developers have a stongly/statically typed interface to that server.
|
||||
The annotation-driven client is particularly useful if you have a server that exposes a set of specific operations (search parameter combinations, named queries, etc.) and you want to let developers have a strongly/statically typed interface to that server.
|
||||
|
||||
There is no difference in terms of capability between the two styles of client. There is simply a difference in programming style and complexity. It is probably safe to say that the generic client is easier to use and leads to more readable code, at the expense of not giving any visibility into the specific capabilities of the server you are interacting with.
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ Once your client interface is created, all that is left is to create a FhirConte
|
|||
|
||||
Restful client interfaces that you create will also extend the interface [IRestfulClient](/hapi-fhir/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/client/api/IRestfulClient.html), which comes with some helpful methods for configuring the way that the client will interact with the server.
|
||||
|
||||
The following snippet shows how to configure the cliet to explicitly request JSON or XML responses, and how to request "pretty printed" responses on servers that support this (HAPI based servers currently).
|
||||
The following snippet shows how to configure the client to explicitly request JSON or XML responses, and how to request "pretty printed" responses on servers that support this (HAPI based servers currently).
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/ClientExamples.java|clientConfig}}
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ This page outlines ways that the client can be configured for specific behaviour
|
|||
|
||||
By default, the client will query the server before the very first operation to download the server's conformance/metadata statement and verify that the server is appropriate for the given client. This check is only done once per server endpoint for a given FhirContext.
|
||||
|
||||
This check is useful to prevent bugs or unexpected behaviour when talking to servers. It may introduce unneccesary overhead however in circumstances where the client and server are known to be compatible. The following example shows how to disable this check.
|
||||
This check is useful to prevent bugs or unexpected behaviour when talking to servers. It may introduce unnecessary overhead however in circumstances where the client and server are known to be compatible. The following example shows how to disable this check.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/GenericClientExample.java|dontValidate}}
|
||||
|
|
@ -36,7 +36,7 @@ REST clients (both Generic and Annotation-Driven) use [Apache HTTP Client](http:
|
|||
|
||||
The Apache HTTP Client is very powerful and extremely flexible, but can be confusing at first to configure, because of the low-level approach that the library uses.
|
||||
|
||||
In many cases, the default configuration should suffice. HAPI FHIR also encapsulates some of the more common configuration settings you might want to use (socket timesouts, proxy settings, etc.) so that these can be configured through HAPI's API without needing to understand the underlying HTTP Client library.
|
||||
In many cases, the default configuration should suffice. HAPI FHIR also encapsulates some of the more common configuration settings you might want to use (socket timeouts, proxy settings, etc.) so that these can be configured through HAPI's API without needing to understand the underlying HTTP Client library.
|
||||
|
||||
This configuration is provided by accessing the [IRestfulClientFactory](/hapi-fhir/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/client/api/IRestfulClientFactory.html) class from the FhirContext.
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ The following example shows how to configure the use of an HTTP proxy in the cli
|
|||
|
||||
As of HAPI FHIR 2.0, an alternate client implementation is available. This client replaces the low-level Apache HttpClient implementation with the Square [OkHttp](http://square.github.io/okhttp/) library.
|
||||
|
||||
Changing HTTP implementations should be mostly ransparent (it has no effect on the actual FHIR semantics which are transmitted over the wire) but might be useful if you have an application that uses OkHttp in other parts of the application and has specific configuration for that library.
|
||||
Changing HTTP implementations should be mostly transparent (it has no effect on the actual FHIR semantics which are transmitted over the wire) but might be useful if you have an application that uses OkHttp in other parts of the application and has specific configuration for that library.
|
||||
|
||||
Note that as of HAPI FHIR 2.1, OkHttp is the default provider on Android, and will be used without any configuration being required. This is done because HttpClient is deprecated on Android and has caused problems in the past.
|
||||
|
||||
|
|
|
|||
|
|
@ -161,11 +161,12 @@ The server responds with the following response. Note that the ID of the already
|
|||
<lastModified value="2015-10-29T07:33:28.047-04:00"/>
|
||||
</response>
|
||||
</entry>
|
||||
</Bundle>```
|
||||
</Bundle>
|
||||
```
|
||||
|
||||
# Fetch all Pages of a Bundle
|
||||
|
||||
This following example shows how to load all pages of a bundle by fetching each page one-after-the-other and then joining the resuts.
|
||||
This following example shows how to load all pages of a bundle by fetching each page one-after-the-other and then joining the results.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/BundleFetcher.java|loadAll}}
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Note that most fluent operations end with an `execute()` statement which actuall
|
|||
|
||||
# Search
|
||||
|
||||
Searching is a very powerful part of the FHIR API specification itself, and HAPI FHIR aims to proide a complete implementation of the FHIR API search specification via the generic client API.
|
||||
Searching is a very powerful part of the FHIR API specification itself, and HAPI FHIR aims to provide a complete implementation of the FHIR API search specification via the generic client API.
|
||||
|
||||
## Search - By Type
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ If the server supports paging results, the client has a page method which can be
|
|||
|
||||
## Search - Composite Parameters
|
||||
|
||||
If a composite parameter is being searched on, the parameter takes a "left" and "right" operand, each of which is a parameter from the resource being seached. The following example shows the syntax.
|
||||
If a composite parameter is being searched on, the parameter takes a "left" and "right" operand, each of which is a parameter from the resource being searched. The following example shows the syntax.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/GenericClientExample.java|searchComposite}}
|
||||
|
|
@ -193,7 +193,7 @@ The following example shows how to perform an update operation using the generic
|
|||
|
||||
## Conditional Updates
|
||||
|
||||
FHIR also specifies a type of update called "conditional updates", where insetad of using the logical ID of a resource to update, a set of search parameters is provided. If a single resource matches that set of parameters, that resource is updated. See the FHIR specification for information on how conditional updates work.
|
||||
FHIR also specifies a type of update called "conditional updates", where instead of using the logical ID of a resource to update, a set of search parameters is provided. If a single resource matches that set of parameters, that resource is updated. See the FHIR specification for information on how conditional updates work.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/GenericClientExample.java|updateConditional}}
|
||||
|
|
@ -233,7 +233,7 @@ To retrieve the server's capability statement, simply call the [`capabilities()`
|
|||
|
||||
# Extended Operations
|
||||
|
||||
FHIR also supports a set of *extended operatioons*, which are operatons beyond the basic CRUD operations defined in the specificiation. These operations are an RPC style of invocation, with a set of named input parameters passed to the server and a set of named output parameters returned back.
|
||||
FHIR also supports a set of *extended operations*, which are operations beyond the basic CRUD operations defined in the specification. These operations are an RPC style of invocation, with a set of named input parameters passed to the server and a set of named output parameters returned back.
|
||||
|
||||
To invoke an operation using the client, you simply need to create the input [Parameters](/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/Parameters.html) resource, then pass that to the [`operation()`](/hapi-fhir/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/client/api/IGenericClient.html#operation()) fluent method.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# Getting Started with the Client
|
||||
|
||||
A starter project containing all nedded dependencies and some starter code for the HAPI FHIR client is available here:
|
||||
A starter project containing all needed dependencies and some starter code for the HAPI FHIR client is available here:
|
||||
|
||||
* [hapi-fhirstarters-client-skeleton](https://github.com/FirelyTeam/fhirstarters/tree/master/java/hapi-fhirstarters-client-skeleton/)
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ page.server_plain.rest_operations_search=REST Operations: Search
|
|||
page.server_plain.rest_operations_operations=REST Operations: Extended Operations
|
||||
page.server_plain.paging=Paging Search Results
|
||||
page.server_plain.web_testpage_overlay=Web Testpage Overlay
|
||||
page.server_plain.multitenency=Multitenency
|
||||
page.server_plain.multitenancy=Multitenancy
|
||||
page.server_plain.jax_rs=JAX-RS Support
|
||||
|
||||
section.server_jpa.title=JPA Server
|
||||
|
|
|
|||
|
|
@ -26,12 +26,12 @@ This interceptor will then produce output similar to the following:
|
|||
|
||||
# Response Customizing: Syntax Highlighting
|
||||
|
||||
The ResponseHighlighterInterceptor detects when a request is coming from a browser and returns HTML with syntax highlighted XML/JSON instead of just the raw text. In other words, if a user uses a browser to request `http://foo/Patient/1` by typing this address into their URL bar, they will get nice formatted HTML back with a human readable version of the content. This is particularly helpful for testers and public/development APIs where users are likely to invoke the API directly to see how it works.
|
||||
The ResponseHighlighterInterceptor detects when a request is coming from a browser and returns HTML with syntax highlighted XML/JSON instead of just the raw text. In other words, if a user uses a browser to request `http://foo/Patient/1` by typing this address into their URL bar, they will get a nicely formatted HTML back with a human readable version of the content. This is particularly helpful for testers and public/development APIs where users are likely to invoke the API directly to see how it works.
|
||||
|
||||
* [ResponseHighlighterInterceptor JavaDoc](/apidocs/hapi-fhir-server/ca/uhn/fhir/rest/server/interceptor/ResponseHighlighterInterceptor.html)
|
||||
* [ResponseHighlighterInterceptor Source](https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-server/src/main/java/ca/uhn/fhir/rest/server/interceptor/ResponseHighlighterInterceptor.java)
|
||||
|
||||
To see an example of how the output of this interceptor looks, see our demo server using the following example query: [http://hapi.fhir.org/baseR4/Patient](http://hapi.fhir.org/baseR4/Patient). The HTML view you see no that page with colour and indenting is provided by ResponseHighlighterInterceptor. Without this interceptor the respnose will simply by raw JSON/XML (as it will also be with this interceptor if the request is not coming from a browser, or is invoked by JavaScript).
|
||||
To see an example of how the output of this interceptor looks, see our demo server using the following example query: [http://hapi.fhir.org/baseR4/Patient](http://hapi.fhir.org/baseR4/Patient). The HTML view you see in that page with colour and indenting is provided by ResponseHighlighterInterceptor. Without this interceptor the response will simply be raw JSON/XML (as it will also be with this interceptor if the request is not coming from a browser, or is invoked by JavaScript).
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/ServletExamples.java|responseHighlighterInterceptor}}
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
HAPI FHIR 3.8.0 introduced a new interceptor framework that is used across the entire library. In previous versions of HAPI FHIR, a "Server Interceptor" framework existed and a separate "Client Interceptor" framework existed. These have now been combined into a single unified (and much more powerful) framework.
|
||||
|
||||
Interceptor classes may "hook into" various points in the processing chain in both the client and the server. The interceptor framework has been designed do be flexible enough to hook into almost every part of the library. When trying to figure out "how would I make HAPI FHIR do X", the answer is very often to create an interceptor.
|
||||
Interceptor classes may "hook into" various points in the processing chain in both the client and the server. The interceptor framework has been designed to be flexible enough to hook into almost every part of the library. When trying to figure out "how would I make HAPI FHIR do X", the answer is very often to create an interceptor.
|
||||
|
||||
The following example shows a very simple interceptor example.
|
||||
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ compile 'ca.uhn.hapi.fhir:hapi-fhir-structures-r4:${project.version}'
|
|||
|
||||
The HAPI FHIR project generally releases a new full software release 4 times per year, or approximately every 3 months.
|
||||
|
||||
Generally speaking it is a good idea to use a stable build. However, FHIR is a fast moving specification, and there is a lot of ongoing work in HAPI as well. There may be times when you want to try out the latest unreleased version, either to test a new feature or to get a bugfix. You can usually look at the [Changelog](/docs/introduction/changelog.html) to get a sense of what has changed in the next unreleased version.
|
||||
Generally speaking, it is a good idea to use a stable build. However, FHIR is a fast moving specification, and there is a lot of ongoing work in HAPI as well. There may be times when you want to try out the latest unreleased version, either to test a new feature or to get a bugfix. You can usually look at the [Changelog](/docs/introduction/changelog.html) to get a sense of what has changed in the next unreleased version.
|
||||
|
||||
## Using Snapshot Builds
|
||||
|
||||
|
|
@ -69,8 +69,6 @@ Using a snapshot build generally involves appending *-SNAPSHOT* to the version n
|
|||
|
||||
### Using Maven:
|
||||
|
||||
To use a snapshot build, you
|
||||
|
||||
```xml
|
||||
<repositories>
|
||||
<repository>
|
||||
|
|
@ -109,7 +107,7 @@ XML processing (for resource marshalling and unmarshalling) uses the Java StAX A
|
|||
Upon starting up, HAPI will emit a log line indicating which StAX implementation is being used, e.g:
|
||||
|
||||
```
|
||||
08:01:32.044 [main] INFO ca.uhn.fhir.util.XmlUtil - FHIR XML processing will use StAX implementation 'Woodstox XML-phrocessor' version '4.4.0'
|
||||
08:01:32.044 [main] INFO ca.uhn.fhir.util.XmlUtil - FHIR XML processing will use StAX implementation 'Woodstox XML-processor' version '4.4.0'
|
||||
```
|
||||
|
||||
Although most testing is done using the Woodstox implementation of StAX, it is not required and HAPI should work correctly with any compliant implementation of StAX.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ A built in parser can be used to convert HAPI FHIR Java objects into a serialize
|
|||
|
||||
# Parsing (aka Deserializing)
|
||||
|
||||
As with many parts of the HAPI FHIR API, parsing begins with a [FhirContext](/apidocs/hapi-fhir-base/ca/uhn/fhir/context/FhirContext.html) object. The FhirContext can be used to request an [IParser](/apidocs/hapi-fhir-base/ca/uhn/fhir/parser/IParser.html) for your chosen encodng style that is then used to parse.
|
||||
As with many parts of the HAPI FHIR API, parsing begins with a [FhirContext](/apidocs/hapi-fhir-base/ca/uhn/fhir/context/FhirContext.html) object. The FhirContext can be used to request an [IParser](/apidocs/hapi-fhir-base/ca/uhn/fhir/parser/IParser.html) for your chosen encoding style that is then used to parse.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/Parser.java|parsing}}
|
||||
|
|
@ -14,7 +14,7 @@ As with many parts of the HAPI FHIR API, parsing begins with a [FhirContext](/ap
|
|||
|
||||
# Encoding (aka Serializing)
|
||||
|
||||
As with many parts of the HAPI FHIR API, parsing begins with a [FhirContext](/apidocs/hapi-fhir-base/ca/uhn/fhir/context/FhirContext.html) object. The FhirContext can be used to request an [IParser](/apidocs/hapi-fhir-base/ca/uhn/fhir/parser/IParser.html) for your chosen encodng style that is then used to serialize.
|
||||
As with many parts of the HAPI FHIR API, parsing begins with a [FhirContext](/apidocs/hapi-fhir-base/ca/uhn/fhir/context/FhirContext.html) object. The FhirContext can be used to request an [IParser](/apidocs/hapi-fhir-base/ca/uhn/fhir/parser/IParser.html) for your chosen encoding style that is then used to serialize.
|
||||
|
||||
The following example shows a JSON Parser being used to serialize a FHIR resource.
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ The following example shows a JSON Parser being used to serialize a FHIR resourc
|
|||
|
||||
## Pretty Printing
|
||||
|
||||
By default, the parser will output in condensed form, with no newlines or indenting. This is good for machine-to-machine communication since it reduces the amount of data to be transferred but it is harder to read. To enable pretty printed outout:
|
||||
By default, the parser will output in condensed form, with no newlines or indenting. This is good for machine-to-machine communication since it reduces the amount of data to be transferred but it is harder to read. To enable pretty printed output:
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/Parser.java|encodingPretty}}
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ This will give the following output:
|
|||
</Patient>
|
||||
```
|
||||
|
||||
Note that you may also "contain" resources manually in your own code if you prefer. The following example show how to do this:
|
||||
Note that you may also "contain" resources manually in your own code if you prefer. The following example shows how to do this:
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/ResourceRefs.java|manualContained}}
|
||||
|
|
@ -147,7 +147,7 @@ By default, HAPI will strip resource versions from references between resources.
|
|||
|
||||
This is because in most circumstances, references between resources should be versionless (e.g. the reference just points to the latest version, whatever version that might be).
|
||||
|
||||
There are valid circumstances however for wanting versioned references. If you need HAPI to emit versionned references, you have a few options:
|
||||
There are valid circumstances however for wanting versioned references. If you need HAPI to emit versioned references, you have a few options:
|
||||
|
||||
You can force the parser to never strip versions:
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Note that in previous revisions of HAPI FHIR documentation we recommended using
|
|||
|
||||
The following examples show how to use the Apache Tomcat CorsFilter to enable CORS support. The filter being used (`org.apache.catalina.filters.CorsFilter`) is bundled with Apache Tomcat so if you are deploying to that server you can use the filter.
|
||||
|
||||
Other containers have similar filters you can use, so consult the documentation for the given container you are using for more information. (If you have an example for how to configure a different CORS filter, please send it our way! Examples are always useful!)
|
||||
Other containers have similar filters you can use, so consult the documentation for the given container you are using for more information. (If you have an example for configuring a different CORS filter, please send it our way! Examples are always useful!)
|
||||
|
||||
In your web.xml file (within the WEB-INF directory in your WAR file), the following filter definition adds the CORS filter, including support for the X-FHIR-Starter header defined by SMART Platforms.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@
|
|||
|
||||
The HAPI FHIR Plain Server ([RestfulServer](/hapi-fhir/apidocs/hapi-fhir-server/ca/uhn/fhir/rest/server/RestfulServer.html)) is implemented as a standard JEE Servlet, meaning that it can be deployed in any compliant JEE web container.
|
||||
|
||||
For users who already have an existing JAX-RS infrastructure, and who would like to use that technology foor their FHIR stack as well, a module exists which implements the server using [JAX-RS technology](https://jax-rs-spec.java.net/nonav/2.0/apidocs/index.html).
|
||||
For users who already have an existing JAX-RS infrastructure, and who would like to use that technology for their FHIR stack as well, a module exists which implements the server using [JAX-RS technology](https://jax-rs-spec.java.net/nonav/2.0/apidocs/index.html).
|
||||
|
||||
<div class="doc_info_bubble">
|
||||
The JAX-RS module is a community-supported module that was not developed by the core HAPI FHIR team. Before decid the HAPI FHIR JAX-RS module, please be aware that it does not have as complete of support for the full FHIR REST specification as the Plain Server. If you need a feature that is missing, please consiider adding it and making a pull request!
|
||||
The JAX-RS module is a community-supported module that was not developed by the core HAPI FHIR team. Before deciding to use the HAPI FHIR JAX-RS module, please be aware that it does not have as complete of support for the full FHIR REST specification as the Plain Server. If you need a feature that is missing, please consider adding it and making a pull request!
|
||||
</div>
|
||||
|
||||
## Features
|
||||
|
|
@ -27,7 +27,7 @@ An example server can be found in the Git repo [here](https://github.com/jamesag
|
|||
|
||||
The set-up of a JAX-RS server goes beyond the scope of this documentation. The implementation of the server follows the same pattern as the standard server. It is required to put the correct [annotation](./rest_operations.html) on the methods in the [Resource Providers](./resource_providers.html) in order to be able to call them.
|
||||
|
||||
Implementing a JAX-RS Resource Provider requires some JAX-RS annotations. The [@Path](https://docs.oracle.com/javaee/6/api/javax/ws/rs/Path.html) annotation needs to define the resource path. The <code><a href="https://docs.oracle.com/javaee/6/api/javax/ws/rs/Produces.html">@Produces</a></code> annotation needs to declare the produced formats. The constructor needs to pass the class of the object explicitely in order to avoid problems with proxy classes in a Java EE environment.
|
||||
Implementing a JAX-RS Resource Provider requires some JAX-RS annotations. The [@Path](https://docs.oracle.com/javaee/6/api/javax/ws/rs/Path.html) annotation needs to define the resource path. The <code><a href="https://docs.oracle.com/javaee/6/api/javax/ws/rs/Produces.html">@Produces</a></code> annotation needs to declare the produced formats. The constructor needs to pass the class of the object explicitly in order to avoid problems with proxy classes in a Java EE environment.
|
||||
|
||||
It is necessary to extend the abstract class [AbstractJaxRsResourceProvide](/hapi-fhir/apidocs/hapi-fhir-jaxrsserver-base/ca/uhn/fhir/jaxrs/server/AbstractJaxRsResourceProvider.html).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Multitenency
|
||||
# Multitenancy
|
||||
|
||||
If you wish to allow a single endpoint to support multiple tenants, you may supply the server with a multitenancy provider.
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ In some cases, it may be useful to have access to the underlying HttpServletRequ
|
|||
|
||||
# REST Exception/Error Handling
|
||||
|
||||
Within your RESTful operations, you will generally be returning resources or bundles of resources under normal operation. During execution you may also need to propagate errors back to the client for a variety of reasons.
|
||||
Within your RESTful operations, you will generally be returning resources or bundles of resources under normal operation. During execution, you may also need to propagate errors back to the client for a variety of reasons.
|
||||
|
||||
## Automatic Exception Handling
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ to create your server) and the overlay drops a number of files into your project
|
|||
|
||||
# Adding the Overlay
|
||||
|
||||
These instructions assume that you have an exsiting web project which uses Maven to build. The POM.xml should have a "packaging" type of "war".
|
||||
These instructions assume that you have an existing web project which uses Maven to build. The POM.xml should have a "packaging" type of "war".
|
||||
|
||||
Adding the overlay to your project is relatively simple. First, add the "hapi-fhir-testpage-overlay" dependency to the dependencies section of your POM.xml file.
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ Then, add the following WAR plugin to the plugins section of your POM.xml
|
|||
</build>
|
||||
```
|
||||
|
||||
Then, create a Java source file called `FhirTesterConfig.java` and copy in the following contents:
|
||||
Then, create a Java source file called `FhirTesterConfig.java` and copy the following contents:
|
||||
|
||||
<macro name="snippet">
|
||||
<param name="file" value="restful-server-example/src/main/java/ca/uhn/example/config/FhirTesterConfig.java" />
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ The validator can be manually invoked at any time by creating a validator and co
|
|||
```
|
||||
|
||||
<div class="doc_info_bubble">
|
||||
Note that in earlier releases of HAPI FHIR it was common to register different kinds of validator modules (such as [Schema/Schematron](./schema_validator.html)) because the FHIR Instance Validator module described below was not mature. This is no longer the case, and it is generally recommended to use the FHIR Instance Validator.
|
||||
Note that in earlier releases of HAPI FHIR it was common to register different kinds of validator modules (such as <a href="./schema_validator.html">Schema/Schematron</a>) because the FHIR Instance Validator module described below was not mature. This is no longer the case, and it is generally recommended to use the FHIR Instance Validator.
|
||||
</div>
|
||||
|
||||
# FHIR Conformance Packages
|
||||
|
|
@ -22,9 +22,9 @@ There are a few key concepts worth explaining before getting into how validation
|
|||
|
||||
Conformance Resources:
|
||||
|
||||
* [StructureDefinition](http://hl7.org/fhir/structuredefinition.html) – Contains definitions of the valid fields in a given resource, including details about their datatypes, min/max cardinalities, valid values, and other rules about what content is valid and what is not. StructureDefinition resources are also used to express derivative profiles (e.g. a description of a constraint on a FHIR resource for a specfic purpose) as well as to describe extensions.
|
||||
* [StructureDefinition](http://hl7.org/fhir/structuredefinition.html) – Contains definitions of the valid fields in a given resource, including details about their datatypes, min/max cardinalities, valid values, and other rules about what content is valid and what is not. StructureDefinition resources are also used to express derivative profiles (e.g. a description of a constraint on a FHIR resource for a specific purpose) as well as to describe extensions.
|
||||
|
||||
* [CodeSystem](http://hl7.org/fhir/codesystem.html) – Contains definiitions of codes and vocabularies that can be used in FHIR resources, or even outside of FHIR resources.
|
||||
* [CodeSystem](http://hl7.org/fhir/codesystem.html) – Contains definitions of codes and vocabularies that can be used in FHIR resources, or even outside of FHIR resources.
|
||||
|
||||
* [ValueSet](http://hl7.org/fhir/valueset.html) – Contains lists of codes drawn from one or more CodeSystems that are suitable for use in a specific field in a FHIR resource.
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ Conformance Resources:
|
|||
|
||||
HAPI has very complete support for validation against FHIR conformance resources.
|
||||
|
||||
This functionality is proviided by the HAPI FHIR "reference validator", which is able
|
||||
This functionality is provided by the HAPI FHIR "reference validator", which is able
|
||||
to check a resource for conformance to FHIR profiles.
|
||||
|
||||
The FHIR instance validator is very powerful. It will use terminology services to validate codes, StructureDefinitions to validate semantics, and uses a customized XML/JSON parser in order to provide descriptive error messages.
|
||||
|
|
@ -59,7 +59,7 @@ definitions provided either by HL7 or by the user.
|
|||
|
||||
To execute the validator, you simply create an instance of [FhirInstanceValidator](/hapi-fhir/apidocs/hapi-fhir-validation/org/hl7/fhir/r4/hapi/validation/FhirInstanceValidator.html) and register it to new validator, as shown in the example below.
|
||||
|
||||
Note that the example below uses the official FHIR StructureDefintions and ValueSets
|
||||
Note that the example below uses the official FHIR StructureDefinitions and ValueSets
|
||||
to validate the resource. It will not work unless you include the
|
||||
**hapi-fhir-validation-resources-[version].jar** module/JAR on your classpath.
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ to validate the resource. It will not work unless you include the
|
|||
|
||||
# Supplying Your Own Definitions
|
||||
|
||||
The FhirInstanceValidator relies on an implementation of an interface called [IValidationSupport](/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/hapi/ctx/IValidationSupport.html) interface to load StructureDefinitions, validate codes, etx.
|
||||
The FhirInstanceValidator relies on an implementation of an interface called [IValidationSupport](/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/hapi/ctx/IValidationSupport.html) interface to load StructureDefinitions, validate codes, etc.
|
||||
|
||||
By default, an implementation of this interface called [DefaultProfileValidationSupport](/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/hapi/ctx/DefaultProfileValidationSupport.html) is used. This implementation simply uses the built-in official FHIR definitions to validate against (and in many cases, this is good enough).
|
||||
|
||||
|
|
@ -79,9 +79,9 @@ However, if you have needs beyond simply validating against the core FHIR specif
|
|||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/ValidatorExamples.java|validateSupplyProfiles}}
|
||||
```
|
||||
|
||||
# Buiilt-In Validation Support Classes
|
||||
# Built-In Validation Support Classes
|
||||
|
||||
There are a several implementations of the [IValidationSupport](/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/hapi/ctx/IValidationSupport.html) interface built into HAPI FHIR that can be used, typically in a chain.
|
||||
There are several implementations of the [IValidationSupport](/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/hapi/ctx/IValidationSupport.html) interface built into HAPI FHIR that can be used, typically in a chain.
|
||||
|
||||
* [**DefaultProfileValidationSupport**](/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/hapi/ctx/DefaultProfileValidationSupport.html) - Supplies the built-in FHIR core structure definitions, including both structures and vocabulary.
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ There are a several implementations of the [IValidationSupport](/hapi-fhir/apido
|
|||
|
||||
* [**CachingValidationSupport**](/hapi-fhir/apidocs/hapi-fhir-validation/org/hl7/fhir/r4/hapi/validation/CachingValidationSupport.html) - Caches results of calls to a wrapped service implementation for a period of time. This class can be a significant help in terms of performance if you are loading conformance resources or performing terminology operations from a database or disk.
|
||||
|
||||
* [**SnapshotGeneratingValidationSupport**](/hapi-fhir/apidocs/hapi-fhir-validation/org/hl7/fhir/r4/hapi/validation/SnapshotGeneratingValidationSupport.html) - Generates StructureDefinition snapshots as needed. This should be added to your chain if you are working wiith differential StructueDefinitions that do not include the snapshot view.
|
||||
* [**SnapshotGeneratingValidationSupport**](/hapi-fhir/apidocs/hapi-fhir-validation/org/hl7/fhir/r4/hapi/validation/SnapshotGeneratingValidationSupport.html) - Generates StructureDefinition snapshots as needed. This should be added to your chain if you are working with differential StructureDefinitions that do not include the snapshot view.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
# Schema / Schematron Validator
|
||||
|
||||
FHIR resource definitions are distributed with a set of XML schema files (XSD) as well as a set of XML Schematron (SCH) files. These two sets of files are complimentary to each other, meaning that in order to claim compliance to the FHIR specification, your resources must validate against both sets.
|
||||
FHIR resource definitions are distributed with a set of XML schema files (XSD) as well as a set of XML Schematron (SCH) files. These two sets of files are complementary to each other, meaning that in order to claim compliance to the FHIR specification, your resources must validate against both sets.
|
||||
|
||||
The two sets of files are included with HAPI, and it uses them to perform validation.
|
||||
|
||||
# Preparation
|
||||
|
||||
In order to use HAPI's Schematron support, a libaray called [Ph-Schematron](https://github.com/phax/ph-schematron) is used, so this library must be added to your classpath (or Maven POM file, Gradle file, etc.)
|
||||
In order to use HAPI's Schematron support, a library called [Ph-Schematron](https://github.com/phax/ph-schematron) is used, so this library must be added to your classpath (or Maven POM file, Gradle file, etc.)
|
||||
|
||||
Note that this library is specified as an optional dependency by HAPI FHIR so you need to explicitly include it if you want to use this functionality.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue