My question is more about modeling simple clinical notes in SOAP (Subjective, Objective, Assessment, Plan) into the FHIR specification.
I have been trying to look into the documentation but it doesn't provide a clear way of doing it or a clear way of which resources to use.
Does anyone have an idea of the best resources to use from FHIR for clinical notes?
Most EHRs will utilize DocumentReference and Binary. DocumentReference would hold the metadata about the note, such as the author and creation date/time. Binary would hold the content in a base64-encoded string.
There is the possibility of forgoing the Binary and using the content.attachment.data attribute in DocumentReference to directly hold the base64-encoded string, but this isn't as common.
Related
We want to categorize patients in our system. For example, in organ transplant, we want to "tag" a Patient FHIR resource as a donor or recipient (ignoring the scenario where a living donor can later become a recipient) since these types of "patients" are stored separately in the back end system. So when someone does a PUT HTTP request with a patient resource, we need to know what kind of patient it is before we can do the update in the database.
It's hard to determine the best way to approach this. Using the meta area seems promising, combined with the UsageContextType of "focus" perhaps, taking on values of "donor" or "recipient".
It's not clear though how to actually code something like this in a Patient resource (JSON for us). Any guidance/examples would be very much appreciated.
Sadly, I think the FHIR folks are going down the same path they used with the V3 RIM....lots of impenetrable standard definitions, but very few practical examples of how to use some of these FHIR standards in the real world. But that is another issue.
Don't understand ignoring the scenario where someone can be both donor and recipient. However, if you needed to, you could add an extension that differentiated. You could also use Patient.meta.tag.
With the RIM there'd have been an esoteric modelling mechanism to define what you wanted, likely walking through 3-4 classes to get to one element (and a whole lot of fixed values along the way). With FHIR, if you're doing something esoteric, you just define an extension.
If you see something in the core specification you find impenetrable, please submit a change request asking for the language to be improved. (There's a "propose a change" link at the bottom of every page and registration is free.)
Is there a way for us to define the policies of a GraphQL API, which is both machine-readable and human-readable, which contains a set of rules (in other words, a specification) to describe the format of the API? I'm not talking about the schema, but of a spec where we can add security-related details (for example, complexity value to be assigned per field and depth limitation values) or any other related details. Any thoughts or ideas? Or can we send all of this within the SDL itself?
For example, for REST APIs, we use Swagger to define information on how to define paths, parameters, responses, models, security and more. Is there a need for a similar approach for GraphQL APIs? Your response is highly appreciated
We are working in an approach to add policies to your GraphQL API and allow you to better manage it, especially as you expose the interface externally.
Part of the challenge is that as opposed to a REST call that can easily be differentiated from others, all GraphQL requests look the same, unless a deeper analysis is performed on the incoming query.
This blog post describes how we perform this analysis: https://www.ibm.com/blogs/research/2019/02/graphql-api-management/
if this is of interest let's connect!
As per my understanding you need a tool to make documentation for the APIs you have build for parameters and so on.
If that's what you are searching, there is like swagger for GraphQL - Swagger-to-GraphQL
Hope that helps.!!
I would like to know what FHIR resource has to be used for bringing the list of specialities that are available for an organisation. These specialities are encounter specific so the response must be returned along with its encounter information based on the organisation.
Is that advisable to use List resource in FHIR?
If you search a FHIR server for a 'collection' of resources (like Encounter, HealthcareService or any other) the standard response would be a Bundle rather than a List.
We have an ImageViewer based on FHIR and we want to annotate certain images within a study.
We haven't found an adequate resource type for storing annotations line linear measurements, ellipse area, angle, text, etc.
On the top of that, the annotations shall point to a specific series/image pair, rather than the whole study.
What is the recommendation here? To create an extension for ImagingStudy (and have to update the whole resource for each annotation CRUD) or a separated suggested resource type?
FHIR ImagingStudy is designed to work with DICOM imaging (and especially RESTful DICOMweb) and we tried not to replicate capabilities between the two. Among other reasons, this prevents some systems from only being able to see part of the imaging record.
Therefore, annotations and image flagging should be handled using DICOM presentation states (e.g., GSPS) and Key Image Notes. The ImagingStudy can reference those instances and request images be rendered appropriately.
We are always looking for feedback on missing use cases, so please let us know on chat.fhir.org if we’ve left a gap.
This question is very similar to my question, however due to the way SO works, I think it is better to ask a new question rather than just continue a thread.
CoreNLP has the Simple API which allows for quicker access to various components of the NLP pipeline. The way to get named entities appears to be:
Form a document annotation from the text
Get the sentences from the document object
Use nerTags() from the sentences object to get the token-by-token ner labeling.
Via other mechanisms, as talked about in the question link above, one can retrieve full multi-token entity mentions such as George Washington, which is an entity mention composed of 2 tokens. Is there a way using the simple api to get these multi-token entity mentions?
Yes, though it gives you less information than the full API, returning only the String spans of the mention. See Sentence#mentions(String) and Sentence#mentions().
If you want to get more information about a mention, you'll have to either use the regular API, or re-implement the logic in these functions. You can also try mucking around in the raw Proto, which will certainly have all the information you could possibly want, but in a less-than-pleasant proto interface. The proto definition is here.