CIMI MTF Minutes 20121220

From CIMI
Jump to: navigation, search

CIMI Modelling Taskforce - Meeting Minutes

Thursday 20th December 2012 @ 20:00-22:00 UTC


Attending

Linda Bird

Galen Mulrooney

Gerard Freriks

Mark Shafarman

Rahil Qamar Siddiqui

Jay Lyle

Joey Coyle

Thomas Beale

Sarah Ryan

Eithne Keelaghan


Agenda

  • Weekly News & Updates
  • Re-examine the use case for TERM_MAPPING in the reference model
  • Lab Report Header
  • Patient Encounter
  • Demographics
    • Approaches to review:
      • openEHR
      • NEHTA (Participation)
      • NHS LRA
      • HL7 v3 RIM
      • FHIM (Federal Health Information Model) Demographics model
      • HL7 FHIR (Organisation, Person, Patient, Agent, Group)
      • ISO13606 (Standard and Draft; consider Contsys)
      • ISO22220
      • MOHH
      • DCM
      • IMH
    • Scope of 'PARTICIPATION.performer'
      • Person
      • Subject of Care
      • Healthcare Provider
      • Organisation
      • Device
    • Participation.location - separate cluster

Weekly News & Updates

  • 2 weeks break. Next meeting - January 10th 2013
  • Scottsdale January 18th - 20th 2013
  • Terminology meeting: We identified 3 different categories of value sets:
  1. Clinical value sets - For these we will try to always use SNOMED CT, with the addition of CIMI extension concepts where required. The terminology_id will be a URL that refers to SNOMED CT.
  2. Non-clinical value sets, with a single authoritative 'source of truth'  (e.g. IANA media types) - For these we will take a copy of the value set into our terminology server, so that the values are available during the authoring process and instance generation. The terminology_id will be a URL that refers to referenced code_system.
  3. Non-clinical value sets, with no single authoritative 'source of truth' (e.g. participation mode) - For these we will provide a maximal set of terms that provides coverage of all member's value sets, and include a hierarchy that indicates the relationship between a value and its specialisations. The terminology_id will be a URL that indicates that this is a CIMI value set.

We have also previously discussed a general principle that those value sets which may be used to define another clinical concept (e.g. 'units of measure' may be used to define 'medications' with strength), would also be represented using SNOMED CT, to ensure that the concept definitions can be incorporated into SNOMED CT.


Detailed Minutes

Linda: Weekly News and Updates. I looked at terminology mapping. Require a value set for... Also Lab Report Header... Look at Patient encounter... Demographics - look at models out there. How to tackle the demographics work. And a few questions. Add? Change? Last item - model review.

Linda (cont'd): Weekly news and updates. Two week break. Meet back on Jan 10th - one week before Scottsdale. So we would have to review what we want to cover over break. Can review models and value sets. All OK?

Galen: I will stay at HL7 hotel and rent a car so I can drive people to and from meeting.

[Linda asks meeting attendees if they are going to attend Scottsdale, and if will be on gotomeeting]

Linda: Any other weekly news or updates?

Linda (cont'd): Just want to quickly review the terminology meeting. We identified 3 categories of value sets.

  1. Clinical value sets - For these we will try to always use SNOMED CT, with the addition of CIMI extension concepts where required. The terminology_id will be a URL that refers to SNOMED CT.
  2. Non-clinical value sets, with a single authoritative 'source of truth'  (e.g. IANA media types) - For these we will take a copy of the value set into our terminology server, so that the values are available during the authoring process and instance generation. The terminology_id will be a URL that refers to referenced code_system.
  3. Non-clinical value sets, with no single authoritative 'source of truth' (e.g. participation mode) - For these we will provide a maximal set of terms that provides coverage of all member's value sets, and include a hierarchy that indicates the relationship between a value and its specialisations. The terminology_id will be a URL that indicates that this is a CIMI value set.

Linda: Next item - look at lab report header. We started to look at that.

[Linda shows spreadsheet]

Linda: Lab Report Header: FHIR, MOHH, HL7...

Linda (cont'd): I had a few questions for Graham from last week. Graham's response on the report version was that this was usually a combination of the organizational-issued report and the time-issued. And the resource version id depends on how many versions the system has seen before (they may not have been sent all the versions). Based on that, the version id is more of a technical thing, not a real world. Now which id is the real-world... Do people think we need a technical version or instead use the date-time issued as the version-id?

Tom: You can follow the info you get in messages, which won't be version id, just their times. Wouldn't want to mandate... With messaging, a lot of inferencing - not like SNOMED. What version, what update... What kind of... document...

Linda: So we would exclude these as not real-world, but more technical. Does anyone use versions numbers in their reports?

Galen: I will have to check.

[on Phone/Jay?]: I don't know.

Linda: Please check.

Mark: Just came back.

Linda: Yes - ask if in Lab Report Headers. Should we include version # of report? Graham said date-time would be used.

Mark: Depends on if Lab Report includes... Lab report has version. If Pathology report is included, we have to figure out how to do this. Pathology Report has addendums, and from preliminary to the final. Sometimes have to be reissued with addendum and sometimes have version#. Sometimes version# at the document level, i.e. pathology reports done as clinical documents - such as surgical reports.

Linda: So - should leave version# in?

Mark: In regular lab, not do this.

Linda: OK. We'll leave it in. Please all give feedback.

Linda: Status and Report Type last time. Diagnostic Service and Specimen - we already have these. The Reason Report was generated - in HL7... clinical document/purpose. The clinical Synopsis was mentioned by someone. The Conclusions - in FHIR and MOHH & NEHTA. Recommendation was in... Dutch model. Comments I thought was in FHIR model. Report representations in FHIR and openEHR. Report Link in MOHH. Diagnosis is in FHIR & NEHTA.

Linda: Any questions?

Linda: OK - at Groningen, we spoke of action information.

[Jay]: Why is Recommendation included if no one is using it?

Linda: Added at Groningen because William said this was in Dutch... But we haven't yet seen the model with this in.

[Jay]: OK - just wondering.

Linda: I'll note down this - to get a copy of Dutch Model. You're right - should have justification for each of these verbally added.

Linda: Action Information, Authority action, Author themselves, Author..., Issued... In the Singapore model, we have notion of Custodianship. It seems to me custodian is another action. I never thought of it as a verb... is everyone comfortable with this?

Mark: All of this is participation of people, places, things in the report. Usually, custodian participates as record-keeper and the author as author. We probably want to distinguish between normal actions in lab and actions that are order-type. Not to do with single report, but with things planned as a result of report.

Linda: In Groningen - we talked about an action-cluster for participants, date-time... grouped together. These actions may reference one or more participations. You may, for example, know the date-time, but not the participant. Is that what you suggest?

Mark: I am saying - your example of actions are people, place, things that participate in generation of report. The others are a result of the report... should be separate.

Linda: Yes - these actions refer to participation in document itself. These refer to lab result and lab-result item... The action of observing, interpreting, approving, reporting, and canceling. Those are similar to participation, but class... in model allows function, time, mode... instead of cluster, as we have done.

Mark: It is a less general way. Since these are all participations. And if you have a single model for participations, it is less confusing. Here it is a subclass of action.

Linda: Yes - interesting point. NEHTA model for participation - going to ask if they have a location. At the moment, must have the party identified. But is going to... would have to have party... optional? Also, might know date-time.

Mark: Do we allow generic participation...?

Linda: Yes - questions for demographics. Most models include... but some have... Probably rather defer that discussion. Joey and Tom? [They were involved in the Groningen discussion in relation to actions]

Joey: What is the issue?

Linda: In Groningen, we discussed... in order to keep the timing, location, participants together with action, we grouped around action. So we have the reporter, the author, the reporting organization all grouped around the related action. Mark says this sounds like participations and if we make Participation extensible we could model these as participations...

Joey: I don't understand participation enough, so instead of action, group has participation?

Linda: Yes - So participation: function, time, mode - example, face-to-face or over phone.

Joey: Is the function the action they do?

Linda: Tom?

Tom: It is the type of activity they are performing in relation to overall.

[Phone-Joey?]: It seems like the... what we call an action is a participation. Thomas - is there a difference between our attribution and participation?

Tom: I would have to look at it in more detail.

Linda: Some things like location are in ISO13606-1's Demographics model, but not in others... So if we did use participation, question is, would we extend with these things?

Tom: My question - no point creating complex model in the actual archetype so end up with data models that would never have real data. There is a danger of over-engineering. I'm not saying that is what is happening here.

Cecil: Action-relationship. In simple cases, have a 1-to-1 relationship, makes sense to use participation. But if we have the location and reason, then these are talking about the acts themselves.

Tom: That sounds like a question of cause of relationship to me... an order...

Cecil: I am bringing it up because HL7 model and NEHTA model. Relationships between acts and entities - when do you use these?

Linda: What is model called?

Joey: Attribution.

Linda: [brings up CEM browser] Attribution has the start and end-time. Has participant. Has patient-location as opposed to provider-location, which is interesting when not face-to-face.

Mark: Reason is relationship between one observation and another. Or reason might be - why did I order this observation?

[Phone - Joey?]: We are basing on action, not participant. You can group on participant... But main part is action - any action that can occur... the reason for that action.

Mark: And I am saying - some of those actions are necessary for complete report. You need a specimen... and some because we are checking to rule out disease. So if don't rule these out - complexity. These are Links.

Linda: I think could be handled by coded reason or link...

Mark: We need to be clear. There are 2 reasons something noted in patient-care that is related...

Cecil: Yes. What you introduce is ambiguity... depends on type of Use-case.

Linda: So we have 2 alternatives. First - to model actions in participation and add other information about participation.

Mark: Or link between 2 observations. Reason for could be a Link to diagnosis. So have 3 Use-cases, which should be separated as they have different semantics.

Linda: But are you suggesting that the activity details should be recorded as separate entries?

Mark: No - author is a participation; receiving lab is a participation. That is directly related - who signed, who responsible. Rather than - I am doing this because I made diagnosis. This is different. If these observations appear in the lab report because of how linked - will have to look in 2 places - adds complexity.

Gerard: Unless you give things different names - then is a semantic link. This is who authored the report, the discussion, the participation, the action and the semantic links - confusing.

Rahil: In the IMH model, is attribution a common model for administrative activity vs. clinical-activity?

Linda: Yes.

Rahil: And Mark is saying we should separate out so are clear. Separate reasons and methods... for participation, adding meta-info - the custodianship - not have clinical reasoning - separate these out. So participant model is one thing and clinical model is another.

Gerard: Yes - these are... clinical things... we must use different words.

Linda: Might be non-clinical actions like approval...

Rahil: In LRA - we had the committal function, the composure function, and the attestor(?) function. And these were functions and you could add other functions - participant model. Then we had other activities - clinical activities, etc. - and these where linked using semantic links?

Linda: Yes - I think that is similar to the requesting lab test, which could either be a semantic link or an identifier. I think this is similar.

Rahil: So spreadsheet with action issued. Is that where you are parking the function for...?

Linda: Yes - the actions are modeled by IMH to group together those properties that relate to the same action ... if model as participations, that would require us to extend this class with attributes such as time and location and make the performer optional.

Rahil: Because you may not need to identify the party, or the participant...?

Linda: Yes - may not know the participant, but know the time.

Rahil: Attribution model - doing 2 things at same time? May not have participant, but have... ? Another - talking about lab report - want to know who authored it...

Linda: No - not the reason and method for report, but is reason for action occurring...

[Phone-Joey?]: Never used in a model. We subclass. Data would be a specimen collected - data... Participants - relates to... Action method - method usedfor collection.

Rahil: And what do for similar action of authoring?

Mark: And what is reason? Specimen collection? Or reason collected?

[Phone]: You can limit in restrictions. Can change value... our intention was not to put in reason for specimen collected. Not put in diagnosis. Always because ordered.

Mark: Not enough detail in model to distinguish between the specimen details that were ordered. Not enough details to rule out 'disease-x'... Want to point to place in record where is diagnosis, and who made diagnosis.

Linda: Specimen collected. Have basic properties of specimen - have both collected and received actions in the Intermountain model.

[Phone]: Not constrained. Usually with attributions - we leave open. Could put nonsensical things... but... if you go to specimen collected and... look at the CDL and go to bottom... See - the reason has not been constrained. To make model right, reason should have been constrained out. Our laxidasical approach...

Linda: Should we model specimen collected and specimen received as participation? Or as Action cluster in each of the models? Tom?

Tom: We would not put anything in that is not going to be queried. We model stuff as participation if needed... Seems like overkill... Passive data... it tracking actions in real-time, is different... But maybe I don't know.

Linda: In the NEHTA model, they record the location of each participation.

Tom: Location is recorded in a composition... But not potentially true if, inside composition, you may want to record it this way. Might be reasonable to put location by participation. My question is - who is going to use this info?

Linda: Challenge is when have date-time. Have diagnosis. Might know who, but always know date. Diagnosis-date in participation. Do you repeat the diagnosis date both in the participation and the action?

Tom: If trying to record historical diagnosis, is not the action of diagnosis that is interesting, but is the diagnosis.

Linda: What about authorship...

Tom: We just have those attributes as hard-coded in the reference model - like author or composer, subject of the entry - all built in. That is what we have done for the commonly occurring ones. Always someone responsible for the record - authoring clinician.

Linda: Rahil - should we look at LRA?

Rahil: Yes - we've done the same. The more common participation-types, like author, attester, verifier etc, we state in the reference model. Others - more role-based participation-type.

Linda: I know you extended functional role. [Looks at LRA model]

Rahil: So if look at functional-role composer - is optional. If look at constraints in composer functional role... you could record the location. So, 4 blue boxes - 3 for composition and 1 for entry.

Linda: For attestation-info, your... -functional must have performer?

Rahil: Attribution class?

Linda: Yes - used in... We had all of them. The committer, the composer, the attestation, also the distribution... other participation types. Obviously the performer is mandatory, but also composer and attestation functional roles.

Linda (cont'd): So if we keep the performer of the participation as mandatory, then need to record the activity attributes outside the participation, for those pieces of data not supported by participation class. Would need to make participation more extensible. We have alternatives ... and probably need more people present to make decisions on this. I suggest we document those and write up.

Mark: Should make it clear. In terms of actions, we make it clear that actions associated with performing-lab observation - and actions related to other... that are clinical.

Linda: That may be in the...

Joey: We used to call it attributes (or actions) and Stan wanted to call it attributions.

Linda: So - further discussion later.

Linda (cont'd): So - Lab Report Header. Authorship, issuing, custodianship. Patient-encounter - referred to in FHIR model. Refers to admission and number of other reports. The patient-encounter that is associated with lab-report. So in lab report, patient-encounter would be a summary of the full patient encounter record, and the lab request would be a summary of the full lab request record. In some stage need to model in full, but if now, only those related to lab report.

Linda (cont'd): The encounter identifier, encounter-type, the patient-type and service are included in the Patient-encounter summary - but we've excluded the patient-number, the patient, the diet-type etc. For the moment, I left in encounter-date-type... encounter-reason. Hopefully... what I excluded will be fine - comments?

Linda: Encounter-identifier - OK in patient-summary? Encounter-type - OK? Need example values...

Rahil: Not going down into more detail of encounter? In LRA - admission event - could be problem or diagnosis or procedure. So encounter reason was more specific, rather than using a generic type for any type of encounter. We had specific categorization of it. But not at this level - higher level.

Linda: So - is the question - whether or not we have more specialized encounter types in the lab report or only in patient-encounter?

Rahil: So, what encounter type - what type in SNOMED...?

Mark: Yes - Are we covering in-patient and out-patient and phone encounters, or only in-patient?

Linda: Whatever member models would consider relevant on lab-report. If details on out-patient encounter are relevant, need to keep.

Rahil: Whoever is using these needs to answer...

Mark: If in-patient, extra information. If outpatient - place occurred (sample drawn) and ....

Galen: FHIM - similar to what you have here, both in and out-patient. The encounter can be any kind of encounter - even phone encounter, so no lab report in that case.

Linda: So - what restriction? In-patient, out-patient... restricted to hospital?

Galen: No - labs ordered from out-patient encounter all the time. But not want to restrict encounter-types... Should maybe restrict to encounter with labs...

Linda: Joey - do you know type of IMH encounter-types? Not included in spreadsheet.

Joey: No - I am not the contact person. More - I built the underpinnings.

Linda: I can find examples from Singapore, but not sure have complete list. In-patient encounter would be encounter-type. I am sure more specific encounter-types... We have encounter-types: newborn, endoscopy, day surgery, emergency... So, any suggestions of how we narrow encounter-type down, or leave to individuals?

Comment: Leave it broad.

Linda: OK - then people can narrow down according to own needs.

Linda (cont'd): Patient class - OK to be included? Hospital-service - pediatrics or outpatient clinic? Value for IMH model includes ...

Rahil: Would that be coded text or plain text?

Linda: In Singapore, is CD - can be coded or text.

Rahil: I mean - part of participation model? Then CD - identifying service within hospital... service-location rather than organization, because all of these values - we have national codes, not SNOMED - national codes that are published.

Linda: Yes - here is IMH... hospital-service-value-set-ECID. So you put this as participation-service?

Rahil: Yes.

Linda: I suppose when get to demographics, and participation, we will define more demographic details.

Linda (cont'd): Is everyone OK with this left in elements of encounter... report? If other that I excluded, let me know.

[Linda shows Patient-encounter Summary]

Linda: Encounter date and Encounter date-time-range, Healthcare provider, Healthcare organization. With Healthcare provider, we have provider who performed lab test, but this allows this to be specialized further. Is everyone OK?

Linda (cont'd): Last is encounter reason - reason for encounter. Either coded element or Text. So in context of Lab Report, maybe should be kept it simple... not expect long explanation...

Mark: If integrated system you would also have an account identifier...

Linda: Yes - could be linked to full report.

Mark: Do we want Lab report to be standalone document for patient or part of an integrated system?

Linda: I think standalone report for this, but it will include both a summary of patient-encounter as well as a Link to the full-patient encounter separately.

Mark: I would like to see behind each encounter - subset of information - so I could get to details. So link to diagnosis would be underneath the readable part - whatever the reason is.

Linda: All OK with this subset of patient-encounter?

Rahil: We will be re-visiting for the broader patient-encounter?

Linda: Yes. Purpose of this is... patient-encounter summary to be embedded.

Linda (cont'd): Next - demographics model. Tom will walk us through the demographics model in the openEHR reference model.

[Linda shows RM for CIMI on screen]

Linda: Each Locatable can have...

Tom: External identifier might refer to a party... and could be based on that model... So essentially...

[Linda shows CIMI RM - Locatable, Party, Actor - the child type corresponding to all real actors, organization and...]

Tom: The role of any actor could take... And individuals have connections between role and actor.

Galen: A single person can play multiple roles. So - I am both a physician and patient. Built into party role... and person's record would exist twice.

Tom: We don't treat patient-concept as a party.

Galen: What if person is author and verifier? Would they exist twice?

Tom: No - Not the type of roles. We don't use these roles to represent authorship or... type of participation of a party. That is the patient-functions. So if look at the openEHR Entry, we have the Subject and Provider as participations built into the reference model. In openEHR - party identifier (?). Often want just NHS(?) number of practitioner. Real demographics of providers... for real purposes... Not just for indicating [that they are] the author...

Galen: You threw me with the word Role.

Tom: Interesting to look at Silverstein books. The basic thing missing is concept of Post. Organization tries to fill... a person who has a role can fill a post. You can get into serious modeling of... Not useful. Our use is patient-relationships... is between patients.

Galen: Actor is subtype of party and person is subtype of actor... [I am] a tad nervous. A person is a person in its own right, and the role depends on the existence of the entity.

Mark: Goes back to roles and entities in HL7. Do you separate entities from roles...

Galen: Commonly used party pattern and entity pattern. Party-pattern has a tendency to conflate the roles and entities.

Linda: The other discussion point - difference in scope. So in LRA and 13606, the scope of demographics includes location and devices.

Tom: 'Agent' is the word for devices.

Mark: I wanted to go to previous point, if no distinction between entity and role, if I am a doctor and a patient then I am only one entity, but play two different roles.

Tom: That model does that. The performer of a role is a party-ref and that points to actor (which is like Entity in HL7).

Linda: So if we rename actor to entity...

Tom: Yes. If doing realistic service, can have bi-direction between actors and role.

Mark: Difference between implementation models and logical models.

Tom: Yes. Party is both logical and for implementation. Roles link to entities. Actor is a good word. A fair bit of literature... Silverstein is most comprehensive. Party and actor are used in lots of models, including models for health.

Linda: So lab report model - we will need representation of person, subject of care, healthcare providers, healthcare organizations, locations. Tom - in openEHR, modeled like a cluster?

Tom: Yes - locations are part of the event-context. So we don't treat as a party. Not useful to treat as a party. Unless they are organizations. But if only saying activity took place in lab... that is what you have to record on the data.

Linda: Set of demographic models that we have - person, patient, organization, healthcare provider, healthcare provider individual and healthcare provider organization. OpenEHR - have more demographic models on CKM?

Tom: Yes - about 30 - go into CKM and you'll see it.

Galen: I have FHIM demographic models... Send to you?

Linda: Yes - I'll send out. OK - openEHR demographic models. The NEHTA sent me theirs. And thanks to Rahil for useful comparison - with HL7 v3 RIM, ISO 22220, EN13606...

Rahil: Used to be British 13940.

Linda: Galen - can you send me the - is it VA FHIM model?

Galen: No - Fed Health Architecture Model [FHIM]. I'll send to you.

Linda: We have HL7 file... ISO 13606 model, ISO 22220, Singapore [MOHH], and DCM (William sent me).

Gerard: 13606 - 2 types - Standard and draft model we are using. Our draft model is not based on 13606, but we are working on formal method of modeling archetypes. It exists as a Mindmap. Will have to be aligned with Consys...

Linda: So I will note that.

Gerard: I want to align as much as possible. In context of renewal of 13606, we will address demographics model again, but it looks like this will be a pattern of clusters and elements.

Rahil: The latest published version of demographics (we will call participants...) is not part of spreadsheet analysis. So, analysis not have current model since it resulted from this. If look at analysis worksheet, the mappings - the LRA participations. We got rid of 'CR_', and added the rules created... I'll have to send to you. You have what was proposed, not what was published. Resulted in LRA-participants model... So I will have to give you another column.

Linda: Thank you. Wanted to look at scope of Participation - performed, person, etc.

[end-of-meeting]