在医疗行业中,处方是个非常重要的临床工作数据概念。因此,在考察用FHIR能如何构造我国所需医疗行业数据模型时,就会需要考虑如何用FHIR表达处方。
在2019年,FHIR的工作组已否认需要使用特定的资源来表达处方(不是药嘱)这个概念,见:
https://jira.hl7.org/browse/FHIR-24905
奇妙的是,IHE规范中却明确有处方(Prescription)的定义并需要引用药嘱(Medication Treatment Plan Item)。
https://www.ihe.net/uploadedFiles/Documents/Pharmacy/IHE_Pharmacy_Suppl_PRE.pdf?#page=12
FHIR官网指出这种复合式的request有三种表达方式:
• Shared requisition id
• "Based on" chain
• RequestOrchestration
https://build.fhir.org/request.html#compound
在FHIR实际应用中,则可以见到多种形态使用容器类资源表达处方并包含药嘱的表达形式,例如:
- 中国2023 FHIR Connectathon中使用消息Bundle来进行处方流转
http://wiki.hl7.org.cn:81/static/fhir-2023/spec-specialty-rx.html
- FHIR讨论区中有人建议使用Bundle并且在MedicationRequest中使用groupIdentifier表达处方号
- 英国NHS同样使用Message类型的Bundle,内含MedicationRequest来构造电子处方:
在美国,目前US Core中没有独立的处方这个概念,只有药嘱
https://www.hl7.org/fhir/us/core/profiles-and-extensions.html
可见目前用于表达处方的方式多为使用Bundle,将多个药嘱打包,以事务、消息或文档的方式在不同站点间传递。
然而,处方这个概念在中国已使用了相当长的时间,若干管理活动都围绕处方展开,例如从管理角度就需要分为西药处方、中药处方、毒麻精放药处方等,从流程角度,处方点评,大处方等都需要从处方,即一组医嘱/药嘱这个角度进行切入进行点评或费用评估,因此,没有特定的数据实体对其进行承载并不合适。
要表达“处方”这个概念,则需要从处方的定义开始考虑。根据我国卫生健康委员会颁布的的处方管理办法:http://www.nhc.gov.cn/wjw/c100022/202201/601940f66bbe4f24b0c5734f04e53543.shtml
其本质为医疗文书,用于记录用药医嘱。
因此,处方作为一个文书实体,且有对应的工作流需要实现,有必要具备特定的类型并持久化保存,而不是以消息(Message)形式出现。毕竟,FHIR对于消息的定义是:
见https://hl7.org/fhir/messaging.html
即消息是用于系统间通信,并不是用于对临床所需使用的文书进行持久化保存。不过消息中可以置入一个文档作为载荷,消息本身却不是一份具有法律效力的临床文档。
因此,处方这个概念在中国可以考虑使用Bundle,其类型为Document,并可在其组成部分的Composition中进一步约定该文档类型为处方。当然,其中仍旧需要遵循FHIR的基本方法论使用引用来纳入患者、就诊、药嘱等其它资源。遵循这个思路制作的处方文档形如:
<?xml version="1.0" encoding="UTF-8"?>
<Bundle xmlns="http://hl7.org/fhir">
<identifier>
<system/>
<value value="3i4569456"/>
</identifier>
<type value="document"/>
<entry>
<resource>
<Composition>
<identifier>
<system/>
<value value="处方编号"/>
</identifier>
<status value="final"/>
<!-- 进一步约束本文档为处方 -->
<type>
<coding>
<system/>
<code value="345345"/>
<display value="处方单"/>
</coding>
<text value="处方单"> </text>
</type>
<!-- 表明处方类型,如西药处方、中药处方、毒麻精放药处方等 -->
<category>
<coding>
<system/>
<code value="3434"/>
<display value="西药处方"/>
</coding>
</category>
<subject>
<reference value="Patient/pat1"/>
</subject>
<encounter>
<reference value="Encounter/ent1"/>
</encounter>
<date value="2023-02-01T12:30:02Z"/>
<author>
<reference value="Practioner/pt1"/>
</author>
<title value="处方单"/>
<section>
<!-- 文档审核过程,由谁审核等在此记录 -->
<title value="审核工作流记录"/>
</section>
<section>
<!-- 审方过程,由谁审核等在此记录 -->
<title value="审方工作流记录"/>
</section>
<section>
<!-- 药嘱清单,引用后续entry中列出的药嘱资源 -->
<title value="药嘱清单"/>
</section>
<section>
<!-- 收费清单,引用后续entry中列出的收费项目资源 -->
<title value="费用,含明细"/>
</section>
</Composition>
</resource>
</entry>
<!-- 患者 -->
<entry>
<resource>
<Patient/>
</resource>
</entry>
<!-- 就诊 -->
<entry>
<resource>
<Encounter>
<status></status>
</Encounter>
</resource>
</entry>
<!-- 药嘱清单,含多条药嘱 -->
<entry>
<resource>
<MedicationRequest>
<status></status>
<intent></intent>
<medication></medication>
<subject></subject>
</MedicationRequest>
</resource>
</entry>
<entry>
<resource>
<MedicationRequest>
<status></status>
<intent></intent>
<medication></medication>
<subject></subject>
</MedicationRequest>
</resource>
</entry>
<entry>
<resource>
<MedicationRequest>
<status></status>
<intent></intent>
<medication></medication>
<subject></subject>
</MedicationRequest>
</resource>
</entry>
<!-- 收费项清单,含多条收费项目 -->
<entry>
<resource>
<Claim>
<status></status>
<type></type>
<use></use>
<patient></patient>
<created></created>
</Claim>
</resource>
</entry>
<entry>
<resource>
<Claim>
<status></status>
<type></type>
<use></use>
<patient></patient>
<created></created>
</Claim>
</resource>
</entry>
<entry>
<resource>
<Claim>
<status></status>
<type></type>
<use></use>
<patient></patient>
<created></created>
</Claim>
</resource>
</entry>
<!-- 开方医师 -->
<entry>
<resource>
<Practitioner/>
</resource>
</entry>
<!-- 审方药师 -->
<entry>
<resource>
<Practitioner/>
</resource>
</entry>
</Bundle>
XMLXML
这样的文档本身就可以作为载荷通过消息进行传输。
当然,这些考虑也不过是一家之言,还需要更细致的讨论和定型,定义好本地所需的profile限定该类型方可实施。