Merge remote-tracking branch 'remotes/origin/master' into ks-20191119-scheduler
This commit is contained in:
Ken Stevens
commit
3e8bdb835a
|
|
@ -140,7 +140,7 @@ public class ClientExamples {
|
|||
String password = "boobear";
|
||||
IClientInterceptor authInterceptor = new BasicAuthInterceptor(username, password);
|
||||
|
||||
// If you're usinf an annotation client, use this style to
|
||||
// If you're using an annotation client, use this style to
|
||||
// register it
|
||||
IPatientClient annotationClient = ctx.newRestfulClient(IPatientClient.class, "http://localhost:9999/fhir");
|
||||
annotationClient.registerInterceptor(authInterceptor);
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ public class ExampleServlet extends ca.uhn.fhir.rest.server.RestfulServer {
|
|||
/*
|
||||
* Plain providers are passed to the server in the same way
|
||||
* as resource providers. You may pass both resource providers
|
||||
* and and plain providers to the same server if you like.
|
||||
* and plain providers to the same server if you like.
|
||||
*/
|
||||
registerProvider(new MyPlainProvider());
|
||||
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@ public class GenericClientExample {
|
|||
}
|
||||
{
|
||||
// START SNIPPET: etagupdate
|
||||
// First, let's retrive the latest version of a resource
|
||||
// First, let's retrieve the latest version of a resource
|
||||
// from the server
|
||||
Patient patient = client.read().resource(Patient.class).withId("123").execute();
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ public class HttpProxy {
|
|||
|
||||
public static void main(String[] args) {
|
||||
/*
|
||||
* This is out ot date - Just keeping
|
||||
* This is out of date - Just keeping
|
||||
* it in case it's helpful...
|
||||
*/
|
||||
final String authUser = "username";
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ public class MyPatient extends Patient {
|
|||
* Accessors and mutators follow
|
||||
*
|
||||
* IMPORTANT:
|
||||
* Each extension is required to have an getter/accessor and a stter/mutator.
|
||||
* Each extension is required to have an getter/accessor and a setter/mutator.
|
||||
* You are highly recommended to create getters which create instances if they
|
||||
* do not already exist, since this is how the rest of the HAPI FHIR API works.
|
||||
********/
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ public class PagingServer extends RestfulServer {
|
|||
|
||||
/*
|
||||
* Set the resource providers as always. Here we are using the paging
|
||||
* provider from the example below, but it is not strictly neccesary
|
||||
* provider from the example below, but it is not strictly necessary
|
||||
* to use a paging resource provider as well. If a normal resource
|
||||
* provider is used (one which returns List<?> instead of IBundleProvider)
|
||||
* then the loaded resources will be stored by the IPagingProvider.
|
||||
|
|
|
|||
|
|
@ -331,7 +331,7 @@ public void deletePatient(@IdParam IdType theId) {
|
|||
@Delete()
|
||||
public void deletePatientConditional(@IdParam IdType theId, @ConditionalUrlParam String theConditionalUrl) {
|
||||
// Only one of theId or theConditionalUrl will have a value depending
|
||||
// on whether the URL receieved was a logical ID, or a conditional
|
||||
// on whether the URL received was a logical ID, or a conditional
|
||||
// search string
|
||||
if (theId != null) {
|
||||
// do a normal delete
|
||||
|
|
@ -947,7 +947,7 @@ public interface HistoryClient extends IBasicClient {
|
|||
Bundle getHistoryPatientInstance(@IdParam IdType theId);
|
||||
|
||||
/**
|
||||
* Either (or both) of the "since" and "count" paramaters can
|
||||
* Either (or both) of the "since" and "count" parameters can
|
||||
* also be included in any of the methods above.
|
||||
*/
|
||||
@History
|
||||
|
|
@ -1024,8 +1024,8 @@ newPatient.getMeta().addTag("http://personality", "Friendly", "Friendly"); // TO
|
|||
@Create
|
||||
public MethodOutcome createPatientResource(@ResourceParam Patient thePatient) {
|
||||
|
||||
// ..save the resouce..
|
||||
IdType id = new IdType("123"); // the new databse primary key for this resource
|
||||
// ..save the resource..
|
||||
IdType id = new IdType("123"); // the new database primary key for this resource
|
||||
|
||||
// Get the tag list
|
||||
List<Coding> tags = thePatient.getMeta().getTag();
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ import java.util.List;
|
|||
* This is an example of a custom resource that also uses a custom
|
||||
* datatype.
|
||||
*
|
||||
* Note that we are extensing DomainResource for an STU3
|
||||
* Note that we are extending DomainResource for an STU3
|
||||
* resource. For DSTU2 it would be BaseResource.
|
||||
*/
|
||||
@ResourceDef(name = "CustomResource", profile = "http://hl7.org/fhir/profiles/custom-resource")
|
||||
|
|
|
|||
|
|
@ -38,9 +38,9 @@ HAPI uses [SLF4j](http://www.slf4j.org/) for all internal logging. SLF4j is a *l
|
|||
This means that in order to successfully log anything, you will need to
|
||||
add two (or three) dependency JARs to your application:
|
||||
|
||||
* **slf4j-api-vXX.jar**: This is the SLF4j API and is neccesary for HAPI to function
|
||||
* **slf4j-api-vXX.jar**: This is the SLF4j API and is necessary for HAPI to function
|
||||
* An actual logging implementation, as well as its SLF4j binding. For example:
|
||||
* The recommended logging framework to use is Logback. Logback is absolutely not neccesary for HAPI to function correctly, but it has a number of nice features and is a good default choice. To use logback, you would include `logback-vXX.jar`.
|
||||
* The recommended logging framework to use is Logback. Logback is absolutely not necessary for HAPI to function correctly, but it has a number of nice features and is a good default choice. To use logback, you would include `logback-vXX.jar`.
|
||||
* If you wanted to use log4j you would include `log4j-vXX.jar` as well as `slf4j-log4j-vXX.jar`. Log4j is a mature framework that is very widely used.
|
||||
* If you wanted to use JDK logging (aka java.util.Logging) you would include `slf4j-jdk14-vXX.jar`. JDK logging is included with Java but is not particularly full featured compared to many other frameworks.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ The HAPI FHIR [Codebase](https://github.com/jamesagnew/hapi-fhir) has a number o
|
|||
The following is a list of key subprojects you might open in your IDE:
|
||||
|
||||
* [hapi-fhir-base](https://github.com/jamesagnew/hapi-fhir/tree/master/hapi-fhir-base): This is the core library, containing the parsers, client/server frameworks, and many other features. Note that this module does not contain any model classes (e.g. the Patient model class) as these are found in "structures" projects below.
|
||||
* hapi-fhir-structures-[version]: There are several structures projects (e.g. `hapi-fhir-structures-r4`), each of which contains model classes for a specific version of FHIR. Generally speaking you don't need to edit these project directly, as most (but not all) of their code is generated.
|
||||
* hapi-fhir-structures-[version]: There are several structures projects (e.g. `hapi-fhir-structures-r4`), each of which contains model classes for a specific version of FHIR. Generally speaking you don't need to edit these projects directly, as most (but not all) of their code is generated.
|
||||
* hapi-fhir-jpaserver-base: This module contains the JPA server.
|
||||
|
||||
# Getting the Sources
|
||||
|
|
@ -77,7 +77,7 @@ If the build fails to execute successfully, try the following:
|
|||
|
||||
**Maven Import**
|
||||
|
||||
Import the HAPI projects as Maven Modules by selecing **File -> Import...** from the File menu. Then select **Existing Module Projects** as shown below.
|
||||
Import the HAPI projects as Maven Modules by selecting **File -> Import...** from the File menu. Then select **Existing Module Projects** as shown below.
|
||||
|
||||
<img src="../../images/hacking_import.png"/>
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,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 ususally 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
|
||||
|
||||
|
|
@ -107,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 procesing 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-phrocessor' 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.
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ The following table shows the modules that make up the HAPI FHIR library.
|
|||
</td>
|
||||
<td>
|
||||
This module contains the Android HAPI FHIR framework, which is a FHIR
|
||||
client framework which has been tailed specifically to run on Android.
|
||||
client framework which has been tailored specifically to run on Android.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Narrative Generation
|
||||
|
||||
HAPI provides a several ways to add [Narrative Text](http://hl7.org/fhir/narrative.html) to your encoded messages.
|
||||
HAPI provides several ways to add [Narrative Text](http://hl7.org/fhir/narrative.html) to your encoded messages.
|
||||
|
||||
The simplest way is to simply place the narrative text directly in the resource via the `setDivAsString()` method.
|
||||
|
||||
|
|
@ -8,7 +8,7 @@ The simplest way is to simply place the narrative text directly in the resource
|
|||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/Narrative.java|simple}}
|
||||
```
|
||||
|
||||
# Automatic Narrative Generartion
|
||||
# Automatic Narrative Generation
|
||||
|
||||
HAPI FHIR also comes with a built-in mechanism for automatically generating narratives based on your resources.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ This interceptor can help with the complicated task of determining whether a use
|
|||
AuthorizationInterceptor has been well tested, but it is impossible to predict every scenario and environment in which HAPI FHIR will be used. Use with caution, and do lots of testing! We welcome feedback and suggestions on this feature. Please get in touch if you'd like to help test, have suggestions, etc.
|
||||
</p>
|
||||
|
||||
The AuthorizationInterceptor works by allowing you to declare permissions based on an individual request coming in. In other words, you could have code that examines an incoming request and determines that it is being made by a Patient with ID 123. You could then declare that the requesting user has access to read and write any resource in compartment "Patient/123", which corresponds to any Observation, MedicationOrder etc with a subject of "`Patient/123`". On the other hand, another request might be detemrined to belong to an administrator user, and could be declared to be allowed to do anything.
|
||||
The AuthorizationInterceptor works by allowing you to declare permissions based on an individual request coming in. In other words, you could have code that examines an incoming request and determines that it is being made by a Patient with ID 123. You could then declare that the requesting user has access to read and write any resource in compartment "Patient/123", which corresponds to any Observation, MedicationOrder etc with a subject of "`Patient/123`". On the other hand, another request might be determined to belong to an administrator user, and could be declared to be allowed to do anything.
|
||||
|
||||
The AuthorizationInterceptor is used by subclassing it and then registering your subclass with the `RestfulServer`. The following example shows a subclassed interceptor implementing some basic rules:
|
||||
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
Security is a complex topic which goes far beyond the scope of FHIR or HAPI. Every system and architecture operates in a different set of rules, and has different security requirements.
|
||||
|
||||
As such, HAPI FHIR does not provide a single one-size-fits-all security layer. Instead, it provides a numnber of useful tools and building blocks that can be built around as a part of your overall security architecture.
|
||||
As such, HAPI FHIR does not provide a single one-size-fits-all security layer. Instead, it provides a number of useful tools and building blocks that can be built around as a part of your overall security architecture.
|
||||
|
||||
Because HAPI FHIR's REST server is based on the Servlet API, you may use any security mechanism which works in that environment. Some serlvet containers may provide security layers you can plug into. The rest of this page does not explore that method, but rather looks at HAPI FHIR hooks that can be used to implement FHIR specific security.
|
||||
Because HAPI FHIR's REST server is based on the Servlet API, you may use any security mechanism which works in that environment. Some servlet containers may provide security layers you can plug into. The rest of this page does not explore that method, but rather looks at HAPI FHIR hooks that can be used to implement FHIR specific security.
|
||||
|
||||
# Authentication vs Authorization
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ public DaoConfig daoConfig() {
|
|||
}
|
||||
```
|
||||
|
||||
On the other hand, if you want the server to be configurable to allow remote references, you can set this with the confguration below. Using the `setAllowExternalReferences` means that it will be possible to search for references that refer to these external references.
|
||||
On the other hand, if you want the server to be configurable to allow remote references, you can set this with the configuration below. Using the `setAllowExternalReferences` means that it will be possible to search for references that refer to these external references.
|
||||
|
||||
```java
|
||||
@Bean
|
||||
|
|
@ -67,7 +67,7 @@ In some cases, you may have references which are <i>Logical References</i>,
|
|||
which means that they act as an identifier and not necessarily as a literal
|
||||
web address.
|
||||
|
||||
A common use for logical references is in references to conformance resources, such as ValueSets, StructureDefinitions, etc. For example, you might refer to the ValueSet `http://hl7.org/fhir/ValueSet/quantity-comparator` from your own resources. In this case, you are not neccesarily telling the server that this is a real address that it should resolve, but rather that this is an identifier for a ValueSet where `ValueSet.url` has the given URI/URL.
|
||||
A common use for logical references is in references to conformance resources, such as ValueSets, StructureDefinitions, etc. For example, you might refer to the ValueSet `http://hl7.org/fhir/ValueSet/quantity-comparator` from your own resources. In this case, you are not necessarily telling the server that this is a real address that it should resolve, but rather that this is an identifier for a ValueSet where `ValueSet.url` has the given URI/URL.
|
||||
|
||||
HAPI can be configured to treat certain URI/URL patterns as logical by using the DaoConfig#setTreatReferencesAsLogical property (see [JavaDoc](/hapi-fhir/apidocs/hapi-fhir-jpaserver-base/ca/uhn/fhir/jpa/dao/DaoConfig.html#setTreatReferencesAsLogical-java.util.Set-)).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Getting Started with HAPI FHIR Plain Server
|
||||
|
||||
Two starter projects are maintained as examples that can be used as a base for a HAPI FHIR Plain Server project. These examples can be used as a guide by examining them or copying relevant bits into your oown project, or they can be used to bootstrap a new project by copying the entire project contents and modifying directly.
|
||||
Two starter projects are maintained as examples that can be used as a base for a HAPI FHIR Plain Server project. These examples can be used as a guide by examining them or copying relevant bits into your own project, or they can be used to bootstrap a new project by copying the entire project contents and modifying directly.
|
||||
|
||||
* **[hapi-fhirstarters-rest-server-skeleton](https://github.com/FirelyTeam/fhirstarters/tree/master/java/hapi-fhirstarters-rest-server-skeleton/)** – This project is a basic skeleton showing the minimal components necessary in order to get started with HAPI FHIR Plain Server.
|
||||
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ In your own class extending this class, you can override the [`getServerConforma
|
|||
|
||||
# Controlling Response Contents / Encoding / Formatting
|
||||
|
||||
FHIR allows for the a number of special behaviours where only certain portions of resources are returned, instead of the entire resource body. These behaviours are automatically supported in HAPI FHIR Plain Server and no additional effort needs to be taken.
|
||||
FHIR allows for a number of special behaviours where only certain portions of resources are returned, instead of the entire resource body. These behaviours are automatically supported in HAPI FHIR Plain Server and no additional effort needs to be taken.
|
||||
|
||||
The following behaviours are automatically supported by the HAPI server:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Paging Responses
|
||||
|
||||
The **Search** and **History** operations both return a bundle which contain zero or more resources. FHIR RESTful servers may optionaly support paging responses, meaning that (for example) if a search returns 500 resources, the server can return a bundle containing only the first 20 and a link which will return the next 20, etc.
|
||||
The **Search** and **History** operations both return a bundle which contain zero or more resources. FHIR RESTful servers may optionally support paging responses, meaning that (for example) if a search returns 500 resources, the server can return a bundle containing only the first 20 and a link which will return the next 20, etc.
|
||||
|
||||
By default, RESTful servers will not page, but will rather return all resources immediately in a single bundle. However, you can take advantage of built-in paging functionality to automatically add paging links to generated Bundle resources, and to handle these links by requesting further data.
|
||||
|
||||
There are two complimentary parts to the HAPI FHIR server paging support: paging providers, and bundle providers.
|
||||
There are two complementary parts to the HAPI FHIR server paging support: paging providers, and bundle providers.
|
||||
|
||||
## Paging Providers
|
||||
|
||||
|
|
|
|||
|
|
@ -36,9 +36,9 @@ HAPI provides a class called [RestfulServer](/apidocs/hapi-fhir-server/ca/uhn/fh
|
|||
|
||||
# Plain Providers
|
||||
|
||||
In addition to **Resource Providers**, which are resource-type specific, a second kind of provider known as **Plain Providers**. These providers can be used both to define resource operations that apply to multiple resource types, and to define opoerations that operate at the server level.
|
||||
In addition to **Resource Providers**, which are resource-type specific, a second kind of provider known as **Plain Providers**. These providers can be used both to define resource operations that apply to multiple resource types, and to define operations that operate at the server level.
|
||||
|
||||
## Resource Operatipns
|
||||
## Resource Operations
|
||||
|
||||
Defining one provider per resource is a good strategy to keep code readable and maintainable, but it is also possible to put methods for multiple resource types in a provider class.
|
||||
|
||||
|
|
@ -80,7 +80,7 @@ Within your RESTful operations, you will generally be returning resources or bun
|
|||
|
||||
## Automatic Exception Handling
|
||||
|
||||
By default, HAPI generates appropriate error responses for a several built-in conditions. For example, if the user makes a request for a resource type that does not exist, or tries to perform a search using an invalid parameter, HAPI will automatically generate an `HTTP 400 Invalid Request`, and provide an OperationOutcome resource as response containing details about the error.
|
||||
By default, HAPI generates appropriate error responses for several built-in conditions. For example, if the user makes a request for a resource type that does not exist, or tries to perform a search using an invalid parameter, HAPI will automatically generate an `HTTP 400 Invalid Request`, and provide an OperationOutcome resource as response containing details about the error.
|
||||
|
||||
Similarly, if your method implementation throws any exceptions (checked or unchecked) instead of returning normally, the server will usually (see below) automatically generate an `HTTP 500 Internal Error` and generate an OperationOutcome with details about the exception.
|
||||
|
||||
|
|
@ -88,9 +88,9 @@ Similarly, if your method implementation throws any exceptions (checked or unche
|
|||
|
||||
In many cases, you will want to respond to client requests with a specific HTTP error code (and possibly your own error message too). Sometimes this is a requirement of the FHIR specification. (e.g. the "validate" operation requires a response of `HTTP 422 Unprocessable Entity` if the validation fails).
|
||||
|
||||
Sometimes this is simply a requirement of your specific application (e.g. you want to provide application specific HTTP status codes for certain types of errors), and other times this may be a requirement of the FHIR or HTTP specifications to respond ini a specific way to certani conditions.
|
||||
Sometimes this is simply a requirement of your specific application (e.g. you want to provide application specific HTTP status codes for certain types of errors), and other times this may be a requirement of the FHIR or HTTP specifications to respond in a specific way to certain conditions.
|
||||
|
||||
To customize the error that is returned by HAPI's server methods, you shuld throw an exception which extends HAPI's [BaseServerResponseException](/apidocs/hapi-fhir-server/ca/uhn/fhir/rest/server/exceptions/BaseServerResponseException.html) class. Various exceptions which extend this class will generate a different HTTP status code.
|
||||
To customize the error that is returned by HAPI's server methods, you should throw an exception which extends HAPI's [BaseServerResponseException](/apidocs/hapi-fhir-server/ca/uhn/fhir/rest/server/exceptions/BaseServerResponseException.html) class. Various exceptions which extend this class will generate a different HTTP status code.
|
||||
|
||||
For example, the [ResourceNotFoundException](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/server/exceptions/ResourceNotFoundException.html) causes HAPI to return an `HTTP 404 Resource Not Found`. A complete list of available exceptions is available in the [exceptions package summary](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/server/exceptions/package-summary.html).
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ The following snippet shows how to define a client interface to handle a read me
|
|||
|
||||
# Instance Level - VRead
|
||||
|
||||
The **[vread](http://hl7.org/implement/standards/fhir/http.html#vread)** operation retrieves a specific version of a resource with a given ID. To support vread, simply add "version=true" to your [@Read](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/annotation/Read.html) annotation. This means that the read method will support both "Read" and "VRead". The IdType instance passed into your method may or may not have the version populated depending on the client request.
|
||||
The **[vread](http://hl7.org/implement/standards/fhir/http.html#vread)** operation retrieves a specific version of a resource with a given ID. To support vread, simply add "version=true" to your [@Read](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/annotation/Read.html) annotation. This means that the read method will support both "Read" and "VRead". The IdType instance passed into your method may or may not have the version populated depending on the client's request.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/RestfulPatientResourceProviderMore.java|vread}}
|
||||
|
|
@ -72,7 +72,7 @@ The following snippet shows how the corresponding client interface would look:
|
|||
|
||||
## Conditional Updates
|
||||
|
||||
If you wish to suport conditional updates, you can add a parameter tagged with a [@ConditionalOperationParam](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/annotation/ConditionalOperationParam.html) annotation. If the request URL contains search parameters instead of a resource ID, then this parameter will be populated.
|
||||
If you wish to support conditional updates, you can add a parameter tagged with a [@ConditionalOperationParam](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/annotation/ConditionalOperationParam.html) annotation. If the request URL contains search parameters instead of a resource ID, then this parameter will be populated.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/RestfulPatientResourceProviderMore.java|updateConditional}}
|
||||
|
|
@ -90,7 +90,7 @@ http://fhir.example.com/Patient?identifier=system%7C00001
|
|||
|
||||
If you wish to have access to the raw resource payload as well as the parsed value for any reason, you may also add parameters which have been annotated with the [@ResourceParam](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/annotation/ResourceParam.html) of type `String` (to access the raw resource body) and/or `EncodingEnum` (to determine which encoding was used).
|
||||
|
||||
The following example shows how to use these additonal data elements.
|
||||
The following example shows how to use these additional data elements.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/RestfulPatientResourceProviderMore.java|updateRaw}}
|
||||
|
|
@ -112,7 +112,7 @@ In this type of request, the client adds a header containing `Prefer: return=rep
|
|||
|
||||
## Contention Aware Updating
|
||||
|
||||
As of FHIR DSTU2, FHIR uses the `ETag` header to provide *conention aware updating*. Under this scheme, a client may create a request that contains an ETag specifying the version, and the server will fail if the given version is not the latest version.
|
||||
As of FHIR DSTU2, FHIR uses the `ETag` header to provide *contention aware updating*. Under this scheme, a client may create a request that contains an ETag specifying the version, and the server will fail if the given version is not the latest version.
|
||||
|
||||
Such a request is shown below. In the following example, the update will only be applied if resource "Patient/123" is currently at version "3". Otherwise, it will fail with an `HTTP 409 Conflict` error.
|
||||
|
||||
|
|
@ -238,7 +238,7 @@ The create operation also supports access to the raw payload, using the same sem
|
|||
|
||||
The [search](http://hl7.org/implement/standards/fhir/http.html#search) operation returns a bundle with zero-to-many resources of a given type, matching a given set of parameters.
|
||||
|
||||
Searching is a very powerful and potentially very complicated operation to implemenmt, with many possible parameters and combinations of parameters. See [REST Operations: Search](./rest_operations_search.html) for details on how to create search methods.
|
||||
Searching is a very powerful and potentially very complicated operation to implement, with many possible parameters and combinations of parameters. See [REST Operations: Search](./rest_operations_search.html) for details on how to create search methods.
|
||||
|
||||
|
||||
<a name="type_validate" />
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ The FHIR specification defines a special kind of operations that have an RPC-lik
|
|||
|
||||
A good introduction to this capability can be found on the [Operations Page](http://hl7.org/fhir/operations.html) of the FHIR Specification.
|
||||
|
||||
FHIR operations are a special type of RPC-style invocation you can perform against a FHIR server, type, or resource instance. These invocations are named using the conventon `$name` (i.e. the name is prefixed with $) and will generally take a [Parameters](./apidocs-r4/org/hl7/fhir/r4/model/Parameters.html) resource as input and output. There are some cases where the input and/or output will be a different resource type however.
|
||||
FHIR operations are a special type of RPC-style invocation you can perform against a FHIR server, type, or resource instance. These invocations are named using the convention `$name` (i.e. the name is prefixed with $) and will generally take a [Parameters](./apidocs-r4/org/hl7/fhir/r4/model/Parameters.html) resource as input and output. There are some cases where the input and/or output will be a different resource type however.
|
||||
|
||||
## Providers
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ http://fhir.example.com/Patient/$everything
|
|||
|
||||
# Instance-Level Operations
|
||||
|
||||
To create an instance-specific operation (an operation which takes the ID of a specific resource instance as a part of its request URL), you can add a parameter annotated with the [@IdParam](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/annotation/IdParam.html) annotation, of type [IdType](/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/IdType.html). The following example show how to implement the `Patient/[id]/$everything` operation.
|
||||
To create an instance-specific operation (an operation which takes the ID of a specific resource instance as a part of its request URL), you can add a parameter annotated with the [@IdParam](/apidocs/hapi-fhir-base/ca/uhn/fhir/rest/annotation/IdParam.html) annotation, of type [IdType](/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/IdType.html). The following example shows how to implement the `Patient/[id]/$everything` operation.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/ServerOperations.java|patientInstanceOperation}}
|
||||
|
|
@ -40,7 +40,7 @@ http://fhir.example.com/Patient/123/$everything
|
|||
|
||||
# Server-Level Operations
|
||||
|
||||
Server-level operations do not operate on a specific resource type or instance, but rather operate globally on the server itself. The following example show how to implement the a server-level operation. Note that the `concept` parameter in the example has a cardinality of `0..*`, so a ``List<Coding>` is used as the parameter type.
|
||||
Server-level operations do not operate on a specific resource type or instance, but rather operate globally on the server itself. The following example shows how to implement a server-level operation. Note that the `concept` parameter in the example has a cardinality of `0..*`, so a ``List<Coding>` is used as the parameter type.
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/ServerOperations.java|serverOperation}}
|
||||
|
|
@ -86,7 +86,7 @@ In all of the Operation examples above, the return type specified for the operat
|
|||
|
||||
The FHIR specification allows for operations to be invoked using an HTTP GET instead of an HTTP POST **only** if the following two conditions are met:
|
||||
|
||||
* All parameters have primtive datatype values
|
||||
* All parameters have primitive datatype values
|
||||
|
||||
* The operation is marked as "affectsState = false". Note that early releases of the FHIR specification referred to an operation that did not affect state as "idempotent = true". It was subsequently determined that *idempotency* was the wrong term for the concept being expressed, but the term does persist in some HAPI FHIR documentation and code.
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ http://fhir.example.com/Patient?identifier=urn:foo|7000135
|
|||
|
||||
# Search Parameters: Date (Simple)
|
||||
|
||||
The FHIR specification provides a sytax for specifying dates+times (but for simplicity we will just say dates here) as search criteria.
|
||||
The FHIR specification provides a syntax for specifying dates+times (but for simplicity we will just say dates here) as search criteria.
|
||||
|
||||
Dates may be optionally prefixed with a qualifier. For example, the string `=ge2011-01-02` means any date on or after 2011-01-02.
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ Example URL to invoke this method:
|
|||
http://fhir.example.com/Observation?birthdate=gt2011-01-02
|
||||
```
|
||||
|
||||
Invoking a client of thie type involves the following syntax:
|
||||
Invoking a client of this type involves the following syntax:
|
||||
|
||||
```java
|
||||
{{snippet:classpath:/ca/uhn/hapi/fhir/docs/RestfulPatientResourceProviderMore.java|dateClient}}
|
||||
|
|
@ -148,7 +148,7 @@ http://fhir.example.com/DiagnosticReport?subject.family=SMITH
|
|||
|
||||
What this query says is "fetch me all of the DiagnosticReport resources where the **subject** (Patient) of the report has the **family** (name) of 'SMITH'".
|
||||
|
||||
There are two ways of dealing with chained parameters in your methods: static chains and dynamic chains. Both are equally valid, although dyamic chains might lead to somewhat more compact and readable code.
|
||||
There are two ways of dealing with chained parameters in your methods: static chains and dynamic chains. Both are equally valid, although dynamic chains might lead to somewhat more compact and readable code.
|
||||
|
||||
<a name="dynamic_chains"/>
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ In this mode, you write code that handles resource storage and retrieval logic,
|
|||
* Parsing / Serialization
|
||||
* FHIR REST semantics
|
||||
|
||||
This module was originally created at [University Health Network](https://uhn.ca) (UHN) as a mechanism for placing a common FHIR layer on top of a series of existing data sources, including an EMR, an enterprise patient scheduling system, and a series of clinical data repositories. All of these systems existed long before FHIR was adoped at UHN and HAPI FHIR was created to make the process of adoping FHIR easier.
|
||||
This module was originally created at [University Health Network](https://uhn.ca) (UHN) as a mechanism for placing a common FHIR layer on top of a series of existing data sources, including an EMR, an enterprise patient scheduling system, and a series of clinical data repositories. All of these systems existed long before FHIR was adopted at UHN and HAPI FHIR was created to make the process of adopting FHIR easier.
|
||||
|
||||
This module has been used by many organizations to successfully create FHIR servers in a variety of use cases, including:
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ When you have downloaded the archive (either ZIP or tar.bz2), expand it into a d
|
|||
|
||||
You can now try the tool out by executing the following command: `hapi-fhir-cli`
|
||||
|
||||
This command should show a help screen, as shown in the screeenshot below.
|
||||
This command should show a help screen, as shown in the screenshot below.
|
||||
|
||||
<img src="/hapi-fhir/docs/images/hapi-fhir-cli.png" alt="Basic screen shot" style="margin-left: 40px;"/>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue