EN: Alan not on call

Review Demo issues briefly

just 5 wks until workshop

must wittle down to the essentially tasks in the next week

many deliverables alan is expecting next week

questions?

SS: another informal F2F at MIT - April 10

working on modeling of data sets in RDF & OWL

will be checking to make certain things WILL connect as expected

EN: Hope to see lots of code & tools coming together by then
... any questions re: demo or tasks?

Did put a link on the WIki to solicit more help for Alan?

No outstanding questions

VK: Introduce Stan Huff and Tom Oniki

Showing clinical model work

looking for overlap with OTF - looking for synergies - represent in RDF & OWL

ACPP TF overlap - look for more overlap with CDISC

<vipul> http://esw.w3.org/topic/HCLS/OntologyTaskForce?action=AttachFile&do=get&target=CEM.ppt

SH: Talk from PPT slides

format of speaking on HCLS TCon

(EN: have 45 minutes)

Will go through slides - questions at end

SH: obviously more info than can be covered in 45 minutes

can plan follow-ups if useful

<ericP> slides are http://esw.w3.org/topic/HCLS/OntologyTaskForce?action=AttachFile&do=get&target=CEM.ppt ?

EN: In the audience we have BOTH clinical and basic LS research

recommend going quickly - let non-clinical folks review on their time

SH: Team effort (slide 2)
... Real goals - not just data - trying to enable LIFETIME e-record (from pre-natal to post-death)

linking to all relevant services

(see slide 3)

SH: Depends on SHARED common info models coupled to shared terminologies & ontologies
... What is a Detailed Clinical Model? (slide 5 - high-level overview)
... Slide 5 - simple example (systemic BP)

<ericP> slide 6

SH: re: longitudinal record (slide 6)

what record to support use 100+ years

legal record

data will outlive service, app, message format, AND person

SH: focused on logical structure of data AND interactions with standard terms & ontologies
... Real time, patient specific, decision support (slide 7)

All patient specific info - most appropriate course of care for that specific patient

<eneumann> scribe: BillBug

SH: Sharing data (slide 8)

reduce labor within HC enterprise

outside enterprise - many needs (need standard model for it to be computable) - especially to support analysis of this data

use data to improve patient care (outcomes-based - evaluate intervention outcomes - natural disease course)

<ericP> slide 10

<ericP> (i think)

SH: National & Internation sharing (slide 10)

last ref - sharing data (slide 8 & 9)

SH: create NEW kinds of HC marketplace (slide 11)

create apps against standard services using common logical model for patient data

<ericP> slide 12

<ericP> (picture seems applicable)

SH: Order Entry API (slide 12)

same back end - front ends swap out - regardless how complex the app

SH: escape repetative, vertically stacked, hard-code connection between backend (serializaiton & data exchange) and specific app
... Shared public standard for DCM & for APIs/Services
... on slide 18 now

EN: What is COS

SH: Common Order Service (consider same as Common Object Service)
... Curly brackets problem (slide 18)

<eneumann> Clinical syntaxes: ARDEN, JELLO

SH: Arden Syntax (slide 18)

place shared data within curly brackets

DCM target shared logical model that provide more specific access to detailed data elements

SH: need standard model & repostiory (slide 19)

<eneumann> thinks Stan's desccription of "Shared logical model..." very close to RDF-OWL model

SH: Can't depend on free-text data (Slide 20)
... Prospective decision support precludes use of free-text

Need shared, precise DCM

SH: Example - SNOMED CT - numbness in specific limb (slide 21)

same codes to represent limb numbness - regardless of which limb - no good for computability

need that in model

SH: Too many ways to say the same thing (Slides 22, 23, & 24)

Need the ability to qualify a measure (e.g. wt) so as to TRULY descriminate TRULY distinct measures

Can end up with totally different representation for same info depending on codes and variable model syntax (slide 24)

SH: RDBMS implications (slide 25)

tuples have different structure

example of using qualification to specify detailed WT type

can't be easily made commensurate across two models (+/-qualification)

end up needing totally different logic

or specific logic JUST to disambiguate

SH: more complex examples (slide 26)

these REALLY encourage a cornucopia of models (if your underlying shared model is NOT sufficient nuanced to capture detail)

<Zakim> ericP, you wanted to note that term mismatch examples all have unequivocal mapping

SH: Need shared terms/ontos AS WELL AS shared, layered DCM (Slide 27)

modelling in layers allows for required variability in application detail

EP: seems previous examples can be unequivovally mapped

SH: though these more complex - and abstract pre-coordinated entities such as syndromes

end up with a very lossy translation

SH: (back to slide 27)

layer model - helps in variety of integration scenarios with differing levels of detail

SH: Slide 31 - How do we use the models?

different use depending on the task - API interprocess comm, Core services, Decision Logic

SH: Bottom line - DCM does NOT dictate physical model

so app sharing and widget sharing can be eminantly re-usable

SH: Data entry validation (Slide 32 & 33)

model helps to insure validation before data reaches backend store

<eneumann> wonders if data storage service (DSS) validation is identical with RDF-S and OWL validation?

known model PRIOR to storing data

need tools that build off that model (validation just one example)

SH: Clinical Element Model (Slide 35)

EIM Subject Areas (high level)

had started with high-level and drilled down to detail

now focus on detail and map it up to the higher-level

<ericP> i envision a panel as an input form for a testor to fill out

SH: Conceptual hierarchichy of Clinical Element Models (slide 36)

from top to bottom - abstract core that gets more detail as you proceed to actual data element

those low-level elements can turn out to be used in many ways in the intermediate layer

EN: LabOpsPanel ?

SH: These are arbitrary collections of data needed for a certain clinical decision process

However, the underlying results may have MANY MORE uses outside of that process node

(e.g., Chem7, Chem20, Serum Sodium)

a STATEMENT - is a single sentence where adverbs& adjectives about single subject.

WHEREAS - a panel is a paragraph with statements about many subjects

EN: 11:50 - time for questions?

Should we jump to later detail slides?

SH: Whatever you like.

EN: Is your work and your consortium - I see XML mentioned

Are folks familiar with RDF?

SH: Familiar with OWL

Alan Rector has been using OWL for same types of models

Very interested to see how they can be used to represent the models

EN: Perusing your models, they seem to have goals very much commensurate with underlying SemWeb Tech/RDF goals
... other questions?

EP: Panels recorded in XML?

SH: Our own XML dialect (XSD?)

EP: enables you to extract elements from panels (e.g., person's wt) for other uses?

SH: yes

EP: seems to be exact match to how RDF is designed to let individual STATEMENTS stand on their own in exactly this way - very promising for SemWeb synergy

SH: Statements

both unitary and compound

e.g., BP - may depend on qualification re: posture, etc.

need to deal with individual element inter-dependencies.

<ericP> slide 59: Hard Issues

VK: Is there underlying UML?

SH: Hard issue (second to last slide)

What is actually instantiated in the software object instantiation?

gamut: only core elements represented as objects - all other info are constraints

other end: ALL elements are instantiated as REAL objects (e.g., BP, wt, serium Na+, etc.)

We chose the middle layer as the appropriate layer to model in UML

at the VA - added their own constraint language to UML to model more detail

VK: balance between implementing ALL detail (and including detail in model) for serialization

vs. an Interlingua (where you have to limit detail for it to be relevant)

Of course, too abstract also has minimal utility (HL7 & RIM)

SH: exactly correct.
... Even within HL7 - been work to additionally constrain models to construct templates that are more immediately useful as opposed to being too abstract to be useful to a broad community with a variety of app requirements.
... From purely Modeling standpoint

models should be independent of these detailed application requirements

pick the model detail layer that you require.

EN: How much effort (e.g., code writing) is required to implement

Is it largely automatic

SH: right now, a lot of effort required

There are better ways to add automation to implementation

Should do more education for SW Engineers to communicate what our app requirements are.

is model hierarchy a problem (typical UML & XML Schema problem)

SH: We're very open to SemWeb Tech collaboration

remember: this work is a decade old

also - design decisions made and ran ahead of available tech

in HC IT commercial sector - have immediate needs the

SH: Yes strict model hierachy is a problem

need polymorphism that includes multiple inheritance

both XML & Java get in our way of doing

EN: very useful for us

suggest those interested in HCLS have follow-up discussions

might be useful to have short SemWeb presentation as mapped to the DCM goals

VK: could coordinate that
... Come up with interesting OTF tasks that include OWL representations of elements from the DCM

<eneumann> ACTION: Vipul to set up on folow-up call with DCM and Stan Huff to describe SW standards and uses [recorded in http://www.w3.org/2007/03/29-hcls-minutes.html#action01]

SH: That would be extremely useful

VK: Aware of Alan Rector work in OWL - will include

SH: We collaborate indirectly with Alan et al (at AMIA meetings, etc.)

<vipul> Gotta go now ...

EN: last question

Work around clinical trials - overlaps with Drug Efficacy HCLS work.

Will see the BP example coming up there too.

We can contribute that the followup

Can help inform how OWL needs to evolve.

<vipul> Will follow up with Stan ...

Leave to VK to setup topics for agenda

VK: Yes - exactly what I had in mind

Examples from CDISC and clinical trials

EN: Has SH et al. worked with CDISC directly

SH: not directly - but very familiar with the work - have worked with them in past.

EN: We can help coordinate work with CDISC

SH: great

EN: Thanks SH et al for presentation - will be in touch to coordinate
... Next call a week from now
... continue on demo.

This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/thniks/thinks/
Found Scribe: BillBug
Inferring ScribeNick: BillBug

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: BillBug Bill_Bug EN EP Eric_Neumann Olivier_Bodenreider Rachael SH SS Stan_Huff Susie Tanya_Hongsermeier Tonya VK Vipul_Kashyap aaaa aabb aacc aadd aaee aaff chimezie eneumann ericP gamut remember tn_bhat vipul
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 29 Mar 2007
Guessing minutes URL: http://www.w3.org/2007/03/29-hcls-minutes.html
People with action items: vipul

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report