CIMI MTF Minutes 20121213

Jump to: navigation, search

CIMI Modelling Taskforce - Meeting Minutes

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


Linda Bird

Gerard Freriks

Stephen Chu

Stan Huff

Mark Shafarman

Harold Solbrig

Jay Lyle

Joey Coyle

Eithne Keelaghan


  • Weekly news & updates
  • Review action list from Groningen
  • Laboratory Results Report modeling:
    • Lab Request
      • Comparative analysis spreadsheet
      • Modeling patterns
      • Mindmaps
    • Lab Report Header
      • Comparative analysis spreadsheet
      • Modeling patterns
      • Mindmaps

Weekly News & Updates

  • Thank-you everyone for your participation in the modeling workshop in Groningen!
  • Thank-you to our wonderful hosts!
  • Other CIMI meetings:
    • UML Taskforce
    • Terminology subgroup meeting
    • Glossary subgroup meeting

Groningen Action Items

  1. Comparative analysis spreadsheet:
    1. Collectively review Lab Request, Lab Report Header and Patient Encounter analysis (All)
    2. Update all spreadsheets, as per discussions (Linda)
    3. Itemise topics for further discussion (Linda)
    4. Distribute for review (Linda to distribute - All to review)
    5. Review and improve Definitions (William & Anneke)
    6. Comparative analysis for demographics models (Linda):
      1. HL7 v3 CMETs: Person, Patient, Provider, Organisation (William)
      2. NHS (including analysis) eg. Patient (Rahil)
      3. FHIM (Galen)
      4. MOHH (Linda)
      5. EN13606 Association (Named Object+Demograpics proposal) (Gerard)
      6. IMH (Stan)
      7. NEHTA Demographics (Stephen)
      8. Etc.
  2. Mindmaps: (Linda)
    1. Update all mindmaps, as per discussions
    2. Create mindmaps for:
      1. Patient encounter
      2. Demographics (e.g. Patient, Person, Healthcare provider, Organisation)
      3. CIMI-CM (Canonical-Model) models
      4. Specific Lab Test Results, including: (IMH to provide clinical models; Linda to mindmap)
        1. Complete Blood Count (flat)
        2. Complete Blood Count (structured)
        3. Creatinine Clearance
        4. Glucose Tolerance Test
      5. Specialise 'Anatomical Location' into 'Specimen Collection Site'
      6. Add link from Lab Request to Lab Results entry
  3. Reference Model
    1. Make changes, as discussed (Michael)
    2. Adding issues to Github (Michael)
    3. Updating BMM generation (Tom & Michael)
    4. Review demographics models (All)
  4. AOM/ADL 1.5:
    1. Update all ADL 1.5 models based on above mindmaps (Tom and Ian / Tooling)
    2. Example instance syntax: Demonstration and selection of example instance representation options (Stan to contact Tom: to demonstrate ADL workbench capabilities for instance)
    3. Lab Results models - Create example instances of models (Joey)
  5. Terminology
    1. Propose terminology bindings for all mindmaps (Daniel, Rahil, Mike)
      1. Semantic bindings
      2. Value set bindings
    2. Propose AOM extensions to support terminology binding approach (Harold / Tom / Michael)
      1. Relationship binding
      2. Value mapping definition
  6. Style Guide (after Scottsdale) (Linda, Tom Oniki, Rahil)
    1. Agree on a structure and contents
    2. Write and review CIMI modeling style guide
    3. Create Style guide on CIMI wiki (Anneke and Michael)
  7. Implementation / Tooling
    1. Create concrete tooling architecture diagram (Harold, Michael, Dave, Tom)
    2. Updates to ADL Workbench to support CIMI models (Linda to ask Tom)
    3. FHIR resource profile and extension for CIMI Lab Results models (Joey)
    4. AML profile work (Dave, Robert, Michael, Harold, Linda, Galen)
    5. UML Style Guide for Archetypes (Dave to lead, Galen etc)
    6. Terminology tooling integration roadmap (ie value sets) (Harold)
    7. Find terminology repository solution (Harold to lead)
    8. Tooling issues: (Harold to lead)
      1. Making 'codes' special in the BMM or other metadata
      2. References/URIs to value sets
      3. Ordinal value representation (i.e. Def/URIs to coded ordinals)
      4. Short & Long value set approach
    9. Converting mindmaps to ADL (Harold, Michael)
    10. Investigate ADL commandline tools (Joey)
    11. Tooling support (e.g. mindmap support, import/export ADL 1.5 from various tools)
  8. Other models (Demographics now; prioritise others in Scottsdale)
    1. Demographics
    2. Body temperature
    3. Heart rate
    4. Immunizations
    5. Medications
    6. Problem diagnosis
  9. Other issues:
    1. Raise issue about removing Magnitude from Temporal datatypes. (Michael)
    2. Consider name of 'Action information' and 'Action' (All)
    3. Datatypes: Relation to ISO21090 datatypes (after Scottsdale)
    4. Value for 'CODED_TEXT.Terminology_id': URI and/or OID for 'Any' SNOMED CT or SCT-CIMI (Harold to lead)
    5. Uniquely identify value sets/codes (URI/URL/OID) (Harold to lead)
    6. Verb hierarchy - Analysis of available hierarchies (Rahil / All)
      1. in relation to the actions and relationship bindings

Detailed Meeting Minutes

Linda: The draft agenda for today - updates reviewing action list and modeling - a couple of entries [Linda reads agenda]. Based on Groningen modeling - want to look at... especially Lab Requests. Look at Mindmap, and weekly news and update. Thanks to those attending the modeling workshop in Groningen.

And many thanks to those who hosted our meeting in the Netherlands.

Linda (cont'd): Other meetings this week - no UML meeting this week. Terminology subgroup met this week. I sent out an email looking for volunteers. If you have a chance, look through the format for Terminology ref sets. Tom sent around OpenEHR... if you could look at this. If we can get content to load up when server is ready, this would save time. Are all OK with this?

Linda: Look through Groningen items. Went through terminology... I've made changes to spreadsheets based on our Groningen discussions. Then I will distribute Demographics model - will do when finish lab results.

Stephen: Do you still want contributions for Demographics models?

Linda: Yes.

Stephen: I can give you the NEHTA one. Not in CKM, but is in pdf. It is a huge document. I will send you... after meeting.

Linda: Yes. And Rahil - great start - comparative analysis of demographic standards out there.

Linda: Gerard - I believe you sent out the EN13606-Association's Named Entity model.

Gerard: Yes - not complete, but... looking for proposal for change to EN13606... I will send you.

Linda: We will follow up with William. Jay - if you speak with Galen, he offered the FHIM demographic model. And Stan - if you can point me in the direction of IMH's...

Stan: Yes.

Jay: I will find out.

Linda: Mindmap - Stan - you offered to... blood count, creatinine clearance, glucose tolerance test... Once completed modeling, would be good to do that.

Stan: OK.

Linda: Michael and Tom - Reference Model - AOM/ADL work. I believe Harold is also involved. I'll skim over terminology... Implementation and Tooling - Dave, Robert, Michael, Harold, Galen... Joey - I believe you all know this...

Linda: Other issues: Harold is leading work to make sure we get terminology sorted out. And all are responsible for reviewing spreadsheet.

Jay: I am not sure what is necessary to be done with the FHIM.

Linda: Demographic model - Galen offered...

Jay: OK.

Linda: Lab Request Comparative Analysis. The one I used - if incorrect, let me know.

[Linda shows diagram] - "Lab Request" in Lab Results - Comparative Analysis spreadsheet

Linda: For FHIR - there is Request Detail class - part of Lab Report. Next - Investigation order -MOHH, covers... Next is IMH order lab - order name, order relation. Quite a lot in there, Stan.

Stan: Yes - supporting real system. It is in use. That is why - all needed for in-patient and out-patient, included tapering doses of steroids and... IV...

Linda: May need you to explain to me.

Stan: I am sure it is under-documented.

Linda: Yes - if you could help...

Stan: We resorted to a Database of examples since it was so complicated... the easiest way to understand.

Linda: Great. The NEHTA - Pathology test result.

Stephen: Yes - has a bit more information than in spreadsheet, especially the request for details. They are important.

Linda: Where do I go for that?

Stephen: In the Protocol of the model.

Linda: OK - thanks. I wasn't sure where to look in HL7. Looking at CCD and... and other models, Mark, Gerard?

Gerard: No.

Linda: Mark - are you there? We'll ask later. Moving on with ones we have. The first item is Order-Name. Stan - can you explain? Type of order or general? Is coded-text? Order-name value-set?

Stan: I think this is the name of the test requested. Would need to look at the value set

Linda: The value set may be too big.

Stan: Maybe. If it's there, it will include hematocrit, CDC or whatever - but not sure if it will be in there.

Linda: Look at IMH Style Guide?

*** [Linda - looks at IMH-Value-Set-spreadsheet]

Linda: We have order-item value set... individual... [order items...]

Linda: Order-name... value is Test Order Name.

Stan: Yes - I should have looked at this. So that ordered items are different from Order Name. Joey - are you on the call? [No answer] Joey helped author a bunch of this - would be of more help.

Linda: OK - I'll highlight in orange... Next is Order Number. In FHIR - RequestOrderId and ReceiverOrderIid. In MOHH we have Order Number and Accession Number... Stan - do you use an order number at Intermountain?

Stan: Yes. Our order number is the one we assign, and External Order number is from who sent it to us. And there can be other order numbers from other institutions. That is why there are more than 1. Sender's order number would be inside these...and receiver order's number. Is opposite role of whatever we are doing in transaction...

Linda: So if we allow for a requestor order number and receiver order number and other order numbers are a local extension, that should be all we need?

Stan: Yes - I don't know... might be an area where we over-designed. Until we have real Use-case, I suggest we leave out other order numbers.

Gerard: I have a pair - order number and order-type, and I can have any number. Another thing: order - procedure is the result of the order - where is order number, I will find it in the instruction. Not the result archetype...

Linda: Is that compatible with this approach?

Gerard: Not quite. But since it is a model of concepts, it's a black box, with orders and results... results are generated, you assess the status, and the results are the results of procedures. This separates things out into separate archetypes. But it is compatible with what you do, so who cares.

Linda: Order-set-id. Stan? I have a question. You have order set id, I have tentatively excluded this, as the values seem like local values. Is that okay?

Stan: Brings up issue of order set ids … and yes those are local values. If you were doing this, those would be LOINC codes for shared order-sets. Make sense?

Linda: Yes. Why are these put into separate attribute? Is it for separate tests within a panel or separate panels? Or are these different from that?

Stan: I need to think about again. It's probably an intentional de-normalization, so can see what the parent is.

Linda: Oh - so it's at the logical level...

Stan: On logical level, is probably the same thing.

Linda: Sure - and if it's derivable, we need to ask ourselves if we mark it as derived and stored ...

Linda (cont'd): Next is Request-status. Nothing on FHIR. MOHH is... investigation order status. IMH [is Order Status]... Leaves NEHTA and Results4Care.

Stephen: We consider the order-status as Lab internal. Why is it included in reports?

Linda: In Singapore, it can be updated or cancelled. Not sure about IMH.

Stephen: I understand, but it is internal. I am curious why it is included in reports. Has its own use.

Stan: We use it as a way to communicate to physician to give status update as to whether ordered or not. Message - specimen was received in lab, is testing. And then you receive results. If they are anxious, then will know it is not getting done and won't order another.

Linda: Test requested. In openEHR - test-requested name. In Singapore it is Investigation Item, with parts Investigation Name, type and specimen. Test requested is repeatable in all cases. If we can look at order item from the Intermountain model.

Linda (cont'd): There are 1-to-many Orders, and 1-to-many Order Items with this. So perhaps it is the order item that is where the test name is recorded.

Stan: Yes - I think that is correct.

Linda: So who collects?

Stan: Whether you are asking Lab to come collect the specimen, or collecting it yourselves.

Linda: So you record the specimen in the Order?

Stan: Yes. Nurse may have drawn sample and is ordering tests - telling lab they don't have to come get/draw specimen.

Linda: OK. So you have one specimen.

Stan: I don't think was covered in Groningen. In specimen itself - not say who is supposed to draw one.

Linda: So collected by... no record distinguishing whether has been collected or should be collected... We have collected activity... Similar to the who-collects. Could be in past or future. We need to be more specific.

Stan: That is who did it. Not meant to be used in the future.

Linda: I think that is consistent. If specimen is included in request, and... has occurred, then we can record the collector.

Gerard: My question - to what level of detail do we go? Where is the boundary?

Stan: Whatever level we decide to have interoperability.

Gerard: So far I focused on the real... only on collection of tests... individual tests. We have to address interoperability. But at the moment, not caring about workflow. Too complex to do all correct the first time.

Stephen: I don't think we can ignore workflow. It draws the process. But... recognize items presented in various models and then...

Linda: Yes. Focus on information requirements, like Stephen said.

Linda (cont'd): Diagnosis-type. We included previously in ... results. But... not aware that other models had it in requests. But... Comments?

Stephen: Concept-name... Diagnostic-Type... is confusing. If Diagnostic-Services-Type... more accurate.

Linda: OK. Diagnostic-Services-Type?

Gerard: It is what you mean, I think.

Stan: What is the Use-case for this? We don't have it. We order hematocrit and Lab knows which department orders this. Not make sense to tell them, so I don't understand. Someone doing something different?

Linda: May have to do with design patterns and not the actual use case. I may have to query this with the team...

Stephen: In OpenEHR/NEHTA, we have Diagnostic-Services.

Linda: Yes - in Result. But this is Request.

Stan: More general question. The reason we look at request is to see what we want in result. Intentionally not doing ordering now. Should we do this level of detail, or only include those examples that we need to include in the result.

Linda: Yes... judgment call as to what makes sense. Include in report or... Only model I could get this information... context of being in Result... IMH model?

Stan: At IMH, we basically point to the order. Might have included physician. If we want the order details, we go looking at the complete order.

Stephen: That is like our model.

Stan: Always order number and any numbers associated with that and maybe ordering physician... but maybe not. But only one or two items... Get into trouble because of changes.

Stephen: We include ordering physician in case of questions.

Linda: OK. Look at items in OpenEHR/NEHTA and then IMH. ... We can say that Lab-Request model is incomplete.

Mark: Yes - different flavors of orders. DICOM orders, series or panels. Vary by type, so need to do type analysis... When ready to order... so there are minimum details in the actual lab results report.

Linda: OK. The full lab request - documented to be incomplete.

Stan: That helps - I can bring people to help me...

Linda: OK. FHIR and NEHTA... Tester identified, receiver identified, test-name... Skip IMH question. Clinical information. Requesting person - in FHIR model, agent or organization... in NEHTA... I am sure is in IMH...

Stan: Probably inside the ordered action.

Linda: Yes - attributions. Order participant - right?

Stan: Yes.

Linda: 0-to-many of those. Certainly other participants but...

Stan: Yes - should probably be one. Is probably an error...

Linda: OK. I think that is the end of list for FHIR and... Any ordered date? Anything else in IMH report regarding request?

Stan: No.

Linda: No order date-time?

Stan: No.

Linda: OK - test identifier, receiver identifier... Comments? OK. In relation to requests, want to look at how put into patterns. Important to think about patterns underlying models. We spoke about patterns... lab requests... I have suggestion to discuss with group. Based on modeling, we use lab-request... Have not discussed finding, but same... include same notion of finding. Then... request... sibling activity. In terms of models... common things... request activity to request another activity. Example, request for material... medication. Would live down here - observation request. We'd have a laboratory observation-request. Any question? Happy to use as starting point.

Stephen: You differentiate activity-request, like patient-procedure from observation request...

Linda: Observation-request comes from action of observing, but... the request in laboratory... is from observation to occur.

Stephen: Activity-request... confusing. Observation is an activity. You have an observation as... rather that descendent of activity.

Linda: I think falls out as... in terminology-binding. Activity itself - when took place, who did it? Then when lab-observation... When you describe, we say what observation in terms of terminology-binding. Not the procedure.

Stephen: Yes - 2 different types, but with characteristics that are not really different. Why is observation a sibling activity and not a child? Your observation procedure... logic...

Linda: Yes - you suggesting lab-request be a direct child of request?

Stephen: Observation is a child of activity.

Mark: I am also confused. Ordinary language... an activity is what someone does, and observation is what someone does. What is the difference?

Stan: Maybe thinking of hierarchy differently. My take on it - structurally thinking of attributes I want to be inherited. But I am hearing...

Linda: Not an ontology.

Stan: Is purpose to show an inheritance pattern and are inherited because they have the same use? If talking real world ontology then those things can be interepreted differently.

Stephen: Material-activity not same as another activity. So under the concept of activity, material activity would have to go.

Stan: I think the way we should be looking at this is whether there is anything that is shared? And if there is, parent... time it occurred.

Stephen: So, observation would have a time. What makes observation so special that is a sibling of activity and not a child? I would put observation as a child of activity, not a sibling.

Linda: This is really looking at the structural aspect... not necessarily the terminology-binding - with inputs from the existing modeling, such as OpenEHR, the LRA etc. It is mostly informed by common practice. It's probably best for us to take a look at models themselves. I'll show LRA [show on screen] This includes abstract classes for each Element type. The LRA is closely aligned with SNOMED. They have property observations - linked to the SNOMED Observation hierarchy. And they have finding observations, and procedures. And material-entity-element and record-artifact. They have done this to support SNOMED terminology-bindings. OpenEHR uses observation, evaluation, instruction and action.

Stephen: Look at attributes defined by LRA model. I don't see difference. They are all the same. Not make sense to have this proliferation of different types.

Linda: LRA modeling is at the element-level... clinical models are then created at the Entry level.

Mark: One aspect that I see... overlap between instruction at clinical level and request that it generates. If send to their part, need all the stuff to validate a real order. Is an activity something one does or something one tells someone to do? How is activity different from request?

Linda: Request - maybe need to generalize... instruction... an activity in itself. Has what is being requested.

Mark: Material activity, or clinical procedure... How are findings not an activity?

Linda: Findings will involve... Observation will involve a number of actions. With finding - actions involved with finding and... documenting action. So each of these will have actions included.

Stan: Let me ask... worry about agreement on hierarchies. Would we get to same place if we just agree on status or activity-time, and then we use the same elements ... will we get to same place... is it important that we all agree on this hierarchy at this time.

Linda: No want to look at how these are used in the models.

Stan: We get agreement on children and content and then put them into classes and patterns.

Stephen: I don't have problem with how organize hierarchy. My concern is use of "patterns". You bring along connotation of conformist criteria. Presenting a hierarchy like this forces some type of conformity. I would like to forget about the hierarchy, and forget about the patterns. It is the use of patterns that concerns me.

Linda: Happy to rename it - Pattern.

Stephen: I think to do the organization of pseudo-hierarchy justice you need to look at the composition level.

Linda: I agree - should look at modeling first.

Gerard: I will repeat - looking at this slide. We can agree on leaves of hierarchy. We model procedures... Data is generated and you collect data... Harmonize with continuity of care... and others deal with management... and administration... and you build a hierarchy of things. Different from what I see here. What we do about diversion that 13606 is doing now... different models... different way of approaching.

Linda: I understand. Driving this - the structural models and term-binding... Also, in the modeling we have been doing, a pattern has emerged. In terms of cluster pattern in these models... we have been clustering around the observable clusters, which binds to the SNOMED Observation hierarchy. The clinical finding clusters, have been modeled as clinical findings.

Gerard: Unclear the difference between observable and finding.

Linda: As SNOMED uses it.

Gerard: What can we agree on?

Linda: If going to bind to SNOMED, we have to agree on what hierarchy each part of the model binds to.

Gerard: My question - use the term in SNOMED and not the ontology behind it.

Linda: Yes - value sets and semantic binding.

Gerard: I'm not willing to bind all my values into SNOMED terminology.

Stan: Need to get back to the models and their attributes. If we look at [this], may find agreement.

Linda: The observation I have made about models... we have an observable cluster, the clinical finding clusters, and the actions: observed action, diagnosed action, and so forth. Activity - the main action of activity... the request action... requested materials. I wanted to present to look at patterns... Need to come back to look at commonality... for Style Guides. As result of Groningen... Lab Result [shows Mindmap]

Linda (cont'd): We have Laboratory Result: Test Observables, test results, action information. We do need to make decisions about how these are linked. Fall out into pattern... how bound to SNOMED. Something to think about...

Stephen: When we last time looked at model, we didn't get to Details. What is it?

Linda: ... allows to extend the archetype in any way.

Stephen: I have issue with extending the models in this way….but I will not hold us up with this... we will look at the attributes and then debate this for each cluster.

Linda: ...Discussion of how to bind to terminology.

Stephen: Terminology supposed to be supporting the information model, and looks like model is subservient to terminology.

Linda: I don't agree that models are subservient to terminology.

Gerard: Looking at details - hanging there. I also have slots I use when need fine-grained detail because I don't know up front... It is without semantic meaning. It needs a better place.

Linda: Yes - any of these points - you may want to extend with details. We discussed this previously, and it was decided that we needed this.

Stan: I argued that we needed to have this.

Gerard: Another main branch we might add in future.

Linda: So if there are other names, if after we look at the structure, we see other things that spring out of the structure requirements, then we can change this. I would like to pursue the pattern coming out of structure.

Linda (cont'd): Lab Request - happy to focus on... Lab Request - we have the request activity itself. The requester order identifier. The receiver order identifier.... And then the Test Requested, with the Test name... This is the information about the test that is being requested. In Canonical model - should be mandatory for lab test requested to be coded… but not necessarily in general model. OK with everyone?

Stan: I think that is correct.

Linda: So test name - what we want to record. Test identifier - 0 to 1. All agree? And Receiver-order-identifier - 0 to 1. Requester person and...

Linda (cont'd): In generic request - action information. I forgot - someone asked whether we needed action-information grouper. Doing modeling - don't think we need. Simplifies the model a bit.

Linda (cont'd): To show you quickly some patterns. Information subject. Clinical entry - action - 0 to many. Activity - 1 of those actions is main action. For example, activity that is clinical procedure. Request has Request activity... Observation Request... Reporting gets tied to... Happy to send these around for comments. Just to give idea of 1 proposed.

Linda (cont'd): Lab Report header. I've looked at 1 Lab Report. [shows diagram] Lab Report... 2nd - looked at composition... from Singapore. HL7 - I looked at clinical documentation.

Mark: Want to look at CCD header information - Yes.

Linda: You have CCR in documentation.

Mark: Oh - but it is CCD. CCR header for CCD document. Do you have questions on it?

Linda: Yes.

Mark: On the right - have the basic container for the clinical document, for clinical document activity. And to left - participant-type... And if is a documentation for a particular event. And - the yellow ones are entities and green are... Could be a person or device... but is a person. Scope by organization - could be person or device. Patient: ... may have a guardian. May have a thing being done. Have entities - enroll - participants in document.

Stephen: Are you considering the model that a CCD document is carrying...?

Linda: We are considering the implementation model as well...

Stephen: CCD not designed for that purpose, so many changes are required.

Linda: Yes.

Mark: Result Section is not the header section. Has more detail... This is just the document header. If talking about results, should look at result section of the CCD document and lab-observation.

Linda: At moment - only header info. [To Stephen]- I could not find Report-header in NEHTA.

Stephen: We have produced a lab composition, and as such this has a header.

Linda: General document header?

Stephen: Summary of the header is embedded in the report.

Linda: Available?

Stephen: No - no composition... Lab Request... We have things for prescriptions... Procedure Report... Lab report... I will have to locate... Not created specifically... Lab Report for composition.

Linda: If you have a generic header...

Stephen: Yes - I will send.

Linda: For Intermountain - could not find anything. Do you have a generic report-header model?

Stan: No - is not its own cluster. There are just elements in the model.

Linda: I couldn't see Results4Care or 13606, so if exists - let me know.

Linda (cont'd): Id and Report-id - FHIR model. The id of resource itself and report id - I assume resource id - version - if new version then gets new report id. Anyone know - Mark?

Mark: If version # is part of resource id? If I have a different version, but be included in a different UUID, must be unique.

Linda: That is what I assumed.

Mark: Would have to have link back to old one in that version report.

Linda: OK. Also notion of report set id. Report id in FHIR, and Singapore (I need to check with Graham) - Composition set. Everyone OK?

Mark: OK with me.

Linda: Good. In Singapore model we have report version number. Interesting to compare with other models - how do this. Status - status of reports and not status of results. Everyone happy? FHIR makes report-status mandatory, but not others. So I have made it optional.

Stephen: From canonical model perspective - OK.

Jay: Relationship between report header status and results status?

Stephen: Status of Results - pending approved. But what is the status of report?

Linda: In context of Lab Report composition... there is the patient-event and the lab test results... Not sure which of these 2 you are asking about...

Jay: Status of report itself - not the test.

Linda: Report has report-name. In CCD - clinical document has a code [shows diagram]

Mark: Class code is what says this is a clinical document.

Linda: OK. Document type - should move... So when FHIR uses Report-name which is a reportable concept, is possible it means report-type [shows diagram]. HL7 - "Name for entire report". Seemed strange that is not a separate report type.

Jay: What would it be if not...?

Stephen: I think report name would be something like biochemistry report or microbiology report...

Linda: Not included in service?

Stephen: Yes, but... you might have looked at it as I don't remember. I will have to get back to this...

Linda: Yes - I may also ask Graham for FHIR perspective. So have Report-name and Report-type and we may be able to collapse them... We have... Diagnostic service... (may be derivable) - all happy with that?

Linda (cont'd): Have specimen... No specimen on request-details. Report itself may need a specimen. What do you all think?

Jay: Would there be a rule for child...? Need to know which one was the specimen. At this level, you can have a different specimen for different tests in this report...

Linda: Right - Need to be consistent. Individual results have their own specimen. Subgroups can have specimens, but main lab results report group does have this. There are specimens that were referred to in the order. I think we may be able to remove this here...

Linda (cont'd): Any final comments? Next meeting - pick up where we left off - report-header. Then patient-event and demographics. I will get updated spreadsheet sent over.

[end of meeting]