NIH | National Cancer Institute | NCI Wiki  

  • Created by Unknown User (deshpans), last modified by Unknown User (wileyal) on Jan 22, 2012

Contents of this Page

Creating datatype mapping

Use Case Number
The author-assigned number to refer to each specific use case. The format of this number is <SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc.

UMLSD1

Brief Description

One persons object is another person's attribute". Depending on ones world view, a real life entity can be modeled in UML as Object, Attribute or value set. In caBIG models now, some model Race (and Ethnicity) as an Object while others model Race (and Etnicty ) as an attribute. This is problematic, because Race data that is modeled differently cannot be "seamlessly integrated" on caGrid (there needs to be a transform).
The evolution of technologies is disruptive and caBIG to really support seamless datasharing experience  needs to evolve beyond interoperability based on CDEs, primarily. It not only needs to support the grid platform but also the mobile, .NET WSDL platform. NCI with its CIMs, PIMs  PSMs, BAM and DAM needs to interoperate with whatever CIMs, PIMs  PSMs, BAM and DAM that they might have.



Actor(s) for this particular use case

DataData Curators

Pre-condition
The state of the system before the user interacts with it

The various data formats along with their pluses and minuses are known

Post condition
The state of the system after the user interacts with it

A direct mapping is created between an agreed upon, standard format and any other format used in the healthcare settings

Steps to take
The step-by-step description of how users will interact with the system to achieve a specific business goal or function

1.Curators identify various datatype formats (A,B, C and X ) that are used to represent data in various tools

2.Most widely represented, evolved  and used format is identified as the agreed upon standard (format X)

3.A mapping is generated between each standard to X (A to X) (B to X) and so on

Alternate Flow
Things which would prevent the normal flow of the use case

None

Priority
The priority of implementing the use case: High, Medium or Low

Medium

Associated Links
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case.

---

Fit criterion/Acceptance Criterion 
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement?

A granular mapping is created between an agreed upon standard format and any other format used in the healthcare settings

Interoperability across various platforms

Use Case Number
The author-assigned number to refer to each specific use case. The format of this number is <SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc.

UMLSD2

Brief Description

The below listed use case describes the interoperability scenarios in the various healthcare applications for a query that is launched from  a 'platform immaterial' tool

Actor(s) for this particular use case

Cancer Researcher

Pre-condition
The state of the system before the user interacts with it

1. There is a very granular mapping that exists between the data format used by the source application and an agreed upon standard data format.

2. There is a very granular mapping that exists between the data format used by the target application and an agreed upon standard data format.

3. There is an API/plug-in available that refers to the mapping and transforms the query from an actor in a source application data format to an agreed upon standard data format.

4. There is an API/plug-in available that refers to the mapping and transforms the results from the target application data format to an agreed upon standard data format.

Post condition
The state of the system after the user interacts with it

Actors gets the data of interest in the format that his tool understands

Steps to take
The step-by-step description of how users will interact with the system to achieve a specific business goal or function

1.Actor fires a query using his source application in a format A

2.An API/ plug-in transforms the query to an agreed upon standard format X and queries the target application in format X

3.The target application exposes an API/plug in that translates the query in format X to target application format (B)

4.The target application returns the data for query in  format B

5.An API/plug-in transforms the results in format B to format X (standard format)

6.The source application exposes an API/plug-in that translates the format X to A specific for the source application

7.Actor gets the data he was looking for in the query

Alternate Flow
Things which would prevent the normal flow of the use case

None

Priority
The priority of implementing the use case: High, Medium or Low

Medium

Associated Links
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case.

---

Fit criterion/Acceptance Criterion 
How would actor describe the acceptable usage scenarios for the software or service that meets the actor's requirement? 

Actors gets the data of interest in the format that his tool understands


  • No labels