Searching: http://spark.furore.com/fhir/_snapshot?id=2a9c339f-f836-4565-b967-318eb5a3bbc4&start=0
From RowNum: 0
id: 2a9c339f-f836-4565-b967-318eb5a3bbc4 (excluded)
start: 0
First Link: http://spark.furore.com/fhir/_snapshot?id=2a9c339f-f836-4565-b967-318eb5a3bbc4&start=0
Last Link: http://spark.furore.com/fhir/_snapshot?id=2a9c339f-f836-4565-b967-318eb5a3bbc4&start=0
Type: Searchset, 18 of 18
OperationDefinition/Composition-document/_history/spark1 Modified: 9/29/2017 5:40:20 AM +00:00

Generate a Document

OPERATION: Generate a Document

A client can ask a server to generate a fully bundled document from a composition resource. The server takes the composition resource, locates all the referenced resources and other additional resources as configured or requested and either returns a full document bundle, or returns an error. Note that since this is a search operation, the document bundle is wrapped inside the search bundle. If some of the resources are located on other servers, it is at the discretion of the server whether to retrieve them or return an error. If the correct version of the document that would be generated already exists, then the server can return the existing one.

URL: [base]/Composition/$document

Parameters

Use Name Cardinality Type Binding Documentation
IN persist 0..1 boolean

Whether to store the document at the binary end-point (/Binary) or not once it is generated. Value = true or false (default is for the server to decide)

Note: this operation definition does not resolve the question how document signatures are created. This is an open issue during the period of trial use, and feedback is requested regarding this question

OperationDefinition/ConceptMap-closure/_history/spark2 Modified: 9/29/2017 5:40:20 AM +00:00

Closure Table Maintenance

OPERATION: Closure Table Maintenance

This operation provides support for ongoing maintenance of a client-side closure table based on server-side terminological logic. For details of how this is used, see Maintaining a Closure Table

URL: [base]/$closure

Parameters

Use Name Cardinality Type Binding Documentation
IN name 1..1 string

The name that defines the particular context for the subsumption based closure table

IN concept 0..* Coding

Concepts to add to the closure table

IN version 0..1 id

A request to resynchronise - request to send all new entries since the nominated version was sent by the server

OUT return 1..1 ConceptMap

A list of new entries (code / system --> code/system) that the client should add to its closure table. The only kind of entry mapping equivalences that can be returned are equal, narrower, wider, and unmatched

OperationDefinition/ConceptMap-translate/_history/spark3 Modified: 9/29/2017 5:40:20 AM +00:00

Concept Translation

OPERATION: Concept Translation

Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server. || One (and only one) of the in parameters (code, coding, codeableConcept) must be provided, to identify the code that is to be translated. || The operation returns a set of parameters including a 'result' for whether there is an acceptable match, and a list of possible matches. Note that the list of matches may include notes of codes for which mapping is specifically excluded, so implementers have to check the match.equivalence for each match

URL: [base]/ConceptMap/$translate

URL: [base]/ConceptMap/[id]/$translate

Parameters

Use Name Cardinality Type Binding Documentation
IN code 0..1 code

The code that is to be translated. If a code is provided, a system must be provided

IN system 0..1 uri

The system for the code that is to be translated

IN version 0..1 string

The version of the system, if one was provided in the source data

IN valueSet 0..1 uri

Identifies the value set used when the concept (system/code pair) was chosen. May be a logical id, or an absolute or relative location

IN coding 0..1 Coding

A coding to translate

IN codeableConcept 0..1 CodeableConcept

A full codeableConcept to validate. The server can translate any of the coding values (e.g. existing translations) as it chooses

IN target 1..1 uri

Identifies the value set in which a translation is sought. May be a logical id, or an absolute or relative location

IN dependency 0..*

Another element that may help produce the correct mapping

IN dependency.element 0..1 uri

The element for this dependency

IN dependency.concept 0..1 CodeableConcept

The value for this dependency

OUT result 1..1 boolean

True if the concept could be translated successfully. The value can only be true if at least one returned match has an equivalence which is not unmatched or disjoint

OUT message 0..1 string

Error details, for display to a human. If this is provided when result = true, the message carries hints and warnings (e.g. a note that the matches could be improved by providing additional detail)

OUT match 0..*

A concept in the target value set with an equivalence. Note that there may be multiple matches of equal or differing equivalence, and the matches may include equivalence values that mean that there is no match

OUT match.equivalence 0..1 code

A code indicating the equivalence of the translation, using values from [ConceptMapEquivalence]{concept-map-equivalence.html}

OUT match.concept 0..1 Coding

The translation outcome. Note that this would never have userSelected = true, since the process of translations implies that the user is not selecting the code (and only the client could know differently)

OUT match.product 0..*

Another element that is the product of this mapping

OUT match.product.element 0..1 uri

The element for this product

OUT match.product.concept 0..1 Coding

The value for this product

OperationDefinition/Encounter-everything/_history/spark4 Modified: 9/29/2017 5:40:20 AM +00:00

Fetch Encounter Record

OPERATION: Fetch Encounter Record

This operation is used to return all the information related to an encounter described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display). The server SHOULD return all resources that it has that are in the encounter compartment for the identified encounter, and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see DAF for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)

Parameters

Use Name Cardinality Type Binding Documentation
OUT return 1..1 Bundle

The bundle type is "searchset"

The key differences between this operation and simply searching the encounter compartment are: * unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) * the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones)

OperationDefinition/List-find/_history/spark5 Modified: 9/29/2017 5:40:20 AM +00:00

Find a functional list

OPERATION: Find a functional list

This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at Current Resource Lists. Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)

URL: [base]/List/$find

Parameters

Use Name Cardinality Type Binding Documentation
IN patient 1..1 id

The id of a patient resource located on the server on which this operation is executed

IN name 1..1 code

The code for the functional list that is being found

Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly

OperationDefinition/MessageHeader-process-message/_history/spark6 Modified: 9/29/2017 5:40:20 AM +00:00

Process Message

OPERATION: Process Message

This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages. This operation is described in detail on the messaging page

URL: [base]/$process-message

Parameters

Use Name Cardinality Type Binding Documentation
IN content 1..1 Bundle

The message to process (or, if using asynchronous messaging, it may be a response message to accept)

IN async 0..1 boolean

If 'true' the message is processed using the asynchronous messaging pattern

IN response-url 0..1 uri

A URL to submit response messages to, if asynchronous messaging is being used, and if the MessageHeader.source.endpoint is not the appropriate place to submit responses

OUT return 0..1 Bundle

A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value

This operation does not use the parameters resource; the parameters "async" and "response-url" always go in the URL, if they are used, and the message parameter is always the body of the HTTP message

OperationDefinition/Patient-everything/_history/spark7 Modified: 9/29/2017 5:40:20 AM +00:00

Fetch Patient Record

OPERATION: Fetch Patient Record

This operation is used to return all the information related to the patient described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource itself is returned, along with any other resources that the server has that are related to the patient, and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their entire record (e.g. "Blue Button"). The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient, and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in DAF. Other applicable implementation guides may make additional rules about how much information that is returned

URL: [base]/Patient/$everything

URL: [base]/Patient/[id]/$everything

Parameters

Use Name Cardinality Type Binding Documentation
IN start 0..1 date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.

IN end 0..1 date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.

OUT return 1..1 Bundle

The bundle type is "searchset"

The key differences between this operation and simply searching the patient compartment are:

  • unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)
  • the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). This frees the client from needing to determine what it could or should ask for

It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.

OperationDefinition/Questionnaire-populate/_history/spark8 Modified: 9/29/2017 5:40:20 AM +00:00

Populate Questionnaire

OPERATION: Populate Questionnaire

Generates a QuestionnaireResponse instance based on a specified Questionnaire, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire. If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a QuestionnaireResponse instance based on the specified Questionnaire and/or an OperationOutcome resource with errors or warnings. The QuestionnaireResponse instance will be populated with an unanswered set of questions following the group and question structure of the specified Questionnaire. If content parameters were specified or the local parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the QuestionnaireResponse with appropriate data is dependent on the questions and/or groups in the Questionnaire having metadata that allows the server to recognize the questions. This might be through Questionnaire.group.question.code, through extensions such as the http://hl7.org/fhir/StructureDefinition/questionnaire-deReference extension or through use of the ConceptMap resource. Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.

URL: [base]/Questionnaire/$populate

URL: [base]/Questionnaire/[id]/$populate

Parameters

Use Name Cardinality Type Binding Documentation
IN identifier 0..1 uri

A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.

IN questionnaire 0..1 Questionnaire

The Questionnaire is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion

IN questionnaireRef 0..1 Reference

The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.

IN subject 1..1 Reference

The resource that is to be the QuestionnaireResponse.subject. The QuestionnaireResponse instance will reference the provided subject. In addition, if the local parameter is set to true, server information about the specified subject will be used to populate the instance.

IN content 0..* Reference

Resources containing information to be used to help populate the QuestionnaireResponse. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers may not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)

IN local 0..1 boolean

If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.

OUT return 1..1 QuestionnaireResponse

The partially (or fully)-populated set of answers for the specified Questionnaire

While it is theoretically possible for a QuestionnaireResponse instance to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. A client SHOULD ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. It will be up to the client to appropriately prune the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.

OperationDefinition/Resource-meta-add/_history/spark9 Modified: 9/29/2017 5:40:20 AM +00:00

Add profiles, tags, and security labels to a resource

OPERATION: Add profiles, tags, and security labels to a resource

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

Parameters

Use Name Cardinality Type Binding Documentation
IN 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 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

OperationDefinition/Resource-meta-delete/_history/spark10 Modified: 9/29/2017 5:40:20 AM +00:00

Delete profiles, tags, and security labels for a resource

OPERATION: Delete profiles, tags, and security labels for a resource

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

Parameters

Use Name Cardinality Type Binding Documentation
IN 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 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

OperationDefinition/Resource-meta/_history/spark11 Modified: 9/29/2017 5:40:20 AM +00:00

Access a list of profiles, tags, and security labels

OPERATION: Access a list of profiles, tags, and security labels

This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:

  • system-wide: a list of all profiles, tags and security labels in use by the system
  • resource-type level: A list of all profiles, tags, and security labels for the resource type
  • individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)

URL: [base]/$meta

URL: [base]/Resource/$meta

URL: [base]/Resource/[id]/$meta

Parameters

Use Name Cardinality Type Binding Documentation
OUT 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

OperationDefinition/Resource-validate/_history/spark12 Modified: 9/29/2017 5:40:20 AM +00:00

Validate a resource

OPERATION: Validate a resource

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:

  • [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules
  • create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints)
  • update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate)
  • delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)

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

URL: [base]/Resource/$validate

URL: [base]/Resource/[id]/$validate

Parameters

Use Name Cardinality Type Binding Documentation
IN resource 0..1 Resource

Must be present unless the mode is "delete"

IN mode 0..1 code http://hl7.org/fhir/ValueSet/resource-validation-mode (Required)

Default is 'no action'; (e.g. general validation)

IN 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 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)

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.

OperationDefinition/StructureDefinition-questionnaire/_history/spark13 Modified: 9/29/2017 5:40:20 AM +00:00

Build Questionnaire

OPERATION: Build Questionnaire

Generates a Questionnaire instance based on a specified StructureDefinition, creating questions for each core element or extension element found in the StructureDefinition. If the operation is not called at the instance level, one of the identifier, profile or url 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a Questionnaire instance based on the specified StructureDefinition and/or an OperationOutcome resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as "must support" will be included. This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support "non-core" resources with minimal development effort.

URL: [base]/StructureDefinition/$questionnaire

URL: [base]/StructureDefinition/[id]/$questionnaire

Parameters

Use Name Cardinality Type Binding Documentation
IN identifier 0..1 uri

A logical profile identifier (i.e. 'StructureDefinition.identifier''). The server must know the profile or be able to retrieve it from other known repositories.

IN profile 0..1 token

The StructureDefinition is provided directly as part of the request. Servers may choose not to accept profiles in this fashion

IN url 0..1 uri

The profile's official URL (i.e. 'StructureDefinition.url'). The server must know the profile or be able to retrieve it from other known repositories.

IN supportedOnly 0..1 boolean

If true, the questionnaire will only include those elements marked as "mustSupport='true'" in the StructureDefinition.

OUT return 1..1 Questionnaire

The questionnaire form generated based on the StructureDefinition.

Open Issue: Ideally, extensions should be populated in the generated Questionnaire that will support taking QuestionnaireResponse resources generated from the Questionnaire and turning them back into the appropriate resources.

OperationDefinition/ValueSet-expand/_history/spark14 Modified: 9/29/2017 5:40:20 AM +00:00

Value Set Expansion

OPERATION: Value Set Expansion

The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. If the operation is not called at the instance level, one of the in parameters identifier, context or valueset must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.

URL: [base]/ValueSet/$expand

URL: [base]/ValueSet/[id]/$expand

Parameters

Use Name Cardinality Type Binding Documentation
IN identifier 0..1 uri

A logical value set identifier (i.e. ValueSet.identifier). The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server

IN valueSet 0..1 ValueSet

The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion

IN context 0..1 uri

The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only useable if the terminology server also has access to the profile registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time

IN filter 0..1 string

A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context

IN profile 0..1 uri

A reference to an external definition that provides additional control information about how the expansion is performed. At this time, there is no agreed format or functionality for the target of this URI. The VSAC Documentation provides one example of the use of this parameter. Implementers using this element will need to agree on an appropriate mechanism for use within their interoperability community. Known uses for profile include: * whether to return the value set content logical definition with the expansion * whether to include inactive concepts

IN date 0..1 dateTime

The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.

IN offset 0..1 integer

Paging support - where to start if a subset is desired (default = 0)

IN count 0..1 integer

Paging support - how many codes should be provided in a partial view. Paging only applies to flat expansions - servers ignore paging if the expansion is not flat. If count = 0, the client is asking how large the expansion is. Servers SHOULD honor this request for hierarchical expansions as well, and simply return the overall count

OUT return 1..1 ValueSet

The result of the expansion

The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used. Clients can work through large flat expansions in a set of pages (partial views of the full expansion) instead of just getting the full expansion in a single exchange by using offset and count parameters. Servers are not obliged to support paging, but if they do, SHALL support both the offset and count parameters. Hierarchical expansions are not subject to paging and servers simply return the entire expansion. Different servers may return different results from expanding a value set for the following reasons: * The underlying code systems are different (e.g. different versions, possibly with different defined behavior) * The server optimizes filter includes differently, such as sorting by code frequency * Servers introduce arbitrary groups to assist a user to navigate the lists based either on extensions in the definition, or additional knowledge available to the server

OperationDefinition/ValueSet-lookup/_history/spark15 Modified: 9/29/2017 5:40:20 AM +00:00

Concept Look Up

OPERATION: Concept Look Up

Given a code/system, or a Coding, get additional details about the concept

URL: [base]/ValueSet/$lookup

Parameters

Use Name Cardinality Type Binding Documentation
IN code 0..1 code

The code that is to be validated. If a code is provided, a system must be provided

IN system 0..1 uri

The system for the code that is to be validated

IN version 0..1 string

The version of the system, if one was provided in the source data

IN coding 0..1 Coding

A coding to look up

IN date 0..1 dateTime

The date for which the information should be returned. Normally, this is the current conditions (which is the default value) but under some circumstances, systems need to acccess this information as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.

OUT name 1..1 string

A display name for the code system

OUT version 0..1 string

The version that these details are based on

OUT display 1..1 string

The preferred display for this concept

OUT abstract 0..1 boolean

Whether this code is an abstract concept

OUT designation 0..*

Additional representations for this concept

OUT designation.language 0..1 code

The language this designation is defined for

OUT designation.use 0..1 Coding

A code that details how this designation would be used

OUT designation.value 1..1 string

The text value for this designation

Note that the $lookup operation is more than just a value set search - the server finds the concept, and gathers the return information from the value set and the underlying code system definitions.

OperationDefinition/ValueSet-validate-code/_history/spark16 Modified: 9/29/2017 5:40:21 AM +00:00

Value Set based Validation

OPERATION: Value Set based Validation

Validate that a coded value is in the set of codes allowed by a value set. If the operation is not called at the instance level, one of the in parameters "identifier" or "valueset" must be provided. One (and only one) of the in parameters (code, coding, codeableConcept) must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code

URL: [base]/ValueSet/$validate-code

URL: [base]/ValueSet/[id]/$validate-code

Parameters

Use Name Cardinality Type Binding Documentation
IN identifier 0..1 uri

A logical value set id (i.e. ValueSet.url). The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server

IN context 0..1 uri

The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only useable if the terminology server also has access to the profile registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time

IN valueSet 0..1 ValueSet

The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server

IN code 0..1 code

The code that is to be validated. If a code is provided, a system must be provided

IN system 0..1 uri

The system for the code that is to be validated

IN version 0..1 string

The version of the system, if one was provided in the source data

IN display 0..1 string

The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name in an extension in the outcome. Whether displays are case sensitive is code system dependent

IN coding 0..1 Coding

A coding to validate

IN codeableConcept 0..1 CodeableConcept

A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present

IN date 0..1 dateTime

The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.

IN abstract 0..1 boolean

if true, then an abstract code is allowed to be used in the context of the code that is being validated. Typically, abstract codes are allowed to be used in value set specifications (e.g. any code that is subsumed by an abstract code). If false (which is the default value), then only concrete codes as defined by the value set are allowed

OUT result 1..1 boolean

True if the concept details supplied are valid

OUT message 0..1 string

Error details, if result = false. If this is provided when result = true, the message carries hints and warnings

OUT display 0..1 string

A valid display for the concept if the system wishes to display this to a user

OperationDefinition/example/_history/spark17 Modified: 9/29/2017 5:40:21 AM +00:00

Generated Narrative with Details

id: example

url: http://h7.org/fhir/OperationDefinition/example

version: B

name: Populate Questionnaire

status: draft

kind: operation

publisher: Acme Healthcare Services

Contacts

- Name Telecom
* System Administrator beep@coyote.acme.com

date: 04/08/2015

description: Limited implementation of the Populate Questionnaire implemenation

code: populate

notes: Only implemented for Labs and Medications so far

base: OperationDefinition/Questionnaire-populate

system: false

type: Questionnaire

instance: true

parameter

name: subject

use: in

min: 1

max: 1

documentation: The resource that is to be the *QuestionnaireResponse.subject*. The [[[QuestionnaireResponse]]] instance will reference the provided subject. In addition, if the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.

type: Reference

parameter

name: return

use: out

min: 1

max: 1

documentation: The partially (or fully)-populated set of answers for the specified Questionnaire

type: QuestionnaireResponse

OperationDefinition/patient-mpi/_history/spark18 Modified: 9/29/2017 5:40:22 AM +00:00

Generated Narrative with Details

id: patient-mpi

url: http://hl7.org/fhir/OperationDefinitino/patient-mpi

name: Patient MPI (Multiple Patient Index) search

status: draft

kind: query

experimental: false

publisher: HL7, Inc

Contacts

- Telecom
* http://hl7.org/fhir

date: 18/08/2015

description: An MPI search differs from a normal search because the parameters are interpreted as inputs to an MPI match process, rather than as direct match criteria on the returned resources

requirements: This query is defined to allow an MPI to be integrated in a FHIR server environment, and to allow a client to delegate the matching process to a specialist. MPI algorithms are often highly tailored to a particular patient set

idempotent: true

code: mpi

notes: All the standard search parameters apply, and are interpreted as inputs to the MPI algorithm. The _sort parameter is not used. Matches are returned in order of highest match to lowest match, with both a % in the score, and an asessement of the match using the extension http://hl7.org/fhir/StructureDefinition/patient-mpi-match

system: false

type: Patient

instance: false

parameter

name: userid

use: in

min: 0

max: 1

documentation: User identity for the MPI to consider when creating a return set. This paraemter is defined in the assumption that the MPI ay be a separate module from other FHIR Servers, with a trust relationship to it. Actualy deployment scenarios will determine whether this parameter is used

type: string

parameter

name: result

use: out

min: 0

max: *

documentation: Patients that match this MPI query

type: Patient