CIMI MTF Minutes 20130321
CIMI Modeling Taskforce - Meeting Minutes
- Weekly News & Updates
- Demographics vs. Clinical Modeling
- Laboratory Panel Specialisations
- Terminology bindings and value sets
- And if there is time:
- Finalisation of Demographics models
Weekly News & Updates
- No meetings next week (Easter)
- Last meeting before Leeds on Thursday 4th March.
- Will anyone be travelling at this time?
- Leeds meeting: Thursday 11th April - Saturday 13th April
- Post Leeds meeting
- Lab Results modelling update [Joey Coyle]
- Immunization model planning [Mike Lincoln]
- Other updates?
Demographics vs Clinical Modeling
- When is CIMI information 'demographics', versus 'core reference model'. (isomorphism)
- For example, is 'date of birth' demographics?
- Is 'gender' and 'sex' clinical? (e.g. as an observation)
- Is 'living dependency' clinical (e.g. as part of an 'Activites of Daily Living' assessment)
Note: Demographics data can still have audit/history details recorded (i.e. who, what, when, where, why of each change)
- How do we decide?
- Based on source models - ie. If attribute is associated with 'Person' in source model, then include it in CIMI 'Person' model
- + Consistent with modeling style
- - May propagate inappropriate modeling choices
- Stability of data - ie never or rarely changing data is demographic, all other is clinical
- E.g.: Birth date is stable -> demographic, while living arrangement/dependency may change over time -> clinical
- ? Gender/sex, ? Address
- Information used to identify the person (demographics matching)
- E.g. Birth date, Name
- ? Sex, ? Address, ? Race, ? Occupation
- Is this information only relevant to the Subject of Care? ... or do we want to record this for other Person Participants as well (e.g. Next of Kin, Clinician)
- E.g. Address may be relevant for Next of Kin -> Person demographics
- E.g. Disability may be relevant for a Dependent -> Person demographics
- E.g. Organ donor type may only be relevant to Subject of Care
- ? How to distinguish between information about the 'Healthcare consumer' Role and the Records
- Does this information relate to a specific healthcare event or not?
- Does it record the results of an observation, evaluation, assessment, activity or procedure?E.g. Age, Living dependency, Biologic Sex
- How is it commonly used in systems?
Laboratory Panel Specialisation
- Where to use LOINC codes?
[Linda goes over the Weekly News and Updates (see above). She states that there will be no meeting next Thursday, which will be Good Friday for some CIMI members. Therefore, the last meeting before the meeting in Leeds will be on April 4th.]
Linda: Any travelers on the 4th of April?
Daniel: I'll be traveling.
Stan: I can join the meeting.
Phone: I will be traveling - in Chili, but can join.
Linda: Leeds will be from the 11th of April to April 13th.
Linda: Joey - [Lab Results modeling] - Mindmap with ADL - how is it going?
Joey: Well - not to the ADL generation yet... Just figuring out the code... Updates next week...
Linda: Thanks, Joey and Patrick. Immunization modeling - Mike? Do you want to talk about this?
Mike: I'll probably leave this until the next meeting. I'll talk to Galen first.
Linda: OK - in two weeks' time. Good timing. Thanks, Mike.
Linda (cont'd): Last week - person archetypes for demographics. This week - when piece of information is in demographics vs. when in clinical modeling. Want a short discussion - get peoples' views on that. Also - some ideas and suggestions. Question - when is information demographics vs. clinical. For example: date of birth - demographics or clinical? Gender and sex - demographics or clinical? Please note that demographic information can still have history / audit-trail recorded, where required? How do we decide when is living dependency part of clinical and when part of demographics? I've come up with suggestions. How do we decide?
Linda (cont'd): Based on source models - if attribute is associated with 'Person' in source model, then include it in CIMI 'Person' model. A 'plus' is that this is consistent with modeling style. A 'negative' is that this may propagate inappropriate modeling choices.
Linda (cont'd): [Second possible way to decide is to base on] stability of data - i.e. never or rarely changing data is demographics, all other is clinical. E.g. Birth date is stable, so is demographics, while living arrangement/dependency may change over time, so is clinical. [Gender/sex? Address?]
Linda (cont'd): Third possible way is information used to identify the person (demographic matching). Eg. Birth date, name [sex, address, race, occupation?]
Linda (cont'd): Fourth - if this information is relevant only to the subject of care. If next of kin can have an address, may be relevant for next of kin - [do we want to record this for other Person Participants as well, e.g. next of kin, clinician].
Galen: Because next of kin is not subject of care, it sounds like it goes on person?
Linda: Person is for recording information on people involved in care, not just subject of care. We have clinicians and next of kin, etc. where the person-information is relevant to health of subject of care. So you might say next of kin has an address and preferred language. So - disability may be relevant for a dependent person ... or may only be relevant to subject of care.
Linda (cont'd): The 5th possible deciding factor - Does information relate to a specific healthcare event or not? So if it records the results of an observation, evaluation, assessment, activity or procedure... [e.g. age, living dependency, biological sex]. So there are four factors we could use to decide if the information should be recorded in a clinical entry or in the demographics... So #1, could let them decide whether or not this information is only relevant to the Subject of Care, or could be relevant to other People; #2 Does this information relate to a specific healthcare event or not?, #3, based on the source models, #4 Stability of the data.
Stan: To be specific, we have 2 choices. One is the question - how much of this information do we want to be in Core Reference Model vs. how much... created as an archetype or cluster or... at another level? And other question - demographic vs. clinical. A key part is - what are the implications? If we talk first about how much of information is in... So spreadsheet - is this what we'd put into the Core Reference Model or archetype...?
Linda: The intention of these demographic archetypes is that this is information that would be put into an archetype construct associated with an entity or-actor, such as Person, or a role, such as Healthcare Provider.
Stan: So - core model - patient... Anything ID... Is that all there is in Core Reference Model?
Linda: Yes - except each Entry has and Information Subject, so if want to put something about fetus or family history, then can.
Stan: So - all the information we are talking about is archetype-able data. So - do we make a patient with a lot of attributes or a person with a small set of things and make all the other appear like clinical data? Although I hesitate to say clinical...
Daniel: Depends on complex items... could be demographic or clinical. So, for example, in delivery... could be clinical... whereas in some models might be considered demographic. So might be in conflict depending on context.
Linda: Yes - good point. Information in demographic archetypes, as opposed to the Core Model.
Stan: So just another kind of isomorphism. Not trying to dictate how represented. So could have a skinny person and... or patient have nothing but id# in patient record and all else in more typical database. Whereas someone else can have all kinds of things, including military information... So not fixing what should do... But, should have one preferred model where we'd create services and interoperability.
[Lost Stan's voice for a while... then he returned and repeated what he said while offline]
Stan: So the idea is another form of isomorphism. Not dictating how represent in databases. But we agree how we do it for interoperability. If those in my standard data record, I need to return according to information model we agreed to. So my job is to put into... what we agreed as standard patient. So... we say we've chosen what we see for interoperability... recognizing that no one's database must conform to this... So not unlike other things where we have isomorphism, the interoperability is achieved through a standard API.
Galen: I thought I would mention... in FHIM, we had similar discussion... gender vs. biological sex. We decided to keep administration gender since is used... whereas the biological sex is an observation, so we moved it out because is possible that multiple observations might be... So... pushed the other type of things to observation - eye color and blood type.
Mark: That is a good approach because if think of too much as clinical, every time someone is moved... duplication... whereas what Stan said... minimum step for interoperability vs. maximum step where have everything. So probably for each implementation, is a minimum set... Date-of-birth, sex, address and a couple of identifiers... And going along with Galen... biological sex... don't want in... pool.
Linda: Both Galen and Mark talk about ... if information is recorded in another part of record. Don't want duplication. I also heard... In Singapore, if want address of next of kin or other participant in record, would not put this in the core, want to link to next of kin more closely. So I think we need to look at examples. So what does this mean? We have contact person - not be used to identify the person. .. but hard to see this being recorded as an observation. So I think it falls into demographics category. Any thoughts?
Daniel: Whether these are contacts relevant for a specific procedure... If that would be a common across... contact persons... a lot of difference... with specific roles and different procedures. Relative to the context.
Linda: Good point. I believe we have contacts on the roles.
Stan: Normally we collect contact person in encounter... Collect like an observation. If another person comes by... we pop up screen and collect on that person. My bias would be to not include as part of demographics.
Linda: So for the information we don't include in demographics, they would be included somewhere else?
Stan: Yes - we need these. Would make same as mode a hematocrit... not lab data, but could be 'clinistrative' - clinical data that has administrative importance.
Linda: So, DCM model that includes contact on person would have to map against the 'clinistrative' entry.
Linda: OK - only one model that puts in demographics.
Daniel: So - what are we doing here now? This list... have removed... is this a Core List of demographics data? A contact person with names, contacts, phone numbers... still demographic data, but is relevant to healthcare in a specific way? So - demographic in nature for subject of care?
Linda: Identify specific information that we would pull out of demographics and put into patient record.
Stan: Yes - what things we want to be attributes... subject of care in that model... and what things we would place in other data about patient in other parts of record.
Linda: This is not just about patient or subject of care... can be used on other people who participate in record. So we need to check with DCM that they don't have a requirement for this to be used for other types of People.
Stan: It wouldn't exclude its use... but have to have a way to map to this, which may not always be obvious...
Daniel: Contact person - would still be demographic data... just that it concerns this other person... I don't think we are distinguishing what is demographic and what isn't. I think we are deciding what to keep in subject of care model. Is that right?
Linda: Not subject of care model - it is any person model.
Stan: Good distinction. So how do we then go on to make model if subject of care? Is that a type of person?
Linda: We have Health Care consumer... which gets the attributes of person, but also the donor type, diet etc... only relevant to patient and not to other persons in record. Does that make sense?
Stan: Yes - we are making a model for person and would also have a model for subject of care.
Linda: Yes - so whether we call this person or subject of care or... any person that participates in record. So we were looking at any person, and the DCM model is for any person.
Galen: Yes - Any person can have a contact person. Not have to be subject of care.
Linda: Great. So - would keep in demographics, Stan?
Stan: I'm OK if all comfortable. But in real working systems, only one does that.
Linda: So Galen, if I am missing FHIM, would you be able to provide?
Galen: Yes - I'll send it to you.
Linda: So - OK to leave in demographics... other people to have contact person... OK?
Linda: We decided... Gender and sex should be observations in the Core reference Model and only the administrative gender should be in the demographics. So presumably this should stay in demographics. OK?
Linda: OK - mother's identification, mother's family name, father's name and marital status... FHIM has against person.
Galen: Yes - in US, these are used to identify the person.
Linda: So not just about subject of care, but about others in record - Yes?
Stan: I see marital status - pertains to family units and family history... the most current marital status... not used to identify an individual... in a different category... My bias is to put in clinical data and integrate.
Mark: Did you mean administrative or clinical?
Stan: Rather than class, I would put under own name.
Mark: In RIM, a different role- relationship... One would scope the role and the other would be a target...
Linda: The mapping I have for RIM is marital status on the person Entity.
Mark: I will double-check.
Linda: So a lot of models... where you record as any person who participates in record... changes over time as you say, Stan. If... that has a marital status, that...
Galen: We need for employment/tax information. We don't need to know about everyone... optional. But need for more than just patients.
Stan: We can include marital status on people other than patients by making specializations. I don't think it implies high overhead...
Linda: Expand on that?
Stan: Create derived elements on person... could be providers or employers or... So, we may not provide marital status on Next of Kin ...... but could include marital status in those classes rather than person...
Mark: I double-checked marital status and it is on person.
Linda: Thank you.
Stan: So I would be OK because common practice, not that it would be harder to implement.
Linda: OK. So spouse name. Used in Singapore... even though in person... the question is... is only used on patient? If so, push down to the healthcare consumer specialization.
Linda: OK - move to patient. OK have race and ethnicity... We talked about this being administrative. In Singapore, you can change your race... depends on what is beneficial at the time... Father and Mother race... Is everyone OK with leaving that in person?
Linda: Great. OK - citizenship. Used in IMH model. Core record or just in person? How used?
Stan: I don't know. Joey?
Joey: Let me look.
Linda: FHIM - citizenship against person, so this could be used for either Patients or non-Patients.
Galen: We didn't have a Use-case for non-patient. If something is an attribute of role of person at the time - we put on role. If on multiple roles, then we put on person. In this case, we didn't have multiple roles, but we still left on person... but we could be swayed either way.
Linda: OK - I see the advantage of leaving on person is... to have... recorded... but if anyone disagrees, let me know.
Joey: The citizenship... contains code that... suggests using ISO3166 ...
Linda: On person or patient?
Joey: On person.
Linda: And FHIM is on patient, but could go either way. So do we put on patient?
Stan: OK either way.
Linda: If undecided, I propose we follow source models... unless we think is correct and should really be on patient. IMH is on patient... Having information on person provides more flexibility. So I will leave unless someone feels strongly.
Linda (cont'd): Another - religion... on person. The RIM puts this on person. OK to follow the RIM?
Galen: We followed the RIM on that.
Linda: OK with you Stan?
Linda: So - how can we speed up? We have birth date... all using as demographics on person... may only be relevant to subject of care... LRA has birthplace ... but Rahil not on the line. Some may argue that keeping all the birth details together is neater, but...
Stan: I object to the age... I don't think that should be here.
Linda: Age can be stored or derived and based on birthdate.
Stan: But age at point of time which is not specified here, so... need to associate this with a particular event.
Linda: But may be it is derived based on the current date.
Stan: Yes - another reason I would not put it here.
Mark: If all you have is age, you would have to say what is date of record... whereas, if have birth date, then this can be calculated.
Stan: Yes - used in systems. Age at time of admission or diagnosis or death. Always in relation to some other thing. This here is fixed, but could change... this should always be modeled as an age modeled as attribute on some other event... part of encounter...
Mark: Yes - logically isosemantic to having a birthdate. Always want birthdate or approximate of person. If store Age... this is at specific date and time. If that was all you had and fill in approximate... Always want birthdate as demographics... but age always one transformation away...
Linda: So Age... But in this context - derivable on date-time. But... does not have a date-time to calculate... Then that is an argument for it being moved. All agree?
Linda: Moved to event-specific records. And not exchange... interoperability.
Stan: The other three are the same situation. Birthdate-age-accuracy and birthdate-age-group...
Linda: All OK? And... other birth-data... A bunch are included in RIM.
Stan: What is birth-data details?
Linda: That is... The openEHR model had a slot for country-specific birth-data so I just included this as an extensible attribute... to have a mapping for openEHR extension mapping.
Linda (cont'd): So I was hoping to get into other topics. I am hoping we can cover some other topics - so it may be more productive to do the rest of this offline. So what criteria did we use in the examples we discussed ...
[Linda's notes #5 - Does this information relate to a specific healthcare event or not? Does it record results of an observation, evaluation, assessment, activity or procedure? ]
Linda: ...adding "Age, Living dependency, Biologic Sex". We also have whether or not it only relates to the subject-of-care, or to other people as well.
Stan: Another way to say - how is it commonly used? If others have modeled and implemented it in systems, then that is a way to model since is easier... already modeled that way.
Linda: OK... I suggest that we take this offline, as we're running out of time. If time in next meeting, we can do this. Can we move on? Or another attribute now? Stan?
Stan: Yes - move on.
Linda: OK - Lab Panel... Thanks to Joey for sending Panels. I looked at CBC with differential. It seemed appropriate to model CBC as one archetype and then... differential since had common parts. So I'll show and see if all agree. So I am showing CBC with manual differential. Can see... CBC panel... So all of CBC would have these features - is my assumption, and all...Joey?
Joey: I am not following. So there is an automated diff and a manual diff done by technician?
Linda: So code 58410-2 (Complete blood count (hemogram) panel - Blood by Automated count) appears both in the Manual differential panel and the Automated differential panel. What is different between these two panels is in row-16 down. The manual diff panel is under the microscope. And row-16 in the automated diff panel includes the auto diff. So I assume rows 3 to 15 are in common between these two ... and row-16 down is manual specialization?
Linda: OK. So I tool Lab test observations model and specialized into CBC which includes the Complete Blood Count by Automated Count. So Test observable has a Test name of 'Complete blood count'. And I have tentatively put the specimen as 'Blood specimen.... Is that right? .....
Joey: I think is whole blood.
Linda: So is OK that is descendent of blood specimen?
Stan: Is anti-coagulated blood.
Linda: So that sounds like specific mapping?
Daniel: Whole blood sample would be the most appropriate binding.
Linda: In specimen hierarchy.
Daniel: That is a blood specimen.
Linda: Have code?
Daniel: 258580003 - whole blood sample.
Linda: All happy with that?
Linda: So we have a test result group. I got these from Joey's LOINC spreadsheet. Inside that, I took the first 5 rows. We agreed we would prototype the first five to see agree on how this should be done... and then hope to automate, Joey?
Linda: We have leukocytes by automated count - with a cardinality of one. I'd like to discuss the datatypes and units. Decision was to use SNOMED units. One was numeric or string. But all seem to be a Quantity in CIMI. So look at...Leukocytes in blood by automated count.
[Linda shows Mindmap]
Linda: Let's talk about units - SNOMED? Is that valid?
Mark: If meet all of your Use-cases - Yes. If not then use UCUM...
Stan: If not in SNOMED, we will add. The question is, if we want to use UCUM codes or not ... So, gets treated as code - code-set.
Mark: That works. Easier on implementation.
Linda: So - 10 to power of 3... 10 to power of 6. Mapped to SNOMED as an extension... So sounds like we are in agreement. Next - data-type. I thought safe to use quantity. Data-type... numerical string. Hemoglobin... I've made it a quantity.
Joey: I think it was Hematocrit that had string.
Stan: I am trying to think why we did that in LOINC and why not numeric...
Joey: Yes, why only that?
Linda: ...Hemoglobin has a datatype of NM or ST.
Joey: Yes - not make sense why hemoglobin.
Linda: So all OK with making that into a quantity?
Linda: Units is assigned the SNOMED values for the gm/dL.
Stan: I think I know why we are doing it this way, because how much Mindmaps are... but should be their own model that gets included... but have to include this in manual diff?
Linda: Yes - but only physically.
Stan: Yes - because what we have to do to get Mindmaps... but when Joey does this, not have 2 duplicate... leukocytes?
Linda: Yes - only defined once in actual archetypes.
Stan: Do you want to... or just make independent models rather than... because other situations... a common element between 2 models... Not sure is valid always to think of as hierarchical... generic blood count.
Linda: I think so... but I think it has advantages doing it this way...
Stan: If you think of sodium and potassium - can be parts of 100's of different panels as individual elements. Don't want to have master panel and then... a Chem 6 and Chem 7 and Chem 8 and...
Linda: Yes. In this case is an advantage... Just having a cluster model is useful. If LOINC adds, we can add here rather than separate panels and it will trickle down. Not sure.
Stan: Say again. You have the thing that is identified by 58410 - only one of those... duplicated... only happens in one place.
Linda: That is true. If cluster, then only one, and then this is include in both places. Yes.
Stan: We made something that doesn't have code 4. No LOINC code that is parent that subsumes both CBC with automated diff and manual diff. We would have to make LOINC code... This thing would be called CBC with diff where diff is not specified.
Linda: So CBC is always associated with diff of one type or another?
Linda: Oh - yes... then...
Stan: Yes - we need 58410... for sure. Maybe we can go back and look at this again ...
Linda: 58410 is associated with the cluster. And in order to be a separate entry a CBC without a differential panel needs to be a sibling of the differential entries.
Stan: OK - so on left-hand-side... CBC... what is that?
Linda: The thing without the diff panel.
Joey: What is the LOINC number for that?
Linda: No LOINC according to Stan. You can argue the 54810 is both the code for the Entry and the code for the Cluster.
Stan: No - don't want to call the same thing... different names.
Linda: So have 2 CBCs - manual and automated?
Stan: My point. In nature - you can have a CBC that is automated or CBC that is manual. In nature - no CBC that is neither automated or manual.
Linda: But can have CBC without diff. What is that?
Stan: Either automated or manual.
Linda: So - no CBC without diff panels?
Stan: No - one axis. Whether CBC is automated or manual. And other is differential, and whether that is manual or automated.
Linda: OK - can do CBC without a differential panel?
Stan: Is 58410 if automated, and different number if manual.
Linda: And 57782-5... that one groups together the automated count with manual diff and the other... the automated count with automated diff.
Linda: So auto count with diff - what codes are used?
Stan: 58410. Its name refers to the collection of individual tests. I may not be understanding how you modeled.
Linda: With CBC with manual diff, it inherits all the properties of the CBC. What distinguishes it is whether the differential is manual or automated. I have CBC with manual and CBC with automated, so we could include the CBC automated count in both, and no generalize these, if needed. You would then have to choose with manual or automated differential in order to populate. So if we do this, then it allows you to use either one or the other.
Stan: OK. My way of thinking - 3 things. CBC - no diff. CBC with manual diff. CBC with automated diff. Is that all we modeled, or did we model a parent that had either automated or manual diff - which I think we don't need?
Linda: So you are saying CBC with automatic differential and CBC with manual differential... make them siblings?
Stan: Yes - no inheritance.
Stan: To create, you need to create something that doesn't exist. Can't... So, to make inheritance, there is a virtual type with CBC and either/or automated or manual differential. So that does not exist in nature and not provide value... Want to ask - is this a CBC? And I can answer - either by itself or same name... and 2 subtypes - automated or manual. So I don't know the value of having a common parent.
Linda: By not having a common parent, it changes the way you query. The other part is, if we semantically consider a CBC with automated count, then the semantic relationships would be there, and the only thing you are gaining is to not have the abstract entry. If CBC with differential is not a CBC, but contains a CBC and a differential panel. Chem7 - contains a sodium, but is not a sodium measurement. So query semantics - I want to query all that contains a sodium, not is a sodium measurement.
Linda (cont'd): I think... If had as sibling models they would each be an entry. And CBC with manual Entry would not contain a CBC Entry ... It would contain a CBC cluster. And at the cluster level they are all siblings.
Stan: So this is important for me to understand. Is there another way to have Entries contained in Entries?
Linda: Entries cannot contain other entries.
Stan: So you could have one cluster - CBC; another cluster - CBC with automated differential, and a third cluster 'CBC with manual differential'. Each of those could be contained in an entry.
Linda: We have modeled CBC as a cluster, and manual differential panel as a cluster. Now - CBC with manual differential as entry, and entry contains these 2 clusters.
Daniel: I am getting sleepy, but I don't understand. If you have a result with only Hemoglobin, how could you compare those - the hemoglobin that is in a cluster and the hemoglobin in a panel? How would you compare two single hemoglobin?
Linda: The hemoglobin - as a single data element will have the same semantic code irrespective of where it appears in a cluster or as an individual element.
Daniel: But would be the... observable... describing the outermost level of entry. So Hemoglobin would be in Observable, but not in Test Results?
Linda: Yes - if outmost is hemoglobin then that is what would be performed. So in case of LOINC, this 58410-2... CBC... used as describing the whole.
Stan: Yes - from LOINC perspective... it is just a collection of tests
Linda: So... based on the CIMI reference model... this panel (Row 3) is done as cluster and row2 is done as entry.
[Linda on mute, so not heard during meeting]: However, to represent a CBC with no differential, we need an Entry to represent this, as everything in a Composition needs an Entry.
Stan: I need to understand more... is worrisome. I shouldn't need to know if the thing I am modeling is entry or part of a cluster. Let me ask - might clarify. So - no reason - probably in the world, bigger things - entry with patient's blood type and CBC with manual differential. The CBC with differential... defined as entry... I can't put in... I am fixing the model as opposed to...setting the things I want to put in a particular entry.
[Linda on mute, so not heard during meeting]: In the CIMI Reference Model, all clinical information is contained in Entries. An Entry can contain clusters, which can themselves contain clusters - however an Entry cannot contain another Entry.
Daniel: Another issue - should there be an observable cluster and in the cluster further down in the result cluster... At least should be the same code to bind at least part of the result and the observable... at least in the outermost... So probably the name, specimen, at least... I don't know if you have more... observable... overlap... Don't know if there is a method. So these clusters that are used in this model - would it inherit from some generic result cluster?
[Linda on mute, so not heard during meeting]: The Observable cluster contains all those properties which may be pre-coordinated into the name of the Entry's outer panel or Observable - this includes things like 'Point of care test flag', which is only in this outer level. The Observable is the Observation that was made, or the Test that was performed in response to the request (if this was performed in response to a request). The Test Results cluster then contains the results of the Observation or Test, including all the tests contained inside the requested test. This is also how Heart Rate is done, where the Observable is 'Heart Rate', while the Test Results contains 'Systolic' and 'Diastolic'. This reduces the level of nesting required in the results, and allows us to provide a list of all the individual tests or panels that make up the requested 'Observable'.
[Linda off mute]
Linda: Yes - CBC... cluster inheritance from generic... So 3 clusters... the manual and auto siblings... Which is what Stan wanted to achieve. The manual and... so siblings at cluster level. So - would be great to have something [another discussion] offline... The three siblings... We can't have an entry inside another entry. How would you like to proceed?
Stan: I just need to understand. We have a CBC by automated and a manual...
Linda: And they both have siblings.
Stan: The thing that says test results cluster... and that would correspond to the LOINC code... the one at the top...
Linda: The 57782-5...
Stan: And the thing in the middle - that is the entry.
Linda: The entry has more than the results... it has the Information Subject for this set of results... it has all the actions... and the associated request that these results are in response to.
Stan: So I am thinking... what is the Entry? That is a different thing... should have a unique identifier... not have a LOINC identifier... only those name clusters will have a 1-to-1 correspondence.
Linda: So that raises another issue. Where do we use SNOMED CT for the meaning, and where do we use LOINC?
Stan: Let's not conflate...
Linda: My point is... And if a generic CBC, how do we say CBC without differential? So we can have another specialization of CBC that allows no other... and that will be a sibling. We are running out of time. OK if I put this back on agenda? Also - a topic... whether to discuss this in the face-to-face meeting. Also - topic of terminology-binding and value sets.
Linda: Any other suggestions? If have any suggestions, please send on email. We'll meet in 2 weeks.
[end of meeting]