This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Clinical Statement Pattern Conversion

From HL7Wiki
Jump to navigation Jump to search

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

Plan

  • Review the Pattern
    • Complete drafting conversion proposals
  • Review change requests
    • Outstanding Change Requests (2), Pending Change Requests (6), and Dispositioned yet to be Actioned (13).
    • Draft change request resolutions and additional conversion proposals as needed
  • Send out voting requests on change request resolutions and conversion proposals
  • Update/Create CMETs based on template conversion proposals that are accepted.
  • Check where we are to determine whether we still can make the September Ballot or the January Ballot
    • Applicable deadlines are:
      • Notification 18 July
      • Initial content 25 July
      • Preview & CMET content due 1 Aug
      • Final content deadline 15 Aug
    • Not likely we'll make September, but January should have a shot.

Pattern Review

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.
    • 20-May-2010
      • Participation + ConsumableChoice candidate for complete removal
      • For Optional STUB use Optional Extension Act.
      • Need to ask domains whether they use it before taking out.
    • 1-Jul-2010
      • Proposed motion for e-vote: Replace Consumable Choice with Common Product Model CMET (R_ProductListed (COCT_RM620000UV)). While the CPM CMET is not fully compatible with the R_LabTestKit and R_ReAgent CMETs, we believe that for the Clinical Statement template we want to encourage that these are going to be updated to be derived from CPM.

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.
    • 20-May-2010
      • At least 2 domains are required to have a need to include it in the template.
      • Orderable Medication is derivable from CPM
      • Suggestion to create new CMET.
      • Need to clarify where to go guidance.
    • 1-Jul-2010
      • Proposed motion is to replace AgentChoice with a new CMET (Consumable Material) that consists of a choice of CPM and current Administrable material construct

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.
  • 1-Jul-2010
    • Proposed motion to build a new CMET in CS and offer it to Pt Admin when done. But we can keep it if they don't want it. Covers LocationChoice + Spatial Coordinates, + the organizational bits.

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…
  • 1-Jul-2010
    • Proposed motion is to replace the choice box with just the CPM CMET. There is a concern that Manufactured Product has the potential for multiple identifiers, but we don't think there are real use cases to support two or more identifiers. If there is, then we can use that to request CPM to adjust their identifiers.

PatientOrRelatedOrSpecimen

  • Create 1 CMET that combines everything and split the participations to go to their own CMET.
  • 1-Jul-2010
    • Rik is going to check what happened with the harmonization proposal. While this may impact the course of our discussion, in the mean time we believe that the following proposed motion makes sense.
    • Proposed motion is to have recordTarget just relate to R_Subject and for subject create a CMET that combines all three (R_Subject, RelatedEntity, and R_Specimen).

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
  • 1-Jul-2010
    • Proposed motion to collapse participant and participant1 into one with typeCode EXPART.

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?
  • 1-Jul-2010
    • Proposed motion is to separate R_AssignedEntity and the three participations that directly relate to that and create a CMET to cover all four for the remaining 3 participations.

directTarget

  • Why is this only on Act? What is the purpose?
  • Maybe Charlie Bishop knows history.
  • 1-Jul-2010
    • Rik to check with Charlie.
  • 9-Sep-2010
    • Proposed Motion: Move directTarget to Substance Administration only.

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.
    • REPC DM000000UVActReference.png
    • 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.
  • 1-Jul-2010
    • Rik to check with Charlie why the boxes are connected the way they are.
  • 9-Sep-2010
    • One possibility: Done to avoid direct connection to ActReference so only other acts in the choice box can utilize this class.
    • Problem is that the entry goes into the outer choice box, so either we need to change that, or better clarify why this was needed.
    • Keep as is for now.

Change Requests

CSCR-097

Postpone decision until we know what harmonization is going to come up. No reason to change anything until we know where it is heading.

CSCR-099

FLUP: We will request William Goossen to withdraw this request.

CSCR-025

FLUP: Motion to not include interuptibleInd as there is no use case for it yet (5 years and going), it's not and the template approach would allow for additions.

CSCR-044

FLUP: Need to follow-up with William whether to put this back on the plate, or keep it as a Patient Care extension of the CS Template.

CSCR-062

FLUP: Indicate to Harry Solomon that unless we hear otherwise, we will consider this one withdrawn.

Retrieved from "https://wiki.hl7.org/w/index.php?title=Clinical_Statement_Pattern_Conversion&oldid=40582"