Stream: implementers
Topic: Patient authored data through intermediary
Alexander Henket (Jan 26 2017 at 10:42):
I want to send glucose and vital signs data from my patient platform to my GP. The patient platform does FHIR REST. The GP does Edifact email. Hence there is an intermediary service that translates FHIR to Edifact and REST to email.
There are several options to make this work:
- Define Operation that explicitly states the endpoint should translate and where to send it to
- Use MessageHeader that states actual source/target and leave it up to endpoint configuration outside of FHIR that this leads to a transform
- ...?
The MessageHeader route is attractive in a messaging country such as ours, but MessageHeader has a drawback in that MessageHeader.enterer|author are fixed to Practitioner which basically means that Patient authored content is not supported. Considering both are optional I could just leave those out and leave the MessageHeader.data tell the receiver that it was patient authored.
Any suggestion or advice? Should I file a tracker for supporting patients in the MessageHeader resource?
John Moehrke (Jan 26 2017 at 15:39):
Use Provenance to identify that the data came from the Patient. Use meta tag value PATAST to indicate the data is Patient Asserted. Also, since you are translating you might want to have another Provenance record for the translation and add marking to the data with TRSLT. These meta tags are indicators of integrity attribution http://build.fhir.org/v3/SecurityIntegrityObservationValue/vs.html
Alexander Henket (Jan 26 2017 at 15:55):
Wow. Didn't see that one coming. I'll start reading. Thanks for the suggestion
John Moehrke (Jan 26 2017 at 16:26):
I will note that we have discussed this in committees but I don't think this has made it into examples or to the Security/Privacy Module page.. but it should. So if you make good examples, or have questions... please help. Getting realworld experience is important.
Michelle (Moseman) Miller (Jan 26 2017 at 20:00):
Could you use Observation.performer with a reference to the Patient to convey that the Patient was responsible for that vitals observation value?
René Spronk (Jan 27 2017 at 07:25):
@John Moehrke In general it may be useful to have PATAST / Provenance resource, although almost all of its contents would be of little use when translation from FHIR to legacy formats such as EDIFACT or HL7v2. TRSLT (you probably meant: MAPPED, which is a better fit IMHO) would make sense if translating to FHIR, but the other way around it doesn't come into play at all.
Alexanders question is about how one instructs the receiving side to "go translate this, en route to designated receiver". In my mind that's an operation (e.g. "TranslateToEdifactAndRoute") with as input parameters a bundle of resources, a referenced sending resource, a referenced recieving resource, as well as some other stuff.
John Moehrke (Jan 27 2017 at 12:27):
If the request about how to make a service that executes some process, then yes an Operation is appropriate. I didn't understand that.
Alexander Henket (Jan 27 2017 at 12:28):
@Michelle M Miller yes and we will. The problem arises when we would do Bundle.type Message + MessageHeader. MessageHeader has an author which at present can only be a Practitioner. That doesn't fly with Patient authored contents, so in the messaging paradigm the Patient is not a supported sender
Alexander Henket (Jan 27 2017 at 12:35):
@John Moehrke Rene and I spoke briefly F2F about this as well. I'm pretty sure Operation is the best way forward. However we depend a little on what the server is willing to offer. At present that is a SOAP based interface that accepts content-type / in SOAP:Body
John Moehrke (Jan 27 2017 at 12:37):
When it comes to services, many API types are available. One can always define an API using server friendly interaction technology with FHIR defined parameters.
Alexander Henket (Jan 27 2017 at 12:40):
Sure, I suppose a SOAP:Body with a <Parameters/> resource that contains what you would preferably POST to a FHIR RESTful endpoint, but instead POST using SOAP is equally valid and very close to what you would do if the endpoint had actually been RESTful
Alexander Henket (Jan 27 2017 at 12:41):
As long as the SOAP interface passes the contents along to the appropriate translation or responds with an HTTP 500 / SOAP:Fault we're good to go -- Functionally the SOAP:Fault matches the OperationOutcome
Lloyd McKenzie (Jan 28 2017 at 03:50):
I think patient-authored messages is a long way outside the 80% for messaging. So I'd lean towards using an extension if you wanted to convey that.
Last updated: Apr 12 2022 at 19:14 UTC
