STU 3 Candidate
This page is part of the FHIR Specification (v1.4.0: STU 3 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
. Page versions: R5 R4B R4 R3 R2
This resource has 5 operations associated with it:
| $validate | Validate a resource |
| $meta | Access a list of profiles, tags, and security labels |
| $meta-add | Add profiles, tags, and security labels to a resource |
| $meta-delete | Delete profiles, tags, and security labels for a resource |
| $cds-hook | The CDS Hook operation is the core API request for CDS Hooks |
For more information about operations, including how they are invoked, see Operations.
The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter:
Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an OperationOutcome
Formal Definition (as a OperationDefinition).
URL: [base]/Resource/$validate
URL: [base]/Resource/[id]/$validate
| In Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| resource | 0..1 | Resource | Must be present unless the mode is "delete" | ||
| mode | 0..1 | (code | ResourceValidationMode (Required) | Default is 'no action'; (e.g. general validation) | |
| profile | 0..1 | (uri | If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error | ||
| Out Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| return | 1..1 | OperationOutcome | If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below) Note: as this the only out parameter, it is a resource, and it has the name 'return', the result of this operation is returned directly as a resource | ||
This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.
This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.
Validate a Patient against the DAF patient profile using POST directly. (Request):
POST /open/Patient/$validate?profile=http://hl7.org/fhir/StructureDefinition/daf-patient
[other headers]
<?xml version="1.0" encoding="UTF-8"?>
<Patient xmlns="http://hl7.org/fhir">
<id value="us01"/>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<table>
<tbody>
<tr>
<td>Name</td>
<td>Peter James
<b>Chalmers</b> ("Jim")
</td>
</tr>
<tr>
<td>Address</td>
<td>534 Erewhon, Pleasantville, Orange County, 3999</td>
</tr>
<tr>
<td>Contacts</td>
<td>Home: unknown. Work: (03) 5555 6473</td>
</tr>
<tr>
<td>Id</td>
<td>MRN: 12345 (Acme Healthcare)</td>
</tr>
</tbody>
</table>
</div>
</text>
<extension url="http://hl7.org/fhir/StructureDefinition/us-core-race">
<valueCodeableConcept>
<coding>
<system value="http://hl7.org/fhir/v3/Race"/>
<code value="1096-7"/>
</coding>
</valueCodeableConcept>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/us-core-ethnicity">
<valueCodeableConcept>
<coding>
<system value="http://hl7.org/fhir/v3/Ethnicity"/>
<code value="2162-6"/>
</coding>
</valueCodeableConcept>
</extension>
<active value="true"/>
<!-- Peter James Chalmers, but called "Jim" -->
<name>
<use value="official"/>
<family value="Chalmers"/>
<given value="Peter"/>
<given value="James"/>
</name>
<telecom>
<system value="phone"/>
<value value="(03) 5555 6473"/>
<use value="work"/>
</telecom>
<telecom>
<extension url="http://hl7.org/fhir/StructureDefinition/us-core-direct">
<valueBoolean value="true"/>
</extension>
<system value="email"/>
<value value="person@example.org"/>
<use value="work"/>
</telecom>
<address>
<use value="home"/>
<line value="534 Erewhon St"/>
<city value="PleasantVille"/>
<district value="Orange County"/>
<state value="Vic"/>
<postalCode value="3999"/>
</address>
</Patient>
Validate a proposed patient update - and for this example, using the Parameters syntax (Request):
POST /open/Patient/example/$validate
[other headers]
<Parameters xmlns="http://hl7.org/fhir">
<parameter>
<name value="mode"/>
<valueCode value="update"/>
<parameter>
<parameter>
<name value="mode"/>
<resource>
<?xml version="1.0" encoding="UTF-8"?>
<Patient xmlns="http://hl7.org/fhir">
<id value="example"/>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<table>
<tbody>
<tr>
<td>Name</td>
<td>Peter James
<b>Chalmers</b> ("Jim")
</td>
</tr>
<tr>
<td>Address</td>
<td>534 Erewhon, Pleasantville, Vic, 3999</td>
</tr>
<tr>
<td>Contacts</td>
<td>Home: unknown. Work: (03) 5555 6473</td>
</tr>
<tr>
<td>Id</td>
<td>MRN: 12345 (Acme Healthcare)</td>
</tr>
</tbody>
</table>
</div>
</text>
<!-- MRN assigned by ACME healthcare on 6-May 2001 -->
<identifier>
<use value="usual"/>
<type>
<coding>
<system value="http://hl7.org/fhir/v2/0203"/>
<code value="MR"/>
</coding>
</type>
<system value="urn:oid:1.2.36.146.595.217.0.1"/>
<value value="12345"/>
<period>
<start value="2001-05-06"/>
</period>
<assigner>
<display value="Acme Healthcare"/>
</assigner>
</identifier>
<active value="true"/>
<!-- Peter James Chalmers, but called "Jim" -->
<name>
<use value="official"/>
<family value="Chalmers"/>
<given value="Peter"/>
<given value="James"/>
</name>
<name>
<use value="usual"/>
<given value="Jim"/>
</name>
<telecom>
<use value="home"/>
<!-- home communication details aren't known -->
</telecom>
<telecom>
<system value="phone"/>
<value value="(03) 5555 6473"/>
<use value="work"/>
</telecom>
<!-- use FHIR code system for male / female -->
<gender value="male"/>
<birthDate value="1974-12-25">
<extension url="http://hl7.org/fhir/StructureDefinition/patient-birthTime">
<valueDateTime value="1974-12-25T14:35:45-05:00"/>
</extension>
</birthDate>
<deceasedBoolean value="false"/>
<address>
<use value="home"/>
<type value="both"/>
<line value="534 Erewhon St"/>
<city value="PleasantVille"/>
<district value="Rainbow"/>
<state value="Vic"/>
<postalCode value="3999"/>
<period>
<start value="1974-12-25"/>
</period>
</address>
<contact>
<relationship>
<coding>
<system value="http://hl7.org/fhir/patient-contact-relationship"/>
<code value="partner"/>
</coding>
</relationship>
<name>
<family value="du">
<!-- the "du" part is a family name prefix (VV in iso 21090) -->
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
<valueCode value="VV"/>
</extension>
</family>
<family value="Marché"/>
<given value="Bénédicte"/>
</name>
<telecom>
<system value="phone"/>
<value value="+33 (237) 998327"/>
</telecom>
<gender value="female"/>
<period>
<!-- The contact relationship started in 2012 -->
<start value="2012"/>
</period>
</contact>
<managingOrganization>
<reference value="Organization/1"/>
</managingOrganization>
</Patient>
</resource>
<parameter>
</Parameters>
Returned when the resource is valid (Response):
HTTP/1.1 200 OK
[other headers]
<?xml version="1.0" encoding="UTF-8"?>
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="allok"/>
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>All OK</p>
</div>
</text>
<issue>
<severity value="information"/>
<code value="informational"/>
<details>
<text value="All OK"/>
</details>
</issue>
</OperationOutcome>
Returned when the resource is not valid (Response):
HTTP/1.1 200 OK
[other headers]
<?xml version="1.0" encoding="UTF-8"?>
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="validationfail"/>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Error parsing resource XML (Unknown Content "label" @ /Patient/identifier/label)</p>
</div>
</text>
<issue>
<severity value="error"/>
<code value="structure"/>
<details>
<text value="Error parsing resource XML (Unknown Content "label""/>
</details>
<location value="/f:Patient/f:identifier"/>
</issue>
</OperationOutcome>
This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:
Formal Definition (as a OperationDefinition).
URL: [base]/$meta
URL: [base]/Resource/$meta
URL: [base]/Resource/[id]/$meta
| Out Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| return | 1..1 | Meta | The meta returned by the operation | ||
At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principle use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons
Get all the tags, profiles, and security labels used on patient resources (Request):
GET /fhir/Patient/$meta
All the tags, profiles, and security labels used on patient resources (Response):
HTTP/1.1 200 OK
[other headers]
<Parameters>
<parameter>
<name value="return"/>
<valueMeta>
<profile value="http://hl7.org/fhir/StructureDefinition/daf-patient"/>
<profile value="http://hl7.org/fhir/StructureDefinition/uslab-patient"/>
<security>
<system value="http://hl7.org/fhir/v3/ActCode"/>
<code value="EMP"/>
<display value="employee information sensitivity"/>
</security>
<tag>
<system value="http://example.org/codes/tags"/>
<code value="current"/>
<display value="Current Inpatient"/>
</tag>
</valueMeta>
</parameter>
</Parameters>
This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource. This operation can also be used on historical entries - to update them without creating a different historical version
Formal Definition (as a OperationDefinition).
URL: [base]/Resource/[id]/$meta-add
| In Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| meta | 1..1 | Meta | Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL | ||
| Out Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| return | 1..1 | Meta | Resulting meta for the resource | ||
This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources
Add a 'paper record lost' tag to a resource (Request):
POST /fhir/Patient/example/$meta-add
[Other headers]
<Parameters>
<parameter>
<name value="meta"/>
<valueMeta>
<tag>
<system value="http://example.org/codes/tags"/>
<code value="record-lost"/>
<display value="Patient File Lost"/>
</tag>
</valueMeta>
</parameter>
</Parameters>
All the tags, profiles, and security labels used on patient resources (Response):
HTTP/1.1 200 OK
[other headers]
<Parameters>
<parameter>
<name value="return"/>
<valueMeta>
<profile value="http://hl7.org/fhir/StructureDefinition/daf-patient"/>
<tag>
<system value="http://example.org/codes/tags"/>
<code value="current"/>
<display value="Current Inpatient"/>
</tag>
<tag>
<system value="http://example.org/codes/tags"/>
<code value="record-lost"/>
<display value="Patient File Lost"/>
</tag>
</valueMeta>
</parameter>
</Parameters>
This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource. This operation can also be used on historical entries
Formal Definition (as a OperationDefinition).
URL: [base]/Resource/[id]/$meta-delete
| In Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| meta | 1..1 | Meta | Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL | ||
| Out Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| return | 1..1 | Meta | Resulting meta for the resource | ||
This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources
Remove the 'current patient' tag from a resource (Request):
POST /fhir/Patient/example/$meta-delete
[Other headers]
<Parameters>
<parameter>
<name value="meta"/>
<valueMeta>
<tag>
<system value="http://example.org/codes/tags"/>
<code value="current"/>
<display value="Current Inpatient"/>
</tag>
</valueMeta>
</parameter>
</Parameters>
All the tags, profiles, and security labels used on patient resources (Response):
HTTP/1.1 200 OK
[other headers]
<Parameters>
<parameter>
<name value="return"/>
<valueMeta>
<profile value="http://hl7.org/fhir/StructureDefinition/daf-patient"/>
<tag>
<system value="http://example.org/codes/tags"/>
<code value="record-lost"/>
<display value="Patient File Lost"/>
</tag>
</valueMeta>
</parameter>
</Parameters>
It represents an outbound call from the EHR, in the context of a user session, and in the context of a specific activity within that user sesssion (e.g. opening a patient record; prescribing a new med; or reviewing orders before signing them).
Formal Definition (as a OperationDefinition).
URL: [base]/$cds-hook
| In Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| activity | 1..1 | Coding | Name of the Activity (expressed as a coding, preferably drawn from SMART's activity catalog) that the user is performing in the EHR, and for which this hook was triggered (e.g. patient-view, or medication-prescribe) | ||
| activityInstance | 1..1 | (string | While working in the EHR, a user can perform multiple activities in series or in parallel. For example, a clinician might prescribe two drugs in a row; each prescription activity would be assigned a unique activityInstance. The activity catalog provides a description of what events should initiate and terminate a given activity. This allows an external service to associate requests with activity state, which is necessary to support the following app-centric decision sequence, where the steps are tied together by a common activityInstance: EHR invokes CDS hook CDS service returns app link card User clicks app link and interacts with app Flow returns to EHR, which re-invokes CDS hook CDS service returns decision with user's choice Note: the activityInstance is globally unique and should contain enough entropy to be un-guessable. | ||
| fhirServer | 0..1 | (uri | Base URL for the calling EHR's FHIR server. The scheme should be https | ||
| oauth | 0..1 | Security details allowing the CDS service to connect to the EHR's FHIR server. These fields allow the CDS service to access EHR data in a context limited by the current user's privileges | |||
| oauth.token | 1..1 | (string | is a bearer token to be presented with any API calls the CDS service makes to the EHR, by including it in an Authorization header like: Authorization: Bearer {{token}} | ||
| oauth.scope | 1..1 | (string | Represents the set of scopes assigned to this token (see SMART on FHIR scopes) | ||
| oauth.expires | 1..1 | (integer | Expresses the token lifetime as an integer number of seconds | ||
| redirect | 1..1 | (uri | This field is only used by services that will return an app link card: when a user clicks the card's link to launch an app, it becomes the app's job to send the user to this redirect URL upon completion of user interaction. (Design note: this field is supplied up-front, as part of the initial request, to avoid requiring the EHR to append any content to app launch links. This helps support an important "degenerate" use case for app link cards: pointing to static content. See below for details.) | ||
| user | 0..1 | (string | |||
| patient | 0..1 | (id | The FHIR resource id of the current patient. For example, 123. | ||
| encounter | 0..1 | (id | The FHIR resource id of the current encounter. For example, 123 | ||
| context | 0..* | Any | activity-specific contextual data (see Activity) that an external service needs. (For exampe, with the order-review activity this will include MedicationOrder and Diagnostic resources, among others) | ||
| preFetchData | 0..1 | Bundle | as a performance tweak, the EHR may pass along data according to the service's Prefetch-Template. This helps provide the service with all the data it needs to efficiently compute a set of recommendations. (Note that in the absence of preFetchData, an external service can always execute FHIR REST API calls against the EHR server to obtain additional data ad-hoc.) | ||
| card | 1..1 | one CDS result for the EHR to present to the user. Cards can provide a combination of information (for reading), suggested actions (to be applied if a user selects them), and links (to launch an app if the user selects them). The EHR decides how to display cards, but we recommend displaying suggestions using buttons, and links using underlined text. | |||
| card.summary | 1..1 | (string | one-sentence, <140-character summary message for display to the user inside of this card. | ||
| card.detail | 0..1 | (string | optional detailed information to display, represented in Markdown. (For non-urgent cards, the EHR may hide these details until the user clicks a link like "view more details...".) | ||
| card.indicator | 1..1 | (code | Urgency/importance of what this card conveys. Allowed values, in order of increasing urgency, are: success, info, warning, hard-stop. The EHR can use this field to help make UI display decisions such as sort order or coloring. The value hard-stop indicates that the workflow should not be allowed to proceed.R[-12]C | ||
| card.source | 1..1 | grouping structure for a short, human-readable description (in source.label) of the source of the information displayed on this card, with an optional link (in source.url) where the user can learn more about the organization or data set that provided the information on this card. Note that source.url should not be used to supply a context-specific "drill-down" view of the information on this card. For that, use link.url instead. | |||
| card.source.label | 1..1 | (string | human-readable description (in source.label) of the source of the information displayed on this card | ||
| card.source.url | 0..1 | (uri | Link (in source.url) where the user can learn more about the organization or data set that provided the information on this card | ||
| card.suggestion | 0..* | grouping structure for suggestion cards, which allow a service to suggest a set of changes in the context of the current activity (e.g. changing the dose of the medication currently being prescribed, for the medication-prescribe activity) | |||
| card.suggestion.label | 0..1 | (string | human-readable label to display for this suggestion (e.g. the EHR might render this as the text on a button tied to this suggestion). | ||
| card.suggestion.create | 0..* | Resource | new resource(s) that this suggestion applies within the current activity (e.g. for medication-prescribe, this holds the updated prescription as proposed by the suggestion). | ||
| card.suggestion.delete | 0..* | (id | id(s) of any resources to remove from the current activity (e.g. for the order-review activity, this would provide a way to remove orders from the pending list). In activities like medication-prescribe where only one "content" resource is ever relevant, this field may be omitted | ||
| card.link | 0..* | grouping structure for a link to an app that the user might want to run for additional information or to help guide a decision | |||
| card.link.label | 0..1 | (string | human-readable label to display for this link (e.g. the EHR might render this as the underlined text of a clickable link) | ||
| card.link.url | 0..1 | (uri | URL to load when a user clicks on this link. Note that this may be a "deep link" with context embedded in path segments, query parameters, or a hash. In general this URL should embed enough context for the app to determine the activityInstance, and redirect url upon downstream launch, because the EHR will simply use this url as-is, without appending any parameters at launch time. | ||
| Out Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| decision | 0..* | grouping structure representing a decision to be applied directly to the user session. Note that a CDS service may only return a decision after interacting with the user through an app link. Decisions are designed to convey any choices the user made in an app session | |||
| decision.create | 0..* | Resource | new resource(s) that the EHR should create within the current activity (e.g. for medication-prescribe, this would be the updated prescription that a user had authored in an app session). | ||
| decision.delete | 0..* | (id | id(s) of any resources to remove from the current activity (e.g. for the order-review activity, this would provide a way to remove orders from the pending list). In activities like medication-prescribe where only one "content" resource is ever relevant, this field may be omitted | ||
© HL7.org 2011+. FHIR STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:07+1100. QA Page
Links: Search |
Version History |
Table of Contents |
Compare to DSTU2 |
|
Propose a change