I am currently using a managed Azure FHIR API and I need to do a mass update to a FHIR element.I have about 200K+ resources of type Specimen
"resourceType": "Specimen",
"id": "101",
"text": {
"status": "created",
}
And, I would like to update the "text" fhir element like this
"resourceType": "Specimen",
"id": "101",
"text": {
"status": "generated",
}
What is the best approach to fix a large set of fhir resources? I've looked at PATCH but it seems to work for a single resource.
You could submit a Batch full of patches. Other than that, you'd be looking at a custom operation or directly manipulating the datastore, bypassing the FHIR interface. There's no standard mechanism to apply an arbitrary change to a set of resources.
Related
As far as I know, there are two APIs that are required to interact with bots
Graph - Access to Microsoft Graph endpoints, which do not provide access to conversations in Teams.
Bot Framework - The endpoints in this API provide access to conversations.
Moving past the difficulty of finding bot-user IDs, the problem becomes the creation of a new conversation in a channel by the bot. This link says it should be possible, but I have not been successful after hours of attempts.
The service URL in the documentation does not match my requests. It says https://smba.trafficmanager.net/teams/, but I see https://smba.trafficmanager.net/amer/ and https://smba.trafficmanager.net/apis/ in other places. Which one is it?
The crux of the issue is the required fields in the JSON data. This link is meant to help with the creation of channel conversations, but it does not explain the data. In that section is the following comment:
Alternatively, you can use the REST API and issue a POST request to /conversations resource.
which leads to here. Unfortunately, that page does not explain how this works because the sample JSON data is incomplete and not targeted at channels. It appears to be related only to new group chats.
Ultimately, I am requesting an example JSON request to the POST /v3/conversations endpoint, which will create a new conversation in a Team (conversationType = channel, to be clear). This is how it is supposed to look for a new group chat, which does not work with a channel:
{
"bot": {
"id": "12345678",
"name": "bot's name"
},
"isGroup": false,
"members": [
{
"id": "1234abcd",
"name": "recipient's name"
}
],
"topicName": "News Alert"
}
What you're trying to do is called "Proactive Messaging" - basically, it's having your bot create the first message in a series, rather than being the 'recipient' in the usual case. You definitely will need a bot for this, but it sounds like you have one already so that's good. In essence, in a Teams context, you're never really starting a 'new' conversation with the bot, it's just 'continuing' an existing one, so you're wanting to post to the endpoint of that converation. I've covered (I hope well) in some other answers, so please refer here for more: Sending proactive messages from an outside process to organizational users via Teams chat bot . If you're still stuck, let me know and I'll try help further.
I managed to get a JSON object to create a conversation. I have been at this for days, by the way.
The following JSON object will create a new conversation in the General channel of a Team:
{
"activity": {
"type": "message",
"text": "got here"
},
"bot": {
"id": "{{botID}}",
"name": "{{botName}}"
},
"channelData":{
"teamsChannelId":"{{teamID}}",
"teamsTeamId":"{{teamID}}",
// The channel ID of the General channel is the team ID
// Use another channel ID here if you want the message to go elsewhere
"channel":{"id":"{{teamID}}"},
"team":{"id":"{{teamID}}"},
"tenant":{"id": "{{tenantID}}"}
},
"isGroup": true,
"tenantId": "{{tenantID}}"
}
Here is the way to reply:
POST {{urlBase}}/v3/conversations/{{conversationId}}/activities
{
"bot": {
"id": "{{botID}}",
"name": "{{botName}}"
},
"text": "reply test",
"type": "message"
}
where urlBase is something like https://smba.trafficmanager.net/amer and conversationId is something like 19:c25ae532345659b67313c54e1310fdb6#thread.tacv2;messageid=2456564642569 .
A ton of helpful information can be found here. That link is buried and completely obscure, but it has most of what you'll want for low-level calls.
Unfortunately, adding a title/subject to the conversation seems to be impossible, which completely breaks my use case. All that work yielded nothing for me because the easiest part is missing, but at least I figured it out. I hope this helps someone.
I was wondering if an object type that has an id property has to have the same content given the same id. At the moment the same id can have different content.
The following query:
const query = gql`
query products(
$priceSelector: PriceSelectorInput!
) {
productProjectionSearch(
priceSelector: $priceSelector
) {
total
results {
masterVariant {
# If you do the following it will work
# anythingButId: id
id
scopedPrice {
country
}
}
}
}
}
`;
If the PriceSelectorInput is {currency: "USD", country: "US"} then the result is:
{
"productProjectionSearch": {
"total": 2702,
"results": [
{
"name": "Sweater Pinko white",
"masterVariant": {
"id": 1,
"scopedPrice": {
"country": "US",
"__typename": "ScopedPrice"
},
"__typename": "ProductSearchVariant"
},
"__typename": "ProductProjection"
}
],
"__typename": "ProductProjectionSearchResult"
}
}
If the PriceSelectorInput is {currency: "EUR", country: "DE"} then the result is:
{
"productProjectionSearch": {
"total": 2702,
"results": [
{
"name": "Sweater Pinko white",
"masterVariant": {
"id": 1,
"scopedPrice": {
"country": "DE",
"__typename": "ScopedPrice"
},
"__typename": "ProductSearchVariant"
},
"__typename": "ProductProjection"
}
],
"__typename": "ProductProjectionSearchResult"
}
}
My question is that masterVariant of type ProductSearchVariant has id of 1 in both cases but different values for scopedPrice. This breaks apollo cache defaultDataIdFromObject function as demonstrated in this repo. My question is; is this a bug in apollo or would this be a violation of a graphql standard in the type definition of ProductSearchVariant?
TLDR
No it does not break the spec. The spec forces absolutely nothing in regards caching.
Literature for people that may be interested
From the end of the overview section
Because of these principles [... one] can quickly become productive without reading extensive documentation and with little or no formal training. To enable that experience, there must be those that build those servers and tools.
The following formal specification serves as a reference for those builders. It describes the language and its grammar, the type system and the introspection system used to query it, and the execution and validation engines with the algorithms to power them. The goal of this specification is to provide a foundation and framework for an ecosystem of GraphQL tools, client libraries, and server implementations -- spanning both organizations and platforms -- that has yet to be built. We look forward to working with the community in order to do that.
As we just saw the spec says nothing about caching or implementation details, that's left out to the community. The rest of the paper proceeds to give details on how the type-system, the language, requests and responses should be handled.
Also note that the document does not mention which underlying protocol is being used (although commonly it's HTTP). You could effectively run GraphQL communication over a USB device or over infra-red light.
We hosted an interesting talk at our tech conferences which you might find interesting. Here's a link:
GraphQL Anywhere - Our Journey With GraphQL Mesh & Schema Stitching • Uri Goldshtein • GOTO 2021
If we "Ctrl+F" ourselves to look for things as "Cache" or "ID" we can find the following section which I think would help get to a conclusion here:
ID
The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache. The ID type is serialized in the same way as a String; however, it is not intended to be human‐readable. While it is often numeric, it should always serialize as a String.
Result Coercion
GraphQL is agnostic to ID format, and serializes to string to ensure consistency across many formats ID could represent, from small auto‐increment numbers, to large 128‐bit random numbers, to base64 encoded values, or string values of a format like GUID.
GraphQL servers should coerce as appropriate given the ID formats they expect. When coercion is not possible they must raise a field error.
Input Coercion
When expected as an input type, any string (such as "4") or integer (such as 4) input value should be coerced to ID as appropriate for the ID formats a given GraphQL server expects. Any other input value, including float input values (such as 4.0), must raise a query error indicating an incorrect type.
It mentions that such field it is commonly used as a cache key (and that's the default cache key for the Apollo collection of GraphQL implementations) but it doesn't tell us anything about "consistency of the returned data".
Here's the link for the full specification document for GraphQL
Warning! Opinionated - My take on ID's
Of course all I am about to say has nothing to do with the GraphQL specification
Sometimes an ID is not enough of a piece of information to decide whether to cache something. Let's think about user searches:
If I have a FavouriteSearch entity that has an ID on my database and a field called textSearch. I'd commonly like to expose a property results: [Result!]! on my GraphQL specification referencing all the results that this specific text search yielded.
These results are very likely to be different from the moment I make the search or five minutes later when I revisit my favourite search. (Thinking about a text-search on a platform such as TikTok where users may massively upload content).
So based on this definition of the entity FavouriteSearch it makes sense that the caching behavior is rather unexpected.
If we think of the problem from a different angle we might want a SearchResults entity which could have an ID and a timestamp and have a join-table where we reference all those posts that were related to the initial text-search and in that case it would make sense to return a consistent content for the property results on our GraphQL schema.
Thing is that it depends on how we define our entities and it's ultimately not related to the GraphQL spec
A solution for your problem
You can specify how Apollo generates the key for later use as key on the cache as #Matt already pointed in the comments. You may want to tap into that and override that behavior for those entitites that have a __type equal to your masterVariant property type and return NO_KEY for all of them (or similar) in order to avoid caching from your ApolloClient on those specific fields.
I hope this was helpful!
I am just getting started with HL7 FHIR and I am having a hard time digging into it the specifics of how the Questionnaire (and QuestionnaireResponse) resource is supposed to be used. We would like to create a questionnaire that has some kind of scoring system. We have previously implemented the Glascow Coma Scale (GCS) ourselves in our own proprietary (minimal) model, so when I found GCS being listed on the examples page I thought it would be a good start for understanding this.
The first question I ask myself is, where are the actual scoring values? The Questionnaire resource lists stuff such as http://loinc.org/ValueSet/LL357-5 as the ValueSet, which contains stuff such as this:
"compose": {
"include": [ {
"system": "http://loinc.org",
"concept": [ {
"code": "LA6562-8",
"display": "No motor response"
}, {
"code": "LA6563-6",
"display": "Extension to pain"
}, {
"code": "LA6564-4",
"display": "Flexion to pain"
}, {
"code": "LA6565-1",
"display": "Withdrawal from pain"
}, {
"code": "LA6566-9",
"display": "Localizing pain"
}, {
"code": "LA6567-7",
"display": "Obeys commands"
} ]
} ]
}
Each of those codes should map to some numeric value and no matter which resource I check out, I cannot find any such values. So confusing. The html page for LL357-5 even lists the values, so they must be found somewhere.
The second thing is that I thought the Questionnaire resource could somehow instruct/point to how the score could be calculated, and I don't really find any such hints. I know the algorithm, but is it not so that a system should be able to receive this Questionnaire, render it, accept values and produce a QuestionnaireResponse containing a score from some kind of referenced algorithm? How does the FHIR Resources say how one actually computes this score?
To convey the values, use the http://hl7.org/fhir/StructureDefinition/ordinalValue extension. It can appear both CodeSystem and ValueSet concepts and also on Questionnaire options.
Handling embedding calculations is more sophisticated than the base Questionnaire resource is set up for. (FHIR resources, in general, only try to represent functionality that most systems that support Questionnaires know how to do, and the lowest common denominator for Questionnaires in healthcare is relatively low.) However, there's an implementation guide called Structured Data Capture (SDC) that describes a bunch of advanced behavior. Doing calculations is covered in the advanced behavior section. There's an example that shows how everything fits together here.
In polkadot-js has provided for developer to define custom types in the pallet, so that polkadot-ui can understand those types (it means can use some underlying API polkadot-js). These types are defined using the json format. This is example
{
"TransactionInput": {
"parent_output": "Hash",
"signature": "Signature"
},
"TransactionOutput": {
"value": "u128",
"pubkey": "Hash",
"sale": "u32"
},
"Transaction": {
"inputs": "Vec<TransactionInput>",
"outputs": "Vec<TransactionOutput>"
}
}
I see that in substrate-node-template/scripts has aggregrate_types.js file that generate types.json. I dont know how to generate it automaticly or I should write by hand.
Example that, in my pallet that i have defined enum RoleID and struct Role. But in UI it doesn't understand what RoleID is. Can you explain more clearly? I believe that it can be related to define types.json.
https://github.com/polkadot-js/apps/blob/master/packages/page-settings/src/md/basics.md#developer
aggregrate_types.json:
Thanks!!!
Presently, generating this by hand is the best way following the docs here. There are not clean ways to automatically generate this to my knowlage, but soon you will not need to worry about at all it once this PR lands in Substrate!
Thanks to https://github.com/paritytech/substrate/pull/8615, you don't have to manually write types.json anymore.
Make sure the metadata version of your node is v14 or higher. Otherwise you need to upgrade your substrate version to make it automagically work for you.
This is not so much a specific programming related question but more on the planning part.
So I have posts in my DB that look like the below:
{
"_id": "57f88bb94b5342b2025d5646",
"postID": "12345",
"profileID": "12345678",
"title": "testT",
"description": "testD",
"views": 0,
"dateCreated": "2016-10-08 06:01:29",
"categories": [],
"__v": 0
}
Now, I am creating the front-end part for it and I need to create the categories from a dropdown list or something similar.
I know I can just populate it or get it from from the DB but where does the list actually come from? I mean say I need to create a post about Lamborghini, it comes under brand and automobile categories.
What I am essentially after is a place where I can grab these categories and their sub-categories.
Does anyone know of such a service/API? Is there another way?
By the way, I am on the MEAN Stack.
Thanks,
Shayan
In the end, I just created the list from all sorts of different sites and made it into one list.
Sadly, it looks like there is no such API service for this.