[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XDI TC Notes Unofficial Telecon Tuesday 2017-03-14
Following are the notes of the unofficial telecon of the XDI TC held on:
Date: Tuesday, 14 March 2017 USA
Time: 9:00AM - 10:00AM Pacific Time (17:00-18:30 UTC)
The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.
Markus Sabadello
Drummond Reed
Joseph Boyle
Phil Windley
Let's continue last week’s discussion about XDI messages and link contracts for a use case of a patient/doctor/hospital interaction scenario that Markus has been working on.
Markus described a health care use case involving a patient and a doctor as follows:
Patient starts with a set of medical records.
Patient consults a Doctor (no pre-existing relationship).
Doctor sends patient an XDI request for:
Reading the patient's current medical records.
Asking permission to write additional medical records.
Patient agrees to the request (some variations possible at this point).
Doctor reads Patient's medical records.
After consultation, doctor writes a new medical record to Patient.
We considered the following pattern to express medical records:
=!:did:sov:1111#medical[#
=!:did:sov:1111#medical[#
=!:did:sov:1111#medical[#
=!:did:sov:1111#medical[#
=!:did:sov:1111#medical[#
=!:did:sov:1111#medical[#recor
(use aggregation pattern to categorize by subsets...)
We discussed the difference between the following XDI operations:
Simply requesting an XDI subgraph:
=doctor[$msg]@~1$do/$get/=
(request by graph branch location)
Request using an XDI variable:
(=doctor[$msg]@~1$do/$get)
(request by semantic type)
How smart can the query get, e.g. how could one only request records related to a certain blood condition?
We discussed again some ideas for a query language that uses {} variables.
We discussed how to do a more open-ended query that requires "user moderation", e.g. a doctor wants to tell a patient "send me those medical records you choose give me". In such a case, a user would manually influence the request/response. This could be done with a policy _expression_.
Link contract execution policy:
…$contract$do$if/$true/….
Link contract defer policy:
…$contract$defer$if/$true/….
Message execution policy:
…[$msg]@~0$do$if/$true/…
Message defer policy:
…[$msg]@~0$defer$if/$true/$tru
A "message defer policy" is a way that allows a requester to specify that the message should be manually approved/rejected by the responder, instead of automatically. This is the requester's equivalent to the "link contract defer policy" on the responser's side.
Drummond suggested that sometimes a query process happens partially through human interaction rather than entirely in a technical query language. For example, a doctor could just ask a patient what medical records they have recently obtained, and then the doctor could formulate a more precise XDI query based on this information (e.g. give me medical records of type "blood test" issued by hospital X).
Phil brought up HATEOAS (Hypertext as the Engine of Application State). Follows the link-page-link-page metaphor. If you apply that same principle to an HTTP REST API, you can get back at HTML page from a query that needs some user action. For example, you can be registering for a university course, and you fill out a form, it may fail not for technical reasons but you need a pre-requisite class.
In an HATEOAS architecture approach, the protocol is defined by the links between the application states.
The next call will be the following week at the usual time (Tuesday 9AM PT). The link where agenda items can be posted for the next meeting is: https://docs.google.com/docume
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]