Board Review: V3.2-1 Service Introduction initial meeting

iscai-msft commented 4 years ago

Looking to schedule a meeting for an service-side informational review of the new TA healthcare endpoint and the new LRO functions. Representatives from the service team who will be coding the SDK for .net and python will be presenting.

The Basics

Service team responsible for the client library: Text Analytics
Link to documentation describing the service: https://docs.microsoft.com/en-us/azure/cognitive-services/text-analytics/
Contact email (if service team, provide PM and Dev Lead): @mayurid @assafi
swagger: https://github.com/Azure/azure-rest-api-specs-pr/blob/3fd71419496befa5e4c0855e722bb224b6567d14/specification/cognitiveservices/data-plane/TextAnalytics/preview/v3.2-preview.1/TextAnalytics.json

About this client library This meeting is the initial informational review

Languages for this review:
Link to the service REST APIs:

Artifacts required (per language)

We use an API review tool (apiview) to support .NET and Java API reviews. For Python and TypeScript, use the API extractor tool, then submit the output as a Draft PR to the relevant repository (azure-sdk-for-python or azure-sdk-for-js).

.NET

Upload DLL to apiview. Link: https://apiview.dev/Assemblies/Review/8a9546061f13429b84826f89461f9e50?diffRevisionId=e2622381ada943b695b1501c9258897f
Link to samples for champion scenarios: AnalyzeHealthOperation.cs AnalyzeOperation.cs

Java

Upload JAR to apiview. Link:
Link to samples for champion scenarios:

Python

Upload the api as a Draft PR. Link to PR:
Link to samples for champion scenarios:

TypeScript

Upload output of api-extractor as a Draft PR. Link to PR:
Link to samples for champion scenarios:

Champion Scenarios

A champion scenario is a use case that the consumer of the client library is commonly expected to perform. Champion scenarios are used to ensure the developer experience is exemplary for the common cases. You need to show the entire code sample (including error handling, as an example) for the champion scenarios.

Champion Scenario 1:
- Describe the champion scenario
- Estimate the percentage of developers using the service who would use the champion scenario
- Link to the code sample

Repeat for each champion scenario

Examples of good scenarios are technology agnostic (i.e. the customer can do the same thing in multiple ways), and are expected to be used by > 20% of users:

Upload a file
Update firmware on the device
Recognize faces in an uploaded image

Examples of bad scenarios:

Create a client (it's part of a scenario, and we'll see it often enough in true champion scenarios)
Send a batch of events (again, part of the scenario)
Create a page blob (it's not used by enough of the user base)

Agenda for the review

A board review is generally split into two parts, with additional meetings as required

Part 1 - Introducing the board to the service:

Review of the service (no more than 10 minutes).
Review of the champion scenarios.
Get feedback on the API patterns used in the champion scenarios.

After part 1, you may schedule additional meetings with architects to refine the API and work on implementation.

Part 2 - the "GA" meeting

Scheduled at least one week after the APIs have been uploaded for review.
Will go over controversial feedback from the line-by-line API review.
Exit meeting with concrete changes necessary to meet quality bar.

Thank you for your submission

lilyjma commented 4 years ago

scheduled 9/23

suhas92 commented 4 years ago

.NET SDK

SDK PR API.DEV Link

Tests:

lilyjma commented 4 years ago

Context

Entity recognition for health care domain
Will try to reuse as much from general case as possible, but there are compositions that make sense only for health case
Hosted API ~Nov 2020
Downloadable containers with minimal telemetry
- Send only billing info
- We have no control over where containers will be run

Demo:

Physician notes
- Ex: summary of patients medical condition, medication, diagnosis info etc.
- API able to recognize entities like patient gender, medication, symptoms. Also identifying relationships (25mg is associated with a medication)
- Entity linking for structured content (links to id of Wikipedia-like articles)
- Recognizes negations
Not general purpose model
- Doctors and physicians labeled the data used to build model --> higher accuracy than general domain (health industry requirement)
- Graph like relationship between entities
  - Ex: hemoglobin > 9
    Entity Linking
Similar entities that shouldn’t link to the same thing
- Ex: Diffuse large b-cell lymphoma vs primary mediastinal large b-cell lymphoma
Can’t just drop in a new database of concepts because lack NLP capabilities
Relation Extraction
More than just recognition
- Hemoglobin level is less than 12 mg/dl
No support of transitive relation now
FHIR integration (coming soon)
FHIR: json standard for how concepts are represented in the medical field to integrate medical systems
Want to expose info in that format as well

Use cases:

Insight and stat extraction
Clinical trial matching
Predictive analytics/models on historic data
Etc.
Serve from Text analytics service
Not creating new SDK and docs etc.
Model types: looking into conversations, emails, or documents
Verticals: maybe finance domain, oil/gas
- Ex: maybe sentiment for a stock
  Text Analytics “Analyze”
Be able to call custom models (by users)
Invoke multiple models in single call
Motivations
- Customers:
  - Process larger and longer docs
  - Simpler to just submit all docs and get result when done instead of splitting
  - Invoking on same input multiple capabilities (competitors offer this)
- Possibilities of integration with other cognitive services
- Internal reasons as well (scaling, SLAs, etc.)
  Custom Text
Training via upcoming Language Studio
No SDK for training for now
- Training jobs done via UI
How/when decide whether these features will be extension to existing APIs/types, etc. or a complete new set?
- More answers later toward end of year

abhahn commented 4 years ago

Python SDK

SDK PR Samples:

Azure / azure-sdk