Comments (4)
@jlamy please provide comment and perspective.
from iti.mhd.
Ok, there are a few separate issues.
First, you are right that the MHD Document Recipient canβt undo the XDS transaction, so what did get persisted needs to be returned. Further, there doesn't seem to be a clear way that the MHD Document Recipient could advertise that Lists or DocumentReference.relatesTo must not be passed.
Second, note that this problem can also happen if the MHD Document Recipient is grouped with an XDR Document Source or an XCDR Initiating Gateway. They don't have to persist anything.
So if we were to adopt a strict reading of FHIR transactions, we could:
- Tightly constrain MHD/XDStar groupings to only allow full-featured XDS
- Switch ITI-65 from transaction to batch (or to an operation or a message), and add our own almost-transaction semantics
But let's look at FHIR transactions. Yes, they are all or nothing, but see: Variations between Submitted data and Retrieved data. There's enough wiggle room here to allow submitted elements within resources and even entire resources to not be saved intentionally: "In fact, for some interoperability paradigms, they're not obligated to store any data at all". So the transaction semantics might be more appropriately described as "If all the resources the server chooses to process can be processed, then the transaction succeeds."
So I agree that the "Partial..." warnings should be ok to return. However, we need more specificity in how to do so:
- For an intentionally unsaved document relationship, I suggest we return the warning only in the entry for the source DocumentReference. Reason: the relatesTo is only in the source DocumentReference, and further, the target DocumentReference may not even be in the same submission.
- For an intentionally unsaved resource (List or DocumentReference), this case is not described at all in base FHIR. Ideally we could get guidance from FHIR-I, but until we do, here's what we are doing in eHealth Exchange:
- it SHALL Return a Bundle.entry.response.status of 204 (No Content) to indicate the Resource has been processed successfully but has no resource identity,
- it SHALL omit the .location and .etag elements in the Bundle.entry.response.
from iti.mhd.
Is there any examples of what this request and response would look like? I would like to get these so that I can understand better, document it better, and have examples for readers. I think examples, even theoretical and possibly wrong, examples would help move this along.
from iti.mhd.
Current assessment: This is not enough of a violation of "Transaction" to be considered non-compliant. Moving to an Operation is not seen as necessary. This because this is defined behaviors for MHD ITI-65 transaction.
change to a closed issue
from iti.mhd.
Related Issues (20)
- publisher bug with exampleBoolean HOT 2
- patient and patient.identifier HOT 1
- testPlan - which search parameters should be tested in combinations
- new sushi and build need slice names rather than indexes
- ITI-65 from Document Source with no EntryUUID
- ITI-65 structureDefinitions should forbid entryUUID HOT 8
- what version should the improvements be? HOT 1
- Please consider allowing replace-logic in ITI-105 HOT 1
- build validation warnings HOT 2
- The Document Source Can Use ITI-65, ITI-105, or ITI-106 HOT 4
- Definition in provide document bundle StructureDefinitions HOT 1
- Signed documents and canonical JSON/XML with other document sharing profiles HOT 1
- FHIR documents in simplified publish (ITI-105) HOT 2
- ITI-64 FHIR documents Publish Option Named With Wrong Transaction HOT 1
- replaceTo is not appropriate for MHD HOT 4
- Redirects in ITI-105 HOT 3
- Can a Document Source Indicate if the Document Should Be Persisted In ITI-106? HOT 1
- MHD_068: Use of PATCH by Document Source to support DocumentReference replace
- cleanup CapabililtyStatement IG build rendering
- Indicate how to write comment on the home page of the guide HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iti.mhd.