Stream: social
Topic: Zynx Health Innovation Discussion
Grahame Grieve (Oct 05 2017 at 21:55):
I have a question about this
Grahame Grieve (Oct 05 2017 at 21:57):
is there a way we can get the connectathon process to work with this?
Aslan Brooke (Oct 05 2017 at 22:07):
I would think so. If you could provide me a link for the next connectathon and/or the connectathon process I could discuss further considerations.
Grahame Grieve (Oct 05 2017 at 22:08):
from yesterday's announcement:
Grahame Grieve (Oct 05 2017 at 22:08):
A reminder that proposals for tracks in the January 2018 Connectathon in New Orleans should be created by 18th October.
Here's an overview of the process: http://wiki.hl7.org/index.php?title=FHIR_Connectathon_Track_Process
The Connectathon page itself is here: http://wiki.hl7.org/index.php?title=FHIR_Connectathon_17 (It's a work in progress of course, but it does have a link to the tracks
Tracks are listed here: http://wiki.hl7.org/index.php?title=Category:201801_FHIR_Connectathon_Track_Proposals
And the main wiki page (with links to these two) is here: http://wiki.hl7.org/index.php?title=FHIR
Feel free to contact me with any queries...
Grahame Grieve (Oct 05 2017 at 22:08):
[me] is @David Hay
Grahame Grieve (Oct 05 2017 at 22:10):
but @Bryn Rhodes might have some ideas on this. But I think it would help if we have a 2-3 paragraph summary of the kinds of things that you can get through the ZyncHealth API for FHIR developers to help this discussion along
Aslan Brooke (Oct 05 2017 at 22:12):
Ok, currently the Zynx API is in beta and we are making PlanDefinition resources available that come from years of producing/selling ordersets and plans of care to hospitals. The PlanDefinition is the only resource we have now but we are looking to expand into the breadth of the Clinical Reasoning Module in FHIR.
Aslan Brooke (Oct 05 2017 at 22:55):
The Innovation Challenge has a total of $20,000 in awards along with an established timeline with the first phase completing on December 1, 2017. So, the timeline will prevent a tight coupling to the connectathon, however we will work on submitting a track proposal that could use the Zynx API regardless.
Grahame Grieve (Oct 05 2017 at 22:58):
Sure, that's kind of what I was thinking. And the connectathon is not suitable as a place to run a contest like this, so it's more about cross-fertilization of ideas and continuity. Though timelines on these things often slip ;-)
Michele Mottini (Oct 06 2017 at 18:14):
From the examples at https://github.com/zynxhealth/documentation/blob/master/README.md it does not seem that the Zynx API is FHIR - it might return FHIR resources but the request URL are different: .../order-sets/c1d06f95-c9f4-436d-ae8b-4de9c141867b
Michele Mottini (Oct 06 2017 at 18:14):
...or is this something new in the specs that I missed?
Grahame Grieve (Oct 06 2017 at 18:18):
no that's not conformant
Bryn Rhodes (Oct 06 2017 at 22:12):
@Aslan Brooke we've been running various scenarios related to Clinical Reasoning (including PlanDefinition and ActivityDefinition) at the last several connectathons. I'd love to see a scenario that involved consumers either ingesting or realizing a plan definition from Zynx. We also have a fairly generic open source environment that can run plan definitions (though it's pretty early days right now).
Aslan Brooke (Oct 06 2017 at 23:51):
@Grahame Grieve no that's not conformant
We realize the ZYNX API is not FHIR compliant at the API interface level at this time, though the resources are FHIR PlanDefinition resources (so at that level they are compliant, if such a division is legal). Currently we are working under the consideration that all our resources will support the FHIR standard but the API may be custom. This allows us the flexibility to create an API that may have functionality not in FHIR but still return FHIR resources. Any thoughts on this approach are welcome?
Aslan Brooke (Oct 06 2017 at 23:57):
@Michele Mottini ...or is this something new in the specs that I missed?
See my comments above, but we are using the FHIR resources, however the API interface to them is being created custom to Zynx. We will have API endpoints that have functionality beyond whats in FHIR but still return FHIR resources. Therefore the ability to use the resources would be in alignment with the FHIR standard, however the interface to them may be Zynx specific and allow us to define functionality not in FHIR. Any thoughts on this approach, or alternatives is welcome?
Michele Mottini (Oct 07 2017 at 01:22):
My thought is that It will force people to write custom clients - that sorts of defeat the purpose of using a standard. Use standard FHIR searches instead of custom request URLs maybe?
Bryn Rhodes (Oct 07 2017 at 02:09):
+1, there's nothing that says you can't do more than the FHIR spec, but at least having FHIR-standard requests for supported functionality would be good.
Lloyd McKenzie (Oct 07 2017 at 02:16):
What are the capabilities you're trying to expose that can't be expressed through existing FHIR capabilities?
Aslan Brooke (Oct 10 2017 at 22:17):
@mimo @Bryn Rhodes
We are going to support PlanDefinition endpoint based on the community feedback. It will most likely be in our next beta release.
@Lloyd McKenzie
The few change requests we have submitted would be the type of capability we could support ahead of them being in the existing standard. We will have others I'm sure, and while we will submit change requests, I imagine we'll support the capabilities if we need them ahead of a release of the standard.
An aside, we are steadfast in support of the data structures that are in FHIR. The only dependency to date is the API to those data structures. Which I think is in alignment with alternative paradigms for transmission of those data resources (e.g. a CCD made up of FHIR data structures)
Bryn Rhodes (Oct 11 2017 at 12:53):
@Aslan Brooke that's great!
Lloyd McKenzie (Oct 12 2017 at 06:15):
@Aslan Brooke I'm not clear on how the change requests would affect the URL paths?
Aslan Brooke (Oct 12 2017 at 23:11):
@Lloyd McKenzie I think your correct about the existing change requests submitted that I've been involved with. My comments were a bit more general about implementing API capabilities not yet in the standard.
My overall take though on the feedback I've gotten so far is that its OK to have an API that has additional endpoints/capabilities, but that we should also support the associated portions of the standard that have similar capabilities.
For example, the one identified initially, if we wanted to have "order set" and "plan of care" end points, we should also support access to all of those resources through the more general "PlanDefinition" endpoint since below all three end points is the same data structures. The "order set" endpoint would just be a way to know you were getting order set resources specifically.
Lloyd McKenzie (Oct 12 2017 at 23:32):
It's allowed - but it's outside the spec and therefore limits who can interoperate with you. I guess the question is whether there's a need to have distinct endpoints for those purposes. PlanDefinition has a flag that lets you filter to only include order sets. And "plan of care" sounds like CarePlan. If most systems will be exposing PlanDefinitions via a single endpoint - and that's what FHIR intends to happen, you should have a good reason for doing things differently - because that imposes costs on everyone who talks to you.
Last updated: Apr 12 2022 at 19:14 UTC
