CIMI MTF Minutes 20130221
- 1 CIMI Modelling Taskforce - Meeting Minutes
- 1.1 Attendees
- 1.2 Agenda
- 1.3 Weekly News & Updates
- 1.4 Outline of Detailed Minutes
- 1.5 Detailed Minutes
CIMI Modelling Taskforce - Meeting Minutes
Rahil Qamar Siddiqui
- Weekly News & Updates
- Review of Demographics Comparative Analysis spreadsheet & models
- Party, Actor, Role
- Person, Organisation
Weekly News & Updates
CIMI 'Terminology & Tooling meetings' @ Tuesday 20:00 - 22:00 TC
Future meeting plans:
Thursday 28th February: CIMI reference model - Proposed updates and related topics
Thursday 7th March: Model mapping and transformations
- Results4Care transformation method ?
- NEHTA template-to-CDA method ?
- Gerard to suggest? (e.g. Valencia & Seville & Vienna) ?
Thursday 14th March: Model instances; and Immunization model planning
Outline of Detailed Minutes
- Review future meeting plans
- Demographics models - Continued from last week
- Person-name structure - Use of ISO 21090 Model for CIMI Model
- Gender and Sex - Demographic Model
- Race, Ethnicity, Citizenship, Nationality - Demographic Model
- Registry - Demographic Model
Review Future Meeting Plans
Linda: Today - the last meeting for demographics models.
Next week - Michael back... get to review the CIMI reference model - proposed update... Goal is to stabilize RIM as much as possible. The week after - model mapping and transformations, even though whole transformation piece is not goal of CIMI... and talk about building up Tooling Apps for members to do transformations of their own. Still hoping for Results4Care presentation... and people from Spain... and NEHTA. If know anyone, please let me know and schedule for 7th of March. Immunization model work - start on the 14th of March. Any comments?
Linda: Tuesday meetings - focus on Tooling.
Harold: We are hoping to settle on tool for our preliminary work to get the value sets into SNOMED. Recommendations in 2 weeks... Goal of getting something in place... Please join in on Tuesday... same time - between 1 Â½ and 2 hours.
Linda: Any other updates before comparative analysis?
Demographic Models - Continued from Last Week
Linda: In previous week we looked at Party and Actor. With Party - a couple of things to tidy up from last week... A couple of row... columns. And in completing NEHTA mapping... mapped to parties but not anything new. To recap, Party had 0-to-many... Maps to the 4 models. Looked at Actor... mapping to... and openEHR. Nothing changed in these. We added scoper last week... in role.
Linda (cont'd): We started to look at person - with respect to mapping person - the most mappings we've had... Two of the extra items... relationship of person to subject of care... And... put on all people irrespective of whether healthcare provider or not. If you can recall... Any party, whether role or actor, can have relationship to another party - that is what these are.
[Linda shows diagram]
Linda: A person is a Party - name, address, contact... But name... more detail... comes from a number of services, but ISO 22220 has a lot of detail. If open up... FHIR, openEHR... have more detail. Want to go into Mindmap for person name. Looked at Given-name... IMH has middle name... We had family name... sequence number and family-name prefix... is a specific type of family name part...
Mark: I believe v3 has all of these as well... just not in there.
Linda: Yes - can you point me to where that is?
Mark: I will get it... if you give me a minute.
Linda: That email from someone at IMH - mentions the v3 RIM... didn't have chance to look at...
Joey: From Tom Oniki?
Linda: Yes - title flag on prefix or prefix flag on title.
Joey: I'm getting it.
Linda: I'm opening up latest...
Joey: Need email to be sent to you?
Linda: No - I have it. Thanks. OK - this is the in EN and ENXP data-types, Mark?
Mark: That sounds right. I will confirm in a second.
Linda: So... I will add a note to the top... EN-ENXP. And I can open that up... just to make sure we have the right thing to map to... Yes - EN and ENXP... That is good to know. Quick look - will finish later. OK - a constraint on EN.
Mark: Yes - entity-name and entity-name part. Sorry - burst of music... Browser opened up 17 windows... [laughter]
Linda: OK - great stuff... And ENXP - EntityNamePart. So part types are Family, Given, title and delimiter. I will do that mapping with words, but hopefully will have similar things to watch.
Mark: Yes - I think part of ISO data type was to make those two consistent.
Linda: Great... I will complete. So have family name... name title... suffix... To show you in Mindmap. A person has a name - reference to cimi-cluster.person-name. Person-name is specialization of actor-name, and actor-name is specialization of party-name, and then we have person-name detail.
Linda (cont'd): So we have the value of the name in person-name. Stephen questioned this last week, but for the moment I kept it as is. We have identifier... part... each has part-number, a value, type, details. A person-name has a use, has a value, date-time range, identifier. We have a date-time range of... and we have usage conditions, status, preferred flag...
Jay: So the structure of clusters allows you to have the scheme of a name in different languages? Do we need to support indexing on the name, or would this be part of the implementation? The indexing allows you to select the right type from the cluster to index on.
Linda: Depends on what you mean by 'indexing'... if you mean the name order preference or the index implementation.
Jay: Perhaps is an implementation detail. OK.
Linda: If you have other info on that... if you think it is a semantic thing... if you could tell us more...
Jay: OK - I will.
Linda: Detailed person-name is specialization of person-name... We have deleted based on discussion with IMH. Title and prefix - based on V3 data-types - the prefix would be a special type of title - Joey?
Joey: No - I'm not sure. If we made a mistake...
Linda: Yes - if you follow v3 data type, then we would be on track?
Linda: Good. Now - nobility-title... here... we changed this to family-name-prefix. Point is - we can specialize title further. Then inside title, can order the title parts... the type of title... is some sort of specialization of... Similarly with given-name... And type has to be subsumed by given name. I assumed middle name is type of Given Name. Have done it as specialization of given name.
Person-name structure - Use of ISO 21090 Model for CIMI Model
Rahil: I have a question. Apologies for coming in late. Are we adding anything in additional to what has been done by ISO 21090 standard? Within 21090... has these different subparts. What value are we achieving by redefining this structure?
Linda: We have been mapping all of the models into the CIMI model...
Rahil: But they could be specific subparts of 21090... And mapping would be to middle-name as defined in the standard. I am looking and thinking - is there anything different?
Linda: Hopefully it is consistent. Are you saying in 21090 that middle name is separate name part type?
Rahil: Yes - a person-name is structured. And person-name has different parts. You have... middle-name... You have preferred-name... And you have... date-time ranges.
Linda: Yes - looks quite similar...
[Linda looks at the pdf]
Linda: And can give quantifier - can be middle-name. So Joey - probably what Tom Oniki is saying that you can qualify with the Title with whether or not it is a Prefix.
Linda: But same with middle-name - if say given-name is middle-name... we can have a qualifier... Might be best to make middle name a specialization of given-name in the hierarchy. I think we are doing the same...
Rahil: Is it worth it - duplicating the effort?
Linda: ...This was discussed in quite a bit of detail in the Reference Model taskforce, and it was decided to start from the openEHR data types, and simplify them in a way that is consistent with the FHIR data types. We also agreed to make these more complex datatypes into clinical models, to allow them to be specialized and extended more easily with local requirements.
Linda (cont'd): Other comments? We also want to be consistent with 22220. Don't want to only consider the attributes in 21090, as some of the other models have additional attributes for these types.
Rahil: If you look at ISO 22220, all of the predefined datatypes and in ISO 21090 are complex data types. So if you have a standard, we want to re-use it. Don't see how this would be done using complex models...
Linda: We previously agreed not to use 21090 as a data type model. And we did not use person-name for data-type because... more clinical content. So I don't see inconsistencies with 21090 except that we have included extra attributes to support the other models. Are you suggesting we push these into the data-type?
Rahil: Yes... I don't see the value in redefining the data-type if we already agreed we will be using HL7... Because it is being used by HL7... a lot of work gone into it... to redefine.
Linda: Sure. These things are used by all of the models. ...making it consistent with 21090 is important. We can revisit whether to include this in data-types in the reference model discussion.
Rahil: Yes - but here, being used as a model. Does not fit in.
Linda: We had discussed previously doing this as an archetype... This allows us to specialize the models even further for direct implementation, and extend them with additional local requirements. And based on the other models being at different levels, and having additional attributes, I think this is necessary. Not all the models we've looked at are abstract models like 21090, but many use concrete name part types. Anyone else have comments? Want to revisit the data-type question?
Rahil: Yes - having a data type and presenting as archetype... complex... need to concentrate on model... and not data-type... It's an effort I think we can avoid.
Linda: Just remember - not all implementations use the 21090 Data types. I appreciate that LRA uses them, but many of the other submitted models don't.
Rahil: You can always have extensions... But to start from scratch and do again... Only because the level of detail... Level of detail we are looking at addressing...
Linda: What about address? Use 21090?
Rahil: Yes - and we extended with our local requirements.
Linda: I think that is okay. If do this as a datatype that is hard-coded in the reference model, then it is not extensible. But if we do as a clinical model then it is extendable. And you have said that in the NHS you need to be able to extend this datatype. The fact that these data-types may need to be extended is exactly why we didn't add them into the Reference Model.
Mark: I don't know if can't extend... It is a question about inter-relationship of CIMI and other groups working on standards. I am not pushing, but that path does exist.
Linda: I don't want to go back on what was agreed before have the group.
Mark: I was not...
Linda: I suggest that you raise this at next week's Reference Model discussion... Do you want to discuss next week, Rahil?
Rahil: Yes. Different persons joined CIMI at different times.
Linda: That would be good if you raised that next week and hopefully the right people will be at meeting next week.
Linda (cont'd): So, basically with the Person Name model, we have same structure as 21090 and ISO22220. Allows you to call family name or leave as generic family name... Similarly we have the suffix. There are other generic parts that can be added, and we have the use-identifier, which identifies this particular use of the name part.
Linda (cont'd): So, in IMH model, they have a usage identifier, in ISO 22220 there is a usage group. Obsolete... and specific identifier for the usage. Need to provide a mapping for all of the models. The date-time range and... should not be in blue highlight since they have not been specialized in any way. Any comments on detailed name?
Linda: OK. So I'll close up name. Inherit address and contact from Party. And Person may have contact person... have type and name and contact... Distinct from generic contact... refers to contact-person... DCM model from Netherlands... So any comments on that?
Gender and Sex - Demographic Model
Linda (cont'd): OK. Gender and Sex. We have the mixture from different models. FHIR, LRA used Gender. 2220 has Sex. DCM has Gender. In FHIM, if Jay is here, you had some interesting specializations of Sex.
Jay: The biological stuff is only there for... Will be moved into clinical... as soon as created.
Linda: So both can be deleted?
Jay: As far as FHIM is concerned.
Linda: OK - FHIM is only... So - gender and sex - I know Nicholas has strong feelings about this... Demographic purpose... But also observation... So have link to observation... Also, Nicholas says... Gender is what is here... and he points to heart.
Rahil: Yes - administrative gender. Sex is part of clinical domain as an observation. Even within gender there is the genetic... Part of the clinical domain.
Jay: Gender could be... if perception... could be as complex as sex.
Mark: From clinician's point of view, it is helpful to know if using administrative gender or clinical gender. So if we describe...
Linda: So are you suggesting we call this administration Gender? Need to provide opportunity to specialize this attribute... but also provide for changes over time.
Mark: Yes - you may need observations over time as administrative gender and clinical gender, which can change.
Linda: Is that what you are suggesting, that we keep this in the demographics as administrative gender, but also allow sex to be added as a clinical model?
Mark: Yes - and both can change. Given surgery and prejudices, both gender and sex can change.
Jay: Can models have both? I see they can have one or the other.
Linda: Yes - I see some of the models have both.
Mark: If you want to make distinctions... It is a lab value or a lab-test value... And the administrative does not have anything to do with it except those who undergo transsexual changes...
Linda: If Gender was an administrative concept, would not have to have biologic sex in the demographics.
Rahil: I was looking at ISO 2222 has sex - what we refer to as administrative gender. But some have both...in the UK, we have person-gender-current and person-gender-past both are sex. But find one being used in administrative sense and other in clinical sense.
Linda: One option of how to handle that is that you can call this gender-sex and each of the demographic model specializations define the exact meaning that they intend, and then if you need to you can link this to an observation in which this was recorded. And if we need current administrative gender, this can be one of them - because there can be multiple...
Jay: If you have more than one, how do you know which room to put the patient in?
Linda: The FHIM model has phenotype and genotype sex. To have special types of biological sex and the administrative gender, these need to have a cardinality of 0..*.
Jay: Would be fine for clinical, but for administrative... why would you want more than one of those?
Linda: If want different type - Rahil?
Rahil: This is the one we looked at. I am not suggesting... Eventually, one gender in demographics - used for purposes of administration... What person sees themselves to be.
Linda: So what type put on form?
Rahil: Yes - so biological sex.
Linda: OK, Jay - I think that answers your question. I misheard what Rahil had said.
Mark: Yes - and administrative sex change just like address. May be outside true scope.
Linda: Yes - we will need to define a Sex observation for this. Thank you for checking that... [Missed some] Is everyone happy with that approach?
Linda: Mother's identifier. Mother's family name appeared quite a bit in 22220, in FHIM, in openEHR. Father's name - only in FHIM. Jay - correct me if wrong. Marital status - appeared in almost all models, not in 22220. Spouse name - only in Singapore model. No one else wanted to know. Defined as text - 0 to 1.
Mark: A local implementation question. In some countries, not allowed to keep person and race as part of record.
Race, Ethnicity, Citizenship, Nationality - Demographic Model
Linda: Optional - OK. In FHIM - you have race-detailed, I assume this is a more specific race?
Jay: Could be the requirement for us is to have races that reach... 6 categories. They roll up and map to broader categories, but the roll-up is not always implemented.
Linda: So - 2 ways. Specialize to race-category and race-details. Other way is to make the Race element repeatable, and then allow local implementations to specialize this as required.
Jay: Could be specialized.
Linda: Great. In Singapore... 0 to many races as well. They talk about double-barrel race... go back... can change your race if one race is more favorable in society. Any other questions on race? All OK?
Linda: Ethnicity - a person's ethnic background. OpenEHR has ethnic-background. LRA has ethi category. v3 RIM has ethnic code. FHIM has ethnicity group-code. NEHTA has... and nothing in Singapore model. All OK with Ethnicity?
Linda (cont'd): Citizenship is interesting... because of something in FHIM models... we have citizenship-country and citizenship... IMH has... FHIM has citizen... The reason I am questioning, I may have deleted the tribal citizenship... IMH and FHIM both dealt with this... I need to look up.
Jay: The FHIM does - for Native American tribes. On the right-hand-side...
Linda: Yes. U.S. models are the only ones. Whether can be handled as specialization of citizenship...
Jay: I am not sure why it couldn't be... Not sure why it is not that way in the FHIM now.
Linda: Yes - let to question of whether citizenship should be citizenship-country or citizenship-nation.
Jay: There is also nationality. What is different between nationality and ethnicity?
Linda: That is true. In Singapore, had nationality... IMH had...
Rahil: Were definitions of nationality and citizenship in there? In UK, the country you are a citizen of is your nationality.
Linda: Different to birth country.
Rahil: Yes... We don't use the word citizenship in records. We use nationality... or country of birth. I was wondering if definitions...
Linda: Yes - some of them do have definitions. We do have definitions in birth-country. Is birth-country different from country of origin?
Rahil: Good question. There is notion of ethnic origin... country of birth... ethnic origin...
Linda: What are they?
Rahil: Ethnic origin is country of origin. Then country of birth would be different. Third is nationality - can change, but ethnic origin and country of birth stay the same.
Linda: Did not have...
Rahil: Yes - did not have... Shrunk down version... Not taken into LRA... local extensions...
Linda: If you could submit a model that have these I can use... I agree - we need to be clear on these definitions... Country of birth - we have in birth data. Citenship and Nationality - Jay - did you raise the question?
Jay: Those terms get used differently.
Linda: IMH model, Joey. Has person-identifier and person-name. I am wondering where that came from... whether health care provider...
Joey: Switch to Mindmap view? So - not a subclass of anything?
Linda: I am sure I got from somewhere... Unless has changed.
Joey: You might have been looking at Sharp model. Go to advanced and search... filter by Sharp models.
Linda: No - looks the same. Very strange... No idea where came from.
Joey: What is it?
Linda: I thought... individual person... Would have beeb in old version? Like on update. Because is a good question - what is the difference... Our definitions need to be clear.
Jay: Definitions differ country to country - one of the problems. In U.S., ethnicity is... or... not...
Linda: Yes - need to include.
Joey: Search on care patient and it will take you there. It is only in Sharp.
Linda: OK [she sees it]
Joey: Models in that are different than IMH.
Linda: So is appropriate to look at these?
Joey: Yes - you can look at.
Rahil: I was wondering... looking at ethnicity... One ethnicity?
Linda: Difference between nationality and ethnic group. We have on... Joey - can you report back difference between ethnic group and nationality?
Joey: Ethnic group - in U.S. - probably Hispanic and non-Hispanic.
Joey: In U.S. - ethnicity - Hispanic and non-Hispanic.
Linda: So... In which case, we have nationality... date-range... May need to introduce the... date-range to support.
Joey: If go to Mindmap.
Linda: OK... Hispanic or Latino, Puorto Rican, U.S... the Nationality...
Joey: So - grabbing the first one... What Jay was talking about...
Jay: there are subclasses of Hispanic... but no subclasses of non-Hispanic.
Linda: Do all feel comfortable with... In the case of IMH or the States... specialize into local or ethnic group... can do with ethnicity. Are all comfortable while people go away and validate?
Rahil: Nationality in States is what we'd call ethnicity.
Linda: Talking about combining.
Linda: Yes - is U.S. where need special... in UK?
Rahil: Map nationality to citizenship...
Linda: So left with Nationality and Citizenship?
Rahil: Yes - OK.
Linda: So - all OK unless do homework and...?
Linda: OK - I kept ethnicity... Don't have ethnicity-value and date-range... Singapore... Now maybe to... Good - please let me know if find out otherwise in week.
Linda: So we have tribal... Jay - we'll have a look. Do you see, Joey? I thought in IMH?
Linda: Tribal citizenship. Can't see.
Joey - are you comfortable with Tribal citizenship being a specialization of citizenship or...?
Joey: Um - not know...
Linda: I meant Jay - apologies. So Jay - are you OK with that approach to tribal citizenship?
Jay: If it is an issue, I will bring back.
Linda: Citizenship-country - we'll use, unless you request otherwise.
Linda: Non-residency. The only model with residency is the IMH. And residency in Singapore is important because there are many non-residents living in country. Are all OK with that?
Linda: OK - good. Religion. IMH, 0-to-1 religions. LRA, 0-to-1 religious... FHIM... Are all OK? OK - organ donor type. IMH - have cadaveric-donor data-type... I've allowed 0-o-1.
Linda (cont'd): We have Birth-date... becomes quite detailed. Birth-date - a date-time - 0-to-1. Birth-date follow-up required. And birth-data accuracy... in 22220... decided we'd include if Use-case. The NEHTA had some birth-date accuracy - whether calibrated from age or... I wasn't sure if needed to include all in model or have as specialization?
Mark: I think you need birthdate to be a date-time, especially twins.
Linda: We do have birth date-time...
Mark: OK - I noticed some do not.
Linda: Yes - we need to cater for time. Agree. OK - move on to Age. Recorded in the FHIM - the age of biological entity and age-group. Can be derived or derived and stored. And... I have date Age-duration. Age accuracy as coded-text and Age-group as coded-text.
Linda (cont'd): OK. Birth-address. Country, region, town... FHIM... birth address. In MOHH - birth-country. Rather than including all of them, I just included birth-address, with all being incorporated within that.
Linda (cont'd): OK - Multiple birth indicator, plurality, birth order... LRA has... 22220 has... DCM has... FHIM has... NEHTA has... So is a real combination of these - OK?
Linda (cont'd): Now - birth sex. Perhaps need to rename and change to something more accurate? openEHR has birth sex. In FHIM - did you say no longer recording the sex karyotype?
Jay: Once again - going to be in clinical package. Can be removed.
Linda: OK - only openEHR has... modeled as an observation... Should we keep in as birth-sex or move out? For clarity - open up openEHR.
Rahil: Linda - 2 models in LRA. Person-sex at registration... no logical sex. But... representation... Considered to be a clinical... included as observation... 2 other models have this notion as sex at birth. Probably safe to have in clinical.
Linda: Coming back to openEHR... Seemed to be duplication in archetype. Need to work out where that came from... Demographics... Was not in person or birth-data... I wonder if it was incorrect. So would remove. Are all comfortable with this? Rahil?
Rahil: Yes - consistent with our approach.
Registry - Demographic Model
Linda: Next - registry - only in openEHR. The Birth Registry is only the openEHR model... Not in birth-data. Not in person. I thought this was in additional demographics - I'll need to check with Tom to where this is. In lieu of finding this in openEHR (which was the only mapping we had) I suspect we can probably delete this, until we find a use case for it - unless it's part of birth certificate. I am going to highlight and investigate further. Some have birth certificate number or a Link to the birth certificate, but not the birth registry.
Mark: Registries are just an organization with collection of observations and demographic data for the birth. Are going to have problem integrating data that are... If conflate name of context with... In some ways, all of birth data except birth weight, is observation at time of birth and whether appear in hospital. Regional registry - have to be accessible across all of those things. If 1 name is 1 thing... difficult to aggregate... must think about. Have to be able to identify as same data or same meaning or time... or don't know if same or at same time.
Linda: Yes - Also, may be recorded at birth or when patient is an adult. May be recording historical data...
Mark: Yes - want to be able to define similar things.
Linda: Similar info about death. I will show you the person-model... Will require some update. We have a deceased indicator - in openEHR, FHIR. We have death-date-time, date-date accuracy, age-at-death - could be derivable. The death-information provider - in NEHTA. The death county and region - going to model the address, death-town, death certificate number. We don't have time to go into biometric data and language. If everyone can have a look - check and confirm mappings offline.
Linda: Any comments, questions before wrap-up?
Linda: Tooling to Tuesday's meeting.
[end of meeting]