Implementing Queue system using List FHIR Resource - hl7-fhir

I would like to use List FHIR resource to implement a queue system.
Are there any existing implementation guides on this?
Please assist.

Not published by HL7. You might have better luck reaching out on the Skype implementers list. (Instructions on how to join are on the FHIR wiki.) However, the List resource does seem like the appropriate one for your use-case.

Related

Inventory Item MFN M15 message in fhir

recently I've implemented MFN M15 message sender using HL7 (v2.x).
I see that HAPI FHIR is emerging as de-facto standard. Can someone point me out what would be MFN M15 message counterpart in https://hapifhir.io/?
NOTE:
I've already downloaded ca.uhn.hapi.fhir:org.hl7.fhir.dstu3:4.2.10-SNAPSHOT, and start investigation in org.hl7.fhir.dstu3.model but some directions would be more than gratefull.
Work on managing inventory using FHIR is still an area of exploration in FHIR (definitely a long way from 'de-facto standard' in this space, though FHIR is certainly becoming that for some areas of healthcare. In DSTU3, you may be able to cobble together part of a solution using Device and Medication. You might also look at this stream on chat.fhir.org: https://chat.fhir.org/#narrow/stream/179165-committers/topic/inventory.20tracking

What FHIR API would enable one to write notes to patient chart - specifically in Epic

I'm looking for a way to write notes into patient chart in Epic. Couldn't find any current FHIR specs about writing notes , but I didn't find this proposal http://wiki.hl7.org/index.php?title=ClinicalNote_FHIR_Resource_Proposal
Are there any other options ?
Great question. I work on the FHIR team at Epic and from a FHIR perspective we are having a similar problem identifying the appropriate place in FHIR to return notes. The proposal you have linked is a starting artifact in defining a new resource for that purpose. Until we determine in the FHIR community if a new spec should be created or an existing FHIR resource should be used, we do not have a FHIR specification to develop support against.
Outside of FHIR, today there are multiple ways to get notes into Epic such as HL7 v2, document based exchange, or something more Epic defined (these are just the ones I'm aware of). Without knowing more about your use case, it is hard to say what option may or may not meet your needs. I recommend you reach out through the contact us at https://open.epic.com/. From this email group they can dive into what integrations would meet your specific scenario and you will have input from a full gamut of integration experts.
And if you are interested in the standards side of things and getting notes in the FHIR specification, I'd encourage you to get involved on chat.fhir.org or any of the HL7 FHIR meetings to provide input on the specification!
*Edited to point to website instead of email.

Which FHIR resource should I use for Treatment Preferences?

While trying to understand how an existing system will map to FHIR resources, I am stuck in the documentation on Treatment/Care Preferences like the ones outlined here: http://wiki.hl7.org/index.php?title=Care_Preference
Would these preferences be handled in a list of extended objects? Or will FHIR be implementing a CarePreference resource?
This isn't catered for in the current set of resources. I guess you use Other (http://hl7.org/implement/standards/fhir/other.htm). It does seem like the kind of thing we'd want to define a resource for, but I'm not aware of any plans for one right now. I forwarded the suggestion along to the appropriate team.
btw, I'm not sure this question meets Stack Overflows guidelines - it might get edited/closed.
"Other" is the solution for now. Speed of the development of a specific resource is likely to be dependent on the number asking for it and the detail of the use-cases they supply. Consider sharing these on the FHIR list server. Alerts might be another mechanism to flag important preferences.

How OSGi interface become known to the gateway?

I have this question that keeps popping up and looking through my notes and slides I cannot seem to find the answer.
The question that's been asked is:
"In OSGi, how does a bundle make its interfaces known to the gateway. How is
this information used by the gateway"
I understand the principles of OSGi framework but I'm not sure how the interface becomes known.
Any help would be really appreciated :)
Thanks :)
It's called the Service Registry. Providers register their services, and consumers get their services from this facility.
It is an implementation of something called a Whiteboard Pattern, the gist of which is that providers and consumers don't directly interact or depend on each other. They have their offerings and requirements satisfied by a mutual 3rd party via published contracts (i.e. the interfaces).

open source gossip-based membership protocol?

I am looking for a library which I can plug into a distributed application which implements any gossip-based membership protocol.
Such a library would allow me to send/receive membership lists, merge received membership lists, etc... Even better would be if the library implemented a protocol with performance O(logn) performance guarantees.
Does anyone know of any open source library like this? It doesn't need to meet all of the aforementioned requirements; even something partially implemented would be helpful.
Take a look at this on google code:
http://code.google.com/p/gossip-protocol-java/
I happen to stumble upon it yesterday whilst looking for java based gossip implementation. It's more a reference implementation for someone to build upon, but it gives the general idea, and after reading through the code you'll definitely be able to build your own or branch what's there to add any features you need.
HTH
Have you looked at Apache Zookeeper? I'm not sure if it's what you're looking for.
ZooKeeper is a high-performance
coordination service for distributed
applications. It exposes common
services - such as naming,
configuration management,
synchronization, and group services -
in a simple interface so you don't
have to write them from scratch. You
can use it off-the-shelf to implement
consensus, group management, leader
election, and presence protocols.
C# bindings are also available.

Resources