This page is part of the Continuous Integration Build of FHIR Specification (v4.0.1: R4 - Mixed Normative and STU ) in it's permanent home (it will always (will be available incorrect/inconsistent at this URL). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see times).
See the Directory of published versions . Page versions: R4B R4 R3

Using Codes Code Systems Value Sets Concept Maps Identifier Systems

4.3.14.66 7.11 Code System http://terminology.hl7.org/CodeSystem/payment-adjustment-reason Variations between Submitted data and Retrieved data

Financial Management   Maturity Level : 1 Use Context : Any

Responsible Owner: FHIR Infrastructure Work Group

Draft Standards Status : Informative

This is Some of the time when using a code FHIR interface, requests to create or update resource instances will behave exactly as the initiator requested. The desired record(s) will be created or revised within the target system defined by and a subsequent query of the data would show the exact same information as was submitted. However, FHIR project. Summary systems are not guaranteed to behave this way. Without any other agreement between exchange partners, FHIR systems are not obligated to store and return data as it was received. In fact, for some interoperability paradigms, they're not obligated to store any data at all. This page discusses some of the considerations around system behavior, including differences in expectations for systems interoperating using REST, messaging, documents and services.

Defining URL: http://terminology.hl7.org/CodeSystem/payment-adjustment-reason Version: 4.0.1 Name: PaymentAdjustmentReasonCodes

7.11.1 Data element support Title:

This value The most common reason for differences between what data is submitted to a system and what data can be extracted from it is that the system doesn't support all of the data elements present in the instance received. In the base resource, no systems are required to support any particular set includes smattering of Payment Adjustment Reason codes. extensions or even any particular subset of core elements.

Committee: Financial Management

For elements that are part of the resource, the expectation is that "most" systems will support the element. i.e., most systems will support capturing a patient's name, gender and date of birth. But "most" does not mean "all". It is possible to be fully FHIR conformant and claim to support the Patient resource, but be incapable of storing any of those data elements. There are use-cases where names may be unnecessary (e.g., agricultural veterinary systems, anonymized reporting, etc.) and similar use-cases for almost every data element. No FHIR resource elements start off as mustSupport Work Group OID: 2.16.840.1.113883.4.642.4.1173 (for OID based terminology systems) Copyright: and very few resource elements start off with a minimum cardinality other than "0".

This In the case of extensions, the very nature of a concept being an extension means that the designers of the specification expected that fewer than "most" systems would support the element, though support might vary widely by context. An extension might be used by 100% of systems in some country, discipline, etc. and not used by any systems in another context. In any event, there is no guarantee that an example set. arbitrary receiver will recognize and be able to persist any given extension.

Source Resource XML

In order to know whether a particular data element is likely to be stored by a given server, a client should check the Capability statement / JSON of that server. If, for a given resource, the StructureDefinition This Code system pointed to indicates that the element or extension is used "mustSupport=true", and the server is capable of storing and returning data in general, then it would be expected that the following value sets: system will be capable of storing and returning that data element. (Some servers such as decision support systems might not be capable of storing or returning any received data.)

ValueSet: Payment Adjustment Reason Codes (This value set includes smattering

All of Payment Adjustment Reason codes.) ValueSet: Payment Adjustment Reason Codes these concerns around possibly not storing resource elements or extensions can hold whether the data is sent using REST , Messaging (This value set includes smattering or Services . However, with documents , a consuming system is expected to accept the entire contents of Payment Adjustment Reason codes.) the document without losing any information or altering it in any way.

4.3.14.66.1 7.11.2 Content System behavior 4.3.14.66.2

Even if a system supports all of the data elements provided, not all systems will actually persist the data received or be capable of returning it in response to a query. mustSupport indicates that a system supports an element but does not prescribe exactly what the system must do with supported elements. Data might be persisted, displayed, relayed, analyzed, tabulated or used in a variety of other fashions. The behavior of a given system should be unsurprising given its context, but it is still important to recognize that not all systems will persist the data they receive.

7.11.3 Payment Adjustment Reason Codes Access permissions

This value set includes smattering Even if a system stores a given data element, that does not mean it will always include that element when responding to queries. Systems will have access permission rules that restrict who can see a given resource instance and, occasionally, who can see a particular data element within a resource. Systems responding to queries might suppress records or may adjust the content of Payment Adjustment Reason codes. resource instances to exclude data elements the querying system is not permitted to see.

7.11.4 Generated and inferred data Copyright Statement:

This Some servers may add additional data elements (or more commonly, extensions) based on information they have generated or inferred from data in the resource, from other resources or other information of which the server is aware. i.e., an example set. This code system http://terminology.hl7.org/CodeSystem/payment-adjustment-reason defines instance queried after being created or updated might have more information present than was included on the following codes: originally submitted record

Code Display Definition a001

7.11.5 Data integration Prior Payment Reversal a002 Prior Overpayment Prior Overpayment  

See the full Servers receiving updates from multiple sources may choose to be selective about what sources they choose to trust for updates to certain information. For example, a patient registry system might choose to only allow updates to name, gender and date of code birth from administrative systems but not clinical systems. If a system filters out patient address information from being disclosed to a system when it queries, it will likely choose to not replace or eliminate the addresses it has on file when it receives an update from that system.

One approach commonly followed by HL7 version 2 messaging interfaces is to not update any elements not included in an instance. For example, if a Patient instance were received with no telecom or contact information, all existing telecom and contact information would be retained and only those elements included in the instance would be updated. Technically, this same approach can be followed with FHIR, however it would be atypical and unexpected. Also, unlike HL7 V2 , FHIR does not have a defined as part of FHIR. construct to use to indicate that a particular data element should explicitly be set to empty if processing a PUT in a mode where omitted elements are typically retained. Systems wishing to fully emulate HL7 V2 behavior will need to use an extension to mirror this behavior.

Explanation One of the columns types of changes that may appear can occur when a resource is created or updated is 'de-containing' a resource - i.e., taking a reference to a contained resource and turning it into a reference to a distinct resource based on pre-existing server information. Typically, this page: Level A few code lists can occur when the server has access to business logic - specifically, statements about uniqueness that FHIR defines are hierarchical can be verified against some repository - each code that the client does not. However care should always be taken that the re-identification that occurs is assigned a level. See Code System reliable between invocations so that 'de-containment' is consistent.

for further information.

7.11.6 Ramifications of storage/retrieval variations Source

While changing data prior to storage or prior to returning query results is possible, it should not be considered "normal" behavior. It creates several challenges:

• Digital signatures will no longer be valid. Any change to submitted data will break standard signatures. In theory, this could be mitigated by using a custom canonicalization for the signature that excludes malleable elements. However, this would require both sender and receiver to agree on the alternate signature canonicalization. The code (used as signature would still be considered invalid by systems that were not party to the code in agreement.
• Workflows can be made more complex. A system that sends a create and then sends an update presuming that it has seen the most "current" version, could accidentally overwrite information set by the server as part of the create process.
• Audit becomes more complicated. The AuditEvent resource instance). points to a specific resource version when tracking what data was returned by a query. If the code record is in italics, this indicates that the code modified when it is not selectable ('Abstract') Display The display (used in returned, then the display element audit record will likely need to be supplemented with information about what elements were filtered.
• Multiple views of the same information by different people (or even by the same people in different contexts) may cause confusion, particularly when attempting to coordinate care across a Coding ). team. Providing OperationOutcome instances containing warnings if information has been suppressed may be helpful, though doing this might not be possible, depending on security policy rules.
• If there data is no display, implementers should not simply display the code, but map lost as part of the concept into their application transmission process, then multiple stages of transmission (or even round-tripping of data) could result in significant degradation as information passes through multiple systems.

7.11.7 Mitigation approaches for storage/retrieval variations Definition

FHIR does provide a couple of mechanisms that can help with the meaning issue of a system that has received only partial data overwriting data that was filtered from its record:

• For systems that enforce the concept Comments use of ETags Additional notes about , the server SHOULD either echo back a copy of what was stored and include an ETag or not return an ETag because what was stored is not the same as what was submitted and the client can't know what the current record looks like, thus preventing a subsequent unsafe update.
• It is at the server's discretion whether or not to accept an UPDATE or CREATE request that is tagged as SUBSETTED , and, if so, how to use process such a request. It is important that the code server implementation considers how to avoid accidental loss of data to which the updating client did not have access, and also to consider the possibility that a client update might invalidate data the client was unaware of.

Note that using either of the above mechanisms may constitute a security breach in circumstances where the individual or system accessing the data should not know that the record being reviewed has been modified in any way. (The presence of digital signatures would present a similar issue.)