Clinical Statement Pattern Conversion

The purpose of this page is to capture the discussion on how to adjust the Clinical Statement to support the RIM-ish approach.

• ConsumableChoice
  • Replace with Product Model
  • Does it allow for devices? Some work in progress with CPM CMET “R2”, but will that be enough.
    • Patient Care (5-Apr): we do need to be able to include devices. We see more work progressing on not only getting blood pressures as clinical statements, but also data on the device, e.g. was it calibrated? maintained? etc. Thus we envision several use cases in which a device must be described in more detail, including id, type, maintenance and so on. This is not clearly identified yet, but the general notion of this use case is actual.
    • CS ConCall (8-Apr) - Intent is not to drop support for devices, but we're hoping we may achieve it through Product Model. If not, then we'll stay as is.
    • Tom de Jong (9-Apr) - The CPM already covers devices, but PC would have to check if all their requirements are met. BUT, the current ConsumableChoice in the Clinical Statement surely doesn’t cover everything you mention! Maintenance dates, for example, are not expressible in either of the CMETs in the choice box.
• AgentChoice
  • Replace with Product Model, but food and dust might not quite work. To be worked out.
    • Patient Care (5-Apr) - we just have got a message from Karen Nocera that diet and food is important to be included.
    • Patient Care (5-Apr) - we also have the allergy model in which Agent has a role and where of course food and dust can be allergogenes.
  • Need to address manufactured vs. any material in CPM.
  • Does CPM cover orderable and aministrable perspectives?
  • Check with Gunther Schadow, Tom de Jong, Mead Walker, Hugh Glover
    • William Goossen (5-Apr) - As far as I understand, these are currently not possible. This has been part of the reason for not using clinical statement for several Dutch projects. I look forward to Tom de Jong and Gerrit Boer's opinions on this.
    • Tom de Jong (9-Apr) - Now I’m really confused… I think the first paragraph is from Hans [it’s hard to tell in William’s e-mails]. I think I can reassure him: the CPM definitely covers both orderable and administrable materials (we will use it for both in Pharmacy). Then William says that ‘this’ is part of the reason for not using the Clinical Statement in some Dutch projects. So what are we evaluating here: the CPM or the Clinical Statement?
    • CS ConCall (8-Apr) - Public Health Entity can support food and dust if Product Model cannot. Still need to check with Tom/Gerrit/Hugh/Mead.
    • Tom de Jong (9-Apr) - Again, it’s a matter of checking requirements, but I don’t see any issues here. I do have to mention that food and DIET are completely different concepts. Food (which is an Entity) would be covered by the CPM, but Diet (which is an Act) would not. I think William doesn’t realize that AgentChoice is currently linked to SubstanceAdministration, so the use in the Allergy model is a different story anyway.
      • Karen Nocera (12-Apr) - Agreed.
• LocationChoice
  • We want to ask Pt Admin to create one CMET to cover all three variants.
  • The OrganizationChoice should be inside the “CS Location CMET”
  • Patient Care (5-Apr): This would suit PC very much indeed.
  • Need a volunteer to help Pt. Admin. to open and work on a project to create the CMET.
• DeviceProductChoice
  • Given all the potential participations with CPM, should collapse them all?
  • Patient Care (5-Apr) - need more background to make any suggestions on this one.
  • Tom de Jong (9-Apr) - If several of the current choice boxes will be replaced by a generic reference to (a CMET based on) the CPM, there is no point in keeping these separate. I do note that a certain amount of specificity will be lost by replacing with a generic CPM-based CMET. But since the Clinical Statement is supposed to be very generic anyway, that might not be a bad thing. There might be a need for a device-CMET and a material-CMET…
• PatientOrRelatedOrSpecimen
  • Create 1 CMET that combines everything and split the participations to go to their own CMET.
• R_InvestigativeSubject
  • Should we replace with R_Subject, or would that widen too much?
  • We don’t think we need the EXPART participation as EXPTRGT is a sub of EXPART and if subject is unknown, there would not be an instance.
  • Check with Austin.
    • CS ConCall (8-Apr) - o.k. with collapsing the participations, but not o.k. with exchanging R_InvestigativeSubject with R_Subject.
  • Patient Care (5-Apr) - No opinion
• ProviderOrPatientOrRelated
  • Replace R_Patient and InvestigatedPerson with R_Subject.
    • ConCall (8-Apr) - Looks like this would open it too wide, particularly for Public Health. We're willing to accept that as it can already be done anyway. But we really need to focus on the minimum.
    • Role stub would then be cleanest. Problem is how to express a role stub. For now stick a role there and call it a stub. Then we need a model for the Supporting Clinical Statement CMET.
    • Could also create a dedicated CMET with minimum data set, but then we have to do that to the entire model, while maintaining an "original mode" CMET that contains the four CMETs.
  • Can RelatedEntity become a part of R_Subject?
    • ConCall (8-Apr) - Austin does not agree with that approach.
    • ConCall (8-Apr) - Why is RelatedEntity there? Should it just go? It can't as we need to indicate that the patient's mom was the informant.
  • Review with Pt Admin.
  • Patient Care (5-Apr) - This is a core part for multiple use cases in Patient Care can a foetus' hart rate still be attributed to the foetus in the mother's record? Can a spouse's care giver strain still be documented in a husband's record for a stroke care provision? can we identify a female donor for an egg in case of infertility treatment?
    • For the latter use case Kai Heitmann suggests the following in current approach:

<targetOf typeCode="PERT">

   <procedure classCode="PROC" moodCode="EVN">
       <id nullFlavor="NA"/>
       
       <subject typeCode="SBJ">
           <patient>
               <id nullFlavor="NA"/>
               <statusCode code="completed"/>
               <Person>
                   <birthTime value="1956"/>
               </Person>
           </patient>
       </subject>
   </procedure>

</targetOf>

• • • This is then a pertinent relationship to a procedure (egg donation) with subject "patient" that is played by a person having a birth date.
    • What would be handy according to Kai but is not possible due to lack of a more generic participation:

<participation typeCode="DON">

   <participationRole classCode="ROL">
       <playingPerson>
           <birthTime value="1981"/>
       </playingPerson>
   </participationRole>

</participation>

• • • If we are working to replace the CMET to a more generic one, why not similar for the participation level?
• directTarget
  • Why is this only on Act? What is the purpose?
  • Maybe Charlie Bishop knows history.
• ActReference
  • Can we remove it from the choice box so we only have one level choice box?
  • Patient Care (5-Apr) - please keep this act reference! See this picture for more detail.
    • 
    • We sometimes have to refer to a single act / clincal statement from an earlier care provision. E.g. if we discuss a current pregnancy, but need data from an earlier pregnancy, e.g. risk factors.
    • It would become very cluttered / mixed if we can only have one choicebox option. We need the option of referring to older choicebox arrangements.
    • Please give us more directions if we can make the suggested changes and still do what we need to do.
  • ConCall (8-Apr) - Further comments from Austin support PC's request as it would break the CMET.
  • ConCall (8-Apr) - Still should consider the component relationship to move it from the outer to the inner choice box.
    • Would need to open up context conduction as part of changing context conduction overall.
    • For CR001 the visio shows it was attached to the inner choice box. It is unclear why/when it was moved.
    • Rik will move the available visios into GForge.