Meeting notes

Notes of the Out of Cycle Care Provision

‘’‘’’20th and 21st February 2012 The Hague‘’‘’’

Present

• Co-chair: William Goossen
• HL7 Modeler: Jean Henri Duteau
• Domain and HL7 Expert: Kai Heitmann
• HL7 Expert: Gerda Meijboom
• Publisher: Michael Tan

DMIM

• DMIM Rework. Adjust the Visio DMIM.
• Connect to new RIM 2.37.3
• Certain Visio error messages appeared.
• PertinentInformation sequence nr 1 and nr 2 have been swapped. But what is the meaning?
• The final goal in the old DMIM only pointed to observation. In the new model it points to the total CMET of care statements. The meaning of final goal is straightforward and remains the same.
• Review the meaning of the relationships like subject of and component of. What are the differences.
• The meaning of Component is that the statements belong to (are part of) this care provision. This is in contrast with pertinent information who do not belong to this care provision, but still have a relationship. The meaning of component is identical.
• On DMIM level we should only consider the clinical terms. That is why we leave the pertinent Information1. The meaning remains the same.
• The explanation of Subject of has to be made more clear. Second sentence has to be adjusted.
• Focus on sequel to. This could point to multiple of previous care provision ( in a certain order mentioned in sequence number). It cannot point towards the future. We changed it to go in both directions. A new sequel replaces an old sequel.
• Do we need the sequence number? In most cases we only need the time line, but we in rare cases the sequence number could be useful.
• Component : A care provision can be part of greater part of care provision. Such as a care plan. This text can be found in the original DMIM walkthrough under component3. This has to change to component1.
• SUMM (summarized by) is also used to a summarize child ( care provisions). This points to other care provisions . The summary recursive link is replaced by pertinent information 2, because summary is also part of pertinent information. But we want to constrain it to “pertains".
• Source of . does not replace another care provision. The distinction between source of and sequel to is not obvious.
• Sequel to has been places opposite source of and summary has been placed opposite component
• The relationship of reason of is pointing to the same CMET of statements. That is why this has been integrated into the supporting clinical statement. You cannot have a relationship pointing out of a CMET. It can only point towards a CMET.
• Reference creates a relationship with an encounter. The type code has been made into subject. This might be too strict. Another option is reference .
• Authorization has a relation with Consent Universal.
• On the left hand side we have relationships to indicate the status of the care provisions. And you also can see by whom the care provision has been changed. The datatype is changed from CV to CD. Kai argues the usefulness of this link, but we leave it for what it is.

Participations

• On the provider side we have “author, performer, information receiver”.
• The information recipient has been generalized to participant.
• Should verifier not also point to “provider”? A assigned person also belongs to a assigned entity. ( This captures also the person). This has been changed to point to provider.
• Is the data-enterer always a person? Kai thinks so, but maybe devices can be data-enteres to. This has not been removed, but left for the ballot.
• The subject could point to a different person. For instance the observation could be done on the mother, but the actual patient is the fetus.
• The maintained entity could be a pacemaker.
• The entry point of R_CaredEntity might be pointing to right spot? Currently at the Record target Choice.
• The entry points for all CS entry points has been removed. All notes made to the CS pattern are remarks to verify whether they are possible in the Clinical Statement. These notes were verified in the CS and found OK. They were removed.
• We need to make a proposal to have the right mood codes in Clinical Statements.
• How do we make distinction between the more structural information and the more clinical content? How do we draw the line.
• Certain attributes in Author are mandatory, like time or signaturecode, changed to required

Walkthrough

• In the DMIM walkthrough we only need to explain what the meaning is of “ sequel to” “source of”, “component” and “Pertinent information”. Pertinent
• First changed the explanation of Pertinent information in the Wiki, The other recursive relationships are prevalent to pertinent information, which is the least specific.

Patient Encounter

• Discussion on merging focal classes (and eventually DMIMs) between PA and Care Provision.
• To deal with the time problem in harmonization of patient encounter and care provision is to connect all relationships to encounter and mention it as work in progress. Many cases look similar in patient admin and encounter look similar, but are different in the explanation.
• The goal is to create an overarching DMIM for Patient Encounter and Care Provision. Maybe there should be a subset of a DMIM for Care Provision or Patient Encounter. But for now we leave it as a virtual DMIM layer. Therefore a choice box has been drawn with care provision and encounter in one DMIM.
• This has consequences on the participations. One missing participation in Care Provsion is the location. This has been added to the DMIM. (Managed participation with ID).
• Need to add responsible party. The related party contains contact.
• Reusable Device only used for scheduling..
• “Reason of” as a separate participation has been removed. There is a separate reason of pointing to the choice box.
• Kai will describe an explanation about templates in Care provision. Where to put the topic of templates? Put that in the overview..
• Explanation about the usage of messages, CDA or services will be moved or referred to. This is actually a generic topic.
• We removed the CMET’s in the patient care. There used to be one called Principal Care Provision Universal. Readers will complain if the material will be missing.
• Discuss with HL7 Editors about the interactions which are generated below the storyboard narratives. DOPC_ST000031UV01** This has been corrected in the last ballot version of January 2012.
• Replace the PubDB RMIM up till the table.

Care record

• Run through the storyboards of the Care Record. The interactions are available. Storyboards are available except for the append. WG will translate the storyboard of Acute care for this purpose. Action WGo.
• We have to do versioning of the Care Record. The versions will change of the IN, the MTs and the HD. So REPC_IN004310UV01 has to change into REPC_IN004310UV02. Action MTA.
• The negation indicator has changed because of RIM02.
• Discussion whether to use a separate relationship of type “reference” to another CP Event or to use a recursive relationship. We decide to draw the “reference” as a recursive relationship to the CP Event.
• Why is the “in fulfillment of CP Promise” limited to a cardinality of 0 to 2.? We change it to 0..*.
• A Care Provision can belong to an overarching Care Plan. This is possible in the Care Record.
• The concern tracker is seen as a component of the clinical statements. This does not have to be drawn separately. The CMET of concern tracking is not modeled yet.
• Why do we need a primaryinformationRecipient? Why is this not just a InformationRecipiet? You could specify the primary recipient in the template. This is changed to a general informationRecipient.
• A participant participation is added to the model between the CP Event and the choice box of provider.
• A choice box created called subject .
• A participation of “location” is created between Service Delivery Location and the CP Event.
• We want to sort the reasons. A sequence number is added to the reason.
• We have created a new CMET called “cared Entity” that contains “Patient and MaintainedEntity”. This could be added to created CMETs. List. ( REPCMT000700UV02).

Care Transfer Request

• Fastest way is to copy the Care Record RMIM and adjust the visio.
• The differences are the mood-code and the pertinent information to a Care Record.
• The RMIM is now called REPC_RM002000UV02.
• The infulfillment of” does not exist in a request. Is deleted.
• Same with “subject”.
• Location (this is where the request is done) would not either exist.
• The desired location has a different participation. Has to be the desired location and performer. Could not find the right participation yet. Destination? Action JDu.
• A reference to a identified Care Record is drawn separately in contrast of the recursive reference in the DMIM.
• Same for the reference to an encounter.
• The recursive function of replacement is also adjusted to a direct relationship to a earlier Care Provision Request.
• Limited the relationships on the right hand side of the model to the most necessary ones in a transfer request.
• The participations on the right hand side are simplified to the most required ones.

Care Record Promise

• This is not only a yes or no to the request, but also the ability to express that you will only uptake certain parts of the care plan. You must also be able to express, that you cannot fulfill order A, but instead perform order B.
• The relationships on the right hand side are minimized.
• There could also be unsolicited promises. The original requester did not ask for the CP, but the performer mentions that he will also fulfill this care provision.
• The Act also contains a reason-code. This is used when a simple code is sufficient. But you must also be able to provide additional supporting information in the supporting clinical information such as lab-results.
• The location is removed because this is regarded as a scheduling issue. This needs more than only a location, but also a time and so on.
• On the relation side we only keep:
  • Reason
  • In fulfillment of
  • Component to the care plan.
• Is a reject simply a promise with a negation indicator? If a reject is a separate interaction,,, it could mean a separate RMIM. Otherwise we just change the name of the RMIM into a promise/ reject RMIM. A reject will indicated with a negation indicator.
• Motion to accept all the material of Care Provision domain including DMIM, RMIM and walkthroughs of Care Record, Care Transfer request and Care Record Promise as defined during the OOC as the baseline for the ballot pending further preparation and publishing refinement.
• Vote: 5 present.: 4 in favor, 0 abstain, 0 against.

Care Record Query

• This RMIM material remains the same. It can be left as it is. There are no references to Clinical Statements.
• The interaction numbers do not change.
• The Care Transfer Query topic will be removed . The requirement ( from Australia) is no longer present. The other project that will be withdrawn is “professional services”. WGo will officially withdraw these projects. Action WGo.