Stream: argonaut
Topic: Writes, must support, and references?
Drew Torres (Jun 22 2020 at 19:13):
I have been digging into US-Core heavily recently. Did others know that US-Core requires support for writing DocumentReferences and DiagnosticReports? How are others treating this requirement? In addition to that thought, how are you treating must support elements for those resources? For example, DocumentReference has MustSupport for encounter. Did you think that requires to support encounter writes? Encounter has MustSupport for Location, did you expect to support writes for Locations? How far down the rabbit hole are others going?
Drew Torres (Jun 22 2020 at 19:14):
In general, if a server also supports writes, how should the server deal with MustSupport elements on writes?
Vassil Peytchev (Jun 22 2020 at 19:24):
In the case of DocumentReference -> Must support encounter, I believe the must-support stops at supporting the reference. It does not mean that the server must support writes for Encounter. I suspect there are many different ways for implementers to handle the recording of the reference...
Drew Torres (Jun 22 2020 at 19:29):
Well I am sure you are in a similar position we are in where organization type security for behavioral health comes into play especially with notes. Not properly recording the encounter reference and supporting resources would be dangerous.
Vassil Peytchev (Jun 22 2020 at 19:38):
Yes, recording the reference is important, and may require additional processing. My point was that this additional processing is not the same as requiring write for the Encounter resource.
Jenni Syed (Jun 22 2020 at 20:39):
@Brett Marquard @Eric Haas I thought we got rid of/clarified that no writes were required for USCDI exchange compliance but I'm not finding that verbiage in the conformance section or general guidance
Brett Marquard (Jun 22 2020 at 20:40):
no writes? I thought DocumentReference and DiagnosticReport for notes always had writes
Brett Marquard (Jun 22 2020 at 20:41):
I don't think we talked about writing the refernced resoruce.
Jenni Syed (Jun 22 2020 at 20:56):
To meet USCDI (read only) requirements?
Jenni Syed (Jun 22 2020 at 20:57):
for Patient access??
Jenni Syed (Jun 22 2020 at 20:57):
I don't think it was our intent to require that support for USCDI
Jenni Syed (Jun 22 2020 at 21:00):
And I don't think anyone has tested writes by a patient (not sure how much writes for notes by provider were tested, but I don't think diagnosticreport writes were)
Eric Haas (Jun 22 2020 at 21:15):
here is where we talk about writes : http://hl7.org/fhir/us/core/future-of-us-core.html#future-candidate-requirements-under-considerations
Eric Haas (Jun 22 2020 at 21:17):
The only place describing write is for Clinical Notes.
Brett Marquard (Jun 23 2020 at 12:52):
@Dennis Patterson had the pleasure of discussing writes in Koln, we added the functionality to discover supported read/write types as a result of that conversation: http://hl7.org/fhir/us/core/clinical-notes-guidance.html#discovering-note-and-report-types
Brett Marquard (Jun 23 2020 at 12:56):
This isn't to say he was endorsing us supporting writes :)
Dennis Patterson (Jun 23 2020 at 15:31):
my memory of that discussion was purely around the fact that some DocumentReference writes have one type inbound and a different type outbound, and how that could be represented/discovered, just as that specific section makes mention. Not around what's required in USCDI :)
Grahame Grieve (Jun 23 2020 at 22:02):
@Drew Torres my take on must-support here would be that if you must-support a reference on an inbound resource, then you must check it, and if it does not exist, then you must either allow it be to created, or to be a broken reference, or, if you don't accept broken references - which an EHR should not - then reject the POST/PUT. you can't simply ignore it
Drew Torres (Jun 23 2020 at 22:05):
That is my take as well. That is why I asked about the implications around regulation and the relation to US-Core and must support elements. It feels wrong to declare that we support a must-support element, but except when writing.... That seems wrong. I have reached out to regulators to ensure they fully understand the implication of some of the must support elements.
Grahame Grieve (Jun 23 2020 at 22:08):
the US core statements around must-support are all geared towards read-only usage, so it would be good for a future version to clarify the expectations. But the underlying intention in the spec is that if an element is labelled must-support, you can't claim that you didn't know an element, and there was some subsequent safety issue that arose later
Grahame Grieve (Jun 23 2020 at 22:09):
the spec specifically says that you can support an element by rejecting certain values for it
Eric Haas (Jun 24 2020 at 15:16):
Grahame Grieve said:
the spec specifically says that you can support an element by rejecting certain values for it
Where is that?
Drew Torres (Jun 24 2020 at 17:41):
It is buried in the create section that says server can implement their own business logic on writes.
Drew Torres (Jun 24 2020 at 17:42):
http://hl7.org/fhir/http.html#create
Drew Torres (Jun 24 2020 at 17:43):
http://hl7.org/fhir/updates.html#7.14
Drew Torres (Jun 24 2020 at 17:44):
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.
Drew Torres (Jun 24 2020 at 17:49):
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 of that server. If, for a given resource, the StructureDefinition pointed to indicates that the element or extension is "mustSupport=true", and the server is capable of storing and returning data in general, then it would be expected that the 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.)
Cooper Thompson (Aug 04 2020 at 15:37):
Regarding the bit what is required from US Core CapabilityStatement for ONC Cures certification, I interpret the (g)(10)(i)(A) requirement as starting with the base of US Core Server CapabilityStatement, but then filtering that down only what is specified in 170.213 (USCDI) (so it excludes Encounter, Location, Organization, etc.). So anything listed in the Server CapabilityStatement, but not listed in the USCDI v1 mapping wouldn't be required. It also says you only need to respond to requests for data, so that would exclude writes.
(g)(10)(i)(A) Respond to requests for a single patient's data according to the standard adopted
in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including
the mandatory capabilities described in “US Core Server CapabilityStatement,” for each
of the data included in the standard adopted in § 170.213. All data elements indicated
as “mandatory” and “must support” by the standards and implementation specifications
must be supported.
Does anyone have a different view on this?
Last updated: Apr 12 2022 at 19:14 UTC
